OnChain invalid timestamp block propagation fail
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- rust
- Bereich
- blockchain, networking
Rechercherichtung
Beginne mit core/verification/queue/mod.rs und der im Issue gezeigten verify()-Funktion. Stelle das Zeitstempelszenario block1/block2 mit den Nachrichten zu status, header response und body response nach und verfolge anschließend ready_signal sowie die Statusantwort des Zielknotens. Als erledigt gilt, dass der ungültige Block abgelehnt, der gültige Vorgänger verarbeitet und die erwartete Statusnachricht gesendet wird, ohne sich auf Logging-Anweisungen zu stützen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
There are some issues in sending invalid timestamp onChain blocks.
Below is a test scenario.
- Make block1 and block2.
- The timestamp in Block2's header should be invalid. Simply make it smaller than block1.
- Send a
status messagewith block2's hash as the bestHash. - Send a
header response messagewhich is [genesisHeader, block1Header, block2Header]. - Send a
body response message== [[], []], which is correspond to block1's body and block2's body. - Block is accepted from the target node only for block1. So the target node should send a status message with block1's hash as bestHash.(This is normal behaviour but it didn't)
And here are problems
- The target node does not send
status messageif in the above situation. However, if I insertedinfo!("55");then thestatus messagecome properly. - In below
verify()function in/core/verification/queue/mod.rs,Ok(verified)is returned twice although the block2 is invalid.
fn verify(
verification: Arc<Verification<K>>,
engine: Arc<CodeChainEngine>,
ready_signal: Arc<QueueSignal>,
empty: Arc<SCondvar>,
more_to_verify: Arc<SCondvar>,
_id: usize,
) {
loop {
// wait for work if empty.
{
let mut more_to_verify_mutex = verification.more_to_verify_mutex.lock().unwrap();
if verification.unverified.lock().is_empty() && verification.verifying.lock().is_empty() {
empty.notify_all();
}
while verification.unverified.lock().is_empty() {
more_to_verify_mutex = more_to_verify.wait(more_to_verify_mutex).unwrap();
}
}
// do work.
let item = {
// acquire these locks before getting the item to verify.
let mut unverified = verification.unverified.lock();
let mut verifying = verification.verifying.lock();
let item = match unverified.pop_front() {
Some(item) => item,
None => continue,
};
verification.sizes.unverified.fetch_sub(item.heap_size_of_children(), AtomicOrdering::SeqCst);
verifying.push_back(Verifying {
hash: item.hash(),
output: None,
});
item
};
let hash = item.hash();
let is_ready = match K::verify(item, &*engine, verification.check_seal) {
Ok(verified) => {
let mut verifying = verification.verifying.lock();
let mut idx = None;
for (i, e) in verifying.iter_mut().enumerate() {
if e.hash == hash {
idx = Some(i);
verification
.sizes
.verifying
.fetch_add(verified.heap_size_of_children(), AtomicOrdering::SeqCst);
e.output = Some(verified);
break
}
}
if idx == Some(0) {
// we're next!
let mut verified = verification.verified.lock();
let mut bad = verification.bad.lock();
VerificationQueue::drain_verifying(
&mut verifying,
&mut verified,
&mut bad,
&verification.sizes,
);
info!("111");
true
} else {
info!("222");
false
}
}
Err(_) => {
let mut verifying = verification.verifying.lock();
let mut verified = verification.verified.lock();
let mut bad = verification.bad.lock();
bad.insert(hash.clone());
verifying.retain(|e| e.hash != hash);
if verifying.front().map_or(false, |x| x.output.is_some()) {
VerificationQueue::drain_verifying(
&mut verifying,
&mut verified,
&mut bad,
&verification.sizes,
);
info!("33");
true
} else {
info!("44");
false
}
}
};
if is_ready {
info!("55");
// Import the block immediately
ready_signal.set_sync();
}
}
}
- Vorherrschende Sprache
- Rust
- Sterne
- 256
- Forks
- 50
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus CodeChain-io/codechain
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 25/100
CodeChain-io/codechain#2002 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
CodeChain-io/codechain#1993 · 2 Kommentare ·
-
Terminate gracefully Offen
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
CodeChain-io/codechain#1987 · 1 Kommentar ·
-
performance rpc
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
CodeChain-io/codechain#1973 ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100
CodeChain-io/codechain#1971 ·
Alle Issues in CodeChain-io/codechain
Ähnliche Issues
-
bug
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
yantrikos/yantrik-os#255 ·
-
bug CLI custom-model
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
raphamorim/rio#1956 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
rust-bitcoin/rust-bitcoin#6930 · 1 Kommentar ·