feat: init verifiable-api crate

[eshaan7]

ToDo

Endpoints

• [x] eth_getProof - GET /eth/v1/proof/account/{address}
• [x] eth_getBalance - GET /eth/v1/proof/account/{address}
• [x] eth_getTransactionCount - GET /eth/v1/proof/account/{address}
• [x] eth_getCode - GET /eth/v1/proof/account/{address}?includeCode=true
• [x] eth_getStorageAt - GET /eth/v1/proof/account/{address}?storageSlots={slots}
• [x] eth_getTransactionReceipt - GET /eth/v1/proof/transaction/{hash}/receipt
• [x] eth_getLogs - GET /eth/v1/proof/logs
• [x] eth_getFilterLogs - GET /eth/v1/proof/filterLogs
• [x] eth_getFilterChanges - GET /eth/v1/proof/filterChanges
• [x] eth_call - POST /eth/v1/proof/createAccessList
• [x] eth_estimateGas - POST /eth/v1/proof/createAccessList
• [x] eth_chainId -> GET /eth/v1/chainId
• [x] eth_sendRawTransaction -> POST /eth/v1/sendRawTransaction
• [x] eth_getBlockByHash -> GET /eth/v1/block/{block_id}
• [x] eth_getBlockByNumber -> GET /eth/v1/block/{block_id}
• [x] eth_getBlockReceipts -> GET /eth/v1/block/{block_id}/receipts
• [x] eth_newFilter -> POST /eth/v1/filter
• [x] eth_newBlockFilter -> POST /eth/v1/filter
• [x] eth_newPendingTransactionFilter -> /POST eth/v1/filter
• [x] eth_uninstallFilter -> DELETE /eth/v1/filter/{filter_id}

Other

• [x] Integration with helios-ts (Wasm)
• [x] Unit tests for verifiable-api
• [x] Integration tests (something similar to RPC equivalent tests)
• [ ] Documentation
• [ ] Dockerfiles

[eshaan7]

One thing I notice a lot here is that there is always the execution rpc and optionally the verifiable api being passed around, but I think it makes more sense to run it in either rpc or api mode.

So even in API mode, we need the RPC for most JSON-RPC methods that are not implemented in the API. That's why the implementation is such as that the execution_rpc is required but you can optionally pass in verifiable_api which just switches some methods to use the API instead.

EDIT: Solved in 9864ba5da34caa81c2036cfba771f8c0ea37c7b5.

[eshaan7]

I am curious if we can do some more code reuse between the two inner execution clients? Feels like they are doing a lot of the same stuff.

Do you mean the 2 clients as in ExecutionInnerRpcClient and ExecutionInnerVerifiableApiClient, or something else?

[ncitron]

I am curious if we can do some more code reuse between the two inner execution clients? Feels like they are doing a lot of the same stuff.

Do you mean the 2 clients as in ExecutionInnerRpcClient and ExecutionInnerVerifiableApiClient, or something else?

Yep!

[eshaan7]

Summary of changes in commit f043d119843594e4d49c5436dc24723cf831d885:

• Added unit-tests for all methods of ApiService, ExecutionInnerVerifiableApiClient, ExecutionInnerRpcClient structs and also for the helper MPT functions in the proof file.
  • Added a bunch of new mock files in tests/testdata and a new tests/test-utils crate for code-reuse in all the above.
  • Improved MockRpc, implementing methods that were previously unimplemented.
  • Added MockVerifiableApi struct (for usage in tests) for VerifiableApi trait -- similar to how we have MockRpc struct for ExecutionRpc trait.

cc: @ncitron

[eshaan7]

Summary of changes in commit 656ef894f5b97db7daadbb34f5407c1890643139:

• Added support for Verifiable-API in rpc_equivalence tests. How it works:
  • On top of the existing helios server, it now spins up a verifiable-api server and another helios server in api mode.
  • All the tests, instead of 2 requests (RPC, Helios) as before, now make 3 requests (RPC, Helios with RPC, Helios with API) where all 3 responses should be equal.
• Added additional get_logs test in rpc_equivalence tests.

The sweet part about this is that since the Verifiable-API server is spun up inside the test suite itself therefore no changes are required on CI side.

[eshaan7]

Note that there's a good amount of redundant code in this PR because of the need to convert b/w BlockTag & BlockId at many diff places. This would be addressed separately in #524.