Add new inbox multiplexer abstraction including delayed messages#6
Add new inbox multiplexer abstraction including delayed messages#6PlasmaPower merged 11 commits intoblock-creationfrom
Conversation
| msg := &arbos.L1IncomingMessage{ | ||
| Header: &arbos.L1IncomingMessageHeader{ | ||
| Kind: arbos.L1MessageType_L2Message, | ||
| Sender: sequencerAddress, |
There was a problem hiding this comment.
Could we include the sender address in the sequencer message to avoid needing it here. Otherwise we'll need access to the state db here
There was a problem hiding this comment.
Hmm.. I was actually thinking the opposite, as this makes having multiple sequencer (batch poster?) addresses easier. Then again, maybe that isn't needed.
There was a problem hiding this comment.
Ah interesting. Let's discuss this in standup maybe
cmd/replay/inbox.go
Outdated
| var requestId common.Hash | ||
| requestId[0] = 1 << 6 | ||
| binary.LittleEndian.PutUint64(requestId[(32-16):(32-8)], wavmio.GetInboxPosition()) | ||
| binary.LittleEndian.PutUint64(requestId[(32-8):], segmentNum) |
There was a problem hiding this comment.
We should consider doing something more like the accumulator system we had in place before. Not sure if it's worth it, but potentially we should add a todo here to revisit that question later
There was a problem hiding this comment.
I'm not sure why that'd be helpful? Even in the previous system I think the request id was based on sequence number.
arbos/block_processor.go
Outdated
| for _, segment := range segments { | ||
| for _, tx := range segment.txes { | ||
| if tx.Gas() > perBlockGasLimit || tx.Gas() > b.gasPool.Gas() { | ||
| // Ignore and transactions with higher than the max possible gas |
There was a problem hiding this comment.
Looks like you removed the logic I had added in 969e985 to allow for the partial reading of a set of txes from a segment. Was that intentional?
There was a problem hiding this comment.
Yeah, I doubt it's worth the complexity, and I'm using the nonce field for delayed message count now. But we can put it in another field if it has significant value. I'm just not sure there's that much of a use case.
Finish implementing remaining ibinops, irelops, and a few others
Add message inbox functionalities
feat: add maximumCachedTime parameter to updateTimerCache calls
No description provided.