feat: verifiable-api

[eshaan7]

ToDo

Endpoints

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

Other

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

[ncitron]

unused?

[eshaan7]

So, the filter is created on the underlying RPC, and its filter ID is stored in Helios and returned to the user. However, when the user requests filter changes for this filter ID, the response is constructed from Helios's state without querying the underlying RPC. This means we can likely eliminate the initial call as well, generating the filter ID on Helios side itself.

[ncitron]

Yeah lets do that

[eshaan7]

So we should get rid of new_block_filter from both RPC and API altogether since it will not be used by Helios?

[ncitron]

Yeah I think if we have unused methods it makes sense to cut them unless you see a reason to keep them?

[eshaan7]

I think we should keep it in the Verifiable-API for completeness, even if Helios doesn't use it.

The POST /eth/v1/filter endpoint allows requests with a kind value of Logs, NewBlocks, or NewPendingTransactions, effectively replacing the eth_newFilter, eth_newBlockFilter, and eth_newPendingTransactionFilter RPC methods.

Removing NewBlocks option would make the implementation feel incomplete.

[eshaan7]

I also don't think it's a big issue to rely on the underlying RPC to return the filter ID so might just wanna keep the current implementation for simplicity's sake.

[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.