state_processor: remove the whitelist deployer check in applyTransaction #363
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We need to update the check in applyTransaction to support the whitelist deployer version 2. However, since we move the whitelist deployer check to the later Create operation to cover both CREATE2/CREATE opcode and contract deploy transaction, this check is not necessary anymore. Does removing this check create backward incompatibility (cannot sync from genesis)? The backward incompatability happens only when the old transactions does not pass the check and when running with newer Ronin version, it passes because we remove the check. However, this is not the case here, as the error in applyTransaction means the transaction is not included into the block.
DNK90
approved these changes
Oct 3, 2023
minh-bq
added a commit
that referenced
this pull request
Oct 4, 2023
…ion (#363) We need to update the check in applyTransaction to support the whitelist deployer version 2. However, since we move the whitelist deployer check to the later Create operation to cover both CREATE2/CREATE opcode and contract deploy transaction, this check is not necessary anymore. Does removing this check create backward incompatibility (cannot sync from genesis)? The backward incompatability happens only when the old transactions does not pass the check and when running with newer Ronin version, it passes because we remove the check. However, this is not the case here, as the error in applyTransaction means the transaction is not included into the block.
andicrypt
pushed a commit
to andicrypt/ronin
that referenced
this pull request
Nov 1, 2023
…ion (axieinfinity#363) We need to update the check in applyTransaction to support the whitelist deployer version 2. However, since we move the whitelist deployer check to the later Create operation to cover both CREATE2/CREATE opcode and contract deploy transaction, this check is not necessary anymore. Does removing this check create backward incompatibility (cannot sync from genesis)? The backward incompatability happens only when the old transactions does not pass the check and when running with newer Ronin version, it passes because we remove the check. However, this is not the case here, as the error in applyTransaction means the transaction is not included into the block.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We need to update the check in applyTransaction to support the whitelist deployer version 2. However, since we move the whitelist deployer check to the later Create operation to cover both CREATE2/CREATE opcode and contract deploy transaction, this check is not necessary anymore.
Does removing this check create backward incompatibility (cannot sync from genesis)?
The backward incompatability happens only when the old transactions does not pass the check and when running with newer Ronin version, it passes because we remove the check. However, this is not the case here, as the error in applyTransaction means the transaction is not included into the block.