Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
  • Feb 28 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Hudson Jameson
The call information is posted in this channel about 10 minutes before the start of the call.
Thanks :)
<M H Swende (holiman)> I'll miss the call today :(
I’ve totally messed up with time zones and will not be able to take part it a call. Huge list of updates and potential answers is posted on GitHub
Matt Garnett
zoom link?
Hudson Jameson
Zoom link coming soon.
Matt Garnett
Hudson Jameson
Daniel Ellison
YouTube chat link?
Nvm. Got it.
Wei Tang
Can you explain more on the SSTORE opcodes increase issue?
Alex Beregszaszi
@kobigurk @shamatar someone should volunteer writing it in EVM and running it against the repricing (to be) proposed by EIP-2045 :wink:
@sorpaas it wasn’t specifically about SSTORE, but the alternative option of scaling every non-reduced opcode upwards. That would mean the block gas limit would need to rise and likely these would be affected:
  • deployed contracts which have some hardcoded limits
  • dapps and wallets
  • (gas) relayers?
  • exchange networks such as 0x?
Wei Tang
But I think we've been doing this for the whole time right? Like EIP-150.
Alex Beregszaszi
We have done it once 3 years ago (Sept 2016 vs. Oct 2019 for the istanbul fork) and the ecosystem has expanded and changed significantly.
Wei Tang
Okay noted. But in my opinion this is a much minor issue compared with reducing gas costs, still.
Alex Beregszaszi
I’m not sure yet which is better, but raising definitely has it own set of challenges.

One note though: if we introduce versioning, then reduction can coexists on the same network without any change in block gas limit (and dapps) needed.

But increase still can’t really work with versioning, because you cannot just raise the block gas limit for a specific version :)

Wei Tang
Yeah I guess let's just make all gas cost changes of existing opcodes go through account versioning. Actually seems like the simplest solution we have at this moment. ;)
Danno Ferrin
:+1: to gas costs benhind accout versioning

@sorpass issues with raising the cost of storage, SSTORE especially, were hinted at in https://eips.ethereum.org/EIPS/eip-2035:

The most problematic cases would be with the contracts that assume certain gas costs of SLOAD and SSTORE and hard-code them in their internal gas computations. For others, the cost of interacting with the contract storage will rise and may make some dApps based on such interactions, non-viable. This is a trade off to avoid even bigger adverse effect of the rent proportional to the contract storage size. However, more research is needed to more fully analyse the potentially impacted contracts.

similar issues were also discussed at the 1.x meetup in January, by Amir Bandeali (https://youtu.be/CnOyVZ3HvK4?t=900). Amir was talking about issues in the context of storage rent / lock-ups, but some similar side effects would also happen from simply raising the cost of SSTORE, if the increase is significant enough
another discussion was in this thread: https://ethereum-magicians.org/t/on-raising-block-gas-limit-and-state-rent/2249
  1. We surely do not need to wait for the entire State rent to be rolled out before increasing the block gas limit. Can we just make state expanding operations (SSTORE, CREATE, etc.) more expensive? Then, recommend the block size increase approximately in the same proportions? For example, make state expansion 3 times more expensive, and recommend raising block size limit by 3 times? Yes, but there are issues to overcome.
btw here's the discussion thread on EthMagi: https://ethereum-magicians.org/t/eip-2045-particle-gas-costs/3311
(please continue discussion there so I don't keep pasting between ACD)
Wei Tang
@cdetrio I remember we discussed this previously. Basically, any upgrades currently to EVM will break something, even adding new opcodes. The ultimate solution is of course account versioning. I think the conclusion at that time was that if we want to apply something without versioning, then we just rather decide what invariant and backward compatibility we want to preserve, and ignore issues that nobody may care, or is a clearly misuse. https://ethereum-magicians.org/t/remediations-for-eip-1283-reentrancy-bug/2434/83?u=sorpaas
Wei Tang
Regarding block gas limit -- I think that may not be a huge issue. Miners can collectively raise the gas limit so that the average is on the previous level.
Note that the above discussion is about on-chain EVM. For wallets, compilers and ecosystem programs, every hard fork will break something for them, and most of them will need to do some updates. And if all they need to do is to re-calibrate the gas estimator, I don't think that's a big ask.

(please continue discussion there so I don't keep pasting between ACD)

And sorry I missed this request! Will do for future discussions!

@sorpass no worries (i'm responding in the EthMagi Thread, will paste your comments)
Kobi Gurkan
@axic interesting, maybe also interesting for Zac
@axic Alex, modulus length is not limited for 1962, so full long arithmetics has to be implemented. We can do few tests of the basic arithmetic and extrapolate
Just to give you a sense of how “slow” EVM is - there is bn128_mul test in ewasm benchmarks that we posted here recently. There multiplication takes 2.3 millisexonds on evmone. Native implementation takes around 90 microsecond. Repricing will not affect it
Alex Beregszaszi

@shamatar Thanks! The repricing is proposed because there doesn’t seem to be a good mapping between actual time an instruction takes and the current gas costs. (While the should be a close mapping between the two.)

Lets say if it takes 2.3ms on evmone, it may still be priced as if it would take 300-600ms, which means it is entirely unfeasible to do that with current prices.

Must also note that in some cases, evmeone was very close to “native speed”. These speeds however heavily depend on the implementations, both the implementation in EVM and on “the native code”.

The main benefit one gets with keeping these as EVM libraries is that the “trusted computing base” (e.g. all the code which is part of consensus) is not extended with precompiles. The more precompiles we add, the more code the clients need to carry.


@shamatar bn128mul in evmone takes 580 microseconds. on the same machine, native rust is 309 microseconds (see benchmarks here. the EVM bn128mul implementation, called Weierstrudel, was optimized for gas cost, not speed (so it uses MULMOD, which is underpriced, rather than MUL, which is much faster than MULMOD). If we (or rather, @zac-williamson who wrote it) optimize Weierstrudel for speed and use montgomery multiplication (i.e. use MUL instead of MULMOD), it will be much faster (we mentioned this on the previous allcoredevs call, Zac estimated it would be twice as fast). And there's an evmone PR to make evmone even faster. So that should bring the evmone + Weierstrudel pretty close to native rust/parity speed.

the native go/geth speed is at 127 microsends, but there are some EVM changes we could make to get even more speedups than the montgomery multiplication one above (e.g. setting the modulus once in memory with a SETMOD opcode, and then using a MULMONT opcode that reads the modulus from memory instead of the stack; in the current implementations there's a lot of overhead from repeatedly DUP'ing the modulus to keep it on the stack).

implementing these optimizations is a lot of work and takes time, but the speed of optimized EVM engine + optimized EVM bytecode can be quite fast (perhaps close to native - for some workloads - though we haven't proved this yet).

From perspective of having an alternative implementation I’d definitely support it. I’ll try to get some benchmarks from Go library and may be libff on my machine to have a comparison too. As far as I understand the opinion is that such another alternative implementation it’s not a stopper for making a precompile and offer “native” speed with it
Wei Tang
Just finished a draft implementation of EIP-1702 variant I. Simpler than I thought, actually. paritytech/parity-ethereum#10771
In case this may be useful for anyone here to review EIP-1702, or if you're interested in implementing it. :)
Greg Colvin
@sorpaas <big thumbs up>
William Entriken

The wiki at https://github.com/ethereum/wiki/wiki is currently locked, surely due to spam. An official substitute has not been recognized (i.e. linked from https://github.com/ethereum/wiki/wiki). May I appeal for write access to the wiki?

A) I would like to correct some things; and
B) I volunteer to act as an editor for the time being.

Lane Rettig
@fulldecent there is also https://eth.wiki/, I’m not sure what the delineation between these two is

So some decisions were made on the ACD Call #63, and I've tracked those in the wiki and the EIP dependency diagram as best I can. One of the higher impact decisions was to go ahead with Account Versioning 1702-Design-1. This allows multiple other EIPs to make progress based on this decision.

I was thinking about what is needed as a next step for EIP advocates and champions. There are some issues I've though about:

  • The EIP Istanbul list is physically large and overwhelming
    • I try to sift the EIPs into probability categories
    • Trivial EIPs without opposition and non-trivial EIPs with support and very clear plans for testing and implementation are Probable in this grouping.
    • Non-trivial EIPs that need small modifications or have unclear implementation and testing plans are Possible.
    • More complicated EIPs or those where there is unclear consensus or minimal implementation/testing plans Could happen.
    • Those that are superceded or have some opposition and lack a voice Will not happen.
    • This grouping is not definitive, or a source of truth. Edits to the wiki to move EIPs into different categories would be helpful.
  • The deadline for EIPs to be proposed has resulted in many placeholder EIPs
    • EIPs with implementation and testing plans should document these clearly in the EIP under Test cases and Implementation.
    • Most have TODO, including those where I have seen elsewhere that the author has a plan.
    • An EIP that has clearly documented plan in these sections is less likely to be swept into the 'too hard' basket mistakenly.
    • Even if there has been no implementation, a record of a specific person who is going to implement the EIP in a specific client will be useful to separate the robust EIPs with momentum vs placeholder EIPs.

10 Probable, if implementation and tests completed. (Trivial or polished EIPs)

  • 1108: Matt Luongo will report back on status of benchmarks, implementation and testing after discussions with Antonio & Zach.
  • 1380
  • 1702 Accepted ACD #63: Design 1 was confirmed. Implementations and design of testing framework to be commenced.
  • 1706
  • 1803
  • 1848
  • 1884
  • 1930
  • 1962 Implementation by Alex in rust with tests. Awaiting geth/parity implementation.
  • 2129 Accepted ACD #63. Implementation by Keep team, lots of support for it to replace 2024.

8 Possible, with refinements based on feedback and implementation and testing

  • 615: Needs a dedicated discussion alongside 663. Is there support?
  • 663: Requires decision about 615.
  • 1109 or 2046: Decision needed to proceed. New PRECOMPILEDCALL or modify STATICCALL?
  • 1283: Already has implementations. James Hancock to talk to Dimitry re: testing.
  • 1344: Needs further discussion (1344, 1965, 1959).
  • 1965: Needs further discussion (1344, 1965, 1959).
  • 2028
  • 2045: Next step is 1) Port optimisations from Evmone to Geth/Parity then 2) Benchmark costs in Geth/Parity.

10 Could happen, with some very clear advocation, implementation and testing.

  • 1057
  • 1352: Needs discussion.
    • Is this meta-only?
    • How do people want precompiles to be defined? Ranges vs client lists.
    • Martin had questions about this EIP that were not addressed.
    • EEA moving toward 1352.
  • 1559
  • 2014: Does this need to be modified to exclude the ChainID component?
  • 2025
  • 2026
  • 2027
  • 2029
  • 2031
  • 2035

8 Will not happen, unless significant advocation seen.

  • 689
  • 1707
  • 1712
  • 1829: A subset of (and is superceded by) 1962.
  • 1891
  • 1959: Looks to be superceded by 1965.
  • 1985
  • 2024: Superceded by 2024.

I was able to edit the wiki with the edit link on the page (rather than through github)

James Hancock
:clap: :clap: :clap:
@and-it-gets-everywhere I think Parity can use Rust implementation directly :)
Holger Drewes
@and-it-gets-everywhere Thanks for this work, this is super helpful! :smile:
@and-it-gets-everywhere I just see that EIP 2028 (calldata gas cost reduction) is now in possible.
I just want to rectify as we are currently working to simulate and find optimal number for the new gas cost. We should be able to share our first findings by July 1st. What would you need from us to move it back to probable?

@GuthL Thanks for the update. Basically what you have just done is super valuable. That is:
1) Keeping everyone informed of your plans, and
2) Making it clear that you're driving your EIP forward with concrete next-steps, which I see you have already listed clearly in your EIP.

