# Verkle - Code-access gas overhead and chunkers comparison
_Thanks to Guillaume, Josh, and Dankrad for their feedback._
Verkle Trees enables Ethereum to go stateless which requires adding contracts code to the tree in addition to the usual account data and contract storage. This allows stateless clients to validate blocks -- required account data, contract storage and code can be verified with a state proof. Code-chunking is the process of transforming the contract bytecodes into tree key-values.
This document analyzes a recent set of ~1 million mainnet transactions to answer:
1. What is the expected code-access gas overhead on current mainnet txs access patterns?
2. How does the 31-byte code-chunker and proposed 32-byte code-chunker compare on real txs?
h/t to Paweł Bylica, who inspired the technical angle for this exploration in a chat we had while I was implementing the 32-chunker.
**TL;DR: the projected average gas overhead (compared to mainnet receipt gas) of going stateless including contracts code in the state tree is ~30%. If the current gas impact is considered too big, there could be some ideas to mitigate:**
- **Change the gas spec to lower the gas charged for code-chunks.**
- **Define a X number of free chunks, and then charge as defined today for extra ones.**
- **Consider if code-chunks charging another dimension in a multi-dimensional gas price schema.**
- **Increase the block gas limit by at least ~30%**.
**The last point might be the most elegant one considering going stateless opens the door to increase the block gas limit.**
**For completeness, it's worth clarifying that all this is relevant if we include the _execution witness_ in blocks, as is expected today. We could decide not to do that, but that would disable stateless verification from the expected benefits.**.
See the _Conclusions_ section for more info.
## Method
The core idea is recording mainnet txs *PC traces*. A *PC trace* records all `pc` values during a tx execution. If a tx execution has a `pc` trace `[1, 2, 3, 10, 15, 16, 20, ...]`, we can simulate which code-chunks are accessed and calculate the corresponding gas for any given code-chunker strategy. A *PC trace* for a tx can contain `pc` records for multiple contracts since contracts can do `*CALL`s.
I built the following pipeline:
1. Run a synced geth node with a [custom live tracer](https://github.com/jsign/go-ethereum/blob/jsign/livetracer/eth/tracers/live/pctrace.go) that records every tx execution *PC trace*.
2. A [new analysis tool](https://github.com/jsign/verkle-chunking-analysis) processes these traces, calculating gas usage under different chunkers and other metrics and writing to .csv files.
3. Some [Jupyter notebooks](https://github.com/jsign/verkle-chunking-analysis/blob/main/notebooks) to analyze and do data visualization.
This pipeline is automatic and can easily be re-run in the future. The *PC Traces* could be recorded via sources other than the Geth live tracer.
## Analysis
A pipeline run was done in mainnet recording **~1 million txs between blocks [20158433](https://etherscan.io/block/20158433) and [20168316](https://etherscan.io/block/20168316) (~2024-06-(24 & 25))**. No sampling was done — all (and only) txs which execute code in existing contracts were used in the described range.
I split the analysis into three sections:
1. Intuition on the txs set.
2. Analyze code-access cost overhead on mainnet txs. (using the 31-byte chunker).
3. 31-byte chunker vs 32-byte chunker.
In an appendix, I show the most important charts but with txs targeting some of the _Top Burners_ claimed by [ultrasound.money](https://ultrasound.money/) to see specific cases.
### Intuition on the txs set
Let's build an intuition about these txs. Nothing about this section is related to Verkle, this is just mainnet info.
*([Open in a new tab](https://github.com/ethereum/go-verkle/assets/6136245/5d42e3b9-c7af-452b-9d4e-af30c0d345cd) to see it bigger)*
The image is 2D-heatmap of counted transactions in two dimensions:
- `execution_length`: is the length of the *PC trace*. e.g: `pc_trace=[1,2,3,4,3,4,3,4,5,6,7]` has length 11.
- `receipt_gas`: is the gas the tx used in mainnet (i.e. Dencun).
Some notes about the image:
- 95% of txs use <260k of gas, with ~50% using <80k gas.
- 95% of txs have an execution length <35k, with ~56% of them <5k.
- Verification check: very short execution lengths with huge gas usage can't exist, nor the inverse. We see that by noticing the ~linear light shadow at the center.
Note that a large `execution_length` doesn't necessarily mean touching much code. The same `execution_length` could be a tight loop or a long linear execution.
### Code-access gas overhead
With each tx *PC trace,* we can simulate which code chunks were accessed and calculate the corresponding gas under [EIP-4762](https://eips.ethereum.org/EIPS/eip-4762) rules.
This analysis considers *code-access gas* any gas strictly required for code access. The code accessed in the account header chunks charges only `WITNESS_CHUNK_COST` since the account header branch is necessarily charged in the tx processing rules or corresponding `*CALL`. Code access out of the account branch must account for `WITNESS_BRANCH_COST` and `WITNESS_CHUNK_COST` (once) per branch and chunk, respectively.
The above means 95% of txs would have an overhead of <800k gas, with ~68% <50k.
Nominal overhead lacks context, so let's see the relative cost compared to the receipt gas for the tx:
An interpretation:
- On average, code-access gas overhead would be ~32.6% of the _current_ tx receipt gas.
- ~60% of txs have a code-access overhead of less than 27.5%.
**Important note:** `code_access_gass/receipt_gas` is a ratio between Verkle code-accessing gas and current Dencun tx gas. EIP-4762 has other gas changes that should be accounted for (for good or bad). This doesn’t mean that “Verkle has on average 32% gas impact on tx”, but “Verkle code-access gas on average is 32% of current (Dencun) gas usage”. Recall no compiler optimizations exist today that optimize for convenient Verkle code-access patterns.
#### Number of executed contracts vs %-code-gas-overhead
To understand which fundamental cause can be correlated with the %-overhead, let's look at the following chart:
([Open in new tab](https://github.com/jsign/go-kzg-ceremony-client/assets/6136245/4b964dff-4997-49cf-b242-4e0f8558545f) to see it bigger)
The Y-axis is the number of contracts that executed code in the tx, and the X-axis is the %-code-gas-overhead mentioned before. This makes sense, since the more external contracts your code-execution invovles the more chances you'll have to pay for _WITNESS_BRANCH_COST_ costs.
To gain more insight, see the _Uniswap: Universal Router_ and _Tether_ cases shown in the appendix.
#### Specific txs
Worst-cases of %-code-access-overhead:
```
Top 10 code-access worse overhead (mainnet txs):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0xc5bf0973ee5a5ef4ac685bf2c242be0f551ddd3e0970df9ffc9028dbe92ae4b6 | 26312 | 146416 | 189000 | 129.084 |
| 0x5b9ca1ded53a98b70196dbb0bb6eb6fd2966ab67c31e59c7dd042d0be2969515 | 28303 | 153301 | 182200 | 118.851 |
| 0x00656146c2f86d90f57d9ba837ff77783c4d312912515cf7f2239aa1f547cc24 | 8588 | 55039 | 65000 | 118.098 |
| 0x2bcd6b0cfde86471b400ade49247ac1097c713631075f6156cc3157c12a15cbf | 30603 | 165483 | 193700 | 117.051 |
| 0x78a92cc616c7c9a58627184183880980072958669518098b1bd50a07c4c5c848 | 8957 | 63890 | 74000 | 115.824 |
| 0x1722760dc671cc61f5e043e58ab8c4d75d442f4e5cba8e139d5d46f97c6a8652 | 9007 | 63926 | 74000 | 115.759 |
| 0x398f4780f3f13f114c296a6a85789fee7d77f75884ee039a7a63ba876f20acce | 8840 | 63845 | 73800 | 115.592 |
| 0x3e2c9ecbf68148ac107167f90ff8d81ab83aa6b96a7697ab8025419cd3ebb6a8 | 11843 | 86550 | 99600 | 115.078 |
| 0xb0c1e43c9eec55b22deb7e4cb232003d2358342534a7dcfa5aed91d295a5430c | 26005 | 125354 | 143100 | 114.157 |
| 0x29d9d522d09a23657f6b79251cbc581a479444227cfac4851f8138fb791eff94 | 10206 | 67168 | 76400 | 113.745 |
```
Out of curiosity, let's check the longest execution lengths:
```
Top 10 longest-execution txs (mainnet txs):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0xf362e9175065cdcd03e85bcc864d0d0218eb74e322677b857539dbb9808d17ef | 4222513 | 19261266 | 1224900 | 6.3594 |
| 0x89e52646f7dbbb937349beb688117cb8d9e0f354cf45a42af4a4b941d42e194a | 3759677 | 17290584 | 334200 | 1.93284 |
| 0x8bddc0f96ddcd1a294d5cb4bc2803a4571de21cc351bf2cbd6aa616386327f81 | 3199329 | 19936221 | 152500 | 0.764939 |
| 0x94f849d3487fbbd66ea017ba08210ba581a7eb609e5e05ed9b42eb8f0f45d2b7 | 2757662 | 16443609 | 129900 | 0.789973 |
| 0x54e852b02f17d74a0c2fc071f1b86585f65adc2df5fdeb72bfbb7e121fedea0f | 2731339 | 15025540 | 1698400 | 11.3034 |
| 0xd6359b2ad6e7368dab2902360697838c10158da8252b306974e8a5a95a9959bf | 2555478 | 5893718 | 148900 | 2.52642 |
| 0x9b1e553129d29da6dece51a50219b1f74d8e34c082f0443146726e17daaaa1ce | 2489375 | 7837455 | 841400 | 10.7356 |
| 0x66cbc46bb6e0bd3e2459a76ca539df89a23662afae69b8f1d64052db823bd61f | 2292441 | 7564676 | 120800 | 1.5969 |
| 0x718418a6e028b0ff52b72b251d3e575103d55f9daa6c673a3c5269b63885dd37 | 2243997 | 13574302 | 115500 | 0.850872 |
| 0x5218326032db00365c95a8b89b947295289fbf172f89889695da68c2b4a87ad9 | 2206091 | 10918926 | 336500 | 3.0818 |
```
as we expected, having a longer execution doesn't necessarily mean a high relative overhead.
### 31-byte chunker vs 32-byte chunker
The currently proposed chunking algorithms are:
- 31-byte chunking: this is the [current proposal of EIP-6800](https://eips.ethereum.org/EIPS/eip-6800#code).
- 32-byte chunking (dense encoding variant): this is a [new proposal](https://github.com/ipsilon/eof/blob/eof0-dense/spec/eofv0_verkle.md#encode-only-invalid-jumpdests-dense-encoding). I wrote a [full implementation](https://github.com/jsign/verkle-chunking-analysis/blob/main/analysis/z32bytechunker/z32bytechunker.go#L98-L181) of it for Geth.
TL;DR of how 31 and 32 byte-chunking works:
- The 31-byte chunking algorithm is very simple. It creates chunks of size 31-bytes, with an extra byte at the start to indicate how many subsequent bytes are a continuation of a `PUSHN` instruction. This algorithm doesn't require auxiliary tables.
- The 32-byte chunking algorithm creates chunks of 32 bytes without prefix byte. However, an auxiliary table is required, which densely encodes which code chunks have invalid `JUMP*` destinations. For example, only if a code chunk has a `0x5F` (`JUMPDEST`) byte that is part of a `PUSHN` will it be stored in this auxiliary table so it can be detected in an invalid jump. Since the table is densely encoded, it must always be fully read.
Let's separate the comparison between gas usage and encoded chunked size.
**Important note:** The 32-byte chunker proposal requires an auxiliary table, but there’s no clear spec on where it should live, which can impact gas usage. I’ve decided to [store it at the start of the bytecode without any EOF-container format](https://github.com/jsign/verkle-chunking-analysis/blob/main/analysis/z32bytechunker/z32bytechunker.go#L37-L44). `bytecode = <table_size_varint> | <auxiliary_table> | <contract_bytecode>`. This is probably the most compact way to store it. A real spec might have another format.
#### Gas usage
This is the hardest metric to estimate theoretically since we’d need a very good low-level intuition of code access execution. The new analysis pipeline is most useful here.
```
The 1079049 txs would have used the following amount of gas:
- With a 31-byte chunker: 44408311700
- With a 32-byte chunker: 43766280500
Thus, the 32-byte chunker used -642031200 less gas (-1.45%) than the 31-byte chunker.
A total of 938995 txs have different gas cost.
Top-10 worst-cases:
| tx | 31bytechunker_gas | 32bytechunker_gas | gas_diff | gas_diff_ratio |
|:-------------------------------------------------------------------|--------------------:|--------------------:|-----------:|-----------------:|
| 0xc697bd93081116e6de9ce8ba1f24de3af583dbeebc1dec6def7d849d813c0061 | 200 | 600 | 400 | 3 |
| 0x0cef36783dafcba2f9c52b6a92c064c8bd32f86616483f29f32c180f337c456f | 200 | 600 | 400 | 3 |
| 0xe0d8bca66fefb2397e5c53564bafe428c7248d31113f720947429fc70750094a | 200 | 600 | 400 | 3 |
| 0x8bd98c1f22f87223e0bea09e3d04f55d2e2d60cddf0a888362d2965d95bb7cd1 | 200 | 600 | 400 | 3 |
| 0xe8b43707a03cbfe159107d93467f0e31fb020be4e81461111ab65d10bfd48af4 | 200 | 600 | 400 | 3 |
| 0xa5b35d52a006b04c1c587cb4bcd7d43a88d7f1b2421fe6ad309f3194bd6369c5 | 200 | 600 | 400 | 3 |
| 0x6e908a2ad36c6788a76f485c1f5ed6293cede04e356dc212f1aa794212489a5c | 200 | 600 | 400 | 3 |
| 0x05e01991059c8d952dd990114cc2585fa4b79c28d194331700cb9a623f4c7ca3 | 200 | 600 | 400 | 3 |
| 0x9f2eb92e99ff54043390720c80ebddf5675b8c7cd87f4894c8542086897334b5 | 200 | 600 | 400 | 3 |
| 0xb2bb87b2c3fde65343ea76c458d6676634ac4c434232d5caa8dc404a9290af25 | 200 | 600 | 400 | 3 |
Top-10 best-cases:
| tx | 31bytechunker_gas | 32bytechunker_gas | gas_diff | gas_diff_ratio |
|:-------------------------------------------------------------------|--------------------:|--------------------:|-----------:|-----------------:|
| 0xb4824ba07a607add50a47ee73b6b89eeb86867b8e8db3f0c2474f6a254380988 | 4100 | 1800 | -2300 | 0.439024 |
| 0x55235513bf49f94bcbb40a1e5b3a1df29aa61b4e8b4de2470875d36e60c7242e | 3700 | 1800 | -1900 | 0.486486 |
| 0x56b4bd66a30151a493e55e4e9ae389e8b60c38ed66e44c7a4057b524d8db648d | 4300 | 2200 | -2100 | 0.511628 |
| 0x250629c2aaa860d4cc217cf4e4665e50d60b664cff2ee715422f869de2a05be8 | 4300 | 2200 | -2100 | 0.511628 |
| 0xd24b5b667fa36c87fa1736652159fdecdeda62df27bf1ea929787c1bba180d27 | 4300 | 2200 | -2100 | 0.511628 |
| 0x880addb0fb3e8eaddb47de476bacec4537ff3dca6acde44dac28bd56a212ddb6 | 4300 | 2200 | -2100 | 0.511628 |
| 0x98beeb091ad4d809183d5301354c37caf89bd387a9b9c216f08bb04b24f80b7d | 4300 | 2200 | -2100 | 0.511628 |
| 0x5b7589d6051eb6d30ab90ca775c798f64e1f0fedae668deafa73b0673e076c02 | 4300 | 2200 | -2100 | 0.511628 |
| 0xfc7a387b7bae983ff1524383c86c4b224a0ffad466f3d8a92ba6cd6cdd5ad17d | 4300 | 2200 | -2100 | 0.511628 |
| 0xb870e62570ec738998e40139bac5cf404b70dec94991633d9e4c7666cfcb6217 | 4300 | 2200 | -2100 | 0.511628 |
```
The 32-byte chunker uses ~1.5% less total gas than 31-byte for the full ~1 million txs run. Recall contracts weren’t compiled with any optimization favoring none of the chunking strategies, and the 32-byte chunker table-encoding format was optimized to take as few bytes as possible. The saved byte per chunk positively offsets the new required auxiliary table size.
Let’s look at the same plot we showed before regarding `byte31_chunker_gas/receipt_gas` but with the 32-byte chunker:
The relative overhead was reduced by ~1.5% (i.e. `32.57*(1-0.015)~=32.09`) as expected. The shape of the histogram is similar to the 31byte chunker.
#### Chunked contract size
This metric is easier to estimate theoretically:
- For 31-byte chunking is ~`original_size*32/31` (+3.22%).
- For 32-byte chunking, the original size plus the auxiliary table size is used. The auxiliary table size overhead mentioned in the proposal is: *avg ~0.1%, worst case 3.1%*.
Let's double-check those claims with all the contracts directly or indirectly (sub-calls) in our txs executions:
```
Avg contract size: 3907 bytes
Total non-chunked contracts size: 320.62MiB
Total 31-byte chunked size: 332.36MiB (3.7% more)
Total 32-byte chunked contracts size: 322.47MiB (0.6% more)
Thus, 32-byte chunker uses -9.89MiB (-3.0%) less than the 31-byte chunker
There are 0 contracts of 32-byte-chunker bigger than 31-byte-chunker.
```
Notes:
- In any chunked code, the size must be rounded to the next multiple of 32. This explains 31-byte chunker real 3.9% and estimated 3.22%
- Similarly, we see a difference between a real 0.9% and an estimated ~0.1% due to alignment reasons.
- In all analyzed contracts, no cases were found where the encoded 32-byte chunked code was bigger than the 31-byte chunked code. (This doesn’t mean it doesn’t exist—but it might be rare)
## Conclusion
An analysis pipeline now exists to take fresh mainnet txs and simulate how Verkle new code-access impacts gas costs and chunked contract sizes. As previously said, code-access gas [isn't the only gas change in Verkle](https://eips.ethereum.org/EIPS/eip-4762), so for good or bad there can be other overheads or reductions in gas usage -- but code-access has probably the biggest impact.
The 31-byte chunker was compared against a proposed 32-byte chunker, which can help decide the best code-chunker, considering benefits and implementation complexity. Any new or existing chunker variant can be added to the pipeline to keep exploring the solution space.
## Appendix - Top Burners
The following is a scoped analysis on txs with the `To` field targeting some top 10 [top burners](https://ultrasound.money/#burn):
- [Uniswap: Universal Router](https://etherscan.io/address/0x3fc91a3afd70395cd496c647d5a6cc9d4b2b7fad)
- [Tether](https://etherscan.io/address/0xdac17f958d2ee523a2206206994597c13d831ec7)
- [Metamask: Swap Router](https://etherscan.io/address/0x881d40237659c251811cec9c364ef91dc08d300c)
- (Bonus) [Uniswap V3](https://etherscan.io/address/0xc36442b4a4522e871399cd717abdd847ab11fe88)
### Uniswap: Universal Router
```
Top 10 code-access worse overhead (Uniswap: Universal Router):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0xfb5af632916a88c6d7923eedb1c27318d3873b9c58b8195cea9943e2457b1ea2 | 15985 | 129146 | 119700 | 92.6858 |
| 0xe5f4fc6c58be9626694f0f8ef1c962b8175a0bc78b040608db1836216fb4685f | 13777 | 115258 | 105700 | 91.7073 |
| 0xfd5ebc0952abd0e8c7544cf324d053648dd3d323318c6c6de8a7ea38eb25dee2 | 18920 | 137399 | 125400 | 91.267 |
| 0x986d13c83ad3e2664745d36f966eff9b11fae76ece00a4b87b59da35b8865184 | 26327 | 197592 | 179500 | 90.8438 |
| 0xcc5e308323c22df3daf95cd4aa5d5f46d56965fe068ee916bd8ba19574547d5b | 28024 | 212180 | 191900 | 90.4421 |
Top 10 longest-execution txs (Uniswap: Universal Router):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0x77bb8bf4b7bb8de8dd1b8dd37abc197ae93375477eedce45654dcd7e1675962e | 278911 | 985569 | 66600 | 6.75752 |
| 0x6f1269a4e32f2c162273e45575ec58f089e436d4e9234d4409306efa5edaa1dc | 249069 | 3071487 | 120800 | 3.93295 |
| 0xe98f148e508b8234a3a060549a95bd8d65a26fcb7b28a25df716f9b9854b6ef6 | 150801 | 1064006 | 562500 | 52.8662 |
| 0x695d31bab4a6b6846cfae6883dbc89797a75035f77feabe1bded07cda844ce38 | 130986 | 1179948 | 284600 | 24.1197 |
| 0xa04b4e14fb75f6b47cbad7fdd6620a5d951b091922038edecd428e98e0ad73c7 | 130739 | 716010 | 286100 | 39.9575 |
```
Notice how for _Uniswap: Universal Router_ the number of executed contracts per tx is way above the mean of mainnet txs. This makes sense, since Uniswap use multiple liquidity pools (thus contracts) to make a swap betwen tokens A and B that don't have a dedicated pool.
Some of worst cases with many charged _WITNESS_BRANCH_COST_s: [Tx 1](https://etherscan.io/tx/0x0a55c13a15bb2479a11e831c4ec442397f946cb8c0bb780b13a8566ec7c69cf4), [Tx 2](https://etherscan.io/tx/0x0dc7122fc3c7ea2ac7129300f5b4b1ff0de069f581d6ec78cc18186d31ba26d6), [Tx 3](https://etherscan.io/tx/0x162dcb57d83abf3e66ae104bd29ec0550f9aeea0a60adbbd0ac24136b6bfae55). We can see how this correlates with the tx interacting with many pools in the swap route which is unfortunate for code-chunk accessing.
### Tether
```
Top 10 code-access worse overhead (Tether):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0x62c675c1ab9d9339e1e24535ff9a3c71a766470e41bdfc13861bd06f5748165c | 1360 | 43174 | 12300 | 28.4894 |
| 0x8053c2fefe1cf809ccf6c822b8296cae833c3e391977d9a292bd8105be222d25 | 1360 | 43186 | 12300 | 28.4815 |
| 0x1f6417de22ce45cf28e71dad1d1c6f9bc8d0f453bc37679ab16aaac633ee4b98 | 1360 | 43186 | 12300 | 28.4815 |
| 0xe9968b2fb6b1db838a6434261bbe881f544c1c89d87608af6ac3d8f4e6ef65e5 | 1170 | 38461 | 10500 | 27.3004 |
| 0xe2e401708712f832c4dae37c50f8168ccd1ac528ef7674b9aa20e98e98d77ea3 | 1170 | 38485 | 10500 | 27.2834 |
Top 10 longest-execution txs (Tether):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0xf13e308c366cfb304e2f08da26e5bd1b8b2710af320530efb6a35c0294c996e7 | 1381 | 64000 | 12300 | 19.2188 |
| 0x4c2a3359a9e8211bf00510d44ba312cc067ced8c94277143267530b49ca3dd49 | 1381 | 64000 | 12300 | 19.2188 |
| 0xdcc14589ac8e488617b1d9d40d271eca4509a91d756c4b49a7b0cd66cff071dc | 1381 | 64000 | 12300 | 19.2188 |
| 0x12040c1b5857fe0d90c587358a15179dab949de8c5b4ee521ccf71fbdf9feb42 | 1381 | 64000 | 12300 | 19.2188 |
| 0x2c5df38fca854c74fe66403673db62272ffaa9e7b464ad4d09e27db189981d71 | 1381 | 64000 | 12300 | 19.2188 |
```
Here we see clearly that Tether only has 1 contract involved in tx, which makes sense since it's an ERC-20 contract. For that reason, the overall overhead of code-chunk gas is lower than average (20.59% < ~31%)
### Metamask: Swap Router
```
Top 10 code-access worse overhead (Metamask: Swap router):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0x02950b300ec71eaee7445f066a57f8dfdc13699ff61d6579ecb303577c72fdad | 31029 | 213897 | 188600 | 88.1733 |
| 0x61751ff4d532506f697e88d85cc25e6e58a5f399e5c103a5c521786763bb42b9 | 29135 | 213315 | 187200 | 87.7575 |
| 0x0a7ddf9089f7d937e370bb5909f60c5a8879fbed4f762a807a63f550b278a6dc | 30900 | 219426 | 191800 | 87.4099 |
| 0xd4bb3f6c655eb9a8f5a90f59c855d8e8b5a7db4f93c4db7c173b524a6f44919d | 31848 | 220130 | 189800 | 86.2218 |
| 0x27b5ae113907233aea4f5c2b07fda253e7dda8e4354af82e6514496cd00c5cde | 28592 | 207165 | 177500 | 85.6805 |
Top 10 longest-execution txs (Metamask: Swap router):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0x7ded3478d162764505df00e97f286f0fe1abb8445f3b34591c3587dbdc9fdfbb | 363933 | 1852977 | 601600 | 32.4667 |
| 0x10aff816b09f3f76a892f5046b684e61182529827abd61ae8eeb6b322d9dd29c | 349232 | 1818801 | 521700 | 28.6837 |
| 0x1fc38ea4166696087a16705608107c2d7f716ec1c1cdc63f97ca6b44a9fc8e8f | 330664 | 1595358 | 521100 | 32.6635 |
| 0x6065ae7b8c1f4473b8bfd307b16abe4615364ae252954b078ed7ef1f5aa03577 | 232694 | 1233037 | 550200 | 44.6215 |
| 0xe6e747d148531b8ea040112025feb0421ee6e79112e31089d45998542fcaa90c | 187163 | 1199467 | 592800 | 49.422 |
```
### Uniswap V3
```
Top 10 code-access worse overhead (Uniswap V3):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0x659deebfbdae58f711ffcf2b138d80056c6c12fb71628b3dbfb6a514a27e7372 | 4101 | 40461 | 35400 | 87.4917 |
| 0xb4afe6c74023732af79dc962dcafa283fb6c1cbdff88ce145a9a1a1704065d20 | 4143 | 40513 | 35400 | 87.3794 |
| 0x7deeda044921a90a000e520ab1ecfc2f597c85568cb990ca06b29d6d360ac847 | 4185 | 40517 | 35400 | 87.3707 |
| 0x9a4313fb0062e4009e5b267c9dd6447fcd82f35a30a7cde41ff2b9938e64bc0d | 4077 | 40581 | 35400 | 87.2329 |
| 0xa3ef961254d6e8111d1edc34c9f2cddda3aeba647ff9326ba54c30bae89db0cb | 3863 | 41081 | 35400 | 86.1712 |
Top 10 longest-execution txs (Uniswap V3):
| tx | execution_length | receipt_gas | 31bytechunker_gas | code_gas_overhead_percentage |
|:-------------------------------------------------------------------|-------------------:|--------------:|--------------------:|-------------------------------:|
| 0xc2eeb0cfed434f60e297fe31e0565095ffd1cb512b4ddf6e3e40d22a3fddf39a | 153515 | 1198556 | 488000 | 40.7157 |
| 0x9676ceafd4213cc7cecfcd92f1033cb8d2c52e3f6ade77f6d24073e8a0955ef7 | 125200 | 1013758 | 406900 | 40.1378 |
| 0xeae5a3cc6457c2c0754ffab63bca3c836124ed2cf778bb914ebfff317246ceb8 | 122620 | 954441 | 370800 | 38.85 |
| 0x284b7d403ede6b619250eb6ecea27c86a15bacc644269333fd049a5f9ce6721c | 117895 | 983338 | 340800 | 34.6575 |
| 0x794f742a34f598924db5641ba14d0028bbbeeab2fd68f8218ed357a06b413ccd | 115885 | 797445 | 388600 | 48.7306 |
```
Sign in with Wallet
Connect another wallet