You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is eligible for a bounty paid out in ETH on OP Mainnet. Read CONTRIBUTING.md to learn how to qualify.
Some chains like zkSync and other zkEVMs compute addresses differently and/or use hash functions that are not keccak256. As a result, CREATE and/or CREATE2 addresses can differ between chains.
Similarly, different block structures or state representations can result in different merkle proofs/roots for the same data.
Not yet sure the best name for this section, or the best way to represent the data. To illustrate why this is tricky: Imagine two chains both compute the address of a contract deployed via CREATE2 by keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]. But one chain requires a custom solidity fork so the init code is different. The address computation is the same, but it's misleading to say "address calculation is the same" because in reality you won't get the same address due to the differing bytecode.
Maybe in this case we do things are the same, and we defer to a compilation/tooling section to explain the bytecode difference
The text was updated successfully, but these errors were encountered:
This issue is eligible for a bounty paid out in ETH on OP Mainnet. Read CONTRIBUTING.md to learn how to qualify.
Some chains like zkSync and other zkEVMs compute addresses differently and/or use hash functions that are not keccak256. As a result, CREATE and/or CREATE2 addresses can differ between chains.
Similarly, different block structures or state representations can result in different merkle proofs/roots for the same data.
Not yet sure the best name for this section, or the best way to represent the data. To illustrate why this is tricky: Imagine two chains both compute the address of a contract deployed via CREATE2 by
keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:]
. But one chain requires a custom solidity fork so the init code is different. The address computation is the same, but it's misleading to say "address calculation is the same" because in reality you won't get the same address due to the differing bytecode.Maybe in this case we do things are the same, and we defer to a compilation/tooling section to explain the bytecode difference
The text was updated successfully, but these errors were encountered: