# Benchmark Verifying RPC results introduces computational overhead, but in practice the cost is often significantly lower than expected.\ Proof verification typically requires only a few hash computations and a single BLS signature check, which is negligible compared to the cost of executing or syncing full node data. ## Verification overhead Verification usualy is not a huge overhead. The most time consuming part is checking the BLS-Signature. The times shown in the table represent the total time required to generate and verify each proof.\ RPC responses were read from the local filesystem to eliminate network latency effects.\ Numbers in brackets indicate the separate durations for proof creation and verification. These benchmarks were obtained from tests performed on an **Apple M3 Max** system: | method | native | JS (wasm) | | ---------------------------- | ------------ | ------------- | | eth\_getBlockByNumber | 24 ms (5+19) | 46 ms (5+41) | | eth\_getTransactionByHash | 16 ms (3+13) | 43 ms (8+35) | | eth\_getTransactionReceipt | 45 ms (43+2) | 68 ms (33+35) | | eth\_getLogs | 19 ms (17+2) | 47 ms (12+35) | | eth\_call ( ERC20.balanceOf) | 12 ms (10+2) | 51 ms (11+40) | ## Latency Measured using the WASM client against `mainnet1.colibri-proof.tech`.\ 3 blocks, 5 runs per block. | Method | local | lightclient | remote | unverified | | ------------------------------------ | ----- | ----------- | ------ | ---------- | | eth\_blockNumber | 138 | 0 | 51 | 26 | | eth\_getBlockByNumber(false) | 171 | 8 | 97 | 27 | | eth\_getBlockByNumber(true) | 347 | 623 | 285 | 56 | | eth\_call | 204 | 48 | 56 | 23 | | eth\_getLogs | 328 | 209 | 212 | 30 | | eth\_getBalance | 153 | 18 | 50 | 22 | | eth\_getTransactionByHash(latest) | 180 | 52 | 66 | 21 | | eth\_getTransactionByHash(historic) | - | 17 | 113 | 24 | | eth\_getTransactionReceipt(latest) | 246 | 124 | 90 | 24 | | eth\_getTransactionReceipt(historic) | - | 18 | 117 | 22 | ## PAP Impact on Latency | Method | local | lightclient | remote | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ----------- | --------- | | eth\_call | +11 / +278 | +59 / +705 | -2 / +138 | | eth\_getLogs | +17 | -14 | +127 | | eth\_getBalance | +6 | +0 | +2 | | eth\_getTransactionByHash(latest) | -6 | +40 | +25 | | eth\_getTransactionByHash(historic) | - | +87 | -6 | | eth\_getTransactionReceipt(latest) | -1 | -11 | +74 | | eth\_getTransactionReceipt(historic) | - | +29 | +36 | | **Note:**: eth\_call will require additional request when used for the first time to fill the cache, so a cold-request may take a bit longer, butrequesting the same or simiular data, will be very fast, since the storage is taken from the cache and verified afterwards. | | | | ### Transfer Size (avg, kB) The size of a payload depend on the method. **colibri.stateless** uses ssz while json-rpc returs a json-response from a RPC-provider: | Method | local | lightclient | remote | unverified | | ------------------------------------ | ------ | ----------- | ------ | ---------- | | eth\_blockNumber | 353.7 | 0.0 | 0.7 | 0.0 | | eth\_getBlockByNumber(false) | 353.7 | 40.6 | 146.4 | 29.0 | | eth\_getBlockByNumber(true) | 365.5 | 0.0 | 146.4 | 576.2 | | eth\_call | 460.6 | 95.1 | 27.7 | 0.1 | | eth\_getLogs | 1062.6 | 802.1 | 279.1 | 121.7 | | eth\_getBalance | 367.2 | 7.9 | 4.4 | 0.1 | | eth\_getTransactionByHash(latest) | 269.8 | 0.7 | 1.5 | 0.7 | | eth\_getTransactionByHash(historic) | - | 0.0 | 3.0 | 0.0 | | eth\_getTransactionReceipt(latest) | 941.6 | 672.5 | 2.6 | 1.0 | | eth\_getTransactionReceipt(historic) | - | 0.0 | 3.9 | 0.0 | **Note:** So, while a complete block is often smaller than the corresponding JSON-RPC data (because colibri.stateless uses the binary SSZ-encoded execution payload from the beacon chain and extracts it directly), other methods such as eth\_call require additional Merkle proofs for every accessed storage value before the EVM execution can be verified. ## Sync Time The first request takes a bit longer since it needs to fetch and verify the pubkeys of the sync\_committee. Initial sync (cold cache): **285 ms** ## Code size Using **CMake-defines**, the code size can be adjusted by including only the required components.\ This is particularly relevant for embedded devices, where memory and storage resources are limited. Here are some examples of code sizes you may expect: | config | code (TXT) | DATA | BSS | Total | | --------------------------------------------------------------------------------- | ------------- | ----- | ----- | ------------------------------- | | FullImage for embedded Device(RTOS) (including OS) only for verifying tx receipts | 200 kB | 35kB | 1.7kB | 236 kB | | Native build on Mac (ARM) with full evm and curl | 281 kB | 177kB | 1.3kB | 460kB | | Native build on Mac (ARM) only for tx verification | 122 kB | 64kB | 1.3kB | 188kB | | WASM (all features) | 660 kB (WASM) | - | - | 980 kB (including js-glue code) | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://corpus-core.gitbook.io/specification-colibri-stateless/specifications/ethereum/benchmark.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.