Support pending moves on EVM chains #6
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This implements Solidity contracts that we will use with an eth_call state overlay to instrument the XayaAccounts contract, so that we can extract the moves generated from pending transactions. The TrackingAccounts contract will be laid over the real XayaAccounts contract deployed on-chain, and the CallForwarder contract will be laid over the sender's EOA address.
This adds support for tracking pending moves on EVM chains. Extracting predicted log events for pending transactions is actually non-trivial. The implementation here uses eth_call to simulate each transaction received (can be limited to just transactions on our contract in the future). geth's state overlays with eth_call are used to instrument the accounts contract so that we can actually return all moves afterwards from the call.
This introduces a whitelist of contract addresses, where only transactions to a whitelisted address actually gets simulated with eth_call to look for pending moves. While this might miss some moves (e.g. from custom-deployed contracts), it ensures that the large majority of transactions on the network, which are not related to Xaya at all, will get quickly ignored.
This adds support for retrieving the mempool content on EVM chains (as is needed for "getrawmempool", which in turn is used as part of pending tracking by libxayagame). We could have used txpool_content to directly mimic Xaya Core's RPC, but this has two drawbacks: First it is a geth extension and one that is not readily available for some interfaces (and not even enabled by default in geth), and second this is highly inefficient if we expect most transactions to be unrelated to Xaya. Thus instead, we keep track of our own "mempool" based on transactions received from notifications, and we use a batched eth_getTransactionByHash call to synchronise this with the underlying node whenever needed.
|
Note that this needs support for the |
domob1812
added a commit
that referenced
this pull request
Apr 21, 2022
Support pending moves on EVM chains
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements support for pending moves on EVM chains. That is quite non-trivial to do, as there is no direct way to retrieve "predicted" events for pending transactions. To work around this, we use a
gethfeature foreth_callthat allows overriding state for a transaction simulation:eth_callto simulate a particular pending transaction and get all emitted move events in return.Xaya X now has a "whitelist" of contracts that are likely to send move events. Every pending transaction calling one of them will be simulated as described, and all emitted events processed as potential pending moves (that get then fed into the GSP).