I've moved 2028 to Probable in the wiki, which is really part-guide, part-sentiment-probe and by no means binding.

If anyone else sees their EIP lower down on the priority lists or not getting the traction they want, speak up too!

Great! If it can help with ACD, we will share our results as they come.
FYI, we are going to do some synthetic network simulation. If any EIP is interested in participating, we could collaborate and reuse the infrastructure.
James Hancock
Periodic updates on progress are huge for advocacy!

If any EIP is interested in participating, we could collaborate and reuse the infrastructure.

sent a DM


One EIP that I think needs a good discussion around is 615.

  • I think that there have been some strong words of support from teams 1 2 that audit and work on contract security. In particular that this would allow contracts to be written that could have significantly stronger analyses and security properties. If this EIP were to be shelved, it might be wise to get some opinions from this crowd first.
  • There have been voices that the code could be broken up into smaller EIPs, however I think the outcome is that the individual component EIPs would not be useful in isolation, and there may be risk that part 1 goes ahead and part 2 never follows. A momentum argument.
  • There were concerns that the number of opcodes (10) introduced was too complex, though a counter is that this simplifies code later on
  • The EIP has a reference implementation

Three ideologies seem to arise:

  • The EVM is going to be around for a long time, and we better not allow it to fall apart (no-615)
  • The EVM is going to be around for a long time, and we better improve it and make it more secure to work with (615)
  • The EVM is only here until we can bridge to newer and greater VMs (no-615)

I'm not saying that a decision should happen now, but I have seen this EIP brought up mostly in fragmented discussions.

Wei Tang
Regarding net gas metering on the question whether we should keep using 1283/1706 or create a new EIP, now I strongly think we should keep using 1283/1706:
  • We have technical specification EIPs, which defines the actual details about the changes. We also have meta EIPs, which tracks which EIPs are included in which hard forks. It's not an issue at all to have several meta EIPs refer to one technical EIP (in our case, have 1013, 1716 and 1679 refer to 1283). This is really clear and I don't see any possibility of confusion.
  • If we create a new EIP to combine 1283/1706, it will be a direct duplication of 1283/1706. This is bad, because now we have two sources of truth (one at 1283/1706, and the other at the new EIP). I strongly think this is not a good thing for documentation and it might lead to confusion.
  • This is most likely not an issue for testing. Previously in all our testing schemes, we seldom refer to hard forks by their technical EIP numbers. We almost always refer to things by its meta EIP (either nickname or number).