Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Justin Drake: Ethereum’s Audacious Roadmap to Build a True World Computer

Episode Date: November 27, 2018

The Ethereum vision has always been to create a world computer. But its scalability and performance limitations have meant that it has fallen far short of that vision. Yet, work on scaling Ethereum has exploded in breadth and complexity over the past years. From variants of PoS, to Plasma / Plasma Cash, sharding, EWASM, BLS signatures, everything has been on the table. While confusing on the surface, underneath a coherent vision for a new Ethereum that will scale near infinitely has emerged. We were joined by Ethereum Researcher Justin Drake to discuss the Ethereum Serenity vision, its core components and the roadmap ahead. A particular focus was the beacon chain, the role of randomness and Verifiable Delay Functions. Topics covered in this episode: Justin’s previous project building on top of Open Bazaar Why he made the switch from application development to Ethereum consensus research The high-level vision for Ethereum 2.0 / Serenity The Ethereum Serenity roadmap to scaling the world computer by 1m times The crucial role of the beacon chain The difference between Ethereum Serenity and Polkadot The role of randomness in making Ethereum Serenity work The limitations of existing trustless sources of randomness How Verifiable Delay Functions can be used to create better randomness The Ethereum Foundation plans to develop an open-source VDF ASIC Episode links: DevCon4 Talk by Justin Drake about VDF & Randomness DevCon4 Talk by Vitalik Buterin about Ethereum 2.0 VDF Research Minimal VDF randomness beacon - Sharding - Ethereum Research Ethereum Project Two Point Oh: Explaining Validators Two Point Oh: The Beacon Chain Thank you to our sponsors for their support: Deploy enterprise-ready consortium blockchain networks that scale in just a few clicks. More at aka.ms/epicenter. This episode is hosted by Brian Fabian Crain. Show notes and listening options: epicenter.tv/263

This is Epicenter, Episode 263 with guest Justin Drake. This episode of Epicenter is brought you by Microsoft Azure. Configure and deploy a consortium blockchain network in just a few clicks with pre-built configurations and enterprise-grade infrastructure. Spend less time on blockchain scaffolding and more time building your application. To learn more, visit aka.m.s.coms. Hi, and welcome to Epicenter. My name is Brian. Today, I'm going to speak with Justin Drake.

He's a researcher at the Ethereum Foundation. We had a super interesting conversation about the future of Ethereum. There was a lot of unclear things in my mind before this conversation, unfortunately, was able to clarify a lot, and I hope you will enjoy it as well. So yeah, please enjoy the conversation. Hi, I'm here today with Justin Drake. Justin is a researcher at the Ethereum Foundation. I actually met Justin a few years ago.

he was back then he was working he was sort of a fellow at anthemis and there was this anthemis retreat somewhere in the alps in france was very gorgeous and and he was there and you know we spent quite a bit of talking a time talking there he was working at a different project then that was building on open bazaar so i've known him for quite a while but recently he's become very involved in the ethyrum space and working on some of the cutting edge etherium work to scale and you know kind of built the new, better Ethereum that will hopefully live up to its original promise of being this world computer. So thanks so much for joining us today, Justin. Thank you for having me. So I'm curious, how did you originally become involved in the cryptocurrency in blockchain space?

Right. So I discovered Bitcoin in 2013. And, you know, in mid-2013, I didn't really understand what was going on. But for some reason, it had this appeal to me. And towards late 2013, I decided I was going to read the white paper. I printed it out. And, you know, it took me maybe 10 readings to actually understand what was going on. But because it's a short paper, I read it several times. And, you know, just the intersection of things of, you know, mathematics, which I studied at university and cryptography and finance and computer science and networking, all these things.

came together. And so in, you know, just a few days after, you know, understanding it, you know, at a high level, I created the Bitcoin Meetup group in Cambridge, UK. And then, you know, a few years later, I basically decided to quit my job and work full-time in the blockchain space. So I was a programmer. part of my time was programming FPGAs. And, you know, I was spending all my free time on Bitcoin,

and it was just becoming unsustainable. So I started looking for an opportunity to work full-time in the blockchain space, and I found this program from Anthemus. Anthemus is a venture fund in London, and they were offering basically no strings attached, a little bit of money to do research for one year on the blockchain space. So I jumped on this opportunity. And during that time, I created a company called Duo.

And as you mentioned, it was building infrastructure on top of OpenBazaar. So why did you decide to build something on top of Open Bazaar? So back then I was taking a user-centric point of view, and I was trying to understand, okay, how can this be useful to people? And, you know, I realized that there was a lot of complexity and that this complexity had to be abstracted somewhere. And this kind of appealed to me, you know, the idea of building a front-hand, the UX, which was totally minimal and abstracted as much as possible. to the extent that you don't even realize that you're using Bitcoin or some other technology. And back in the day, OpenBazaar was the most promising actual use case of Bitcoin. We were talking about remittances and getting discounts on Perse.com.

But these things didn't really appeal to me. And then OpenBazaar, this idea of peer-to-peer decentralized marketplace was like a fascinating vision. And I wanted to help out by building infrastructure on top of it to make it easy for people to use Open Bazaar. So when you started working on Open Bazaar, Ethereum was already around. So why didn't you decide at that time to say, okay, I want to build something on Ethereum, right? Were you, you know, did you feel more committed to Bitcoin or maybe more in line with Bitcoin's vision as opposed to Ethereum's? So, Ephraim was almost nothing back then. It was an idea, it was a team, but it was extremely ambitious.

And I had some doubts as to whether or not the developers would actually pull it off. But for sure, it's an idea that appealed to me, and I followed it very closely. The more if theorem developed, the more I realized, you know, this is the right answer. And within the open-bazan community, I, you know, lobbied in a way for more than just Bitcoin support. In particular, I wanted to have Ethereum support. But it was difficult. I'd say that they were almost Bitcoin Maximilist,

