Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
adr-11-centralized-sequencer.md
Outdated
| We implement a standalone centralized sequencer that: | ||
|
|
||
| 1. Implements the Generic Sequencer interface from the `go-sequencing` package | ||
| 2. Exposes a gRPC service for rollup clients to submit transactions |
There was a problem hiding this comment.
this isnt the case with execution api anymore right?
There was a problem hiding this comment.
Yes, not the case once we move this code back into Rollkit
adr-11-centralized-sequencer.md
Outdated
| batchTime time.Duration | ||
| bq *BatchQueue | ||
| lastBatchHash []byte | ||
| seenBatches map[string]struct{} |
There was a problem hiding this comment.
what is the reason to keep seen batches here?
There was a problem hiding this comment.
The seenBatches map is more so relevant to a verifying full node to know whether a batch was successfully published to DA or not. My understanding is this structure is equivalent to the dataCache type in Rollkit. We can get rid of it in favor of dataCache which seems like isn't currently used in Rollkit
There was a problem hiding this comment.
we dont verify in the sequencer as well. we just pull from the queue and pass it to be executed. is there an open issue for verification?
adr-11-centralized-sequencer.md
Outdated
| seenBatches map[string]struct{} | ||
| seenBatchesMutex sync.RWMutex | ||
| metrics *Metrics | ||
| db *badger.DB |
There was a problem hiding this comment.
do we need this to have storage?
There was a problem hiding this comment.
The only reason to have storage currently is to keep track of the last batch hash, which is needed when a rollkit node is restarted. We can store this in Rollkit's store instead to make the centralized sequencer stateless
There was a problem hiding this comment.
make sense, in the current design we store lots of other things, would these things be removed as well and stored in rollkit?
tac0turtle
left a comment
There was a problem hiding this comment.
left some comments, it would be good to understand how the sequencer can move faster than the DA layer or in tandem
Co-authored-by: Marko <marko@baricevic.me>
|
|
||
| rollupId sequencing.RollupId // Identifier for the rollup this sequencer serves | ||
|
|
||
| tq *TransactionQueue // Queue for storing pending transactions |
There was a problem hiding this comment.
do we need this if we fire off as soon as we get the data? also should rollkit construct batches instead of the sequencer, well they are the same thing or will be with the changes
There was a problem hiding this comment.
I don't see a strong reason to have this either. Thinking that with the new changes, for a centralized sequencer setting, we should just default to the pre-separation code.
cc: @gupadhyaya
There was a problem hiding this comment.
rollkit relays transactions as they gets into mempool. centralized sequencer needs a place to collect transactions and prepare batch at the batch interval (could be 1s or 2s, etc). hence the transaction queue. while the centralized sequencer and rollkit node are same but different processes, you don't want the sequencer to directly access mempool right? if you don't store it, will you create batch for every transaction? (i know with api change of submitting []Tx instead of single Tx via SubmitRollupTxs api, still you could fit in multiple sets of txs (relayed via multiple SubmitRollupTxs calls) into a single batch. queue is convenient, but open to any other ways to handle this.
There was a problem hiding this comment.
Would it not work that ordering is done by the aggregator execution env and we just getTxs() and submit that? what extra ordering is there?
| lastBatchHash []byte // Hash of the last processed batch | ||
| lastBatchHashMutex sync.RWMutex // Mutex for thread-safe access to lastBatchHash |
There was a problem hiding this comment.
are there multiple callers updating this? what is the reason for the mutex? seems expensive if there is only one updater
There was a problem hiding this comment.
you can get rid of mutex. only one caller (header producer of rollkit)
| seenBatches map[string]struct{} // Map to track batches that have been processed | ||
| seenBatchesMutex sync.Mutex // Mutex for thread-safe access to seenBatches |
There was a problem hiding this comment.
for the batch producer the verifybatch is basically return true, hence you can get rid of this alltogether.
| - Similar to the other methods, it first validates the rollup ID. | ||
| - It then checks if the provided batch hash exists in the internal data structure that tracks seen batches. | ||
| - If the batch hash is found, it returns a response indicating that the batch is valid. If not, it returns a response indicating that the batch is invalid. | ||
|
|
There was a problem hiding this comment.
should we add a TODO here? Currently VerifyBatch only does a quick verification of the batch hash exist in the seenBatches, however in the future, it is expected to perform the full DA verification where the batch submitted to DA as referenced using a DA height and VerifyBatch would query the DA at the referenced height to verify that the batch exists in DA.
There was a problem hiding this comment.
would this be what the pending header system would work off of.
There was a problem hiding this comment.
pending headers in rollkit is different. the verifybatch is for transaction batches.
verifyBatch for the batch producer (which is rollkit's header producer) is basically return true
for fullnodes, it needs to provide a stateless verification, meaning the verification is done using the DA
|
|
||
| This method should be looking at the DA layer to update its view of which batches have been published. | ||
|
|
||
| These methods work together to ensure that the centralized sequencer can effectively manage transaction submissions, retrievals, and verifications, providing a reliable interface for rollup clients to interact with the sequencer. |
There was a problem hiding this comment.
should we add something about the batch submission loop?
The centralized sequencer runs a batch submission loop at the batch timer interval which prepares a batch and submits it to DA. The batch timer is configurable.
|
closing this and bringing it into my pr, ill update it there |
Overview