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

Advanced Simulations #2018

Open
joshstevens19 opened this issue Mar 28, 2023 · 2 comments
Open

Advanced Simulations #2018

joshstevens19 opened this issue Mar 28, 2023 · 2 comments
Labels
A-rpc Related to the RPC implementation C-enhancement New feature or request D-complex Quite challenging from either a design or technical perspective Ask for help! M-prevent-stale Prevents old inactive issues/PRs from being closed due to inactivity

Comments

@joshstevens19
Copy link
Contributor

joshstevens19 commented Mar 28, 2023

Describe the feature

Hello! I'm truly impressed by your work with reth keep it up guys.

Although the concept I am about to raise might appear unconventional, it has the potential to create a significant impact when executed effectively.

While transaction simulations play a crucial role in testing, they may not be as thoroughly explored in developing innovative module approaches for scalability and generating contestable proofs. In theory, signed transactions which never get sent (secured by deadlines and other measures to make them invalid past that block) can demonstrate that a submission would be approved on the blockchain without necessitating EVM state storage. This method offers numerous potential use cases. For example, storing an action in a data availability layer which is 1000x cheaper but still decentralised, you'd still be able to obtain execution state checks to confirm the transaction's success.

However, it can be challenging to conduct simulations across varying blocks and swiftly progress to another block without multiple RPC calls, given the slow nature of over-the-wire HTTP calls. As a result, it's difficult to validate both off-chain transactions concurrently (imagine many pointers done at different blocks offchain (1) > offchain (2) > offchain (3)), here you would want to check 1 and 2 before 3. Ideally, a single RPC call should enable the execution of an array of transactions with designated block numbers collectively, ensuring sequential processing of each transaction.

We could consider naming this method:

reth_simulateBatch

This function would receive an array of objects containing.

  • transaction
  • blockNumber/tag

And yield an array of data (same result as eth_call would give), it would execute the smallest block number first and go to the next block number once complete until all has been checked. This would not store any state changes just simulating the array of actions.

Such a feature could empower you to achieve remarkable things with reth that are otherwise unattainable with other nodes. Furthermore, it places a strong emphasis on speed, which is crucial in this context.

Anyway this is just a very high level brainstorm let me know your thoughts

Additional context

this may be possible with tenderly etc but I’m thinking of a free open source approach to this where you do not rely on a third party service.

Also wanted to note that ethereum state bloat is the biggest elephant in the room and these kind of approaches allow state to be stored outside ethereum but still with ability to prove it.

@joshstevens19 joshstevens19 added C-enhancement New feature or request S-needs-triage This issue needs to be labelled labels Mar 28, 2023
@ape-dev-cs
Copy link

Just for visibility, there's a FOSS implementation here which uses reth which does something very similar to what you describe: https://github.com/EnsoFinance/transaction-simulator/

@onbjerg onbjerg added A-rpc Related to the RPC implementation D-complex Quite challenging from either a design or technical perspective Ask for help! and removed S-needs-triage This issue needs to be labelled labels Jul 3, 2023
@github-actions
Copy link
Contributor

This issue is stale because it has been open for 14 days with no activity.

@github-actions github-actions bot added the S-stale This issue/PR is stale and will close with no further activity label Aug 27, 2023
@mattsse mattsse added M-prevent-stale Prevents old inactive issues/PRs from being closed due to inactivity and removed S-stale This issue/PR is stale and will close with no further activity labels Aug 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rpc Related to the RPC implementation C-enhancement New feature or request D-complex Quite challenging from either a design or technical perspective Ask for help! M-prevent-stale Prevents old inactive issues/PRs from being closed due to inactivity
Projects
Status: Todo
Development

No branches or pull requests

4 participants