Skip to content
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

Verify block id as part of block header validation for savanna blocks #730

Open
heifner opened this issue Sep 9, 2024 · 5 comments
Open
Assignees

Comments

@heifner
Copy link
Member

heifner commented Sep 9, 2024

For legacy blocks, the block id can't be verified until the action_mroot (merkle root of action receipts) is calculated which requires applying the transactions. For Savanna blocks the action_mroot is the finality_mroot (merkle root of the finality tree) which is known before applying the transactions.

For savanna blocks, verify the block id as part of block header validation.

@enf-ci-bot enf-ci-bot moved this to Todo in Team Backlog Sep 9, 2024
@arhag arhag added 👍 lgtm and removed triage labels Sep 9, 2024
@arhag arhag added this to the Spring v1.1.0-rc1 milestone Sep 9, 2024
@linh2931 linh2931 self-assigned this Sep 30, 2024
@linh2931 linh2931 moved this from Todo to In Progress in Team Backlog Sep 30, 2024
@linh2931
Copy link
Member

What about transaction_mroot? It is a part of block ID. It is unknown until transactions are applied.

@heifner
Copy link
Member Author

heifner commented Sep 30, 2024

What about transaction_mroot? It is a part of block ID. It is unknown until transactions are applied.

It is known before they are applied, see: https://github.com/AntelopeIO/spring/blob/main/libraries/chain/controller.cpp#L4127

@linh2931
Copy link
Member

Thanks. I was looking at the transaction_mroot for producing.

@linh2931
Copy link
Member

linh2931 commented Oct 4, 2024

finality_mroot is known after valid structure built. To build valid structure, we need action_mroot (not the one in the header but the merkle root of action receipts)

valid_t block_state::new_valid(const block_header_state& next_bhs, const digest_type& action_mroot, const digest_type& strong_digest) const {

It is only available after transactions are applied. That's why 2 stages are currently used (step 7 in the Changes Required section): AntelopeIO/leap#2080.

Currently finality_tree root is checked by

EOS_ASSERT(bsp->finality_mroot() == actual_finality_mroot,

block id is checked by
EOS_ASSERT(producer_block_id == ab.id(), block_validate_exception, "Block ID does not match, ${producer_block_id} != ${validator_block_id}",

Not sure if we can move the checks any earlier.

I also think the following check is unnecessary as it uses the same value to check itself

EOS_ASSERT( id == bsp->id(), block_validate_exception,

@linh2931
Copy link
Member

linh2931 commented Oct 7, 2024

But we can verify action_mroot (Finality Tree Root) as early as in verify_basic_proper_block_invariants(). I will do that.

@linh2931 linh2931 moved this from In Progress to Blocked in Team Backlog Oct 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Blocked
Development

No branches or pull requests

4 participants