Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ECIP-1056: Agharta EVM and Protocol Upgrades #131

Closed
sorpaas opened this issue Aug 27, 2019 · 9 comments
Closed

ECIP-1056: Agharta EVM and Protocol Upgrades #131

sorpaas opened this issue Aug 27, 2019 · 9 comments

Comments

@sorpaas
Copy link
Contributor

sorpaas commented Aug 27, 2019

No description provided.

@ghost
Copy link

ghost commented Sep 8, 2019

Hi core dev team,

I was wondering if there are any technical chats between yourselves about it and if Agharta changes are good.

e.g.:

Via EIP-1702 new account version:

  • EIP 145 (Bitwise shifting instructions)
  • EIP 1014 (Skinny CREATE2 opcode)
  • EIP 1052 (EXTCODEHASH opcode)

Is all generally ok with eip-1702, 145, 1014 and 1052? Or are there disagreements that will be sorted out after Atlantis?

@soc1c
Copy link
Contributor

soc1c commented Sep 9, 2019

yes, all four EIPs make a lot of sense. We should not get distracted now though and focus on Atlantis. Will organize calls after Atlantis

@YazzyYaz
Copy link
Contributor

I highly suggest we name the hardfork Agartha instead of Agharta.

Agharta is a Miles Davis album: https://www.youtube.com/watch?v=crpJgZxqMcg

Agartha is the Hollow Earth kingdom: https://en.wikipedia.org/wiki/Agartha

@BelfordZ
Copy link
Member

Im not sure its been mentioned, but this would make anyone looking to develop a new EVM would need to implement all previous versions as well.

That being said, we must be prudent to ensure that changes are very well documented, and the implementation of each version can be replicated by following this documentation with relative ease.

We should hold off on including this ECIP until the following are very well defined:

What will be the canonical model for describing the EVM
In what format will changes to this model be proposed
where will the model which specifies each version be located?
Further, it would not be wise to make changes to the EVM until this is sorted out. So to be clear, I don't think we should put a date on this HF until the above is sorted out.

@soc1c
Copy link
Contributor

soc1c commented Oct 25, 2019

what specifically are you referring to?

@bobsummerwill
Copy link
Member

@BelfordZ When I asked more about EVM versioning on ETH All Core Devs, it was clear that there were two different "levels" of versioning which we need to model:

  1. Straight version numbers, which 1702 can handle.
  2. Actual deep semantic versioning, which likely needs KEVM-level analysis.

@BelfordZ
Copy link
Member

BelfordZ commented Nov 7, 2019

@soc1c I was referring to the implicit use of EIP-1702, which has since been removed. Please dismiss above comment.

@bobsummerwill
Copy link
Member

Please can an ECIP Editor close this issue? Agharta is shipped. Thanks!

@soc1c soc1c closed this as completed Feb 3, 2020
Agharta Hardfork automation moved this from In progress to Done Feb 3, 2020
@bobsummerwill
Copy link
Member

Thanks, @soc1c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

6 participants