Wrong Execution Result using frontier hardfork #222
Comments
|
I believe the error is here: There must be check there, if it is before Homestead hardfork it should not fail after charge the code deposit. |
Lohann
changed the title
|
Yeah we unfortunately still had a few compliance issues in the current version, especially for older hard forks. We've been focusing on using this VM in production in Frontier (not to be confused with the frontier hardfork you referred 😄). So strict compliance wasn't necessary. I'm currently also addressing the compliance issue, developing a new version in the |
|
@sorpaas thx for the reply! I fixed this in PR: https://github.com/rust-blockchain/evm/pull/223/files So far so good, with this fix my client was able to synchronize up to 100k blocks from ethereum mainnet, I'll leave it sync and see if detect any other issues. About Frontier I had a lot of issues trying to integrate it with existing ethereum tools, even tough frontier goal is being a compatibility layer for substrate, It behaves completely different than the expect from a regular ethereum node, some examples: 1 - eth_getBalance returns the reducible balance instead the total balance, which is very weird because after transfering a given amount to an account, the 2 - It uses substrate state root instead the expected ethereum state root, which use blake2 instead keccak256 and have a completely different trie structure, because of that will be impossible to implement rpc methods like eth_getproof very important for ethereum light-clients. 3 - Block Timestamp is stored in milliseconds instead seconds, and the api converts it in seconds, which makes impossible to recompute the block hash and execute light-client txs locally like how helios does. |
|
I believe that by made this crate ethereum compliant, the number of contributors and attention to this project will increase, i liked the way the code is structured, is way cleaner than revm (which is mess and really hard to understand). If it is compliant, It has potential to be used in the Rust Ethereum Full-Node. |
|
Yeah there are some specific requirements we need. In particular, we need something really flexible -- we need to be able to implement custom gasometers (for custom PVF size calculation and stuff) as well as really customized backend logic. We unfortunately don't have another EVM at this moment able to do that -- all of them have the gasometer deeply intertwined with the interpreter. Usually people just fork an EVM implementation and change things there, but I really want something reusable that stays close to Ethereum main spec. The differences you mentioned regarding Frontier (the project) are compromises because certain things are just too different. It's possible to get around them (using child trie), but it's complicated, not yet available in Substrate, and probably not worth the effort. So unfortunately those annoying things will probably stay, because end users usually don't care. I wouldn't call the design currently in the |
Hey @Lohann revm author here, feedback is always welcomed and appreciated. My focus at the beginning of the last year was mostly on reth so I didn't have a lot of love/time for revm. This had changed as reth is stable and I have finally refactored a big chunk of the internals to be a lot better, exposed the handlers for internal logic override and made docs that explains how it works. You can read more on it here: https://twitter.com/rakitadragan/status/1745632344873030049 |
Crate version: v0.41.0
I was using this evm for syncing to ethereum mainnet, as sanity check I computed the state root using the VM and compared it against the expected state root, whoever I found a sync mismatch when processing this transaction at block 49018:
https://etherscan.io/tx/0x5c4fdc85bf5efdfcbf7d4991c37287a9c3d5b660b57b0082118c3cff3c69dff1
I was syncing using the correct preset Config::frontier, after a investigation I've found the cause of the issue.
Issue
The current implementation doesn't consider the pre EIP-2 contract creation behavior, I'll use this transaction as example: 0x5c4fdc85bf5efdfcbf7d4991c37287a9c3d5b660b57b0082118c3cff3c69dff1
Actual State Changes - incorrect
Hardfork: frontier
Gas used: 145029 (which is the transaction gas_limit)
Result: ExitError::OutOfGas
Not contract created.
Trace logs
Expected State Changes
Hardfork: frontier
Gas used: 125984
Result: Succeed(Returned)
Empty Contract Created at
0x630ea66c8c5dc205d45a978573fa86df5af1fe7aThe difference in the execution is that if there's no gas for paying the bytecode deposit
bytes.len() * 200, it must deploy an Empty Contract Account, which is the same as deploying a regular contract, but without the bytecode.For compute the state root I'm using this crate: https://docs.rs/trie-root/latest/trie_root/
The text was updated successfully, but these errors were encountered: