If versioning is inherited from parent contract to the child, then it would be quite easy to deploy generic factories that would be used to take advantage of the old rules, with the cheaper opcodes, no?
@AlexeyAkhunov I don't think the goal here is to "prevent people from using older versions", but rather to "encourage people to use newer versions". Older versions are fine and people can continue to create new contracts of it as long as there are no current known EVM vulnerabilities (otherwise, we need emergency hard fork and backward compatibility has to be broken anyway). In the mean time, to encourage using new account versions, we can do changes such as systematically decrease opcode gas cost, so that older account versions are slightly more expensive to use, and contracts are better off migrating to the forward-compatible EVM version when it is possible.
Back to your questions -- the direct answer is a quantitative "yes", but I do think the above should have addressed the concerns behind the question.
@ajsutton Okay let me rephrase it -- older versions are fine and people can continue to create new contracts of it as long as there are no current known EVM vulnerabilities. The thing is, whenever there's a vulnerability, we'd want to patch it both in the legacy EVM and the forward-compatible EVM. Because it's patched in legacy EVM, contracts under old rules cannot exploit it either.
This is why I also emphasis that account versioning is not for emergency hard forks. Those are situations where backward compatibility has to be broken.
avoid the next situation similar to EIP-1884
account versioning is not for emergency hard forks. Those are situations where backward compatibility has to be broken.
Well, as I see it, if we don't 1884 now, we will eventually have to do it in an emergency instead. So I still don't see how that reasoning applies to 1884. I guess you mean that next time, we can ship it "softly" even earlier, and let people migrate, and only much later actually change/remove it "breakingly", and then not bothering the "active ecosystem". If so, I finally understood your reasoning :)
@holiman Yeah. That's one way the forward-compatible EVM can work, and I do think that's a viable method. But just want to provide you an idea that will have even less backward incompatibility impact, and does what 1884 tries to accomplish.
Imagine, in an alternative universe, we decide to apply 1884 after 1702/39-UNGAS/40-UNUSED. The current 1884 specs, we increase certain opcode's gas cost, but note that this is functionally equivalent to decrease other opcode's gas cost. We apply 1884 as follows:
- In legacy EVM (version
0), we do nothing. - In forward-compatible EVM (version
1), we apply 1884 by decreasing other opcode's gas cost.
After this is done, we make sure to inform miners to configure their client to set the block gas limit according to the forward-compatible EVM gas cost config. Note that this is something that has to be done when we re-calibrate gas cost anyway, no matter whether account versioning is in place. When hard fork happens:
- In forward-compatible EVM, any exploit is fixed, because as noted earlier, while we do not change gas cost of SLOAD, etc, we decreased gas cost of all other opcodes, which is functionality equivalent to increasing gas cost of SLOAD, etc.
- In legacy EVM, the situation is that SLOAD gas cost equal to the forward-compatible EVM, while other opcode gas cost is more expensive compared with the forward-compatible EVM. The gas config becomes in all cases more expensive compared with forward-compatible EVM. As a result, the exploit also cannot happen.
Nothing is perfect. This method certainly involves a slight increase in implementation complexity, and sometimes, gas cost analysis might be too complex to adopt this method, and we may be just better off using what you said above. But I just want to note that this is a possibility, and it indeed works for "simple" cases like EIP-1884.
I also want to note that once things move forward to the forward-compatible EVM, we can expect less and less of this when we do gas cost changes. After all, the forward-compatible EVM is forward-compatible in gas cost changes.
D for forward-compatible EVM, and we make the gas cost provided to be g0 / D, and the gas cost calculated to be g * D, where g is the actual gas cost, and g0 is the gas limit.
To put it simply, the core architecture of ethereum as we know it today is not finished. If you are going to build a skyscraper(long term maturation of anything) first you build a solid foundation. Immutability on a foundation of sand won’t get anywhere long term. Until ethereum can last on its own for decades untouched we don’t have a foundation stable enough to lock forever.
I can see value in both camps and I am happy to see ETH and ETC working together. The differing values of each community adds value imo, as we will discover solutions otherwise we wouldn’t have. The version system outlined above as an example. That being said, if we don’t accept there are points we see differently and continue to rehash the same principles discussion I see it driving us further apart. Just my two cents.
https://www.youtube.com/watch?v=aipGCSGV8ZA
if (blocknum % 1000 = 0) and (most recent 256 headers time >= FORKTIME). Only occuring at x000 blocks provides some certanty, as well as provides a backward compatible number we can say “the fork was at block x000"
FORKBLOCK
Couple other q's:
@tkstanczak which version of Nethermind should I include in the blog post that points to Istanbul compatibility?
@holiman @Arachnid @cdetrio @jpitts is anyone responsible for http://forkmon.ethdevops.io/?
