Open VictorTrustyDev opened 7 months ago
WIP!!!
Problems need to be solved:
stateRoot
(a.k.a AppHash on Cosmos) needed to compute ETH-block hash: can not be obtained during block execution => Append on next block, during ABCI BeginBlock
event.x/evm
new design relates to store & module:
Module ABCI events:
eth_getBlockByNumber
?)EndBlock
transactions
(many bytes, MarshalBinary
will truncates data WARNING)receipts
(which include logs) (many bytes, MarshalBinary
will truncates data WARNING)transactionsRoot
(32 bytes)receiptRoots
(32 bytes)blockBloom
(256 bytes)miner
(optional, 20 bytes, target: no need to fetch tm BlockResult and ResultBlockResults)gasLimit
(optional, 8 bytes, target: no need to fetch tm ConsensusParams)gasUsed
is the final cummulative gas (8 bytes)timestamp
(optional, 8 bytes, target: no need to fetch tm BlockResult.Header)Store:
By using fixed key for new stores, data is prune-able on prune-nodes.
Events:
x/evm
's events. (I bet this cost more than storing new values on x/evm
since txs and receipts are truncated by MarshalBinary
while events are Json-text)New specs:
stateRoot
is clearly visible, thus enough input for computing ETH block hash.RPC endpoints are targeted to only fetch from
x/evm
store for block header & information, one query, one readEVMTxIndexer:
EthBlockIndexer
with since, I guess, the indexing and store will change alotBackward compatible:
Unknown result:
Spec changed by the spec defined in 2nd post (above):
Problem: RPC is complex with fetching data from everywhere in order to build response for Json-RPC queries. That can down performance.
Solution: build entire EVM block then indexes it during
EndBlock
. Later can just get block and return corresponding result for related Json-RPC endpoints.Props:
Cons:
Backward compatible for existing chains:
x/evm
keeper to see if block is available or not< enabled
=> fallback to legacy implementation.>= enabled
=> it is pruned, returns error.Steps:
x/evm
storeChildren tasks:
91
100