Conversation
| #[derive(Default)] | ||
| pub struct Pipeline { | ||
| stages: Vec<QueuedStage>, | ||
| unwind_to: Option<U64>, |
There was a problem hiding this comment.
Can just call unwind directly
| stages: Vec<QueuedStage>, | ||
| unwind_to: Option<U64>, | ||
| max_block: Option<U64>, | ||
| exit_after_sync: bool, |
There was a problem hiding this comment.
Essentially the same as max_block so I just deduplicated
| let mut unwind_pipeline = { | ||
| let mut stages: Vec<_> = self.stages.iter_mut().enumerate().collect(); | ||
| stages.sort_by_key(|(id, stage)| { | ||
| if stage.unwind_priority > 0 { | ||
| (id - stage.unwind_priority, 0) | ||
| } else { | ||
| (*id, 1) | ||
| } | ||
| }); | ||
| stages.reverse(); | ||
| stages | ||
| }; |
There was a problem hiding this comment.
there is a possible overflow since id & unwind_priority are usizes. in general, the sorting here is a bit confusing. let's say, we have the queue of [stage1, stage2, stage3, stage4] and we want the resulting unwind queue to be [stage4, stage1, stage2, stage3], so we assign priorities stage3 - 1, stage2 - 2, stage1 - 3. if we were to add stage5 at arbitrary place, wouldn't we need to modify all of the existing priorities?
There was a problem hiding this comment.
That's correct. I've been thinking about a better way to do this as well
| rx.send(PipelineEvent::Ran { stage_id, result: None }).await? | ||
| } | ||
|
|
||
| return Err(e) |
There was a problem hiding this comment.
hmm, any additional error handling we'd need to do here? just making sure that if it's a fatal error, on next restart the pipeline should recover the previous state from the db
There was a problem hiding this comment.
We should never encounter fatal errors that result in unwinds, those are bugs that we should fix as it alludes to something major has gone wrong. If an unwind is necessary the stage should specify that
If we encounter this branch then the current transaction is aborted, so it will sync from the point where the transaction was committed last. If we want to go further back than that then I'm not sure how we would determine that without the stage telling us since we don't track a history of stage progress
mattsse
left a comment
There was a problem hiding this comment.
I'm lacking a bit of context here and it's not obvious what the pipeline does.
crates/stages/src/lib.rs
Outdated
| @@ -60,18 +62,15 @@ pub enum StageError { | |||
| /// | |||
| /// TODO: This depends on the consensus engine and should include the validation failure reason | |||
| #[error("Stage encountered a validation error.")] | |||
There was a problem hiding this comment.
include block number in error?
| stage: Box<dyn Stage<'db, E>>, | ||
| /// The unwind priority of the stage. | ||
| unwind_priority: usize, | ||
| /// Whether or not this stage can only execute when we reach what we believe to be the tip of |
There was a problem hiding this comment.
Unsure what this refers to, it doesn't say tip of tip?
There was a problem hiding this comment.
there's another tip on the next line -.-
github annotations for unchanged lines could use some work
| /// Create a new pipeline. | ||
| pub fn new() -> Self { | ||
| Default::default() | ||
| } |
There was a problem hiding this comment.
redundant new, can just use default
| .map_or(false, |(progress, target)| progress >= target); | ||
|
|
||
| // Execute stage | ||
| let output = async { |
There was a problem hiding this comment.
does it make sense to move this to a separate function?
There was a problem hiding this comment.
Unsure, it won't really be used outside of this loop. If you just want to execute a stage directly you would call Stage::execute
Do you have ideas for how to improve the rustdoc then? It just executes the stages serially, and once it has looped through all of them, it executes them again. It's the main driver in staged syncing. If a stage encounters a validation error, it unwinds the stages in reverse order and syncs again. That's all it does |
mattsse
left a comment
There was a problem hiding this comment.
I see, was just lacking the context on Pipeline/Stage in general.
should merge and iterate over with follow ups?
|
Yeah let's merge and think of a better unwind priority system |
…ve-import chore(executor): removed useless import
Resolution checkpoint Resolution checkpoint paradigmxyz#2 Resolution checkpoint paradigmxyz#3 x Resolution checkpoint paradigmxyz#4 Resolution checkpoint paradigmxyz#5 Resolution checkpoint paradigmxyz#6 Resolution checkpoint paradigmxyz#7 Resolution checkpoint paradigmxyz#8 Resolve checkpoint paradigmxyz#9 (transaction primitive) Resolve checkpoint paradigmxyz#10 (rpc api transactions) Resolve checkpoint paradigmxyz#11 (building w/o feature flag) Start review Compiling with and without `optimism` feature flag Remove `DepositTx` from txpool mock tests, they never go into the txpool fmt code lint fix signature tests Co-authored-by: nicolas <48695862+merklefruit@users.noreply.github.com> Use free CI runners (revert before upstream) Co-authored-by: refcell <abigger87@gmail.com> Signature test fixes Co-authored-by refcell <abigger87@gmail.com> Fix Receipt proptest Co-authored-by BB <brian.t.bland@gmail.com> lint Fix variable-length compact for txtype/transaction Co-authored-by: Brian Bland <brian.t.bland@gmail.com> Fix basefee tests Remove unnecessary rpc deps Co-authored-by: Brian Bland <brian.t.bland@gmail.com> Co-authored-by: refcell <abigger87@gmail.com> Co-authored-by: nicolas <48695862+merklefruit@users.noreply.github.com> Co-authored-by: Roberto <bayardo@alum.mit.edu>
Resolution checkpoint Resolution checkpoint paradigmxyz#2 Resolution checkpoint paradigmxyz#3 x Resolution checkpoint paradigmxyz#4 Resolution checkpoint paradigmxyz#5 Resolution checkpoint paradigmxyz#6 Resolution checkpoint paradigmxyz#7 Resolution checkpoint paradigmxyz#8 Resolve checkpoint paradigmxyz#9 (transaction primitive) Resolve checkpoint paradigmxyz#10 (rpc api transactions) Resolve checkpoint paradigmxyz#11 (building w/o feature flag) Start review Compiling with and without `optimism` feature flag Remove `DepositTx` from txpool mock tests, they never go into the txpool fmt code lint fix signature tests Co-authored-by: nicolas <48695862+merklefruit@users.noreply.github.com> Use free CI runners (revert before upstream) Co-authored-by: refcell <abigger87@gmail.com> Signature test fixes Co-authored-by refcell <abigger87@gmail.com> Fix Receipt proptest Co-authored-by BB <brian.t.bland@gmail.com> lint Fix variable-length compact for txtype/transaction Co-authored-by: Brian Bland <brian.t.bland@gmail.com> Fix basefee tests Remove unnecessary rpc deps Co-authored-by: Brian Bland <brian.t.bland@gmail.com> Co-authored-by: refcell <abigger87@gmail.com> Co-authored-by: nicolas <48695862+merklefruit@users.noreply.github.com> Co-authored-by: Roberto <bayardo@alum.mit.edu>
* feat: support opBNB * chore: update revm * fix: merge conflicts * feat: add opbnb features * chore: fix fmt * fixup! chore: fix fmt * fix: add opbnb features to more code spaces * feat: add mgasps log * ci: change ut runner to github official provided * fix: mgas ps log * ci: fix unit, integration test job * fix: revm spec dispatcher * chore: update revm * fix: add fermat fork timestamp to fix revm init * update revm and alloy-chain version --------- Co-authored-by: j75689 <j75689@gmail.com> Co-authored-by: Keefe Liu <keefe.l@users.noreply.github.com>
Add pre-round context to next round execution
Add pre-round context to next round execution
add missing import
…gmxyz#10) Implement padded Falcon-512 signature verification precompile using pqcrypto-falcon library for post-quantum cryptographic security. Changes: - Add FALCON_PRECOMPILE_ADDRESS at 0x540000 (Tectonic address space) - Implement falcon_verify with 897-byte pubkey + 666-byte signature + variablre message ABI - Set conservative gas pricing: 1200 base + 12/word (40% of ecrecover base cost) - Benchmark suite vs ecrecover baseline Performance: ~17.6µs verification (6.4x faster than ecrecover @ 114.0µs) Gas cost rationale: EIP-7592 pricing model based on 2.7x speedup minimum
Implements the execution and unwinding loops of the pipeline. The saving/loading of stage progress is also implemented, although it's not nice to look at w/o db abstractions