dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:2929
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:2929 [2022/05/21 14:26] nick created |
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:2929 [2022/05/21 14:30] (current) nick |
||
|---|---|---|---|
| Line 49: | Line 49: | ||
| Gas costs were increased to mitigate this, but recent numbers suggest they were not increased enough. Quoting [[https://arxiv.org/pdf/1909.07220.pdf]]: | Gas costs were increased to mitigate this, but recent numbers suggest they were not increased enough. Quoting [[https://arxiv.org/pdf/1909.07220.pdf]]: | ||
| - | : Although by itself, this issue might seem benign, **''EXTCODESIZE''** forces the client to search the contract ondisk, resulting in IO heavy transactions. While replaying the Ethereum history on our hardware, the malicious transactions took around 20 to 80 seconds to execute, compared to a few milliseconds for the average transactions | + | : //Although by itself, this issue might seem benign, **''EXTCODESIZE''** forces the client to search the contract ondisk, resulting in IO heavy transactions. While replaying the Ethereum history on our hardware, the malicious transactions took around 20 to 80 seconds to execute, compared to a few milliseconds for the average transactions// |
| This proposed EIP increases the costs of these opcodes by a factor of ~3, reducing the worst-case processing time to ~7-27 seconds. Improvements in database layout that involve redesigning the client to read storage directly instead of hopping through the Merkle tree would decrease this further, though these technologies may take a long time to fully roll out, and even with such technologies the IO overhead of accessing storage would remain substantial. | This proposed EIP increases the costs of these opcodes by a factor of ~3, reducing the worst-case processing time to ~7-27 seconds. Improvements in database layout that involve redesigning the client to read storage directly instead of hopping through the Merkle tree would decrease this further, though these technologies may take a long time to fully roll out, and even with such technologies the IO overhead of accessing storage would remain substantial. | ||
| A secondary benefit of this EIP is that it also performs most of the work needed to make stateless witness sizes in Ethereum acceptable. Assuming a switch to binary tries, the theoretical maximum witness size not including code size (hence "most of the work" and not "all") would decrease from | A secondary benefit of this EIP is that it also performs most of the work needed to make stateless witness sizes in Ethereum acceptable. Assuming a switch to binary tries, the theoretical maximum witness size not including code size (hence "most of the work" and not "all") would decrease from | ||
| - | **''(12500000 gas limit) / (700 gas per BALANCE) * (800 witness bytes per BALANCE) ~= 14.3M bytes to 12500000 / 2600 * 800 ~= 3.85M bytes''**. Pricing for code access could be changed when code merklization is implemented. | + | **''(12500000 gas limit) / (700 gas per BALANCE) * (800 witness bytes per BALANCE) ~= 14.3M bytes''** to **''12500000 / 2600 * 800 ~= 3.85M bytes''**. Pricing for code access could be changed when code merklization is implemented. |
| - | In the further future, there are similar benefits in the case of SNARK/STARK witnesses. Recent numbers from Starkware suggest that they are able to prove 10000 Rescue hashes per second on a consumer desktop; assuming 25 hashes per Merkle branch, and a block full of state accesses, at present this would imply a witness would take 12500000 / 700 * 25 / 10000 ~= 44.64 seconds to generate, but after this EIP that would reduce to | + | In the further future, there are similar benefits in the case of SNARK/STARK witnesses. Recent numbers from Starkware suggest that they are able to prove 10000 Rescue hashes per second on a consumer desktop; assuming 25 hashes per Merkle branch, and a block full of state accesses, at present this would imply a witness would take **''12500000 / 700 * 25 / 10000 ~= 44.64 seconds''** to generate, but after this EIP that would reduce to |
| **''12500000 / 2500 * 25 / 10000 ~= 12.5 seconds''**, meaning that a single desktop computer would be able to generate witnesses on time under any conditions. Future gains in STARK proving could be spent on either | **''12500000 / 2500 * 25 / 10000 ~= 12.5 seconds''**, meaning that a single desktop computer would be able to generate witnesses on time under any conditions. Future gains in STARK proving could be spent on either | ||
| : (i) using a more expensive but robust hash function or | : (i) using a more expensive but robust hash function or | ||
dido/public/ra/xapend/xapend.b_stds/defact/ethereum/eip/2929.1653157588.txt.gz · Last modified: 2022/05/21 14:26 by nick
