Most people working with Ethereum have questions about ETH2.0. Kevin Owocki hosted some developers working on the project for a recent episode of the Gitcoin Livestream to cover the basics. You can watch the playlist of highlight clips, listen to the audio discussion or read the edited conversation below. Thanks to Joseph Delong from PegaSys, Zak Cole from Whiteblock, Matt Garnett from Quilt, Greg Markou from ChainSafe, and Mamy…
Most people working with Ethereum have questions about ETH2.0. Kevin Owocki hosted some developers working on the project for a recent episode of the Gitcoin Livestream to cover the basics.
You can watch the playlist of highlight clips, listen to the audio discussion or read the edited conversation below.
Thanks to Joseph Delong from PegaSys, Zak Cole from Whiteblock, Matt Garnett from Quilt, Greg Markou from ChainSafe, and Mamy Ratsimbazafy of Nimbus for taking time to share their knowledge.
Kevin Owocki
How would you describe what ETH2’s goals are and how is it going to enhance, extend, transcendent and include ETH1?
Joseph Delong
I think throughput is the largest development for ETH2- increasing the transactional throughput for through the network. There are a lot of kind of like side enhancements that come from the designs and people are working to maximize those, but mostly network throughput. It’s like you could only have one chain, you can do so many transactions, and you can scale a single chain by block size, but it’s not really a good scaling mechanism. So you have to kind of like make separate chains and have a different kind of like coordination system in between.
Kevin Owocki
As I understand it, basically if you scale up just the block size, then you create a centralization problem because then only a certain number of people can afford to run nodes.
Zak Cole
As the block size increases, you’re also going to be more affected by latency within the network. And that’s going to increase the your uncle rate. And the higher the rate, there’s going to be a direct correlation with overall security within the network. So as the uncle rate increases, the lower the security threshold is going to be within the network, especially in a proof of work chain. At a particular threshold, you don’t actually require 51% control of all of the hashing power in order to actually execute a 51% attack.
Matt Garnett
Just to extend on that. There’s two things that we’re trying to scale with ETH2, and those are data availability and actual processing of data. And we already have a really good way of scaling data availability with the paper that Vitalik co-authored in 2018 via data sampling. This makes it so that now clients who are have the same kind of minimum hardware requirements are already expecting like a Raspberry Pi or something, they can potentially agree that a lot more data is available there like the traditional ETH1 chain. But when it comes to processing, if we continue to keep the node requirements where they are for ETH1, then we’re going to only see the same amount of transaction throughput, per shard. And so the scaling of processing comes by paralyzing those across many shards. And those shards may not necessarily be able to communicate synchronously. And so this is kind of where we’re trying to understand, how are dApps going to communicate across the shards? How are we going to build applications and decide where these apps locations need to live.
Zak Cole
The way that I view it is phase zero is kind of more of an experimental phase that allows us to kind of stake and experiment with that staking process, and validating and experiment with different procedures and processes. That’s the purpose for Beacon chain for phase zero.
Kevin Owocki
So if I’m a Gitcoin user, and I’m actively using the main net, my life doesn’t change that much with Beacon chain?
Zak Cole
No, because the ETH1x chain is essentially going to be independent of the ETH2 Beacon chain at that point in time, until we figure out how to roll up ETH1 as an execution environment that’s going to work and operate within ETH2.
Greg Markou
How long would an async request to another shard be? Let’s say there was like an Oracle shard, right? Where all of our price feeds are going into, then Defy is on a different shard. I go to make a request from the Defy side to be like, “Hey, what’s my latest price?” What’s like the time latency that we would have?
Matt Garnett
So, there’s kind of like two ways you can do this. The first like naive way would be as part of the protocol. This changed whenever Vitalik released a new proposal at DEVCON time. In this case, the latency is just a single slot because every time you create a new block on the Beacon chain, you’re cross linking in every single shard, so as long as the shard is live, ie like they’re able to like agree on a new route, then you’ll be able to access, whatever hop on that shard and the next block or the next slot on your shard. So that’s like a huge improvement and to me this makes asynchronous communication a lot more viable for most applications. There are some times where synchronous communication is critical. But if we can do it within like 6 to 12 seconds to me, that solves a lot of the problems or concerns that people have.
So the second way that is if you do some sort of roll up, or you separate posting transactions with actually executing them, because we have a scheme where I can submit transactions on two shards, and then we have a roll up with computers that are powerful enough to execute the same amount of transactions on those two shards. Then we can potentially have the throughput of those two shards combined for actually processing. The downside of this is that now you’re in this optimistic roll up format. And the minimum requirements to validate that is higher than the minimum requirements to be a validator on ETH2, and to me for Defy roll up or shard, this seems okay because if you have hundreds of thousands or millions or whatever dollars and ETH, then it’s important for you to validate this and so running like a slightly more powerful computer than a Raspberry Pi is an acceptable trade off.
Joseph Delong
The way that you described it, Greg, it’s like a cross shard read though too. If you’re not mutating state across two different shards, then it’s instant. Right? I can provide a witness that shows what the state of the thing that I’m going to check in the contract for this other shard. So as long as you’re not mutating state, it’s just one slot.
If you think about it shards are really just roll ups.
Matt Garnett
Matt Garnett
This is something that I’ve tried to talk to the EF researchers about, because it sounds like something that’s interesting. If you think about it shards are really just roll ups. This is kind of like the thesis I’ve come up with over the last month. And really these committees are just ways of making it a more permissionless way of submitting the roof of these optimistic roll ups. And so there’s really no reason why we couldn’t expand the number of shards or roll ups on the Beacon chain to say this is a new slot where the Defy roll up lives. And this is the mechanism for determining who the operators are. There doesn’t seem to me like a technical reason why not. That doesn’t seem like it’s on the roadmap for ETH2 in the near future, but maybe down the line phase three or four or something. We can get a lot of the same benefits related to that by just doing roll ups inside of shards because realistically, there’s not a lot of execution that happens in a roll up. It only happens whenever you like fall back to like the main chain. And the idea is these shards are as secure as the Beacon chain is- that’s like the whole goal of it. So if you take that assumption, then yes, you should be fine, just like doing the same thing inside of a roll up. I think it’s more up to the community. Do they accept the fact that if you have this kind of Defy shard, that to communicate outside of it, there is a trade off of doing it synchronously? I don’t know. That’s a good question that I don’t have an answer to.
Matt Garnett
Basically, (there has been situations where) a lot of transactions are trying to come through and just knock the gas prices up astronomically high, so that it’s difficult to actually get transactions in. In ETH2, it definitely doesn’t get worse. But the question is, how much better can we make it? And that’s gonna be up to developers and how effective EIP 1559 is at keeping gas prices at a reasonable level. It’s unclear how much that’s going to help alleviate these situations. If we have it like the shards in ETH2, they’re not increasing the transactional throughput for synchronous communication between contracts. And so we still have the problem of if you want to be like synchronicity, communicating every single slot with your contract and it’s going to be best to be on that shard. And so if that shard is going to be saturated with lots of transactions and potentially- there’s only a finite number of transactions that can be included so the price of those are going to go up. I think the thing that ETH2 is going to help with is that if we kind of have this Defy shard that a lot of applications are on and we don’t have to try to share that with other kinds of dApps that are also trying to get their transactions in. And so hopefully, that can like kind of alleviate a little bit of the pressure. And so now it’s like everybody is like fighting for just a single shard, it’s always spread out the pressure a little bit.
Kevin Owocki
I understand that because a Ethereum 2 will be based off of proof of stake, it will be much easier to run a node. I do have a rack of Raspberry Pi’s in my garage, and I could run into there. Do you think that staking as a service services will become a thing? And does that introduce a centralization risk?
Zak Cole
There’s definitely going to be a lot of staking as a service, because the average person that just has a bunch of money, think about the user base for Coinbase versus you know, miners or something like that. People are going to be much more apt to just pay somebody else some money to just stake than they are to run that infrastructure themselves.
Mamy Ratsimbazafy
One thing I’m worried about with staking as a service is that with proof of stake, you need to have your privates key on staking service, because you need to sign transactions. So this means that your private key is in another host that you might not trust. So you have your 42 ETH at risk.
Zak Cole
Yeah, that’s essentially like a custodial service.
Greg Markou
When you make a deposit, you put two keys in, your withdrawal key and your signing key. I think your withdrawal key is actually hidden. Basically, the signing key is responsible purely for doing the actual validation process, when you’ve got new attestations coming in and whatnot, and you need to propose blocks. That’s what your signing key is used for. When you actually want to exit and take your funds back, those funds will actually go to your withdrawal key. So your signing key could be compromised, but you can still withdraw.
Mamy Ratsimbazafy
But if you’re signing keys compromised, someone could sign multiple transactions that are conflicting, and you get slashed. So he won’t get your money but he can empty your deposits.
Kevin Owocki
I remember being at DEVCON last year and talking to a few developers that were sort of worried that ETH2, because of the sharding architecture was going to change the way composability worked on the Ethereum network. So if you think about Compound, which is built on top of Dai has a dependency. Does compound have to live on the same chain as Dai?
We’re not taking away things that they can already do, we’re giving them more things they can do.
Matt Garnett
Matt Garnett
My argument is that the transactional throughput on a single shard is going to be closely equivalent to what we already have in ETH1. And so if we want to continue using Ethereum 2 like everyone uses ETH1 then it’s going to continue work in the same way. It’s just that now we’ve opened up a lot of other potential for applications to be built on other shards. And if you decide that you want to build on another shard, and you’re going to have to transact maybe asynchronously. We’re going to build tools to make this really easy for developers. But we’re not like taking away things that they can already do, we’re just giving them more things they can do.