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

feat: add support for async transaction execution #1439

Merged
merged 2 commits into from
Sep 12, 2024

Conversation

morph-dev
Copy link
Collaborator

What was wrong?

The trin-execution doesn't support async block/transaction execution. This is needed if we want to use state network to execute transactions (e.g. eth_call, eth_estimateGas).

How was it fixed?

Created AsyncDatabase trait and added support for using it in order to execute transactions.

Some refactoring of the trin-execution crate:

  • moved some files into evm module
  • extracted shared logic (creating BlockEnv, creating Evm with/without tracer) into separate functions (simplifying BlockExecutor a bit)

To-Do

@morph-dev morph-dev added the state network Issue related to portal state network label Sep 11, 2024
@morph-dev morph-dev added this to the Devcon 2024 milestone Sep 11, 2024
@morph-dev morph-dev self-assigned this Sep 11, 2024
@morph-dev
Copy link
Collaborator Author

@KolbyML, I didn't do any end-to-end testing to make sure that trin-execution still works. Any recommended way to do it quickly (quickly in the sense that it doesn't take days to run it)?

@KolbyML
Copy link
Member

KolbyML commented Sep 11, 2024

@KolbyML, I didn't do any end-to-end testing to make sure that trin-execution still works. Any recommended way to do it quickly (quickly in the sense that it doesn't take days to run it)?

if you run cargo run -p trin-execution --release, it should be able to execute the first million or 2 blocks in 2 hours or something, I haven't executed the dos attack in a while so we might not execute it in 1 go anymore which would make things much slower

Copy link
Member

@KolbyML KolbyML left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit: looks mostly good, one concern with how mix_hash is used because the way the code is written, it wouldn't match the code before this PR in that, it would set BlockEnv::prevrandao to Some() for pre-merge blocks, where before this PR we had a specifically set it to None for pre-merge blocks.

Maybe this might be fine, and Revm is smart enough to ignore this, but I think we should re-add the if merge {} check for BlockEnv::prevrandao, for sanity sake.

gas_limit: header.gas_limit,
basefee: header.base_fee_per_gas.unwrap_or_default(),
difficulty: header.difficulty,
prevrandao: header.mix_hash,
Copy link
Member

@KolbyML KolbyML Sep 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

prevrandao: header.mix_hash, I believe we should still be checking if we are past the Merge for prevrandao.

mix_hash won't be none in pre-merge blocks, it was used in PoW mining. Maybe it will be fine? but I would rather not take chances

For difficulty I think what you did is fine as the processed header should always have the right difficulty

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't know that header.mix_hash won't be none pre-merge. I fixed it.

@KolbyML
Copy link
Member

KolbyML commented Sep 11, 2024

@KolbyML, I didn't do any end-to-end testing to make sure that trin-execution still works. Any recommended way to do it quickly (quickly in the sense that it doesn't take days to run it)?

I think one of the best ways would be to tap into existing EL testing infrastructure, but that would require us to build a lot of EL infrastructure out such as the JSON-RPC, and maybe command line arguments, I haven't fully looked into the process of this.

For now with our limit scope being state bridging (for the time being), just running Trin execution might be the best solution for the time being, like I gave an example for above

@morph-dev
Copy link
Collaborator Author

if you run cargo run -p trin-execution --release, it should be able to execute the first million or 2 blocks in 2 hours or something, I haven't executed the dos attack in a while so we might not execute it in 1 go anymore which would make things much slower

I will let it run over night and merge in the morning if everything looks ok.

@morph-dev
Copy link
Collaborator Author

I will let it run over night and merge in the morning if everything looks ok.

It managed to process 3'981'311 blocks, but then it failed because it panicked while deserializing era1 file.
I downloaded problematic file and deserialization worked fine, so I assume that there was some network issue and somehow wrong file (bytes) was downloaded. Should we add hash check and retry to prevent this in the future?

Then I tried to resume execution (from the latest saved checkpoint - block 3'700'003), but that one failed. This was also not caused by this PR. I investigated it and figure out the problem (see #1440). I managed to fix the issue locally (in a bit hacky way), and I was able to continue execution.

Execution is still running, it passed 4'400'000 as I'm writing this. I will consider this a successful test, at least in regard to this PR, and I will merge it now.

@morph-dev morph-dev merged commit aab46ab into ethereum:master Sep 12, 2024
9 checks passed
@morph-dev morph-dev deleted the eth_call_2 branch September 12, 2024 08:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state network Issue related to portal state network
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants