-
Notifications
You must be signed in to change notification settings - Fork 69
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
IF: use the same way to determine if instant finality is active #2043
Conversation
libraries/chain/controller.cpp
Outdated
trx_mroot = calculate_trx_merkle( b->transactions, !hs_active ); | ||
EOS_ASSERT( b->transaction_mroot == trx_mroot, block_validate_exception, | ||
"invalid block transaction merkle root ${b} != ${c}", ("b", b->transaction_mroot)("c", trx_mroot) ); | ||
} |
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 opens up an attack vector as you can create a block with invalid mroot that will pass this validation. I think we can go with your first implementation. There is a small race condition at time of activation, but even if that is tripped and the block is considered invalid, the node will attempt to sync the block in the future and succeed; that is what I meant by re-try.
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.
Thanks for your insight!
Note:start |
#2028 reports
transaction_mroot
difference between when it is first calculated and when it is recreated increate_block_state_i
. The difference is caused by the way howhs_active
is determined for mroot calculation. Whentransaction_mroot
is first created,hs_lib > 0
is used as an indication ofhs_active
; increate_block_state_i
, only presence ofinstant_finality_extension
is used.This inconsistency causes integration test failures too.
This PR changes to use the same
hs_lib > 0
as the indication.Resolved #2028