owned this note
owned this note
Published
Linked with GitHub
# Ethereum 2.0 Q&A session - ROUGH NOTES, NOT READY FOR PUBLISHING
Danny: the basis of the spec for 2.0 is there, there are still a lot of components down the line
Danny: This new spec gets us where we're going faster
Danny: We have an existing POW blockchain, it has some issues, and doesnt get us where we are going, we need pos and scalability. the 2.0 roadmap is an effort to create in parallel to this chain.
Creating a side universe, that allows us to rapidly develop and iterate.
In the short medium terms creartes a scalable solution in parallel to the existing one
There are a number of teams on the beacon chain. Beacon is a coordination for the ecosystem, where the validators live. Here's where the shards are secured and coordinated.
Beacon is the core POS chain and when the shard chains exist, you can add them.
The next laer is to add excecution, cross-shard communication.
Later on you can add snarks.
What do we do with the existing POW workchain? depends on what the community wants.
How do we begin to migrate the community
Afri: What is the estimated timeline? Basic beacon chain eth 2.0
Danny: there is a lot of client teams working here - call for clients
Paul (sigma prime): its very difficult to plan but we are hoping that march/april next year we are gonna be able to have clients, and some interoperability. Depends on coordnation.
lane: what are the challenges?
Paul: any of the unknowns, significant problems at the spec, seems unlikely at this stage
Lane: what's parity's perspective?
Afri: we are excited. We have POC implementations, upgraded on top of Parity Substrate. We joined later, but we have shasper implemented.
Danny: there are block references in the POW chain, and you can use the POW block reference as finality for the POW chain. We can have a hybrid with the beacon chain.
Afri: We are looking forward for a new testnet, cross-client, we need a new non POW testnet to advance
Jacek: We are working on eth 2.0 client - Nimbus. From Status perspective, ETH2.0 is not just the beacon chain, we started out as a sharding client, we are inerested in the potential sharding has to offer and the ways POS gives access to a lot of devices. For beacon we are sticking to the march timeline. On top of that there is a lot of execution work, for the sharding. The timeline to put a sharding world out there is long.
I see march as a good indicator to put something out there, give it to the community to tear it apart.
Danny: 1st half of next year for the clients to start is gonna give us enough pressure to work effectively.
Jacek: this is really a push, a target to work against, and it gives the comunity something to play around with and be able to validate
# Questions
Where are the EIPs or other specs? How does the ETH2 group decide on roadmap / features / coordination?
Will ETH2 follow the EIP process or a separate process?
What is the “Ethereum roadmap”, exactly?
Danny: I outlined the 2.0 roadmap, i dont think anyone can say what it is.
Vitalik: the 2.0 roadmap has existed in many places over time. some of the first docs specified, the whitepaper, then around march 2015 there is a blogpost with the versions. Serenity should have switched to POS. After homestead we got delayed by the DAO, metropolis ended up being split, and now there is constantinople coming soon and some minor forks.
Initially we just said we wanted to move to POS, ideas around sharding were also set from the start. At the highest level there is the approach of keep on upgrading the protocol and keep on adding technical improvements.
Maybe before 2017 it was much less clear as it was not clear how POS and sharding would look like. Then we developed Casper FFG.
In the initial idea we had the hybrid POS implemented.
Then time passed and we realised we should go the way we're going now with the beacon chain.
There are blogposts, a lot of it has been happening on ethresearch, a lot of protocol has been happening here.
We just wrote the spec and it's being edited and becoming more incremental.
Proposed changes now live in the issues, any other ideas that are more abstract there is a github issue and ethresearch.
Ethresearch is more abstract.
In terms of very fundamental features of the protocol, ethresearch has become the defacto place. A lot of discussions happening on cross shard transactions. If an idea is more complex then it can be turned into a white paper.
The github is becoming the point of resources.
How does eWasm fit into the tl?
Vitalik: there is rough consensus that eWasm will be the EVM.
I favor the point we should retire the EVM soon.
We should have a contract on eWasm with an EVM intepreter.
Jamie: is the cryptocurrency of ethereum 2.0 ether?
Vitalik: There is hte intention to make deposits on the beaconchain, here is intentions to make ether in the POW chain transfer w/o becoming validators. There is the idea to have convertibility.
I dont think that we are fully decided at this point.
Paul: ethereum 2.0 eth has to be the same eth, should be moved across. I agree on moving it from 2.0.
Jacek: it gives applications a lot of freedom about when they want to make the move. That's up to every dapp to decide. which is an interesting set up in general.
Paul: it gets a bit complicated hwen we get to the stage of rolling the pow chain into 2.0.
Bryant: eWasm is a whole new development and tooling that needs to be built. We have these solid tools for EVM, but its not quite clear to me how we can get ready to go with ewasm tooling.
Vitalik: the solidity compilers have been adding ewasm.
Greg: somehow ewasm and EVM have been in an argument. The community seems to be very conflict-averse. The aversion of conflict creates more conflict, as you didnt have conflict and then you need to work out a bigger one. We have a toolset growing on EVM, and the longer it takes to get EVM2 out, the longer it will take to get tooling out.
We dont know how long its gonna take for ewasm, if we try to deprecate the EVM1 we are going to create a huge amount of complexity for a lot of people who are getting work done here. The contracts work on solidity and there are lots out there, and now we are putting companies in a position where they can lose the solidity code.
That doesnt mean ewasm shouldnt be the fundamental layer but we cant just abandon what we are without creating much more complexity. We have to keep evolving what we have and talk to other development teams to see what problems they find on EVM1.
Dmitry: what bout account abstraction
Vitalik: we have been removing overcomplicated things. How much we can abstract?
I feel we are on port with the simple versions of abstraction but the more complex ones have many tradeoffs we need to look after.
Bryant: Ethereum 1.0 is a long term service and 2.0 is the next step.
Danny: in the roadmap as i see it the EVM exists till we fork it into a contract and a shard. Depending on the company, they wont have to migrate to wasm.
Greg: its just harder than it is to do the proofs
Danny: IMO as long as people put some work on the EVM, given that we have this parallel scaling roadmap and the EVM remains untouched, we do have time to coordinate on these forks in the next 2 years. I think that its probably a good idea to get the EVM to a good place.
The general consensus is that we should have regular forks. Right now we should be considering what is going into the next fork.
Who is responsible for maintaining the roadmap?
How is it communicated? By whom? In what format? When?
Is there one, canonical roadmap, or several?
Danny: there are parallel ones living in the same universe.
Vitalik: one thing i liked is the idea of a near future hf of the evm chain.
This would both improve the evm chain but also give us practice to do the ewasm implementation.
Greg: who's gonna write the contracts? they are not DOS hardened.
Vitalik: ewasm ingeneral is meant to run on untrusted code.
Casey: one of the goals of proposing new create compiles is that the clients have to run a wasm engine to execute them. So it's not forcing clients to run a wasm engine, but it gives them the option to use a wasm engine in the future as a fallback.
This is just one proposal to improve the EVM. The question is how do we add the precompile without adding complexity.
LANE: what a precompiler is?
Greg: we write precompiles cause current EVM is not fast enough for crypto code or do snarks, things that take a lot of computation. We cant make EVM 1 fast enough so we'll switch to a faster VM. The problem is that if you get a certain code it can take quadratically more time. There is no technical obstacle to make EVM1 as fast as we need. I dont understand what's the big push to do it. The answer is that we dont have enough expertise to write compiler to make EVM run fast. There is plenty of people to write compilers.
I dont think we should use 3rd party engines. We have to write our own so we can find the DOS factors and how we can fix them. Understanding other compilers is harder than understanding ours and find the DOS factors.
Casey: I think there is a parallel in the evm vs ewasm and making the switch. One reason to replace its because its easier to switch to ewasm cause there is tooling available. The question is about 2.0 launching in parallel and leaving the EVM alone, adds more complexity to the commmunity., ideally this should be seamless, the mainchain should upgrade and there would be cheaper gas for everyone.
Streamr: how can be already so much interest to prevent moving on, why do we need to support EVM ad infinitum?
Bryant: ewasm having tooling available is true to some extent. EVM was invented for our usecase, in my opinion ewasm is a totally different usecase and the tooling is not there imo.
Casey: EVM was developed for the SC whether solidity or serpent but it wasnt developed for the usecse of executing cryptographic functions on the c library. its easy to compile c into ewasm, but not so much to the EVM, is it that easy to build a compiler for evm and c?
Im not against any efforts to improve the EVM, but i wouldnt work on it personally because it's the much harder path.
Greg: i can see ewasm can be used to implement a fair amount of EVM 2.0, you can put a canonical EVM1 to ewasm compiler in the blockchain. You dont have to port your EVM code, you just have to use a compiler for the new client for speed.
The arguments over performance dont have to be there either thanks to modern compilers. In a community this size if a client team cant find such a person to build it they are not looking so well.
Once you get something solid and a lot of people are using it the tendency is to keep it.
Streamr: does it make sense to be backwards compatible at this point?
Boris: the question is who decides, this is what we are trying to surface. We have ETH2 specs and research, we know that people that wanna participate can head there, and deciding which of htese things go forward. Do you see a similar EIP process for eth2?
Danny: imo we are a little bit early to go down the EIP process and formalizing it, the community working on the specifications is ready to go into the real launch, and then write an ETH2 genesis EIP and then formalize how to upgrade and build standards. People are more about rapid communication and building, working towards client testnets rather than formalization of the next EIPs.
Jacob: What kind of tangible obstacles could delay POS? eg the source of randomness for the beacon chain is not clear if its been solved.
Vitalik: i definitely agree the fundamental probllems are figured out- Im more worried about small things. The other nice thing about the roadmap is that it can be rolled in stages
Jacob: on the topic of source of randomness, is it possible to realise what doesnt work
Vitalik: yes there is a massive lake and yes the lake is miles away, but the way the protocol has been designed it does not depend on randomness to achieve security. The attacker will not be able to take on a committe because of the size, and not able to revert a single block. There are defensive components, randomness is not a prerequisite for anything.
Danny: randao is the base of what we are going to use but wont degrade the base layers.
With POS we dont have a source of entropy, we need a source of entropy to allow us to shuffle validators, etc.
Randao is a mechanism where all the validators participate and hwen there is a new block on the beacon, randao provides the new source of entropy, is a distributed way to come up with random numbers, and the dao is formed by he validators, it is a solid source of entropy.
Justin has been working on improving this source of randomness.
Vitalik: the way that bc protocols work, is one guy makes a block, another one makes one, etc. COMPLETE
Marek: would it not be good to have a better evolutionary approach and more HFs.
Vitalik: this approach has already been taken.
Danny: We would like to have more frequent releases and not roll so many things at once. You'll see that this is demonstrated soon. how that process goes will inform how we go in the future.
Question: randomness beacon, does it require hardware?
Vitalik: it does, this is not competitive POW, its a computation that's done once.
Casey: one of the 2.0 design goals is that the network still runs in the event of WW3.
Vitalik: a scenario like this has happened with the ddos attacks, and it was because the ethereum protocol was heavily loaded
Ethernian: should be governance a part of an ethereum standard? Governance formalized as a part of ethereum standards.
Danny: being POS and scalable is the goal. the coordination is now in open dialogue, and from there we can formalize but its too early still. In terms of research, we have seen more teams involved on research so what clients are hopefully doing is understanding the research, and moving from there. There is a coordination problem, not governance.
Marek: Do you think that Ethereum is developing slowly?
Danny: the research was not in a place whwre it was ready to build. Research is fuzzier and takes more time. I dont know if this could have happened any sooner, now that we are in the implementation phase, i want it to happen as soon as possible, and real world things are gonna hold us down, like testing.
Its hard to have a standard on whether the research took too long. Maybe in a year we can assess that.
COMPLETE HERE
Danny: there are a lot of ideas to create and debate cross shard communication.
Vitalik: on the research side for 2.0 there is a point to improve, a state execution layer
Questions: How do we do proper POS testnets, because therewont be any real value at stake
Vitalik: we can launch the beacon chain relatively early, and just launch it with real deposits that will give us the technical testnet.
Q: Would it attack players to do attacks?
Vitalik: it will create an envuronment with real users and real world applications, eg, apps with a lot of data eg decentralized twitter.
Im most interested in exactly how much eth will need to be staked.
Q: ERC-20 tokens and migration. Is there gonna be a new standard for token contracts
Vitalik: One of them is that if u have an app, you can just make a version on the 2.0 chain, ewasm chain and eventually phase one of them out. The easiest thing is discreet interactions.
Other kinds of applications, is if you have your own token, you would probs wnat to have a migration roadmap for this.
If you have solidity code you will be able to just compile it into web assembly.
2 directions are possible: merkle proof utility and you should be able to make a light client fitting into 1.0 and 2.0