and they've gradually been softening their stance. They've added more coin. And now, you know, they're at a point where they're looking to integrate Ethereum. But yeah, I guess that's part of the reason why I left Topolpon Bazaar, but I think the main reason why I left Open Bazaar is because I felt it was a bit too early. So in order to build a decentralized pit of a marketplace, you need all this infrastructure, right? You need a scalable blockchain to start with. But also you need identity, reputation, dispute resolution, stable coins, all these things that are basically going to take years

to build. And Open Bazaar is about mashing together. all these components and making a nice user experience. But we don't really have the foundations. Absolutely. Because that's one of the interesting thing that like stands out to me here is, you know, first you go and you work on a company that's trying to build like, you know, slick end user application tries to be, you know, make all of the, you know, abstract all of this complex technology, make it like easy and user friendly.

And then you go to like the absolute polar opposite and work on like Ethereum. research and as far removed from like user experience and interface as possible. So that's, that's quite a, you know, it's quite a shift you made. Yeah. I mean, in 2013 and 2014, I was drinking the coolate. I was, you know, had these grand visions of, of, you know, how society would be reshaped. And, you know, part of it, you know, was that there was this belief that, you know, Bitcoin would actually scale and would be the platform for all these things. But, you know, as as we learned more and more, you know, Bitcoin took a very conservative stance and didn't change. And I think that led to the frustrating of people like myself who were, you know, almost Bitcoin maximalist in the sense

that I believe Bitcoin was, was the answer to basically flip-flopping and leaving Bitcoin. in terms of going to the polar extreme at the consensus layer, I guess I learned a hard lesson that we are still very early and fundamental problems like scalability need to be addressed. And so maybe we should address these first before thinking of the application layer. But do you feel tempted that once maybe in two years or three years when there's lots of progress been made, do you want to go back to building end-user applications?

I think that that might be an option. It will take a few years for the full Ethereum 2.0 vision to be fully rolled out. But once it's mature, I expect Ephraim 2.0 to not require so much maintenance and so much change. And it might make sense for me to build something at the application layer or the service layer, because I was effectively on top of the application layer,

the service layer, I was building front-hands and a search engine, and we implemented the OpenBazaar client in JavaScript as a decentralized node that would run in the browser. So this is kind of infrastructure that is not really the small contract layer, but one layer above. So now let's switch to Ethereum. And Ethereum is interesting because you know, when the Ethereum

write paper came out back in 2014, there was already, you know, talk about switching to proof of stake, and there was some of these long-term ideas for sharding and scaling. But I think at the time, because they were maybe very abstract, people could still have at least

this subjective sense that they have some idea about where things are going and what things look like. But then over time, what we've seen, in the last year, it's just explosion in complexity. And now there's, so just to list some of the things that are being worked on, right? So there's Casper, and then there's this Casper FFG, right?

There's Fast Vanality gadgets. There's Casper CBC. Then there's plasma. Now, there seems to be a lot of different plasma implementation, including plasma cache. So there's a tremendous variety of activity there. Then there's the whole sharding. And I guess you mentioned that Vlad is working on some sort of sharding. correct by construction, so maybe there's different sharding directions.

Then this is something we're going to speak later quite a bit. There's this beacon chain work. Then there's work on using maybe BLS and threshold signatures. There is work on verifiable delay functions and maybe having like ASIC, Ethereum specific ASIC, which is very different from the proof of work ASICs. Then the work on EWASM. So I think, you know, it has been, come to the point where it's, I think, really, really hard for people to have a sense of where

are things going, where are they at, then what's Ethereum going to look like in the future? So what's your take on it? Is this great because there's so much activity? Is it that maybe it's too scattered and maybe not focused enough? Or like, how would you describe at this moment kind of the work on Ethereum 2.0? Right. So, I mean, you talk about complexity in general and the whole space. And I'd say that a lot of the research was driven by the need for scalability. And scalability really is a non-trivial thing. So, you know, you mentioned plasma and all the variants of plasma. That's a layer of complexity, which is a layer two. And then there's a research happening at layer one with things like Casper and Sharding. I'd say a lot of the complexity is, finding the right way towards the optimal way forward. But a lot of the research and the new ideas that have come out have settled down

towards a really, really nice vision, which actually is simple and can be explained and implemented with relative ease. I'd say a lot of the complexity has been modularized. and what I'd like to call gadgets. So for example, the finality, Casperfg, you can think of that as just one module. You can go into the details if you're interested, but you can also think of it abstractly

as just like a finality gadget. And we have all these various finality, all these various gadgets, and they all fit in quite nicely in the If youm 2.0 vision. And then in terms of roadmap, we've segmented things into three layers. And it's not just in terms of roadmap,

but also in terms of modularity. So the layer zero is basically just the beacon chain, which is this piece of system infrastructure, which manages the rest of the system. And it provides services, for example, such as randomness, the management of the validators, it provides finality and various several things. And it's where most of the complexity lies.

And then we have phase one, or layer one, which is the data layer. So if you think of a blockchain, you have two things going on. One, you have a consensus game, people agreeing as to what data is being fed into the blockchain. And that would be layer one for us. And then we have layer two,

which is the execution of the transactions, basically giving meaning to that data, running it through an EVM and having a notion of state. And so we have this. progressive roadmap where we're focusing on layer zero and then layer one and then layer two. Maybe one thing that would help people wrap their head a little bit around, you know, around what you're talking about in these different components and the roadmap is if we, let's look at the sort of a little bit towards the end state. Let's assume all of these things

actually get built out and they work and we now have this upgraded Ethereum that's kind of capable of delivering all the promises made or the expectation set. What does that look like in terms of, you know, what are the main components? How do they interact? But also, what does it look like from a user experience perspective? Right. So in terms of the main goals of Ethereum 2.0, number one is to move away from proof of work onto proof of stake.

And that's partly, you know, to reduce the cost of proof of proofs of stake. of work, but also to enable new things. You know, for example, we're enabling finality and we're enabling sharding by having proof of stake. And then the second aspect is scalability with sharding. And the idea here is that instead of having one single blockchain, you have 1,024 blockchains. So you have roughly on the order of magnitude of 1,000x increase in scalability. So from the point of view of the application developer, you can choose a shard and and have your app, your DAP, live in that chart.

And it will have a virtual machine, somewhat similar to the virtual machine and if you're 1.0, except that the virtual machine will be based on web assembly. In terms of the good news is that you'll have this upgraded virtual machine, and you'll also have more scalability and hence lower fees. The bad news is that you'll have

complexity in terms of the cross-shod communication. And another thing we want to introduce is the notion of sustainable storage or storage rent or storage maintenance fees. And the idea here is to set things up from an incentive standpoint so that the state doesn't keep growing eternally. And so as a application developer,

you will have to take that into account which might make your life a bit more difficult. You mentioned there's going to be all of these different charts. As an application developer, I mean, is this going to be a kind of similar thing to maybe a cosmocon or polka dot relay chain and that there may be different, and not a relay chain and parochane,

that there may be different blockchains that there may be for a bunch of game-related charts and other shards. or does it, is that all abstracted away and I don't care and does it just provide scalability? Right. So I'd say FM2.0 is very similar to Pocod. So we have this notion of a central chain, which we call the beacon chain, they call the relay chain. And we have shards when they have parachines. The main difference is that we are going towards a homogeneous shards. So every blockchain at the consensus layer is exactly the same. And that from an implementation standpoint just makes a whole load of simplifications. So even though from a theoretical standpoint, it might be slightly less

powerful, it means that you have a simpler and potentially more robust system. Yeah. And then my other question was, will I as an application developer, will I choose particular charts because they differ in some way, maybe on the type of applications, I'll also on that shard or in some other ways or is this something that I don't care about? Right. So you would probably choose your shard based on gas costs. So every shard will have its own gas market, which is another complexity. And so, you know, you want to choose the shard with the lowest fees. But at the same time, you want to choose a shard based on proximity to other applications. So within each shard, things should happen quite fast and quite cheaply, you want to try and avoid the cross-sharp communications.

There is the proof-of-work chain as well, right, where today the ether lives and the application live. And now in the future, of course, we expect that the DC-Centras applications will run on these charts. So what is going to happen with the main, today's Ethereum proof of work chain? Right. So we use the Ephraim 1.0. chain, the proof of work chain, basically for bootstrapping, for economic bootstrapping. So we already have this, this, you know, billions of dollars in tokens, and we use that to bootstrap the Ephraim 2.0 system. And, you know, one of the main questions that it asked is, is the FM2.0 if going to be the same as the 1.0 event? Yes, it's the same. And we're using the same

precisely to have this bootstrapping mechanism. And so down the line, the proof of work chain would then at some point be shut down? Right. So we don't really know exactly what we're going to do with the proof of work chain. Most likely, in my opinion, is that it's going to stay alive in somewhere or another for many years to come. One option is to integrate it as a contract within one of the charts. But that's quite an ambitious vision.

It's possible that it will just live there for some time. Another option is to have some sort of a bomb that gradually will mean that applications will have to move away. So you can imagine, for example, a gas price bomb or a gas limit bomb. You know, over time the gas limit goes to zero or over time the gas price goes to infinity. And then the tokens, will it be possible to move ETH from the proof of work chain to the charts and also back? It's a unidirectional thing. So you take the if in the 1.0, for example, 32 if, you deposit that into the beacon chain, and that makes you a validator.

Once they're in the beacon chain, you can withdraw them in the shards, and then between the shards and the beacon chain, you can do whatever you want. Oh, that's interesting. So you basically burn your old eth, and you receive then, New Eve on the on the on the beacon chain exactly and so when the beacon chain i guess that's maybe a time to speak a bit more about the beacon chain in detail things I understand right is one is that it keeps track of the validators right so the validators both on the beacon chain but also on all the charts and it has this process of you know selecting the validators for the different charts

and kind of the set of validators and i think that's what we're going to speak a lot more about later, because I think that's a key part of your work. And is there also, does it also keep track, for example, on all of balances of ether or will those be in the different charts? Right. So it keeps track of balances of ether for the validators, the validators being the key consensus participants in Ephraim 2.0. And, you know, it does grant work, for example, handling the deposits and the rewards and the penalties and the withdrawals and all these things. As I mentioned, it also basically provides infrastructure for the shards and for the system. So it provides randomness.

Randomness is important because we will be sampling validators to perform various tasks. So we'll say, okay, this validator will have to propose blocks on shards, you know, X, Y, and Z. and this set of validators as a committee will have to do attestation or notarization on this specific chart. So the way that we achieve scaling is basically by giving different validators, different tasks spread out across all the shards. It's very different from the current model where everyone's working on the same shard in this massively replicated fashion. And so we're making these smaller groups of validators be large enough that they are statistically representative of the wider pool of validators, but they're still quite small. And then is there also a kind of a rotation of the validator set so that a particular shard will have some validators for some time, but then as a validator, I continually will work on different shards. Yeah.

So in general, you want to have as much rotation as possible. and that's to prevent what I call adaptive attacks. So once you know who is assigned to which charge, you can try and bribe them or you can try and dedos them or try and do bad things. So the more you shuffle them, the greater the security. And we have different types of committees. So we have one type of committee which is for notarization.

It's basically to solve the data availability problem. And basically you're asking validators, is this piece of data available to download or is it not? And if enough people say that it is available to download, then given your honesty assumption, then the data is indeed available to download. But there are things which are more difficult and you can't do the shuffling so fast. And that, for example, is the state layer, the execution. layer. So when you want to execute a transaction, you need to have access to the relevant state. And downloading that state will take time. You need to sync up. And so you can only shuffle so

fast. We are looking into a very interesting approach called stateless clients. So in the stateless clients, basically, users come with their own state. They include the state in the transactions directly. And they include witnesses, which are basically proof. that the state corresponds to the state route, which is the master checkpoint. And that would mean that the executors, those who are executing the transactions, do not have the, do not need to have the state, and so they can be rotated maximally fast. Okay, great. This is helping a lot, I think, in wrapping my head around a little bit.

If you've listened to previous episodes with Marley Gray and Matt Kerner, You know that Microsoft is committed to providing enterprise-grade tools and infrastructure for blockchain developers. Well, the Azure Blockchain Workbench is perfect for organizations building consortium networks. Take the Ethereum Proof-F Authority template, for example. It's ideal for permission networks where consensus participants are known and reputable. Ethereum on Azure has on-chain network governance that leverages Parody's extensible proof-of-authority client. Each consortium member has the power to govern the network or delegate their consensus participants to a trusted operator. And Paradis, WebAssembly support allows developers to write smart contracts in familiar languages

like C, C++, and Rust. Azure Blockchain Workbench was created on the same principles that drive all production services in Azure, so you know you're relying on secure, redundant infrastructure that can scale. And with built-in services like authenticated APIs, off-chain databases, and secure key management services, you can scaffold your infrastructure in just a few hours. To learn more about Azure Blockchain Workbench and how Microsoft is advancing blockchain usability and enterprise, check out AKA.ms slash epicenter and start building today. We'd like to thank Microsoft Azure for their support of Epicenter.

You mentioned that this is unidirectional, right? So we move the ether from the main chain and I can now deposit it in a contract and I get this right to validate. Does that mean, is there a token transfer on the beacon chain though? Because in the initial phase, right, there is just a beacon chain and charts don't exist. exist yet. So does that mean if I'm moving my ether now to to stake on the shard, I'm essentially locking it up until the shards become live and only at that point I'm starting to be able to transfer them? Or can you? Yeah, that is correct. So in the initial phases when we don't have the

shards, you need to kind of be a believer and want to be a validator for a reasonably long amount of time. You cannot transfer the tokens to other people within the shards. It's not an application layer thing. It's not a user thing. It's purely a system thing and we only have system infrastructure. And in particular, there's no small contracts. It's all extremely simple. Where you would use your EF and do all the transactions and contracts would be in the shards. And so you'd have to wait for that to happen. And that would only happen in phase two when you actually have the shards have a notion of state. In phase one, we would have the shards. So we would have blocks and each shard would be growing over time. And there would be consensus as to what

the data is, but you wouldn't be able to use your EF. Okay. Interesting. So that will require kind of like a big leap. And I guess potentially it will mean that lots of ether would get locked up for, you know, I guess it sounds like it could be a long time, no. Exactly. Yes. I mean, we are hoping for hundreds of thousands of validators eventually. So each validator needs to come in with 32 if. But I think the minimum number of validators that we will require to start the process will be on the order of 10,000 validators. I mean, maybe a detailed question,

but I guess will there be some sort of like higher reward if there's fewer validators so that there's an incentivization? to move early? Exactly, yes. So the more people there are, the small the rewards. And so if there's only 10,000 validators, there will be a huge incentive to be a validator. You can check the specific curve.

It's basically a quadratic curve. So it's not, you know, exactly linear. There's a different curve that was chosen. So you mentioned the polka dot relay chain before. And of course, one of the, the functions of the relay chain, besides, at least the way I understand it, besides looking out for the security is that it also has this interoperability function. Or, you know, in the cosmos as well, even though the security and validation layer works very differently there, but you have the cosmos

hub, right, that you can basically use to, you know, keep track of like token balances and stuff like that. So how does this cross chart communication work here? Is there, does their beacon chain have a function in terms of supporting interoperability between charts? Yes, absolutely. So one of the key things of the beacon chain is to allow the various charts to communicate with each other. And one of the processes that we have here is the notion of a crosslink. So periodically, within every shard, there will be checkpoints, which will be included in the beacon chain. And then these checkpoints, which we call cross lengths,

will be used for other shards to be able to read the state on every other shard. So basically, you can think of the beacon chain as being a light client for every single shard. In terms of additional infrastructure that we have for cross-shard communication, number one is we have finality. So once you have a crosslink which is finalized, that's like a super strong crosslink. And it should never revert. And so you can really rely upon that at the application layer

when you want to communicate with our charts. We also have some sort of notion of pre-finality. So within each chart, we have so-called attestations, which are votes from other validators, on the block. So every time a block is created, you have a bunch of validators who are invited to vote as to whether or not that block is building on top of the tip. So basically, building on top of the parent, which was kind of on the canonical chain. And if a block gets sufficiently many of these attestations, then with very high probability, that block is going to eventually

be finalized, even though the crosslink right now hasn't been included in the beacon chain, and the beacon chain has not been finalized. So basically, we have this spectrum of finality, where it starts with a beacon proposer building a block, and then you have these attestations coming in, and then you have the notaries coming in, creating a crosslink, which gets included in the beacon chain, and then the beacon chain gets finalized through the Casper FFG process. Cool. So recently there was the Web 3 summit in Berlin, and Gavin gave a talk and a demo about substrate and PolkaDot.

And I thought Dennis from A16C, he asked this really good question, which was basically about the compostability of PolkaDot versus Ethereum. And we made this point that, you know, today on Ethereum, it's really nice in that you can write this application and uses, you know, maybe Maker as a stable coin and uses like Dharma and prediction markets and, you know, lots of different things. And it's very easy to write this application. And, you know, basically asked Gavin, okay, how is that going to work in the PokkaDot model?

And, you know, PolkaDot initially talked about having cross-chain smart contract calls. But Gavin basically made the point. And I hope I'm, you know, not misquoting him here, but that. You know, even though that's in the works, but that it's going to take a long time to make this even semi-feasible. And that, you know, in the meantime, it will actually be much better to build things like that on Ethereum, you know, where you have a lot of, you're basically on a single chain. So I'm curious about this point of composability and, you know, the ability to write applications that, you know, like use lots of different contracts. Do you have a sense of how that will differ in terms of the difficulty between, you know, maybe the future Ethereum and something like PolkaDat?

So right now in Ephraim 1.0, everything is interoperable. So if you have two small contracts, they're basically on the same chain. And when you make a call, it's a synchronous call. So that's relatively easy to reason about. In the 2.0, we want to, you know, maximize the natural. network effects. So we want all the shards to be part of this one organism, which is coherent. But there are boundaries between the shards. And so the question is, how do we make these boundaries as small as possible and reduce the friction? And part of the story here is at the

consensus layer, the protocol layer, adding infrastructure to make it easy for the various charts to communicate. So I mentioned these cross links. The cross links allow for asynchronous between the shards, which is different from the synchronous communication that you're used to within the If you're 1.0 context. But we're also adding, you know, this notion of attestation, this pre-finality. And you can use that at the layer two layer. Basically, you can have optimistic cross-shard communication protocols. So with high probability in the default case, things will happen as you'd expect, even if you haven't gone through this whole process of finality. And so you can use that to your advantage to have very short cross-shard communication protocols.

One of the things that I expect will happen is a standardization in the cross-shard communication protocols, something very similar to what has happened with the standardization of tokens, for example, ERC20, Ephraim 2.0 application layer will be, a state layer will be, you know, very universal and very generic. So you can build whatever type of communication you want. And, you know, that makes it a bit more complicated because you have to make a choice. But I think the, the best designs will be experimented upon and they will be standardized. Okay, okay. I guess. that maybe reminds me a little bit of, you know, let's say the work that interledger is done,

you know, if the interledger protocol, which also kind of like, you know, a higher level chain agnostic. And, you know, recently we did a podcast with Stefan Thomas. And we also talked a little bit about their assumption that actually the interledger protocol, it will mostly function between layer two solutions, right? So like the lightning and the radin and stuff like that. and in between there will be the interledger. So do you, I guess it goes a little bit in this direction too, know that like many people could come up with some sort of like standard interface

between the different charts and then there will be kind of like a competition and maybe a standardization effort and at some point maybe people will converge on some, some standard? Right. I think there will be lots of experimentation and some standardization at the application layer. I also think we can make upgrades and add infrastructure as required. So one of the pieces of infrastructure that I'd like to see, for example, is, you know, synchronous, maybe cross-shot transactions, just of pure if. So we're taking a very specific use case, just the transactions of if, and, you know, kind of adding native infrastructure for that.

you know, we might take the best designs at the layer two and the most popular ones and enshrine them. So basically include them at the protocol layer, maybe to simplify them in some way or to give them a special feature. The way that I think, you know, of Ifrm 2.0 is as this base layer, which is actually very simple. And then you have all these gadgets which add functionality. So, you know, finality is just a gadget. You don't really require it. It's nice you have because it makes the communication cross-chain simpler and also you have more confidence in the chain when it progresses.

And I think we will add more and more things going forward. So we will make sure that the EVM is aware of components that are added at the protocol layer. let's not say in this future i'm going to ether scan and i have an address and i wanted to see how many ether are in in this address then what does ether scan do on the back end like does my ether live in a particular shard and now there has to be some sense of oh which shard do i need query to see the balance or like how would that work? Yeah, so I think most likely the address will contain the short number in addition to what we know as the address right now.

Just because the concatenation of these two fields and you just paste that into ephascan and it would be the same user experience that you used to. Okay, okay, great. Well, we've alluded to it before, but let's dive into this now. So the question about randomness, like what is, what's the reason for? for needing randomness in the Ethereum 2.0? Right. So at the consensus layer, you need randomness to sample the validators.

So you have this massive pool of validators, potentially close to a million validators, and you want to assign them different tasks. And it's important from a security perspective that it'd be random, because otherwise as an attacker, you can try and assign yourself to one specific shot and take over that shot, for example. And so the two types of sampling that we do is, one which is kind of monopolistic sampling, where you just sample one single person

and you give them a task, and they have monopoly power over that single task, and we use that, for example, for block proposals. So at every single so-called slot, there's one single proposer per shard who is invited to extend that specific chart. But you also have these. committees. So committees are, you know, on the order of hundreds of validators and they're meant to be

large enough to be statistically representative of the wider pool. And because you have this honesty assumption, so for example, you're assuming that the two-thirds of the validators are honest, when you do the sampling process, the committee, you know with extremely high probability that at least half of them are honest. And so you can ask them to do a task and and vote. And if at least half of them vote for something, then you know that there's at least one honest person who's voted. And so whatever they're voting on is indeed a reflecting of the truth.

I would say let's come back to the role of how specifically randomness is used in the validator sampling and how you verify the full delay functions. But I would love to also hear your take a bit. on, you know, what is the value of having randomness as a, you know, as something you can make an API call to, right? Like, I'm building an application and I can now say, hey, give me some randomness and I use that to, you know, make some decision or, you know, split some fork or maybe distribute some money or, you know, do a lottery. So I think the lottery example is something that, you know, is kind of obvious to anybody, right? So we could, we could make a smart contract. We all

put some money in and then randomly chooses maybe one out of everyone who put the money in, you know, according to, you know, how much it put in. So you could make this trustlessly centralized lottery, which, you know, sounds pretty great. But what are some, what are some other exciting applications that you think would be possible with having this randomness source? Right. So let me just go back to the randomness, because in a way, we already have randomness with proof of work, right? Proof of work is about randomness. sampling a minor and you have a random number, which is going to be your block hash. And that is something that we already exposed in the film 1.0 layer as an upcode that you can use.

One of the things that you need to be very careful of is that this block hash is biasable, meaning that an attacker, if they want to, can have some amount of influence over what that random number will be. And the way that they do that as a miner is that they will withhold their block and not broadcast it if the block that they've mined has a random number that they don't like. They basically discard it. And a lot of the decentralized randomness schemes suffer from this bias problem. And so, you know, we've put a lot of effort in trying to build something that unbiasedable, similar to what DFINITY is doing, where they have an unbiasedable random number scheme using BLS signatures. Now, why is unbiasedability important? Let me take the example of the

