feat: Flashblock RPCs #4
Conversation
cody-wang-cb
changed the title
| }; | ||
| } | ||
|
|
||
| pub fn transform_tx( |
There was a problem hiding this comment.
implementation similar to https://github.com/paradigmxyz/reth/blob/main/crates/optimism/rpc/src/eth/transaction.rs#L84
| } | ||
| } | ||
|
|
||
| pub fn transform_receipt( |
There was a problem hiding this comment.
implementation similar to https://github.com/paradigmxyz/reth/blob/main/crates/optimism/rpc/src/eth/receipt.rs#L26
src/rpc.rs
Outdated
| Self { eth_api, cache } | ||
| } | ||
|
|
||
| pub fn transform_block(&self, block: OpBlock) -> RpcBlock<Optimism> { |
There was a problem hiding this comment.
implementation similar to https://github.com/paradigmxyz/reth/blob/v1.1.5/crates/rpc/rpc-types-compat/src/block.rs#L84
| @@ -0,0 +1,163 @@ | |||
| use crate::cache::Cache; | |||
There was a problem hiding this comment.
websocket implementation similar to https://github.com/flashbots/rollup-boost/blob/flashblocks/src/flashblocks.rs
cody-wang-cb
changed the title
| }; | ||
|
|
||
| // Then parse JSON | ||
| let payload: FlashblocksPayloadV1 = |
There was a problem hiding this comment.
I wonder if we should move the parsing logic off the receiving worker. Feels like this could potentially block new messages.
There was a problem hiding this comment.
I feel like we need to be a bit cautious of making this process entirely async, given there's order requirements (payload with lower index should be processed first).
Which means even if it ends up blocking i think it's ok, but the most important thing is to make the parsing logic fast (which it is now, currently it's < 1ms for sepolia payload). Wdyt?
There was a problem hiding this comment.
We can still do ordering and move it off the worker for receiving (with a queue of some kind). Though I'm happy for us to address this in a follow up.
There was a problem hiding this comment.
Sounds good, created a ticket for this
## 📝 Summary Making flashblock websocket as flag so that it can be customizable. Also added receipts, account balance, block number into the metadata field, such that the RPC node can build the RPC response for `eth_transactionReceipt` and `eth_getBalance` for pending blocks. (base/node-reth#4) Added an integration test to test that the metadata field indeed has the new data. ## ✅ I have completed the following steps: * [x] Run `make lint` * [x] Run `make test` * [x] Added tests (if applicable)
feat: Flashblock RPCs
Added support for 3 RPCs
eth_getBlockByNumberwith pending tag.eth_getTransactionReceipt, it checks if it exists in the DB first, if not, then maybe it's a flashblock receipt then it checks in the cacheeth_getBalancewith pending tag.It runs a websocket client and listens to the rollup-boost web proxy. It parses the message and store the necessary information into the cache.
For message out of order scenarios, currently only handles to not updating older blocks, but doesn't handle cases like same block payload message out of order, will be TODO for future updates.
Added unit and integration tests, supports reth 1.2.2.