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

fix: put CommittedTransaction::error in block hash #5095

Closed
wants to merge 1 commit into from

Conversation

Erigara
Copy link
Contributor

@Erigara Erigara commented Sep 23, 2024

Context

Error in CommittedTransaction was not reflected in the block hash which allowed for this value to be tempered result in block false rejection.

Closes #5001.

Solution

Include error in block hash calculation.

@Erigara Erigara self-assigned this Sep 23, 2024
@github-actions github-actions bot added the api-changes Changes in the API for client libraries label Sep 23, 2024
@mversic
Copy link
Contributor

mversic commented Sep 23, 2024

we specifically don't want to do this. This stands in the way of #4967 as noted here and there is no reason to do this because it has no effect on blockchain integrity

@mversic
Copy link
Contributor

mversic commented Sep 23, 2024

in other words, it's important that we don't include CommittedTransaction::error in block hash or signature so that leader can send block before validation and update that value afterwards

@mversic mversic self-assigned this Sep 23, 2024
@Erigara
Copy link
Contributor Author

Erigara commented Sep 23, 2024

it has no effect on blockchain integrity

i think by checking this error we can assure that peers are on the same page at least to some extent (they all agree on outcome of each transaction in the block)

@mversic
Copy link
Contributor

mversic commented Sep 23, 2024

it has no effect on blockchain integrity

i think by checking this error we can assure that peers are on the same page at least to some extent (they all agree on outcome of each transaction in the block)

we can do this without making this value a part of the block hash. The same way we circulate some other messages between peers

however, if leader will not categorize instructions (for performance reasons), what good is this to us since there is no value to be agreed upon? In the case of block sync, yes we can reject the block if the value is incorrect. But we still don't have to protect the value with a hash

@Erigara
Copy link
Contributor Author

Erigara commented Sep 24, 2024

what good is this to us since there is no value to be agreed upon?

not sure i got your point but, if we don't somehow check result of block execution peers have a risk of silently diverge

@mversic
Copy link
Contributor

mversic commented Sep 24, 2024

what good is this to us since there is no value to be agreed upon?

not sure i got your point but, if we don't somehow check result of block execution peers have a risk of silently diverge

I'm talking in the context of #4967 where we don't categorize transactions ahead of time. I don't see how we can have both.

@Erigara
Copy link
Contributor Author

Erigara commented Sep 27, 2024

Will update after merge of #4967

@Erigara Erigara closed this Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api-changes Changes in the API for client libraries
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CommittedTransaction::error is not part of the block hash
2 participants