"eth" | "ethereum" | "foundation" | "mainnet" => SpecType::Foundation, "etc" | "classic" => SpecType::Classic,
There is a great talk by Charles Hoskinson at ETC Summit 2017 which I only saw for the first time around two weeks ago.
In it he talks about "The Two Ethereums" always existing, but the irreconcilable difference between those visions only becoming apparent at the time of the DAO fork.
Those two visions were "A Better Bitcoin" and "World Computer". We call those visions ETC and ETH2 these days. And I guess ETH1 is "World Computer Prototype"?
The "right answer" on "what to do" at the time of the DAO fork was different for these two visions. Hence the split.
The beautiful truth in this insight is that there is no conflict whatsoever between these two visions - they are entirely complimentary. We FINALLY seem to be getting to the point where we can respect that duality, and we can collaborate on the huge technical commonality, while maintaining the differing philosophies.
So that is pretty much the scope of ETC.
It is a much more tractable problem.
"So what is the scaling plan for ETC?"
L2. State Channels already work on ETH2 (Fate Channels + Connext already in production).
Fate Channels don't need CREATE2 so will work today on ETC as well.
Connext will work on ETC when we get Constantinople opcodes at Agharta in Jan 2020:
The plan for scaling L1 on ETC is not to scale L1.
Or at least to only do that in a sustainable "Moore's law" style manner.
Only to the degree which the current tech stack can support.
Security always comes first for ETC.
"Better Bitcoin", not "World Computer"
Hope that gives everyone some more insight into the thinking.
@/all Core dev meeting in 10 min.
Zoom Link: https://zoom.us/j/121989443
Regarding the discussion in the meeting on tooling support for EIP-1707 code prefix vs 44-VERTXN account versioning extension. Thanks to MrChico for spotting this -- the concern on 44-VERTXN's ecosystem tooling support can be wholly addressed just by making the
version field optional with default value
This I believe, from all information I have in hand, means that 44-VERTXN is nearly superior in all aspects compared with EIP-1707 code prefix.
I know one use case for versioning that I recently thought about
The biggest use case for versioning is definitely to avoid the next situation similar to EIP-1884. EIP-2348 discussed today does not do anything about that at all. However, fortunately, we have this covered. ethereum/EIPs#2341
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.