lottery. Let's say that an attacker has one single bit of bias, meaning that they can choose between two random numbers at any given point in time. For example, when the lottery winner is selected. Now, if you have a lottery with $100 million, and you as an attacker, you come in with another $100 million, so there's $200 million in the pot. If you had no bias, your probability of winning would be one-half, and so your expected return would be $100 million. But now that you have one bit of bias, you can re-roll thy once, and so you can choose between two numbers, and so your probability of winning now is three-quarters, and so you've basically

stolen 50 million from the community just by being able to bias a randomness. And so just in general, gambling, casinos and all these things are obvious applications. So in terms of applications beyond lottery, you have all the various gambling applications like casinos and poker rooms, but you also have games, you know, such as CryptoKitties. And there's also applications in proofs. system. So if you have a zero knowledge proof, for example, a stock, you can decompose it into smaller chunks where you have this interactive protocol. You have a, you know, a prover who's challenging who's being challenged. And here you need to have a strong randomness for the security to work.

You can also think of systems which, again, have a pool of validators and you sample them. And so you can use that to build, you know, proof. proof of stake systems on top of Ethereum. And so with somebody like BLS, you mentioned DFINITY and, you know, for a listener, we're interested in that. We did a podcast with Tom and Dominic before, where we also talked about, you know, BLS and their role there.

Does that qualify as unbiasedable? Yes. So the way that their scheme works, I mean, BLS is just a technicality is that you have various participants who, have a share of a secret. And if sufficiently many people come together, specifically you need to reach a certain threshold,

then you can generate the next number. And you need at least this amount of people to generate the next number. And the next number is totally unique and deterministic. And it's impossible for someone to predict the next random number if they don't have the share and it's impossible to to bias because there's just a single correct answer as to what the next random number will be. Right. So in DFINITY, right, specifically, let's say we have

500 kind of nodes in this set and then if more than 50%, I mean, you know, 250, I guess, right, come together, they can create the next key. But which of those 250 come together is irrelevant, right? like anyone, you get the same result, but you need to get those 250 in order to get that result. Right. I mean, you do want to have a well-defined committee because if you have, let's say, two different committees that are each invited to create the next random number, then you can grind between the two. You know, one will come first or something like that. So, yeah, you do want to have on ambiguity on who will be doing the task. The main problem with the definitive scheme is, is what happens if you don't reach the threshold of active participants,

people who are online and honest? And this is a problem because people could be dishonest and actively decide to not participate. And DFINITY is already making an assumption that one third of the people are going to be dishonest. But the other problem is that in the honest people, they could just be offline for all sorts of reasons. And one of the design goals that we have in Ethereum is to survive World War III.

So if, you know, 80% of all the validators suddenly go offline and they stay offline permanently, you know, we still want the system to go ahead. In the case of DFINITY, it takes just 10 or 15% of the honest players to go offline for the liveliness of the system to be threatened. So it's 10 or 15% but wouldn't they need just around 50% or 50% or? of the participant to produce the next signature? So definitely requires two thirds to be honest and online. So there's two assumptions here.

Honest and online. Already you've lost one third that are dishonest by assumption. And so you're only left with 66%. Of these 66%, if you have even a small fraction that are offline, let's say 10%, then you will eventually get a committee where you don't, have this threshold of half that is honest and online. And with 10% I think you will hit that, you know, within a day or two. Ah, yeah, yeah. Okay. Because there will be different committees chosen and then you could get unlucky in some way, I guess, if the committee isn't, if it's not a

big enough number and then halt. Yeah. I mean, I guess we'll see if these assumptions are so problematic or if you couldn't then also do something. like a hard fork in a kind of extreme scenario like that and you could still recover? Yeah, so you could try and do a hard fork, but you need to know who's online and who's offline because if you just, you know, restart and most people are still offline, then, you know, you'll just stall, you know, 10 minutes later. So that's not useful. In terms of whether the assumption that, you know, two thirds are honest and online is like a good one to make in the long term, that's very difficult to know.

It's a bit like a seatbelt, right? The seatbelt is only useful in the one instance where you have an accident. And that rarely happens. But when it does happen, you really want the seatbelt. Yeah, I mean, of course, nobody will argue that things being equal, it's much preferable if the thing goes wrong and doesn't have this assumption. So that's no question here. So let's speak about the, I guess, the verifiable delay function and the role that this delay function

has in, you know, and how randomness is created on the speaking chain? Right. So you have these two classical families of randomness schemes. One is based on commit reveal and one is based on threshold cryptography. So commit reveal, that includes the proof of work because in a way you've committed yourself to a random number just by burning electricity and then you have the option to either reveal it or not reveal it. And And then there's schemes which are, you know, based on proof of stake, which is called Randall. So with Randall, you just pick a secret on your computer. You commit to it by hashing it and publishing the hash.

And then at some point in time, you're invited to reveal the secret. And that will contribute towards the entropy pool of the system. And then you have this other scheme, which is based on facial cryptography that are upon which definity is based. And in each of these two classes, you have two of three properties that you want. The three properties that you want is one on predictability. Two, you want liveliness. You want the scheme to continue even if people go offline.

And three, you want unbiasedability. The commit reveal doesn't have unbiasedability. And the threshold scheme doesn't have strong lightness. And so the approach that we're taking is to take Randall, which is not unbiasedable, but has this strong likeness property and somehow upgrade it so that you have unbiasedable random numbers. And this upgrade process involves introducing the notion of time.

So you want to try and introduce lower bounds on the amount of time before an attacker knows how he's manipulating the randomness so that he's basically manipulating things in the dark and he will be unable to actually have a meaningful bias on the randomness. So let me try, because I think I sort of wrap my head around how this works now after, you know, we spoke briefly before and I watched your, you know, your theorem talk. So let me try to explain it.

Maybe you can correct me. So let's say now what we're doing, right, is like me and you, you know, the two of us, right, we together create a random number. you know, we make up this one period. And, you know, you create this random number and you submit it and I create one. And I submit it and then the two together create this, you know, random number. And now the issue is if, and this is a, there's a time out here, right? So let's say you go first, I go second.

If I don't do it, then it's just yours that will be taken as the input for that. But now if you just have that, right, then I'm second. I could check what random number results, and then I could decide or not decide to add my bit and then, you know, bias the result. And now with this verifiable delay function, basically what we're doing is, let's say I have five seconds to add my bit to this,

which will then generate the random number for a particular period. But to calculate actually what's the output, the random number resulting? from our inputs, it takes longer than I have to submit my number, right? So I can take yours and I could put in possible answers for my random bit, but to know how I will bias it, it will take me, let's say, a minute, but I only have five seconds to submit the random number. So now I don't have the chance anymore to bias the random number. Yeah, that's exactly right. So instead of having just two participants, you want to have many more. So that there's at least,

one, which is honest and online, the honest participant will not reveal to the world what their secret is. And so that will create an element of unpredictability within the Randall epoch. The Randall epoch, let's say, it's 10 minutes, and you have 100 participants, one of which is honest. And then at the end of the epoch, what the Randall process does is basically it exores all the revealed numbers from these 100%. people. And the X-O is going to be, again, unpredictable because you have one person that is adding unpredictability to it. But the problem is that the last revealer, or those who are towards the end, it could be the last, or the last two, or the last three, et cetera, they have influence

once they know what everyone else has revealed, because it's an audit list. And so to prevent this last repealer attack, you basically, exactly as you said, you add a minimum guaranteed delay between when you make the action and when you know the result of your action. And so even if you want to try and bias things, you won't have enough time to know what the action, the result of your action will be, and hence you won't be able to bias. Yeah. And of course, if I'm able, for some reason, right, if I have like some super quantum computer, something and I can let's say I we have a thousand people who revealing this random bit and I'm the last one and let's say I had this like amazing supercomputer and I was able to do it

within a split second then I could still calculate okay you know how would I influence this random number and then decide whether I reveal it or not so there's this hardware component that comes in here exactly so If you have hardware, which allows you to defeat the randomness, so defeat the guaranteed delay, which is enforced basically by doing computations. It takes time to do computations, and hence it takes time for you to compute the output of the VDF. F stands for function. It's just a function, which returns in output.

If you have this hardware, then basically you're falling back to Randall. So if it happens that you are the last revealer, then you will have one bit of attacks. surface. Now, in order to create this guaranteed delay, you basically need to have an assumption about the speed of hardware of the honest people and the speed of the hardware of the dishonest people, the attacker. And specifically, you want to place a bound on how much faster an attacker can be. So let's say that your bound is 10x or 100x. So an attacker cannot be 100 times. faster than the honest players. And if you have this bound of, let's say, 100x,

then you can make your computation time be 100 times more than the guaranteed delay that you want. And so an attacker can only compress things down by a factor of 100. And the way that we make sure that it's impossible for an attacker to have harder, which is 100 times faster than what the honest people have is basically to give the honest people, the community at large, access to really fast hardware to start with. So the EFirm Foundation is looking to build an ASIC, a state-of-the-art ASIC with state-of-the-art circuits

for computing this VDF, and we're going to use an advanced node, and we're going to make as many optimizations as we can. And after that, we're going to make the assumption that the attacker can't be that much faster than what we were, what we were capable of doing. And of course, the interesting thing here about doing this like ASIC is now, now let's say we have this ASIC and it performs at a certain,

at a certain performance. Now, if you compare this in Bitcoin with ASICs, I as a minor, I have a, if I can improve my, you know, performance, electricity consumption,

has to put by, you know, 5%. great, I'm going to do it, right? I'm going to invest a lot of money in that because I can then earn more money and become more profitable, which is how Bitmain became like a massive company. But here it's not really the same, right? So here my advantage only comes in if I'm able to like be orders of, you know, maybe an order

of magnitude faster than the rest. Otherwise, like kind of small improvements doesn't really get me anything. Exactly. Small improvements gives you nothing. So long as they're below. low this critical point. And even after the critical point, even if you've somehow managed to reach that, you know, you're 100 times faster, then there's a graceful decay of the security. So let's say you're 101 times faster, then you actually have almost no influence. You know,

maybe one in a million times you'll be able to influence one bit. So you have this perfect unbiased ability if you're, you know, below a certain number. And then that gracefully decays to, to, to, to Randall. So also, of course, economically, there's very unlikely that we will see, you know, an industry merging like we've seen in Bitcoin or like around proof of work to continually try to have better shapes and faster shapes. Like, there's just no incentive to do that here, really. Exactly, right. There's very, very little incentive. So in terms of the incentives required for proof of work. You know, we're talking on the order of $1 billion per year that are burnt by the

miners and used for the security of the network. In the context of VDFs, you need almost, almost no rewards. You need on the order of a million, you know, it's nice to have a reward to incentivize the block proposers to include the VDFs on chain, but you don't need, you don't need more than that. And so if you have a faster VDF, it doesn't really buy you that much. One of the things that it does by you is that it gives you a larger so-called look-ahead, meaning that you will be able to know what the random number will be slightly before everyone else. But, you know, at the application layer, you need to be aware of this and make sure that you wait a sufficient amount of time. And at the consensus layer, we're also doing that.

We're making sure that even if the attacker knows a little bit ahead of everyone else what the random number is, that doesn't actually affect the system in any way. Okay, okay. So it could be something like, let's say now we have a lottery and I'm able to calculate it's like slightly more, or, you know, I mean, I guess there could be some interesting use cases. Let's say you have some on-chain event, right, that's resolved by this random number.

And, you know, maybe you have some derivative market that's based on this. And now if I'm able to slightly, you know, calculate this 10 seconds earlier, then maybe I get some benefit in being able to, you know, trade on this or do something like that. But it doesn't really undermine the core. So if you take the example of the luxury, for example, you're going to have a point where the ticket sales have ended. So for example, for the euro million in the UK, you know, ticket sales closes, I don't know, at 9 o'clock or something. And then at 10 o'clock is when they actually draw the number. So there's this one hour gap between when the ticket sales close and when the draw is made. And, you know, applications will have to do a similar thing.

