-
Notifications
You must be signed in to change notification settings - Fork 429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Message index/count refactor - Part 1 #2535
base: master
Are you sure you want to change the base?
Conversation
// messages are 0-indexed | ||
type MessageIndex uint64 | ||
|
||
func BlockNumberToMessageCount(blockNumber uint64, genesisBlockNumber uint64) MessageIndex { | ||
return MessageIndex(blockNumber + 1 - genesisBlockNumber) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about having a single type that represents the position which is what you pass around, and then having accessors for .Index()
and .Count()
?
You could even wrap it like this so you don't accidentally do some illegal operation with it.
type MessageIndex struct {
inner uint64
}
I'm interested to hear others' thoughts too on this part of the PR since it's the core of the design.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But what is the meaning of .Count()
?
Is it the current length of the messages container, the length of the messages container that the caller expects, or just .Index() + 1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
initial thoughts
eb469ab
to
7f76867
Compare
…h receives msgIdx instead of msgCount
…tch and AddMessages
…r and refactors it.
…MessageFromSequencer
…Streamer.addMessagesAndReorg
Resolve NIT-2569
Different parts of Nitro (TransactionStreamer, InboxTracker, ExecutionEngine, Broadcaster, BlockValidator, etc), need to access the number of messages, or the content of a message, or the result related to processing a message.
Those properties are accessed in different ways through Nitro's code base, decreasing code readability.
Examples:
pos
,num
,seq
,index
.While reading the code base it is not uncommon to confuse what is the semantic meaning of a variable, such as if it is holding the number of messages, or a message identifier.
This PR is the first part of a refactor that unifies how properties related to messages are accessed through Nitro.
This PR mainly focus on refactoring TransactionStreamer, ExecutionEngine and Broadcaster.
It decreases message count usage in favor of using message indexes, such as declaring
func (n *ExecutionNode) Reorg(newHeadMsgIdx arbutil.MessageIndex, ...
, instead offunc (n *ExecutionNode) Reorg(count arbutil.MessageIndex, ...
.It names message indexes identifiers as
msgIdx
.If the approach of this PR is approved, then later more PRs are going to be created with the following goals: