Advanced Simulations #2018
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
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.
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.
The text was updated successfully, but these errors were encountered: