Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Vitalik Buterin: Ethereum Frontier Launch, Scalability and the Road Ahead

Episode Date: August 10, 2015

Close to two years after the initial whitepaper, the revolutionary Ethereum network has finally launched. The decentralized smart contract platform is, without a doubt, the most exciting cryptocurrency project since Bitcoin. The versatile platform with its turing-complete scripting language aspires to power the distributed applications of the future. Ethereum Founder Vitalik Buterin joined us for the second time to discuss the Frontier Launch, future plans for scalability, governance and the road ahead for the organization and the protocol. Topics covered in this episode: Ethereum’s frontier launch and the upcoming development stages The plans for how to create a scalable blockchain architecture The thinking around transitioning to proof-of-stake The state and new board of the Ethereum Foundation How Ethereum’s development will be funded in the longer term His thoughts on the governance of Ethereum and Bitcoin When private blockchains make sense and if Ethereum What mistakes were made during the development of Ethereum This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/091

This episode of Epicenter Bitcoin is brought you by Ledger, makers of the Ledger Nano Hardware Wallet. Half piece of mind in knowing your private keys are protected by industry standard physical security. Go to ledger wallet.com to learn more and use the offer code EB09 at checkout to get 10% off your first order. Hi, welcome to Epicenter Bitcoin, the show talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kutjua. And my name is Brian Fabin Kroen. We're here today, we're here today, we're one of our recurring guests, which is Vitalik Butarian, of course, he doesn't need much of an introduction. And he's been on the show before in December last year. We talked about scalability. No, actually

not so much. We talked about proof of stake, Ethereum, and it was a really great episode. And many of you will have heard that Ethereum has just launched their frontier release finally. So we have Vitalik on and I'm super looking forward to it hugely. So thanks so much for coming on, you know thank you you glad to be on yeah so actually the frontier launch so we're recording this on on on Saturday August 1st it was just two days ago and and I was right where I am at this moment and you were there as well and it was kind of how did that actually feel for you finally finally reach a step because when you guys started the idea was it was going to be like in a few months no the launch yeah I'm

definitely relieved you know we have this has been going on for quite a long time now. And, you know, originally we thought we were going to launch back in, well, originally we thought we were going to launch back in February 2014. And then it kept on getting pushed back and back a couple of months. And, you know, there definitely were times where it seemed like it was just going to keep on going forever. But, you know, finally, it's happened.

I guess we've moved past stage two and we're on stage three now. So that's great. So you guys were both there at the Ethereum office. How did it feel to be there when it launched and when there was the Genesis block? Yeah, it was great. We had quite a lot of people, maybe somewhere from a third to half of the deaf team all together in Berlin. Got to celebrate a bit. Cool, yeah.

I mean, it's of course hard to know, right, how big of an event this was. Perhaps it was big an event. Perhaps not. You know, history will tell. But it was definitely nice, though, because having, you know, no, knowing these people well who have worked on this and having seen them work on this for such a long time. And it was obviously an abstract thing. And now it's actually life, right?

It's actually here and running. So I think this is a huge change. I'm sure it's going to be very motivating for people too now. Yeah, I think so. So let's get started by talking about the frontier launch. So could you explain what is the frontier launch in the different steps of launching Ethereum? Sure. So the frontier launch is the first time that

there is going to be the live Ethereum network and, you know, ether is going to be valuable. There's, you know, people are going to actually be able to develop applications on it, and they'll have confidence that whatever state those applications end up happening actually will end up carrying forward. So it's not just the test that I'll get deleted in two or three months. It's a kind of very early developer-focused launch. So what we've done is we've sort of split up launch into these multiple stages, where the first stage is frontier, where we explicitly say, you know, this is the zero-be-dragons, no safety guaranteed network.

It could easily end up having bugs on it. It's just something for miners to help get the network started and for its developers to start building on it. You know, the only interface is a command line. So this is the sort of stage that we'd like to see the Ethereum network going for for a couple of months. And if it goes for a couple of months without hitches, then, you know, we'll move on to the next stage, which we're calling Homestead. And, I mean, originally the plan was that Frontier would also be sort of quasi-centralized, so the Ethereum Foundation would be like checkpoints and blocks every day.

but we've decided there are a bunch of reasons why we can't really do that to that extent. So we ended up delaying, delaying Frontier a bit more and pushing into the points where it's kind of halfway to where we wanted Homestead to be in the first place. So differences between Frontier and Homestead that remain are to some extent marketing. So it's kind of the difference between Alpha and Beta. there still are a few kind of default kill switch features that are in frontier. So the main one is this thing that we're calling canaries, which is basically that there are a few contracts on the blockchain, and the core developers have the ability to send transactions to these contracts,

which basically mark a particular chain as being invalid in some way. So, you know, if, say, the blockchain forks and we decide that one fork is valid and the other fork is invalid and it's just happening because one of the clients has a bug in it, then we will launch a transaction, which is specifically targeted to the bad chain, which would basically eventually get into the blockchain and basically mark it as, you know, being wrong and everyone will automatically stop mining on it. So people, the clients then will automatically stop mining. Yeah, exactly. Yes. So that's something that's, I mean, it's centralization to some degree, it's there in frontier, it's a kind of training wheel that's going to come off in Homestead. So aside from that, I mean, yeah, Homestead is just going to have, I mean, the software is going to continue to improve, obviously. It's the point where we start recommending that people actually start building, you know, more serious and

long term applications on it instead of basically just sort of very very early development in testing. Step three is Metropolis. So this is where we release MIST, which is, you know, the Ethereum browser. And Ethereum is finally going to have a GUI. Yay. If you want, you know, you could actually download and use MIST right now. So, you know, there is a very early version of MIST. It works. There is a wallet, animalogysig wallet in that version of MIST.

they work, but they're still sort of very alpha stage and we're not claiming that they're kind of ready for anything close to mainstream use at this point. But you know, at some point we're going to sort of formally release MIST and yay, people be able to use it. Is that also when the IDE comes out, the Mix IDE? The Mix IDE is out already. It's continuing to evolve over time, but it's, I mean, there is a version you can use it. Okay.

some confusion on there, at least for me, is this what you're calling now LF0 or is that something different? So mix is a kind of piece of software that came out of Aleth zero. So LF0 itself, you know, is just sort of very simple GUI for the C++ client. And the sort of main direction that the C++ client is going to take is being for development and mix is a kind of GUI that's designed for developing contracts. Mist is the thing that came out of Goetherium. Okay. And so what other, can you tell us, but what other components are being released with the Frontier launch or what, you know, so there's some other websites like stats, etc. Is that being released now? Okay. So Frontier release includes, number one, the actual blockchain.

number two, it includes the development tools mix. It has two clients. So the Go client is the one that's kind of the most audited and the most likely to be sort of free of serious security issues. C++ client is undergoing an audit right now. it should become more and more ready over the next month or so as the audit progresses. The Python client is not audited, but it's there. You can theoretically run it.

It syncs the blockchain. So that's all in place. There's also a few of these sort of statistics pages. There is a stats.eath.com is the one that we're running. It's the sort of view of the entire network. You can see the world map. You can see nodes mining on pretty much every continent of the world map, except for Antarctica. But then those darn penguins, I heard they like an XT more or something.

Then there are a bunch of third-party services that are up already. There's, I think, etherchain.org is already up. So that's a third-party service? That's not being run by ETH dev? No, it's not being run by ETH. party. And, you know, it's a block explorer. It's got all the blocks, it's got the transactions and it counts. It's showing all. So I had a question, why, what are the, what are the utilities of having different clients? Like why a Go client and a Python client and a C++ client?

There are a few reasons behind that. And one point is that it's kind of, there are kind of political benefits to having multiple clients because it makes it easier to say this is a system that's controlled by the, where the sort of the protocol specification is actually defined by a formal specification first and implementation second. Whereas with a lot of these other crypto protocols, they basically say, you know, well, the implementation is the spec. And if the implementation has a bug in it, well, that's just, that's just a fun little feature that's, that was supposed to be there all along. So that's basically the, you know, by having multiple clients, it kind of makes it harder for one of them to start sort of running away from all the others and adding on

its own extensions and so forth. So that's, I mean, this whole sort of governance issue is important to our degree because, you know, we've seen how sort of things are evolving in the Bitcoin ecosystem with Gavin and Mike pushing out Bitcoin XT and so forth. forth, so that, so this kind of centralization of the ecosystem by means of one client is basically being able to define the spec is one of the things that we're trying to avoid. Another issue is just from a security perspective is that, you know, by having a very, very large suite of tests and by seeing that we have three separate implementations that implement and pass all these tests perfectly. That just makes sure that there's a much lower

probability that there are going to be any kind of security issues between these clients. So, you know, basically you can think of one of the clients as being kind of like an automated generator of tests for the other. Now, of course, there are costs with a multiple client approach. So, you know, one of the costs says that there's just a much larger amount of development effort that's required. So, I mean, opinions inside the team differ to some degree. I mean, even though I was the one that was pushing this multi-client approach much, much harder early on, I mean, right now I do think that we over-invested in that to some degree.

But it's, you know, there are trade-offs between these things. It's definitely still an interesting experiment that I'm sure a lot of future software projects will learn from. Cool. So the launch, as far as I know, and I asked you, I think, about this yesterday or something, everything went perfectly fine, right? Yeah, I think so. Okay, that's right. And so one thing that's also notable, right, right now and beginning, it's not actually possible to do transactions.

Because can you explain why that's the case? Yes. You know, that was a fun one. I remember after we launched, there was this really nice article on the budget. Bitcoin Reddit, Ethereum launches incapable of doing transactions, which was just perfect. So basically what we did was we decided that we were going to set the gas limit in Ethereum starting off to 5,000. And 5,000 is only about a quarter of the 21,000 gas that you need to actually send a transaction.

So this would be the equivalent of like Bitcoin having a block size limit of 20 bytes. The idea behind that is to just let the network sort of start off and stabilize first, and then only after the network is stable, people get sort of start bringing and setting transactions in. So at this point, it's looking likely that this sort of thawing process is going to happen in the next few days, maybe even Sunday or Monday. So the thawing process basically is that we set, we release an update to the cloud. which basically, and that update basically tells miners to start voting the gas limit upwards. So right now the way the gas limit is set in Ethereum is it's basically this voting mechanism

where each block has the ability to set a gas limit, which is within about 0.05% of the previous gas limit. And so over time, you know, if you think it's too low, you can sort of push it up, if you think it's too high, you can push it down. So it's a sort of voting mechanism that should target roughly the median of what all the miners wants in the long term. So within that sort of protocol rule, there are, of course, different strategies for how to vote. So the current strategy is to target just a 5,000 limit. The strategy will update to is targeting a limit of 314-1592, which is the same as we had on Olympic. Then after that, there are other strategies that we're thinking of. So one strategy that I came up

with is targeting a particular uncle rate. So uncles, for those who aren't aware, is this idea in Ethereum that if you mine a block and the block doesn't make it into the main chain, you can still get included after the fact and still receive most of your reward. So the original idea behind this uncle mechanism was that if basically to avoid penalizing miners that are too badly connected, because with Ethereum having a 15 second block time, if you are badly connected, that is a serious penalty. And, you know, there might be sort of centralization issues

with one particular cluster, ending up having all the power and so forth. So that's something that we wanted to kind of mitigate. But the other nice benefit that this uncle read mechanism ends up giving us is it ends up giving us a kind of in-chain reading of basically how all the network's doing. So if the uncle read is 0.1, that means that, you know, 91% in the blocks

are making it into the main chain and 9% aren't. If the uncle rate is 0.4, then that means that 71% of the blocks are making it into the main chain, but 28% aren't. And based off of that, we have an idea of kind of how healthy the network is. And the theory is we may be able to basically use that

in order to sort of target the gas limit. So we could say, we want a uncle rate that's not higher than 0.4. If it's higher than 0.4, then start adjusting the little bit the gas limit down. If it's lower than 0.4, and it looks like transactions are starting to fill up, then push the gas limit upward. So let me understand this properly.

Is the reason that the gas limit is related to this uncle rate because the smaller blocks propagate faster? Yes, exactly. Okay, so then basically if you notice, oh, blocks are propagating too slowly, there's a high uncle rate, lots of orphans are happening, you'll need to decrease the blocks. size, okay. That's a very interesting mechanism. I think also interesting, you know, if you think sort of Bitcoin, right, because similar discussions happened there a lot and it sounds like you guys.

Yeah, I think a lot of the sort of theoretical research we ended up doing on Olympic has similar applicability to the Bitcoin block size debate. Because what's happened, and with Bitcoin, it's having a lot of the same concerns, you know, If the block size gets pushed upward, then propagation time is going to increase, and there are these centralization risks and so forth. So, you know, in Bitcoin's case, I think currently the block propagation time is somewhere from around 20 seconds or so to get to the great majority of the nodes. And if it goes up from a megabyte to eight megabytes, then they'll go up from that to three minutes

and that end, you know, start seeing larger uncle rates. So it's a lot of kind of the same math. I mean, my intuition is that with the way Bitcoin currently is now, something on the order of 8 to 12 megabytes is going to be safe, anything higher. I mean, you know, if they figure out how to make convertible blue lookup tables work well, then that might be a way forward, but we'll see. Well, let's come back to this later. We actually wanted to ask you about that.

But the one thing we didn't get to talk so much about the last time you had you on, and this topic we wanted to talk about, is scalability. I think it's the one topic that you've been most interested in, and I guess it's a topic I'm becoming people interested in as well. And then, of course, you guys have the advantage that you sort of can go from scratch, really think through what way to go about it. It is quite frankly, I think, a complicated topic for, for us who don't spend that much time thinking about the technical aspects of it.

But you've written a really nice white paper, which is a 50-page, very comprehensive white paper. So I just want to briefly sort of read out the problem, which I think will make sense to anybody. So in the, what do you call it, the sort of abstract, you write, so all blockchain consensus protocols have an important limitation, and that's that every full participating node in a network has to process every transaction, right? So it's pretty obvious that if that's the case, then, well, then we're going to have this sort of discussion we have in Bitcoin now. Well, the only way to scale is to make transactions huge or maybe do some sort of off-chain thing.

make the blocks huge. So what is your, what's your thinking? How should, what is an alternative design that does scale better? I mean, to start off, there are two easy but bad ways of solving the scalability problem. So the first way is to just say, okay, let's have a thousand blockchains. There's two reasons why that's bad. One reason is that interoperability is harder and it becomes, becomes harder to sense transactions that have effects between one blockchain and another

blockchain. The other much bigger reason is that each one of these blockchains is only going to have a thousandth of the security. The second bad way of fixing scalability is to just say, let's have big, big, big blocks, and let's rely on all the consensus participants having big, big, big servers, and that's the solution. So the first one compromises security. The second one compromises decentralization.

and particularly I think some of these centralization effects might end up compounding with each other. So for example, you know, with mining, if we see the blocks is increased by a factor of a thousand, then we could easily see just throughout everybody used two or three mining pools and then switch to using one mining pool. So that's going to be a bit problematic. Now, the approach that I'm outlining in that big long paper is basically that instead of trying to have every node process every transaction. You sort of organize transactions into groups that have effects on sort of the same part of the state. And then you take these big collections of transactions and you send them off to a random sample of validators to verify. So let's say you have 10,000 transactions that affect

like this sort of one corner of the map. And you might think of that corner of the map as, say, being all addresses that begin with 3.5. And so one of the important problems, properties of this kind of design is that you actually have to sort of think a bit about positioning, and you have to kind of think about, well, okay, I have a contract and I want to position this contract sort of close to other contracts that are going to be interacting with it a lot. So, you know, this is sort of general theorem that it's impossible to parallelize arbitrary computation. And therefore, you know, that means that if we want scalability, the abstraction is just going to have to be leaky to some degree. So, you know, the idea is anyway is that you have this big, set of maybe 1,000 and 10,000 transactions with addresses beginning with 3.5. And this collection gets sent off to this random sample of 135 validators. Then that collection has a, what we call a collection header. And it's the collection header basically, you know, it contains a hash of the collection. It also contains the state route before applying the transactions and the state

route applying after the transactions. So the person who creates the collection has to figure out what the sort of very fine-grained effect of all those transactions is, and just summarize it with the Merkle Route. Then once that's created, the person that creates the collection sends that collection with a bunch of Merkel proofs, with the Merkle roots, with the header, along to these validators. The validators all check that it's valid, and they all sign it. Then, when you have the signatures, you take the collection header, and then you add the 135 signatures to the collection header,

and then you put that into the main chain. And the main chain basically follows a principle of, well, if two-thirds of 135 randomly selectionality, or say it's correct, then it's correct. So the header chain almost doesn't even know what's happening at the bottom level. And so this is the kind of principle that it's working on, you know, that you have all of these different groups that are creating these collections, all, you know, hundreds of collections in parallel.

The collections all get signed in parallel. Then finally, the signatures make the route by the top chain. And the top chain kind of keeps track of the status of these Merkel roots, which are basically summaries of what goes on at the bottom. I mean, that's, of course, a very design that seems to make intuitive sense, right? So you have all this stuff. You try to divide it up, give it to some subset, you know, they process that, and then somehow you integrate it back together.

But the obvious thing that jumps out here, you mentioned contracts have to be close to each other. I mean, what are the implications of that? So, like, I come with my random wallet. Yeah. So to some degree, this depends on what application you're using. So I think with Ethereum particularly, in some cases it's not going to matter. So, for example, you could imagine Auger existing in sort of one of these subspaces, then, you know, Azus existing in some other subspace,

then some stable coin existing in some third subspace and so forth. And if people that use one application tends to just use one application, then it's going to work mostly fine. The problem comes from, well, what if I have some money in, or some, more general even, what if there's some contract in, say, Subspace 35, and it wants to send off a message to something that's in Subspace 68? Then basically what's going to happen is that, well, one of two things might happen. There's actually two strategies for handling this.

There's a synchronous strategy and the asynchronous strategy. So the synchronous strategy basically says that, okay, what we're going to do is we're going to wait until there is some collection of transactions. And that processes simultaneously subspaces 3,5, and 6.8. Then once that collection happens, in that collection, everything can happen synchronously. Now, and the theory is eventually that collection is going to happen, the transaction is going to get in, and it's going to have exactly the effect that it's all going to work basically the way it works now.

The problem with the synchronous model is that it's going to take a very, very long time until all of these sort of possible pairs of subspaces end up appearing in a collection at the same time. And if you imagine a big long chain of events that triggered by a transaction that might affect, say, five or ten random different subspaces, then it's going to take a billion years for it to get in. So the asynchronous approach, this is the approach that, I mean, it works pretty well under a slightly modified synchronous model.

It's also one of the approaches that Dominique Williams has been working on, is that basically you say that if a transaction has an effect that goes into a different subspace, then basically it doesn't have the effect immediately. The transaction just kind of creates a receipt. And a receipt you can think of as being something that just sort of gets Merkel hashed in and it's kind of registered as saying, subspace 35 created this receipt.

Then half an hour later, on subspace 68, you would say you create a transaction that kind of pings the contract on the other end. And then what that contract does is it checks, okay, are there any receipts in subspace 35 that are not yet registered as having been sort of used up by subspace 68? If there are, then that means that there are new receipts and all of these new receipts you sort of start making a computation. So the idea is that, you know, sort of every, and then when you do make a computation off these receipts, then the receipts end up sort of in subspace 68. the receipt ends up being marked as used and it can't be used anymore.

So the idea is a sort of asynchronous two-step process. It's vaguely similar to Peter Todd's tree chains in some sense as well. So, you know, basically you have a kind of, it's a sort of debit credit system. You have, you know, the contract in subspace to be five creating an effect. And then later on, the contract and subspace like, say, takes the advantage of that effect. Let's take a short break so I can take you to Paris. I dropped into La Maison du Bitcoin, the House of Bitcoin, the House of of Bitcoin in the heart of Silicon Sontier, home to many startups, including Ledger.

And I spoke with Nicola Baca Ledger's CTO about the level of security in their devices. Well, Ledger is based on a smart card chip that is exactly the same smart card chip that you have in banking chips and in passports today. But something that has been validated for the industry for more than 20 years. Today's a favorite second factor is the phone. When using a phone, you are transmitting an encrypted version of your transaction to the phone to the screen that can be displayed to you and validated to you. So we leverage on two insecure devices, your desktop and your phone to create a secure validation

with ledger. We believe that hardware wallet are very primitive today. They are just used to confirm transactions and to display some validation. And that's it. In the future, as Bitcoin Protocol moves towards smart contracts to add a lot more use cases, we believe that those devices will evolve into something that I would call consensus devices, which basically will be able to confirm for specific services, specific rules. How easy would it be to hack a ledger?

It wouldn't be very easy, to be honest. I think the best would be for you to try physical attacks first, like glitching, like sad channel attacks. If you want to really attack it, you will need to get a bit more equipped with a focused yon beam station or a scanning electron microscope. So that's going to cost you probably a few millions. and as well you are going to be able to decad the chip,

so that's going to be a bit risky for you at well. But you are free to try, of course, and let us know if you manage to do anything. Ledger is building the infrastructure, which will provide the best level of security for the Bitcoin industry. You two can benefit from this technology and get an affordable secure setup for storing your bitcoins

with the Ledger Nano. So go to ledgerWallet.com and use the offer code EB-09 to get 10% off your first order that offer code is valid until September 30th of 2015. We'd like to thank Ledger for the continued support of a percent of Bitcoin. Are there some security implications because is it received as trustworthy as receiving a transaction? So the idea, so the implications are, so the thing that you want to avoid is he wants to avoid a situation where, let's say,

subspace 35 sends a transaction, then that ends up having an effect in subspace x-8. But then as it turns out, that particular block in Sub-Space 3-5 ends up getting reverted for some reason, and then you have an effect without a cause. So there are two ways of avoiding that. One way is this synchronicity approach where you basically end up saying that if subspace 35 ends up getting deleted, then pretty much, or reverted, then all of the sort of children in what I call the dependency code also get reverted. So the dependency code is this idea that, you know, you have a...

Basically, the block, and then every block that's dependent on the block, every block that's dependent on the block that's dependent on that block and so forth. And so you can think of, you know, a change in one subspace that's sort of eventually propagating to every other subspace in a kind of butterfly effect. So theoretically, you can calculate the dependency code, and you can sort of revert the entire code. The second idea is that you basically say that in order for this receipt to be claimed,

you have to wait until it gets finalized. So there's some point at which you have this concept of finality, where in subspace three five, at some points you agree that this block is never going to get reverted. And at that point, only after that point will you be able to claim this receipt in another subspace. So, look, these receipts, what they're going to be. basically are, is they're kind of sort of cryptographic documents basically saying, here is an event that happened in this one subspace. And then that event might be something like contract three five, some contract agreed to send 10,000 units of, uh, I don't know, e dollar to

68154. Then, you know, later on, if let's say you are user 618154, then what you can do is you can create a transaction that basically sit pointing, hey guys, over here in subspace three five, I have a receipt address to me. So it's a sort of internal protocol mechanism for like keeping track of these sort of cross substate events that get created. I mean, it almost reminds a bit as well

of the side chains idea, you know, of having these SV proofs in one chain and then using that and the other chain. Yeah, you mean, you can definitely think of it as being a side chain type protocol. Today's magic word is Frontier. F-R-O-N-T-I-E-R. Head over to Let's TalkBitcoin.com to sign in,

enter the magic word, and claim your part of a listener reward. So what are some of the other ways to solve scalability? So you wrote a blog post recently about state tree pruning. Can you explain what this? Yeah, so state tree pruning is, I mean, it's not the ultimate solution because, you know, every note still processed every transaction in state tree pruning.

But the idea is that, you know, right now, one of the problems with the sort of murgletree approach that we took is that, you know, basically Ethereum clients store the state a full copy of the state

after every block at any point in history. So, you know, they store the entire history, they store this, you know, the balance of every account, every storage item of every account at every point ever. So this is... So then also, sorry to catch you up,

but that also means like the code of every contract. Yes. Okay. So that's, I mean, it's not as bad as it seems because, you know, most of the time from one block to the next block, the state is almost the same and there's not much extra information that has to be stored. But even still, it's inefficient because what it means is that because of the way that the Merkle trees are constructed, every time even one storage key is updated,

that's another maybe 1,000 bytes worth of tree nodes. have to be stored in the hard drive. So the idea was state tree pruning is that, well, if, let's say, at some point, there are some nodes that were part of the Merkel tree, and then a new block happens, and those nodes aren't part of the Merkel tree anymore, then at some point after, let's say, 5,000 blocks, those old Merkle tree nodes just get deleted, so they're not stored anymore. So the idea is that, you know, yes, we'll be storing the current state,

and it will be storing 5,000 blocks of historical state, but we're not going to be going beyond that. So that has the benefit that it's going to be much more efficient in terms of state size. So it should be able to reduce the state by quite a lot. But on the other hand, it's also a bit, it does, well, the one issue that it introduces is that clients are not going to be able to revert

more than 5,000 blocks. So if you revert more than 5,000 blocks, thousand blocks, then basically you're screwed and you have to redownload the whole chain. So this is the sort of one vulnerability that you get as a trade-off, but, you know, I think it's an acceptable trade-off in exchange for cutting down storage costs by factor of 10 to 100. So, you know, without this, on the Olympic TestNet, we got up to somewhere between 10 to 40 gigabytes of sort of total storage. State true pruning should be able to lock that down by a factor of quite a lot, you know,

more than, definitely more than 10. One thing about Olympic, though, is that there are a lot of people that were kind of deliberately spamming the network with transactions that tried to sort of take up as much storage as possible. But that's something that is, you know, it's not going to happen on Frontier because in Frontier, you know, we specifically economically incentivized being sort of economical with your storage and even clearing as much as you can. So, you know, with Frontier, there should be almost as much clearing as there is adding. And so in general, state reprooting is just this optimization to save on hard drive space. So, you know, instead of storing 100 gigabytes, you've got to store 5 gigabytes, and that's great. The things that it doesn't solve are, first of all, you know, the cost of processing transactions. It doesn't solve bandwidth issues.

And those two things are ultimately going to be what defines these limits of scalability for Ethereum. Okay. And I mean, but any, you know, given the potential that Ethereum has and sort of the long-term, you know, the long-term outlook of Ethereum, you know, you want to try to keep that down as much as possible and implement every scalability solution possible so that it is scalable over the long term. So one of the things that has been talked about in which we can go into and now is that in a subsequent release of Ethereum, we'll be moving from preterm. proof of work to proof of stake. So can you talk about that and what is the relationship there with scalability? I don't think proof of stake is a scalability solution. I mean, it can improve things slightly because there are ways that you can sort of reduce some of these centralization issues and say make the system work when, say, you know,

every node is humming out, a full node is humming along and say 50 or 100% CPU utilization instead of 10%. But it's ultimately not going to solve it. The thing the proof of stake will do is it will allow us to provide much more security, much more cheaply. So, you know, there's people that sort of always keep on saying that, oh, you know, you can't use, you should only use the Bitcoin blockchain because it has 100 times more hash power that makes it the most secure.

Well, with proof of stake, you theoretically have, you know, we can calculate as all being basically the same security margin as Bitcoin and even faster. So the way that these product, the way that our current thinking in terms of proof of stake works is it's a sort of multi-round protocol where every single round people basically, or the validators basically make bets on which blocks they think are going to end up being in the final chain. And people have the ability to make these bets at kind of whatever ratio they want, three to one, nine to one, 50 to one, 100 to one.

And, you know, the theory is that the higher you bet, the larger the reward is, but the higher you bet, you know, the much, much more you'll lose if a block ends up not being in the main chain. So the general approach is that, you know, there are multiple sort of candidate. blocks, people end up betting, one of them ends up getting more bets than others, eventually kind of converges, people bet three to one for a block. Once you see that every other valetor bets bet three to one for a block, you bet nine to one for that block, once you see everyone also betting nine to one, you bet 27 to one and so forth. And eventually one, two-thirds of

people are comfortable betting 10,000 to one, that's when you call the block finalized. So, one of the sort of economic arguments that I've made is that... Just jump in, I think that is absolutely fascinating way of arriving at consensus. I have to say that that sounds brilliant. And so one of the interesting things is that proof of work to some degree is also a betting game. Because with proof of work, basically when you mine a block, you are saying, you know, I am making a bet where I agree that if I mine this block and it gets in, then I am going to win 25 bitcoins. But if I mine a block and it doesn't get in, then I am going to lose some number, let's say, 10 or 15 Bitcoin's worth of electricity costs.

So to some degree, you know, when you're actually downloading the longest chain, you actually are literally checking for, you know, which is the chain that the majority of people are willing to bet on. So, you know, the advantage of proof of stake here is basically that instead of the sort of amount of money at stake converging linearly, it kind of converges exponentially. Just let me jump in here and ask a little bit more about this. So if the point at which the block is chosen and says that's the one and gets in is when the ratio is 10,000 to 1, I mean, isn't there implication that somebody, if they have a lot of financial power, essentially just put that money up and then you get in? The idea isn't that anyone has the ability to bet. The idea is that there are these validators.

and these are like validators that put in a whole bunch of money in the proof of stake system and each of them has the rights to vote a particular amount. So theoretically, you know, if you have a lot of money, then yes, you could take,

you know, you could throw it all in and you could sort of make whatever block you want to win, but that's basically equivalence to a 51% attack. So the amount that that would cost is basically, you know, more ether than there would be deposited in the stake system in general, period. Okay.

No, no, that makes sense. So I wanted to ask about 51% attack. So what does a 51% attack look like in Ethereum? In proof of work Ethereum or proof of stake Ethereum? Well, let's both. Proof. I mean, proof of work Ethereum is just like Bitcoin. You know, you just mine your own, go 100 blocks back, mine your own chain.

Your chain is longer. And bam, you win 100 blocks to get reverted. That's not different at all. In a proof of stake, it's, uh, So there's two possibilities. I mean, one possibility is a sort of attack before finality and the other possibility is sort of attack after finality. So before finality, you know, theoretically, it might be possible for you to sort of slightly bribe all of the voters to sort of switch over for one particular block to another. And, you know, you might be able to have some

amount of influence there. But, you know, we don't sort of treat that as being too much of a problem because, well, the block is not supposed to be finalized at that point anyway. after finality, what that basically means is that volu validators basically stakes their entire security deposits on that particular block being finalized. So one thing that could happen is if two-thirds of the validators end up being, end up basically wanting to create a new fork, then they can say, okay, well, we're going to, we already voted on that block, we're also going to vote on this new block. And, you know, when that happens, that means that all these validators are going to have to lose their security. deposits on the, but you know, they'll be able to sort of make two chains and those two chains will all look indistinguishable from each other. And at that point, basically, the system goes into this mode where it kind of uses subjective resolution. So, you know, users would individually

look at which chain they saw first and, you know, eventually sort of a consensus would form around one of them. But this is the kind of emergency mode, you know, the cost of it should be basically economically equivalence to, you know, buying more A6 than the rest of the Bitcoin network combined. And at that point, basically having power the power to sort of screw up with it to whatever extent you want in any case. And so with double spending, so in Ethereum we have two types of transactions, right? So we have the monetary transaction of financial nature and then we have contracts. What is the risk of double spending on a contract?

Does that look like you can rerun the contract? So the idea basically is that you be able to revert blocks and when you refer, word blocks that means that you know if there is some instance where a happens before B, then in the new block you created you might have a situation where B happens before A. So one example of a 51% attack might be is that let's say I register on the Ethereum name registry, Vitalik.eath. Then you decide, ooh, I'm an evil advertiser. I want to have that page for myself and I want to create ads about pornography on that site. Then basically what you do is you say, you

You do a 51% attack where you sort of revert all the blocks at the, before the, after the points where I registered Vitalik.Eath, then in your own private chain, you would register Vitalik.eath for yourself. And in your chain, you would have, you would own that domain, and you would be able to point the domain to where, whatever you want. So, you know, that's another example would be a lottery. So for example, or just gambling in general. So if you're participating in some kind of gambling,

application and you lost a big bet, you could try to reverse the few blocks and instead of reach Rianti if you win the next time. So another example might be a market. So for example, if people are replacing orders, then let's say some big event happens and because of that price is suddenly moved by a lot, then you might want to sort of revert the blockchain by a bit and be able to claim all of these sort of historical orders that are up prices that are really much, much, much higher than they currently should be. So like basically every different application has sort of its own different set of things that you could potentially do if you had the ability to magically reverse the watchings time.

Okay, but I guess the idea is that with proof of state that will be more expensive. I wanted to circle back very briefly at one point there. So you said in the case of 51% attack, the attackers, so these two-thirds of the validators that would execute that attack would lose. their security deposit, but how is that possible if the chain is forked? Wouldn't then they be able, at least on that fork that they control, to still have that security deposit or to roll back to the point where they had it? So actually, so basically this, it depends. So theoretically, they control the chain and they, you know, they can refuse to accept transactions. But I wrote this blog post on censorship a few weeks back where basically pointed out,

that if even a monopoly coalition of users controls a particular chain and they wants to sort of make that chain available to everyone, then there are going to be ways to sneak transactions into the chain that ends up having the effect of basically doing it just about anything. And one of those things could be destroying security deposits. So it's, you know, they basically theoretically would be able to, but at the cost of like basically, you know, just showing the functionality of the entire network. And at that point, the value of their security deposits will be knocked down to zero in any case. You're listening to this show in parts, thanks to all the support we get from our great sponsors.

We have some fantastic companies who work with, and we're very proud of what they do and of their products and the companies be happy to stand behind. Every week, we reach a large audience of thousands and thousands of people deeply involved in the Bitcoin cryptocurrency space, people running companies. these people having a lot of influence and people who are just enthusiastic about technology, about progress and about the future. So if you're involved in a project or startup and think that reaching our audience could help you, email show at epicenterbitcoin.com and let's talk.

So just very briefly before we move on, you know, besides their main client, right, some of the things you guys are working on is whisper and swarm. Yes. What's their role, particularly in the context of scalability? Are those relevant for scalability as well? So and maybe just... I mean, they are relevant, there aren't relevance to blockchain scalability,

but they definitely are relevance to application scalability, because applications definitely should be doing a whole bunch of things off the blockchain so that, you know, if you don't need consensus on them. And just for listeners who aren't aware of that, so Whisper is the files, no, Whisper is the messaging system, and Decentralize messaging, and Swarm is. is a file source system or the other way around.

Yeah. Correct. Okay, so you've really mentioned before the topic of governance, and that's actually something we wanted to talk about. I think it's something that's really important that we start covering more because it's a tricky topic that's sort of under, I think under-discussed.

And we're going to have Gavin and Rusen on soon to talk about this topic as well. So in this context, you guys just added a new foundation board. Yes. Can you tell a bit about that and what's going to be the role of the foundation board in the development of Ethereum? So we brought in a new executive director, Ming Chan, and also three new members to the foundation board.

So then the foundation board is going to be the board of the foundation, you know the sort of governing group that sort of ultimately makes decisions um they are in the I'm I mean they basically are doing the same sort of things that a board of directors would do in any kind of regular and nonprofit organization um and uh I mean there are also other sort of specific focuses you know things like fundraising things like sort of managing institutional partnerships that are also important. Okay, so first of all, when you talk about them doing something that any other nonprofit

foundation board would do, well, I mean, I think normally, because we have a sort of a weird tension here now, like a foundation is a centralized institution, and then it's running this decentralized protocol. Right. So, I mean, the foundation isn't really running the protocol, so to speak. I mean, right now, you know, it is the one that's developed a soft, But it's the, and, you know, the foundation is going to have sort of a lot of, I guess, moral authority over it. But, you know, moral authority is basically all that there is.

So, you know, if the foundation ends up acting in some way that's objectionable, then people can create sort of a different thing and call it Ethereum. And, you know, the Ethereum ecosystem will ultimately kind of end up following that. So. And so there's one thing that point out here, most of the people on the board are not, I mean, apart from yourself, are not. from the crypto space, was that a choice? Or did that just sort of happen? Yeah, it was a choice. And why did you choose to do that?

In part because just because we wanted to sort of help expand Ethereum beyond just the existing crypto space and try to push hard toward, you know, sort of mainstream institutional adoption. It's, you know, basically just part of this whole idea of, expanding, you know, that I've been caring about quite a lot over the past half years, really just expanding beyond a sort of small crowd that's sort of congregating around things like Bitcoin and old coins and moving it toward, you know, opportunities to actually sort of help people on a large scale. And doing that necessarily involves having sort of input from people that are from these more traditional industries. Yeah, I mean, that definitely does,

make sense. Now, the foundation will have the task of managing the funds that were raised on the crowd sale. And so essentially how it works for people who don't know is there's a foundation who has the funds from the crowd sale and they pay East Dev as a for-profit company developing the software. I'm curious like, what will that look like in the future? Like how much money is left from that crowd sale? And what is the first of all, importantly, this idea of if Def being a for profit company. I mean, technically it's registered as a company, but you know, it is a subsidiary of foundation. So this isn't, this isn't like, you know, myself, Gavin and Jeff have shares and we're and we're sort of contracting with the foundation right now. It's, uh, if dev is basically an arm

of the foundation. Now, in terms of how things are going to go in the future, there definitely are sort of a lot of people inside Ethereum that are heavily interested in doing their own thing. And that could, that would entail starting a company. I think we'll see multiple companies. There's, you know, people are interested in going toward applications. Some people are interested in sort of staying in working on the core. So, I mean, I think it's going to be impossible to avoid sort of some kind of diaspora effects in that sense. But I think ultimately, you know, which organizations we're involved with might not necessarily matter too much because, you know, we're ultimately all going to be in the same Skype groups. We're all going to be developing the same sort of stuff.

and in any case. In the long term, one of the ideas was for the foundation to take on sort of a more, I guess, advocacy and communication-focused role. But I think we're still deciding the extent to which it'll be that and the extent to which the foundation will sort of directly be running and managing development. So then is the idea that eTH dev continues to be the core developer of the software or that, or that's the idea? all these smaller companies, spin-off companies, then... I think the spinoff companies are going to end up doing increasingly more over time. I think a good outcome would be something similar to Linux, where 75% of the code is just written by companies in the space.

It was the foundation right now, in terms of how much money it has left. The foundation's current capital is, I believe, somewhere on the order of 1.5 to 2. million or so, not including the ether. Now, including the ether, of course, there is quite a bit more. And right now nobody knows really what the exact price of ether is. If I check on coin marketcap.com for ether coin, that's obviously sort of one of the bellwether is that I guess some people are looking at, but it's a... It's currently at a...

Yeah, currently at 280. There are exchanges where you have bid orders already popping up. Some of them are going somewhere on the order of $1 or $2. So, you know, it's very hard. I mean, right now it's hard to say. Once this sort of thawing process happens in three or four days and we actually start seeing a large amount of volume, and then I guess we'll see just how rich the foundation is,

I mean, it could end up sort of surviving for any amount of time between six to eight months and something like that. And I mean, if Ethereum really goes up, then, you know, forever. And but then it supports to note that, you know, ether isn't the only route for the foundations to get funding for continued development. So, you know, there are just sort of plain old donations and sort of Bitcoin Foundation style memberships. You know, there's a lot of possibilities. And that's one of the important points that, you know, the board and directors are actively working toward.

Okay. Okay, so that's very interesting. One of the things that I was talking with Taylor, Gering at some point, and he mentioned the topic of private blockchains, and he mentioned that Ethereum was specifically set up to support that. And I also saw on, I think, Sebastian, you saw it on one of the pages. It mentioned basically how you can say an identifier and basically run sort of your own private Ethereum network. what role do you see for that?

Do you think that's going to become frequent usage? Or do you think most? Yeah, I think there's going to be lots of private networks. I know a lot of groups that are very interested in that concept already. And for what applications do you think that these private networks make sense? And for what applications do you think people would choose the main Ethereum network? Right. So I actually have a blog post on this and I'm going to publish the next couple of days.

But the general idea is, I mean, both categories have different advantages. So with private networks, for example, you know, it's sort of easier for whoever is creating the application to sort of have control over it to have the ability to quickly update things if they need to reverse transactions and so forth. Things are also much, you can also have much lower latency, faster transaction confirmations. You can also have potentially cheaper transactions, higher scalability, and higher transaction throughput. Now, with that particular part of the calculation, I think, is going to change a lot once scalability comes in. But, you know, this is the world we live in right now. Public blockchain, they have two benefits. One of them is the no-trust aspect.

So you can create applications where even you don't have full control, and even the developer application either has no control or partial control. The second thing that's kind of important is a sort of network effect argument. So the idea here is, let's say take one particular blockchain application, let's say domain name transfer escrow. So the idea here is that, you know, there's in general, if I have a domain name, I want to sell the domain name to you, then the issue that we would have is that, you know, either it's a standard counterparty risk problem. If I send the money first, then you might not send the domain name. If you send domain name first, then I might not send the money.

And in general, we have entities on the internet that work to sort of to solve this counterparty risk problem that are just escrow providers, but they charge 3 to 6%. Now, blockchain-based solution is, if you have domain names on the blockchain, and if you have money, on a blockchain, then you can send your domain name into a contract, which automatically hands it over to the first person that provides the money. So the trade becomes atomic. It either happens or it doesn't happen. And, you know, with that, you can basically cut the escrow costs down to three cents. And that's a really cool application, and it's wonderful. But one of the important point is that in order for that application to actually work, you need to have domain names and

currency on the same public blockchain. Or all the same blockchain. But, you know, ultimately it's going to be very hard to sort of, I think, for people to agree on a sort of private blockchain for everything, because that would just involve so many industries. So I think the public approach is going to win out for that sort of stuff. Yeah, that makes perfect sense. I think that's going to be very interesting to see how that goes. And I'm sure there will be a lot of sort of interoperability as well where maybe private blockchins will be interoperable with the public blockchain. Absolutely. I wanted to circle a little bit back to this governance topic, especially because it's been such a, you know, because of the block size debates mainly.

I'm sure you've been watching that as well. And, you know, before Ethereum, you were deeply involved in Bitcoin for a long time. What are the main takeaways that you've learned from watching the block size debate when it comes to Ethereum? Right. So there's two issues there. One of them is a sort of object level. issue of, well, you know, well, how do you regulate the block size? And the thing is that, you know, with Bicklin has always been, the choice has always been between sort of one megabyte and eight megabytes, and it hasn't really advanced much beyond that. But, you know, with Ethereum, we've always sort of been not thinking, not about numbers, but about mechanisms. So, you know, originally the thought was fixed value. Then the thought switched over to this sort of exponential

moving average approach. Now I'm switching over to this uncle retargeting approach. And I think that the sort of choosing institutions instead of choosing results in general is a kind of more robust way of doing governance. But the sort of meta-level concern is that, you know, in general, how do these decisions get chosen? Right. So let me just jump in because you guys, you can maybe have those discussions and say, oh, we're going to talk about institutions and mechanism, not about end result, because you have much more control over that whole. discussion. And Bitcoin, nobody has that control.

I mean, you can go in there and say, hey, we need to talk about the process, not the result, but that doesn't mean anybody's going to listen to you. Yeah, I agree. I think that, yeah, I mean, Ethereum does benefit from a sort of greater degree of development centralization and sort of feel just, I guess, moral centralization to some degree. And, you know, that does have benefits. And do you think that's something that because of exactly that you would want to maintain in some extent?

I think that in the long term, something that's sort of highly decentralized is necessary, but I think like these are, this is the kind of phase where having some group of people that sort of has a sort of, this sort of shelling points of greater moral authority definitely

can help sort of move the community forward in one direction. I think, I mean, I think it's kind of like the frontier canaries. I think it's a training wheel. It's useful now and it's going to get less and less useful over time. And at some point, you know, switch over to the points where making it as distributed as possible is the correct thing. Yeah, of course, like one of our listeners pointed this out.

You could have that built into the Genesis block. You could have the governance model built in. Yeah. Why was that not done for Ethereum? Was that something that was successful at some point? It was just something that we, I mean, for a lot of those things, we just didn't have enough time to think of them. And we wanted to just keep frontier simple.

Is that something that could be implemented in the future or is it too late now that it's been released? I mean, something it could be done so one of our ideas for 2.0 is basically to have this idea where people can vote on changing the code and even having as much of the code as possible be inside of the virtual machine language

so all the changes could literally be sort of processed just automatically on the consensus level. Okay, cool. So before we come to an end here, we're sort of at the end of the technical discussion. So looking back on the last, two years and you've come a long way from writing the white paper to now releasing Ethereum, you know, can you give us sort of an idea of what you've been through? And if you would have

done anything differently, what would that have been? There's a lot of things that I would have done differently. I mean, first of all, I think just the way the project formed was just incredibly non-standard. Like most sort of startup-like things tends to be, oh, hey, you know, here are a few of us. We're friends and we have a good idea. Let's have a good idea. Let's work together and make it. Whereas Ethereum was, hey, I have a white paper. I'm going to send it to 20 of the people that I just happens to know in the last one or two years. And, you know, the first 20 people to respond back on the email or Skype just ended up being co-founders. So that was a sort of approach that's highly non-conventional. I ended up having its costs.

And, I mean, there definitely were sort of moments internally where the thing came. it looked like it was coming close to pulling apart on a couple of instances, but, you know, ultimately we got through. Can you elaborate a little bit? Like, what were some of the instances that this approach almost made this project fail? There are, I think, a lot of sort of cultural misalignments, especially sort of between people that are kind of more like developers, people who are more like non-developers. I think that the thing is that in general, you know, just to build just about anyone can be, can sort of theoretically be a business development person. And there is, whereas, you know, with developers, it's so, you know, with coding it's something where a lot of people just, it's obvious that if someone can't do it at all, and if someone

can do it, that means they can do it at least decently. So, figuring out sort of really how to structure the sort of non-technical side of the team, I think, is important because, like, non-technical people, I think, are extremely crucial, but the difference between people that can really push a project forward and people that just sort of hang around is, I think, a big one. There's, I mean, just on the cultural side, I think all people had all these sort of different visions, but, I mean, that's inevitable to some degree,

but it's something that really sort of needs to be handled while. I mean, there was sort of, on the technical side, I think we sort of ended up doing, one of the problems that we kept on having over and over again is we kept on thinking that the project is going to launch in two or three months. And so we ended up sort of continuing to try to keep all these sort of clients up and walks up with each other. And that ended up slowing development down by a lot. and we ended up trying really, really hard to get consensus between C++, go and Python on features that don't even exist anymore. So that was something that, you know, if we had thought carefully on that, we could have easily, I think, cut the development time down by at least three or six months.

In terms of just costs, I mean, there were a lot of costs that we had early on that we didn't need to have. You know, these sort of $1.7 million that we spent even before the crowd sale, I think, obviously could have been greatly optimized. I mean, to some degree, this is all kind of first-time major business experience, both for myself and for a lot of other people on the project. But I think that, you know, from here we've earned a lot of lessons in Denver, and foundation is going to be quite a bit more sort of efficient and focus going forward. in terms of, yeah, I mean, from a technical standpoint,

