-
Notifications
You must be signed in to change notification settings - Fork 4
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
consensus: save block metadata #646
Conversation
92aa008
to
7af6e38
Compare
7e329ef
to
c38d8f2
Compare
7af6e38
to
faf3cbd
Compare
09b62ae
to
79bdda4
Compare
f67bc7b
to
943a172
Compare
ffeb35d
to
04b1c2c
Compare
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.
Thank you thank you for figuring these out!
Generally LGTM. Most of my comments are about explaining the semantics to our API consumers (and to future nexus code maintainers).
@@ -66,6 +65,7 @@ require ( | |||
github.com/go-git/gcfg v1.5.1-0.20230307220236-3a3c6141e376 // indirect | |||
github.com/go-git/go-billy/v5 v5.5.0 // indirect | |||
github.com/go-git/go-git/v5 v5.11.0 // indirect | |||
github.com/go-kit/kit v0.12.0 // indirect |
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.
Do you understand how this was added? We're not using it directly, and the only other depedendency change is that cometbft went from being an implicit dep to an explicit one. Maybe Go only adds indirect deps when they are actually used, rather than all transitive deps?
04b1c2c
to
627e4d0
Compare
8457396
to
1e6aa7e
Compare
003826c
to
07fc1af
Compare
b44e84b
to
2487e50
Compare
640bdb7
to
89331f8
Compare
944e7a8
to
24cbe24
Compare
89331f8
to
d1f3ce3
Compare
24cbe24
to
8a8fbb1
Compare
d1f3ce3
to
5e9bbf1
Compare
dee5dc1
to
e0ea8d8
Compare
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.
Looks good! There's a few remaining comments from ptrus/mitja which need to be addressed, but hopefully those are minor changes. Thanks
0f3b539
to
aa9edaf
Compare
aa9edaf
to
0ba038a
Compare
|
||
ALTER TABLE chain.blocks | ||
ADD COLUMN proposer_entity_id base64_ed25519_pubkey, | ||
ADD COLUMN signer_entity_ids base64_ed25519_pubkey[]; |
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 was the reasoning for storing Entity IDs instead of Node IDs here?
A validator entity can have multiple validator nodes registered. In that case, we lose information about which exact node signed the block.
In practice, only a single node per entity will be active at any given epoch (since the network limits to one at this point), so this shouldn't be that problematic. However, I feel we could easily have used node IDs here to avoid this.
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.
Actually, it probably makes sense/is fine, since we mostly don't care about individual validator nodes in other places/in the API.
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.
yeah, it's for reasons of API simplicity like that. the general style of nexus is to have analysis precompute stuff that the API side will need, even sometimes at the cost of lossiness
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.
we mostly don't care about individual validator nodes in other places/in the API.
Yeah it was a combination of this, also because we don't track historical validator entity<>node mappings (though it is possible to add now in the history.validators
table).
block_hash HEX64 NOT NULL, | ||
time TIMESTAMP WITH TIME ZONE NOT NULL, | ||
num_txs UINT31 NOT NULL, | ||
block_hash HEX64 NOT NULL, -- NULL in 32_block_meta.up.sql |
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.
These comments are wrong 32_block_meta.up.sql
does not make these fields NULL
-able.
prevSigners = append(prevSigners, entity.String()) | ||
} | ||
batch.Queue( | ||
queries.ConsensusBlockAddSigners, |
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.
This doesn't work correctly in the fast-sync case. When in fast-sync, blocks are not processed in order, so the previous block (cmtMeta.LastCommit.Height
) might not exist, and therefore this query won't insert any singers.
Some quick suggestion on how to fix this:
- doing an Upsert, and making all other fields NULL-able (I think a previous version of this PR was done in that way)
- storing the signers in a separate table
I noticed this in E2E tests of #764 since some blocks are missing signers in the edenfast
test case.
proposer and signers