Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
Tomasz Kajetan Stańczak
@tkstanczak
thanks @s1na
Danny Ryan
@djrtwo
eth2 call 20 — June 27 (one week from today)
ethereum/eth2.0-pm#51
Wei Tang
@sorpaas
@gcolvin I'm thinking, EIP-1702 variant 1 (that is, contracts form a contract family by CREATE of the same version, and code prefix is not required) should also work well for EIP-615. The variant 1 can still have code prefix, but compared with variant 2 (CREATE uses code prefix to determine version), it just makes the prefix optional. So for EIP-615 we can still use code prefix if we want for variant 1. There are situations (like simpler EVM upgrade) where we don't necessarily want to change/add code prefix, but may still want to use account versioning. This may be an advantage of variant 1 compared with variant 2.
Greg Colvin
@gcolvin
I think I agree, @sorpaas, though I haven’t time to look right now. The way I think we (you, me, and @holiman) finally thought it should work is that CREATE specifies a version, and the VM’s validator replies whether the code is valid for that version. Whether the VM uses a prefix for that purpose is something that only VM’s validator cares about.
Wei Tang
@sorpaas

CREATE specifies a version, and the VM’s validator replies whether the code is valid for that version

For this we probably need to define two new EVM opcodes (VCREATE and VCREATE2), and the legacy CREATE and CREATE2, as in variant 1, just uses the current call frame VM version.

I think it may be good to do this step by step. Have base account versioning first, and then we can deploy VCREATE and VCREATE2 separately.

Greg Colvin
@gcolvin
I’m confused then. How does a client create code of a particular version of a particular VM?
Wei Tang
@sorpaas

Currently we almost certainly either just want the newest version, or use the current version of the VM context -- all of our current upgrades are about improvements on EVM. So with base layer of account versioning, contract creation transaction always creates the newest version, and CREATE/CREATE2 always use the version of VM context. I tried to do some editing on the spec if that's clearer for what I mean: http://eips.ethereum.org/EIPS/eip-1702

And in the future we can define VCREATE and VCREATE2 so that any particular version is deployable at any time.

Greg Colvin
@gcolvin
OK. I think version 1 works until we have eWasm. Then "Define LATEST_VERSION in a hard fork to be the latest supported VM version” seems inadequate.
Wei Tang
@sorpaas
Yeah when eWasm comes we need to change it to something like defined in “Extending Contract Creation Transaction” (under “Extensions” section).
Wei Tang
@sorpaas
And just another comment regarding upgradable contract and account versioning -- my current conclusion is that it's not affected at all by EIP-1702 variant 1 (or variant 2)!
  • If the contract uses the proxy contract pattern, it will not be affected. Deployment of the delegate contract happens through contract creation transaction, which deploys the latest VM version.
  • If the contract uses a CREATE opcode internally, then the owner can deploy an upgrade (which will be of the legacy version), and use that upgrade to turn the contract into proxy contract pattern. From this point on, the contract can upgrade its VM version. The only potential drawback is just that it will costs slightly more gas (another DELEGATECALL) and use one more call frame depth, because we turned previously one indirection into double indirection.
Wei Tang
@sorpaas
FYI just did another update to EIP-1702 -- I'm making the version of the execution frame always the same as the account code's version. That is, when fetching code from an account in state, we always fetch the version field of that account together, and "associate" the version with the code. This should be easier to implement (we just need to change all definition of code into (code, version) tuple), and it should provide more sensible results for DELEGATECALL/CALLCODE.
Greg Colvin
@gcolvin
Makes sense.
Hudson Jameson
@Souptacular

@/all ACD Call in less than 9 hours. Please review the agenda.

Agenda: ethereum/pm#102

Alexander
@shamatar
What is a communication channel for a call?
Hudson Jameson
@Souptacular
The call information is posted in this channel about 10 minutes before the start of the call.
Alexander
@shamatar
Thanks :)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<M H Swende (holiman)> I'll miss the call today :(
Alexander
@shamatar
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
@lightclient
zoom link?
Hudson Jameson
@Souptacular
Zoom link coming soon.
Matt Garnett
@lightclient
<3
Hudson Jameson
@Souptacular
Daniel Ellison
@zigguratt
YouTube chat link?
Nvm. Got it.
Wei Tang
@sorpaas
Can you explain more on the SSTORE opcodes increase issue?
Alex Beregszaszi
@axic
@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
@sorpaas
But I think we've been doing this for the whole time right? Like EIP-150.
Alex Beregszaszi
@axic
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
@sorpaas
Okay noted. But in my opinion this is a much minor issue compared with reducing gas costs, still.
Alex Beregszaszi
@axic
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
@sorpaas
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
@shemnon
:+1: to gas costs benhind accout versioning
cdetrio
@cdetrio

@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
cdetrio
@cdetrio
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.
cdetrio
@cdetrio
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
@sorpaas
@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
@sorpaas
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!

cdetrio
@cdetrio
@sorpass no worries (i'm responding in the EthMagi Thread, will paste your comments)
Kobi Gurkan
@kobigurk
@axic interesting, maybe also interesting for Zac
Alexander
@shamatar
@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
Alexander
@shamatar
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
@axic

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

cdetrio
@cdetrio

@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).

Alexander
@shamatar
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
@sorpaas
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. :)