going back to this multi-client issue, I think, I mean, once again, opinions differ, but the approach that I would have preferred is to have maybe stick to two clients and have one clients not even bother with networking and just sort of interpret the blockchain at least right up until maybe two months before launch, and only at the sort of two months before launch point

to actually start bringing the networking up into consensus with each other. Proof-of-work, I think we personally think we should have just stuck with Shaw-3, because as cool as the ASIC-resistant proof-of-work algorithm is, and as much as it's, I think, it's nice that we have it now. The time that we lost, I don't think it was worth it, especially given that proof-of-work is only going to exist for about a year. So, you know, knowing what I know now, I would have just sort of stuck with shot-3 for the proof-of-work

and went straight to Bruno steak after that. Cool. There are a few other protocol changes that were kind of like that as well. These are a lot of things. There's another topic we briefly want to come to. So Ethereum, of course, you guys are using this notion now or this term of a world computer, which I really like. I think it's a good metaphor.

And one of the characteristics of features of such a world computer is that it's enormously powerful. No, one could, assuming everything works well, you know, one could do great positive things. Right, so this is right now this is the world smartphone computer. Yeah. In two or three years when we have scalability, it's going to be the world super right. Right. Right now it's a very shitty sort of world computer that can do any transactions. But, you know, presumably, assuming, you know, it works out, it can be very powerful, right? And of course, people will presumably do many great things with it, but also bad things with it. How do you feel about that? Is that something you worry about?

Bad things? Yeah, I mean, people are, it's definitely going to happen. And at this point, we kind of don't really don't really know what's going to happen to some degree just because it's, that it's not even watched yet. Honestly, we haven't even seen any activities in the sort of community. Like, I've seen absolutely no, nobody even suggest the idea of, you know, even, I mean, even something that's sort of on the, that's sort of borderline controversial, like, So it wrote on Ethereum. Like, no one's even brought that up.

And that's, I mean, that's kind of, I think, from a sort of PR standpoint, it's definitely a positive sign. Yeah, I mean, I think more talk also the long term, right? Recently, yeah, in the long term, definitely. I mean, I think if you think about it's sort of inevitable like any, you can't blame the software. You can definitely do harm with C++ or Linux or any type of software operating system, what have you. But there is potential there because it is quite game changing since there is no central point of failure, etc. Like, you know, if we look at this on a more high level, like recently, this is a more high level, like recently, this is, is sort of

topical because recently Stephen Hawking's Elon Musk I think Steve Wisniak wrote this open letter calling for the ban of autonomous weapons is you know in the context of Ethereum is

is this something that you can see is potentially in the future powering really really bad technology or harmful technology for humanity I mean if Ethereum gets anywhere that I'm sure it'll end up powering really bad technology just because, you know,

things that get really big are going to always end up having some good and some bad in them. It's, I mean, not to give the sort of core really cliche its standard response, but it's just like the internet in that sense. And what's your view in this context, just on AI in general, like strong AI? Is this something you think about? Oh, AI is definitely a problem. I mean, to some degree, it's orthogonal to the blockchain issue, just because, you know, here we don't even have

sort of anything close to smart AIs yet. But it's, I mean, this sort of idea that at some point when AI becomes slightly more intelligent than humans is going to become really good at optimizing itself when it becomes even more intelligent, even more and more intelligent, and become this sort of singularity thing that, you know, depending on whether or not we program it well,

is either going to make our lives grill or really nice, or it's just going to fill the universe with paper clips and choke everyone. that's yeah I mean that's definitely a concern and I definitely applaud everyone who's working on solving that problem to what extent that ties together with blockchain issues

I'm not sure because I mean the thing is it's almost a sort of completely different category of stuff like the sort of decentralized technology is they enable all these sort of applications that are unstoppable and that sort of allow people to create these kind of complex patterns of interaction

that cannot be prevented. And, you know, yes, there definitely are sort of these patterns of interaction that are going to end up leading to bad things. But ultimately, you know, at the bottom of it all, it's still humans doing things,

doing things with humans to humans. So it's, to some degree, a bit more mundane in that sense. So where do you see your role in Ethereum going forward? I know you don't plan very far ahead, but is it something that you see? you see the stuff working on for, you know,

months or 10 years, or are there other areas you're interested in other things like the world? If the Ethereum ecosystem continues, you know, continues being a sort of viable and growing thing, which, you know, all indications point out that it really is, then, I mean, I'm definitely going to be in the ecosystem for quite a long time. In the ecosystem, in what capacity? I'm not sure yet. I mean, that's still something I have to decide for,

myself. And are there any other areas, maybe not directly related to decentralized technologies that you're interested in, are the places you see yourself going towards? Hmm. In cryptography, economics, all this sort of, I mean, this whole sort of rationalist community is always sort of interesting and worth following. At this point, you know, yeah, I mean, I a bunch of different things. But, you know, as I've sat, I don't really plan too far ahead. Okay. Well, this has been a really interesting conversation.

I want to say that I installed the client, and I encourage anybody who wants to, you know, get their hands dirty and give it a try to go to Ethereum.com and install geth. Ethereum.org, I have to runesethoram.com. Certainly someone who's trying to make a lot of money in domain reselling. And so one thing that you'll need to know is when you install the client, I did it on Mac. It's quite simple to do, but you do have to have either Mac or PC or Linux to do it.

Yeah, no free BSD installations yet. What's that? No free BSD installations yet, I think. Yeah. And you have to generate the Genesis block and then you can launch a node and start mining, et cetera. And in a few days, hopefully you start writing contracts. Yeah, so Vitalik, thanks so much for coming on. And I think it's super exciting that if you're finally launched and hopefully we can revisit the topic in a few months, six months or so, when we'll actually see some application, see some traction, have some more like proof. and the testing and sort of real-life context of what's possible with this, how it works. Yeah, definitely. I'm really looking forward to following that process.

I'm definitely looking forward to it myself. Yeah, absolutely. So we are the end of our show. So one last thing before we wrap up, actually two last things, but one is that we've started doing this contest, which is bribing people for leaving reviews and iTunes. Now, we do a draw once a week and one person wins a t-shirt, regardless what they write, it can be very negative or can be very, very wonderful and full of praises.

Both are fully acceptable. So if you want that, please do that and send us an email with show it, Appson, and Bitcoin. So we can know what the review was. And also one last thing. We're redesigning our website and redoing our website. It's been on our plate for a long time, and now we finally need, you know, we really need to do it. And so we're looking for our WordPress developer, so anybody who knows WordPress, who knows how to do HTML, CSS, you know, who likes to use gulp, all these web technologies, should get in touch with us and hopefully help us build our new website. Thanks so much for joining us.

So we put out new episodes of WebSend of Bitcoin. Every Monday, you can subscribe to show and Icom. or get it through your podcast app on Android or iOS. And of course, you can also get it on YouTube, watch the videos on YouTube.com slash eBitcoin. And thank you so much. We look forward to seeing you next week.