They'll have to make sure that if someone is able to know the random number earlier than everyone else by a little bit, they can't use that to their advantage. Okay. And so, yeah, so you guys are the Ethereum Foundation, together if Filecoin is now funding this effort to create this open source ASIC. Can you speak a little bit about that? Like, what are some of the unique challenges around this? Right. So the number one challenge around the ASIC is just the cost of it. So it's, you know, if you want to have a state-of-the-art ASIC, it's going to cost between 15 and 20 million. and it would be nice if we could split that cost across multiple parties. And Falkoin is one of these parties that has the most interest in contributing because they would like to use a VDF in their protocol. So it's a win-win if we do collaborate. At this point in time, we actually haven't made a go-no-go decision

on spending, you know, 15 to 20 million. Right now we're still in the viability phase, and we're sharing the cost 50-50 in the various studies that we're doing before taking a decision. One of the nice things is that more people are interested in the VDF, so the meme is spreading in that sense. So we have Solana, who is also potentially looking to join the so-called VDF alliance, because they're using a VDF in their protocol. We're in discussions with Tesos. So we have a call with offer, and they're potentially going to,

they might join the Alliance. You know, we're looking to submit a grant to the proposal to the Tesos Foundation. And then you have Chia that is also using a VDF in their protocol. And they might also join the Alliance. Chia is right now taking a slightly, technically different approach.

You know, they're using so-called class groups, where we're using RSA groups, you know, is a minor technicality. And I really hope that we do converge towards the same solution because it would be nice if we could have a kind of a cross-block chain standard for the VDF. And then you mentioned that this would be given away for free. So how are you going to give away these devices? Right. So we have two hardware assumptions.

The first hardware assumption is that an attacker can't be much faster than the commodity hardware. And the second assumption is that there's at least one piece of hardware, which is controlled by an honest player, which is online. So the strategy I'm taking is to build thousands of these VDF rigs, distribute them as widely as possible in the most decentralized fashion possible, and hope that at least one of them is going to be online at any point in time. So, you know, anyone from the VDF Alliance is more than welcome to have a VDF rig. You know, we'll give them to enthusiasts. We'll give them to exchanges to a firm foundation members. We'll give them to, you know, Edward Snowden or the Electronic Frontier Foundation EFF.

we'll give them to as many people as possible. Also, there's projects that are looking to use VDFs at the application layer. So, for example, there's a decentralized exchange that is looking to use VDFs to prevent front running. And so we'll make sure to give them a rig as well. Okay, okay. But it's not like it is something where there's maybe like a marginal reward to like incentivize people to keep it on and keep it running, but there's no, it's not really comparable, you know, in, like if something like ASIC, right, that you'd want to have, I don't know,

you know, a big center where you have like many of these running or like that's, you know, that doesn't seem like something that will happen here. So one thing which may happen is that people who are simultaneously validators in Affirm 2.0 and VDF evaluators, so people running the hardware, they might have an incentive to try and slightly overclock the VDF so that they're the first one to have it, and they're the first one to include the VDF output on-chain and get the tiny reward that is assigned to the first block proposer who includes it on-chain. maybe last thing here and I know this is a difficult question like what is the timeline on these things

you know when it is I guess I guess some of the main milestone seem to be you know the launch of the beacon chain maybe the launch of the shards and and then having actual I guess you said the state transfer where you can have like each moving over there and on what timeline do you expect that to happen Right. So I've said publicly in several instances that I believe the beacon chain will be available in 2019. That's phase zero. Phase one, which is the data layer will come in 2020 and then the virtual machine will come in 2021.

Now, just to give a little bit more color on this, a lot of the complexity has been put in this. the beacon chain. So just reaching this initial milestone will be pretty huge. And I'm expecting it to happen towards the end of 2019. The data layer is very nice because there's almost nothing there. It's just blobs of data that are recorded in a hash chain. There's blocks and headers. Every block is fixed size. There's very, very little complexity going on. And the folk choice rule, and the mechanisms of attestations that I talked about is going to be the same as in the beacon chain. So I expect the data layer to come early 2020.

One of the nice things is that with only the data layer and not the state layer, you can still do useful things. So this is what I call alternative execution engines. So one of the easiest examples is Truebit. So with Truebit, you allow people to make transactions and these transactions are recorded in the blockchain. And with each transaction, they're basically making a claim as to what the effect of that transaction is. So for example, the transaction is compute this function.

And instead of having the EVM actually compute the function, the result is given. And there's a collateral. And then someone, a challenger, can come in and say, hey, hold on, this is not the correct answer. The correct answer is three, not two. And then they engage in this game where they figure out

who's correct and who's wrong. And the nice thing about this game is that it happens in logarithmic time. So it happens very fast. And at little cost for the virtual machine. And so what you can do is that you can stuff the shards with, you know, all these transactions and execute them somewhere else.

For example, in If you're in 1.0. And this is one of the main challenges that Truebit has. Truebit is a wonderful system, but even just putting the data on the blockchain is extremely expensive. And so now they have this nice option of putting the data on the shards and running the execution on Ethereum 1.0. And then the last phase will be. the EVM 2.0, which is based on WASM, on WebAssembly. The nice thing here is that WebAssembly is becoming a standard across many, many different blockchains. So it will be well tested and it should be relatively straightforward to add WebAssembly. So that might, you know, we might also see Phase 2 relatively soon.

One of the things that we haven't completely figured out, for example, is the sustainable storage model. do we make sure that we align the incentives in such a way that the state doesn't blow and grow uncontrollably? Cool. Well, thanks so much for coming on, Justin. That was super helpful. I feel much more clear about, you know, what's coming for Ethereum. So, yeah, great job.

And thanks so much. Thank you for having me. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes. Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can

watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, the guest, or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much and we look forward to being back next week.