Rick Dudley: The Future of Ethereum as a Strongly Typed Proof-of-Stake Blockchain Network (Ep. 168)

Transcript

[Music] This episode of Epicenter is brought to you by Jax. Jax is a user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to jx.io and embrace the future of cryptocurrency wallets. and buy the Ledger Nano S, the hardware wallet which sets the new standard in security and usability. Get it today at lewallet.com and use the offer code epicenter to get 10% off your order.

Hi, welcome to Epicenter, the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Sebast and my name is Brian Fman Crane. We're here today with Rick Dudley. I've known uh Rick for quite quite some time because I used to work at Monx and uh he used to work uh he does still works at Monx as well. And uh Rick is one of the most opinionated people I think in in the blockchain space, the most vocal and also knowledgeable. He's been involved in all kinds of project and has a really wide uh knowledge of of many different projects. So we're really excited to have him on today. So besides uh besides his work at Monax where he's focusing on uh DevOps developer operations, he's also a co-founder and CEO of a startup

called Vulcanize which is doing a lot of work with helping startups building blockchain applications and they're also building their own product called Vulcanized DB. And he's also very involved in in Koala which is the I actually don't remember what it stands for but they've been running a blockchain workshops and doing a lot of work around u legal policy and uh blockchain technology where he's been very uh very involved in. So thanks so much for joining us today Rick. Oh thanks for having me. Well, I guess to get started, can you tell us what's what's the story of how you first heard about blockchain, Bitcoin, or or whatever it was back then and and how you got involved in this area?

So, in in chronological order, uh I was um I was helping some friends play video games for money. We were writing scripts and automating um you know, the the process of playing video games. Uh this was in 2006, 2007. Um, I was studying computer science at the time, so I knew that there should be a way to like make that not possible, so you could prevent people from uh writing these bots and playing with these bots. Um, and so I filed a patent uh for that process. I was awarded a patent for that. Uh, if you look at that patent, it's very similar to Provably Fair Gaming. Um, and I and I wrote that patent uh before the Bitcoin paper was

published. Uh then I read the Bitcoin paper when it, you know, very early on. Um I thought it was kind of weird. I wasn't super interested in it. Uh it was too risky and speculative for me. I couldn't figure out like how I was going to keep my keys and all these sorts of issues. Um then fast forward to November I'm so bad with dates. November 2014, I believe. I I had some friends from the hacker community who were in really into Dogecoin and they said, "Hey, you should come check out this Ethereum thing and tell us what you think." And there was a a meetup in New York uh with I guess a lot of the core devs, Gavin and Vitalic gave a presentation. Uh, and um, Joe Luben was running it and uh, and uh, I I

asked the first question uh, after all the talking was done and I was basically like, you know, I how is this thing going to work? Like I don't think this is going to work. You guys haven't explained to me like there's so many pieces missing from your explanation. Like how are you going to address these issues? And they didn't really have answers for me. Um, and then I went to another uh meetup later and eventually I started working with uh Joe Luben at Consensus uh February of 2015. Um, and that's that's basically how I got started to being really active uh in the blockchain space.

Now, what was your role there and then how did you transition to to Monas? Yeah, that's interesting. So, uh, so at that time at Consensus, I don't know what it's like now. Uh, people didn't really have roles. Uh, we just sort of rifted on whatever. I mean, there's just a lot of activity. A lot of meetings were going on. Uh, I wanted to develop provably fair gaming ideas. Uh so if you look at the gaming ideas that have been announced from consensus today uh not not Dow Wars that was uh Peter uh Boro but um but like if you look at like virtue poker um that was that was an idea that I had almost as a well frankly

almost as a joke. Um, but I was developing Provably Fair Gaming stuff there. And then um I just wasn't really happy working there in terms of just sort of inside baseball stuff. And then um and then so I stopped doing that. And then uh I was just doing like I was always I'd been an IT consultant before so I was just like picking up consulting gigs. And then um an a friend of a friend of mine asked me to help them pitch an idea um which was sort of the genesis of vulcanized DB and that it got me thinking about some of these questions relating to how databases and uh and

blockchains interact with each other and then I just I applied for a job at Monax and I got the job and started working at Monax. So you mentioned that when you were at that first meet up with you know G and Vitalik and all that you were very skeptical about um Ethereum. How has that view evolved? Do you still think of it the same way? I have a lot more faith in well maybe faith is even the wrong word. Vitalik has demonstrated to me in my interactions with him that he's like a pretty I mean he's pretty smart like he's really smart and he but most importantly he like he really evaluates a lot of different positions and and

looks towards reasonable solutions and tries to like make things that actually work. Um and so that was my main concern. Uh, I remember I was having a conversation with with the friend who who who took me to the meetup. He was like, "Why are you gonna start like working on Ethereum stuff? Like, you don't think it it's like you think it's horrible?" And I'm like, "No, I mean, yeah, it's horrible, but it's like the closest thing to actually achieving these goals that I've ever heard of, right? And these are goals that a lot of people outside of even the blockchain community, just just computer enthusiasts have wanted to see these things happen for many years. And like Ethereum is the closest to getting it done. Like, I'm probably not going to get another shot. like there's not going to be another Ethereum really in my

lifetime. So, I should I should start working on it. So, so I think that um I'm still very cynical. I think I think a lot of the things that were broken then are broken now. Uh the difference is I'm much more confident now that we're working to fix those things. Okay. So yeah, before we get into the into the meat of you know into the of those things that you mentioned, tell us about what your involvement is right now in Ethereum and sort of you know projects uh around the Ethereum ecosystem.

Sure. So, I I work on Casper. Uh I would say primarily with Vlad, but obviously with Vlad and Vitalic and Greg and there's a there's a whole team of people now working on Casper and uh I I provide uh my my strong opinions and insights into into the different uh portions of that development. Uh I work at Monax where we deploy EVM based uh blockchains for you know a a bunch of different clients. I have my own clients at at Vulcanize. All of those projects are EVM based at this point. All of them have some EVM component to them. Um, so that's mostly what I do with Ethereum. I

mean, notably, I'm not paid by the foundation for anything. And, uh, also notably, um, most of these projects are not on the Ethereum network per se. They are just using the Ethereum virtual machine. So, you're not paid by the Ethereum Foundation. Uh, I know this is something that we've talked about privately. Uh, what what kind of position do you think that puts you in as a contributor to these projects, not being paid by the foundation? Well, I think it it it it at least helps with the optics of neutrality. Um, I I think I mean, one day I may be paid by the foundation. I'm not opposed to being paid by the foundation, but I think that um it helps to have outsiders and also I

don't I don't really hold a lot of cryptos. Like I try to hold as little cryptocurrency as possible. Um I'm pretty riskadverse and uh and since all of my business is based in that, it it would be weird to then like double down on that risk. So I I think as someone who really just wants the tech to work and that's really what I'm concerned with. I'm not concerned with the politics. I'm not really concerned I mean I'm I'm a little bit concerned with people's feelings like you know as a human or whatever but like ultimately you know it's important to me that the technology works and is correct and makes sense to me and that's primarily what I'm what I'm working on right now as as it stands today. Uh you know Ethereum came out uh quite a while

ago now I guess in in blockchain years. uh you know there there's an ecosystem of projects that are being developed on Ethereum. Um there's been a lot of industry support uh quite notably Microsoft uh is is is now investing massively in sort of the ecosystem the Ethereum ecosystem uh we've seen of enterprise um come in and want to experiment with Ethereum. Uh, I'd like to get your thoughts on what what you think is sort of the the the current state of Ethereum and what makes you hopeful that Ethereum will continue to thrive as a platform moving forward.

I think Ethereum as a platform moving forward, I'm very optimistic about about Casper. I'm actually optimistic about the the type system additions to Solidity. There's also like a they're doing some sort of abstraction to solidity um in terms of how it's executed and compiled. Um I'm optimistic about those things and obviously sort of the scalability uh promises that are going to come along after the transition to proof of stake and I and I think that the enterprise developments are good. Um I think that they help the community. I mean, I don't have any problem. I mean, obviously, I I think enterprise is fine and good, and I'm I'm not like dogmatic about uh pro or con enterprise. Um, some

of that work is going to be helpful to people broadly, some of it's going to be helpful to the foundation and developers broadly, but a lot of it is just going to be helpful um to the people who are funding it almost exclusively. So I I don't have um particularly strong opinions. Uh it's such a big space. I don't I don't have a lot to say about it in particular. So regarding Casper, of course, for those who don't remember, um when Ethereum launched, there was always this idea, okay, we want to transition to proof of stake. So today, Ethereum still uses mining, right? But with proof of stake, there would be that people essentially kind of vote with their coins and so that you don't need mining

anymore and you have can have maybe more security, you have maybe better speed, better scalability and not this energy wastage. But the technology wasn't really there at the time. So they put in this kind of difficulty bomb, right? That at one point all of a sudden the difficulty of mining would go up completely through the roof and essentially the Ethereum network would ground to a halt if they hadn't done a a hard fork by then. Uh, and the idea was that this would sort of force people and and set a time limit to to move to to Casper. I'm actually not totally sure when that hard fork is coming up. Of course, it's also possible that they'll just remove that um sort of uh explosive device in there so that there's more time for Casper. But uh then the project has been Casper and of course we have

done some podcast with flat sampler about that as well uh which is the the Ethereum uh foundations efforts research effort to figure out how to exactly do that. So um I would I would love if you could kind of run us through you know what Casper looks like from a very high level and and what are some of the challenges in making that transition work? Yeah. So from a very high level um there's Casper the consensus protocol which is basically correct by construction and and there's a there's a there's a very simple phrase about betting where you're you're betting on um who do you which uh which path do you think is

going to end up being the canonical path in the future. And then there's also sort of these other things that get kind of called Casper uh because they're they're so often t spoke about in the spoken about in the same breath that we kind of conflate them together. So one of those is the is the VM uh that would be required. Uh one of them is sort of the language on top of that VM and then one of them is sharding. Um and so all the all four of those things kind of get grouped together and we just sort of call them Casper. It's really important to understand that proof of work historically compared to other um consensus algorithms uh and other things in the Byzantine

fault tolerant consensus system space has a very unique security model that doesn't really map well to things that we're accustomed to in the real world. Um and and this has been actually a serious point of confusion and contention for people trying to understand proof of stake. So a lot of the old proofofstake algorithms pre-tender um were these weird bastardizations of proof of work and they were very in my opinion lowquality because they weren't they weren't based they weren't grounded in sound research and and they were fundamentally based on this misunderstanding of how consensus systems work. So after tenderint um you know there's tenderint and there's and

there's casper um and these are very different security models than the proofof work security model and they're fairly different security models from each other um and and so I think that when we talk about improving the security it's important to understand that um although I do think it will improve security um it's a pretty big set of tradeoffs right so so you mentioned there are different security models here. So can you can you just run us through very quickly what you know what's the Casper security model you know what's the tenement security model and how are those you know what are the main difference between them and also between uh proof of work.

So proof of work you have all of your participants are anonymous because they have to do so much work in the proof of work that's why you believe their statements. uh in Casper you believe statements because uh if the validators are equivocating uh they lose their bond. Uh the same thing with Tinder. In addition with Tinder you also sort of rely on the fact that some percentage of the of the validators are known. Either you are a validator yourself or you trust the these named entities that are validators. uh whereas in Casper the goal is to not have that requirement to be more like Bitcoin and or more like

proof of work and and provide uh synonymous uh validation uh in to you know entirely. So those are kind of the major differences as a consequence of this. Casper provides better security against um oligarchs or you know like like mining cartels um than Tinder does. I mean Tinder doesn't really kind of addresses that but not really. So that's the major security difference.

I mean, Casper's really trying hard to have the best of both worlds in regards to the privacy and synonymous nature of the validators as well as the speed and scalability um of a proof ofstake system. [Music] Let's take a short break to talk about Jax. Jax is a multicoin wallet created by the people at the central. Now, in the past, if you had a whole bunch of cryptocurrencies, it was a pain to handle them. You either had to leave them on an exchange, which was insecure, or you had to have all these different wallets, which was a hassle.

Fortunately, now with Jacks, those medieval days of darkness, misery, and suffering are over. Jack supports multiple cryptocurrencies and new ones are being added. But it's not just storing cryptocurrencies you can do with Jax, but you can also exchange them directly from with inside the wallet thanks to their Shape Shift integration. And since there's only one seed, Jax makes it super easy to back up and sync to your other devices. Jax works with Windows, Mac OS, Linux, Android, iOS, and has browser extensions for Firefox and Chrome. So go to jacks.io, that's jax.io to download the wallet and get started today. We'd like to thank Jax for their

support of Epicenter. What are the challenges in getting those best of both worlds? No one's ever created an algorithm that works that way before. Um, so there's just that challenge. Uh, I I do agree with Vlad that it needs to be correct by construction. Um, and so that's just a challenge just making any sort of algorithm correct by construction. Um, that means that um, you have mathematic proofs that are explaining why the algorithm is the way it is. um not just some tests or some like handwavy explanation, but you actually have a a proof that you can

walk through that shows that uh the algorithm you're presenting satisfies the requirements uh of the people asking for it, that it was constructed correctly. You had an analogy to building a like a building, right? And in one building you would have walls, the building you would have windows. I thought that was pretty uh so so the iterative So the iterative approach to algorithms is is okay we build you know in both cases we're trying to build a skyscraper right and in the iterative approach you build a complete first floor uh but you forgot the toilets so you build a second floor and now you've got toilets but

your windows are kind of weird and you build a third floor and and you just go through this process and eventually at the top floor at the penthouse you have you know a functional thing and you say oh look well this is what every floor should look like and then you know ideally you go back and you rebuild the whole building um with the correct architecture. Um with correct by construction uh you're building out the whole building but with just a feature at a time and or a collection of features. So you build out all the walls and you have a full towers worth of walls. Oh, but you don't have a roof. Then you put on a roof and you're like, "Okay, great. Now we need windows." Now you build a whole new building with windows. Um, and the difference here, I mean, it's a it's an

interesting analogy. I mean, analogies break down at certain places, right? But what happens is when people are looking at the correct by construction process, they say, "Hey, you don't have any windows. You don't have any doors. Like, this thing is useless." And it's like, "No, I mean, when we actually add doors, they're going to be totally awesome doors. You just have to wait for that." as opposed to the iterative approach where you've got this janky door that's just going to fall off the hinges as soon as someone tries to open it, but oh, there's a door there. Um, and and I think that uh just in general to get software developers and software engineers to take the correct by construction approach and frankly to get

clients and customers to go with the cor the correct by construction approach uh can be a real challenge. But I but I do think that uh when security and safety are a priority, it's it's the best way to develop software and it's how NASA develops software. So there you go. And NASA never fails. Well, their software is of extremely high quality. Yes, I'm certain it is. Um, so perhaps talk about, you know, I I think that it's clear to everyone that tenderint was built for a specific type of application and Casper was built for Ethereum which was also built for a

specific type of application. And so there are there are trade-offs there. I think uh it was Vlad that said in a Reddit post once that tender favors consistency over availability and Casper favors availability over consistency. So what applications can we derive from this? In what context will Tennere Tener be best and what context will Casper uh Yeah. So that's interesting because that's one of these points where I kind of disagree. I mean me and Vlad I think are very agree on a lot of things but we really disagree on some things and I and I think that that characterization although true uh kind of misses the point. So, so censorship resistance is a form of availability. Um, and and also

he just means availability in the broader sense as well. But if you don't know the state of the data that's available to you, it's not worth anything, right? So, so I would say that there's actually a different trade-off which is the relationship between finality and availability. And and this is actually an interesting point about Casper where Casper provides uh finality uh client definable finality in its availability and I that's actually one of the major innovations of Casper. So so the why would I use Tinder over Casper? I would use Tinder because it's easier to reason about. It's available today. Uh there's tests. Um

you know you can run it, you can download it and use it. Um it's much easier to reason about. Um it provides a very simple finality model that which is very important for an application developer to understand uh when they can when the data is actually in the log like when is the data truly irrevocable. It's much harder to tell in Casper uh if your data is truly irrevocable. You can end up in in weird states in Casper. And of course Casper is not done. So the goal is that you wouldn't have those states, but right now, you know, we don't have the proof of that.

Um, and so I I mean it's almost like not a fair comparison because Casper because you know I run production I've run systems with the goal of putting them in production that run Tinder. There is no code of that level in Casper. But the the goal of Casper is is that um the users are able the the applications are able to decide or the users of the applications are able to decide when uh a d a piece of data is is actually finalized which is a very fascinating property um that I don't think any other system really has. You can sort of put that into tenderment sort of. So, so one way of thinking about the difference

between uh a BFT uh database and uh just a merely fault tolerant database is that uh a Byzantine fault tolerant database is exposing the replication state uh to the end user. Um and and so both Tinder and uh Casper have the ability to do that but they they do it in slightly different ways. So Ethereum has been yeah like there's a billion dollars now right that are secured by the Ethereum network and there's a lot of interest and lots of projects building on Ethereum and then if you look at Casper this is such a a huge change know to go from proof of

work to proof of stake how do you think that change as a network will be possible and and do you believe that's actually going to happen and you know would that for example mean that different clients like GE uh would also transition to that or would they kind of then just have one client? How do you see that playing out? Yeah, so I I would assume that all the existing clients would would um migrate to uh proof of stake. I think that it's actually fairly easy to one of the benefits actually of of Ethereum currently running and proof of work is that you can um use proof of work to establish the uh canonical nature of

your uh your second genesis block or your proof ofstake genesis or whatever you want to call it. Um and so I think that that helps. I don't know if if we're going to run both I mean we're going to have to run both networks in parallel but I'm not entirely sure what that really means in terms of uh switchover or uh yeah so uh that's an interesting question and an interesting challenge. I I think it's there's some interesting questions too, right? Like if you if you run EVM one while you're running the Casper EVM, whether it's Rowling or whatever, where those uh other EVMs maybe expected proof of work or expected gas to work a

certain way, are you going to emulate that? How are you going to replicate the the proof of work part of it? Do you need to replicate? I don't think you need to replicate that. But um but what if you do or what if it turns out that some major application is relying on it in some weird way that you didn't expect blah blah blah. So I think there's there's interesting technical challenges there. But I think from a policy standpoint or from an operational perspective, it's fairly straightforward that we can um we can just switch to uh we can just switch to proof of stake um by just insisting that people do it. And what's the timeline? Do you think that's realistic here?

The full changeover I think is would I'm like I'm almost 100% certain that would happen within three years. Uh and I'm pretty certain it would happen within one and a half or two depending on how aggressive we are with the testing. I I Yeah, I mean I think that's very conservative. I'm being very conservative with three years. I mean I think that we'll have significant features and value before three years. So throughout this discussion uh you we've touched on on on Rolang and type languages and this is actually something that I wasn't really aware of since until you mentioned it to me last week.

So um scenario which is a project that uh we've covered on the show before. We've had Greg Meredith on uh a few months ago to talk about scenario and that that project is is sort of splitting up. So, Greg has um left the scenario project and is now working on his own uh thing which is called Rchain that would implement um a Rolang uh VM and of course Rolang is a functional programming language that is typed uh so in theory much better for sort of high-end enterprise applications. Um now you mentioned that uh Rolang uh would be

compatible with future versions of Ethereum. Can you explain what that means and how that would be beneficial to Ethereum as a network? So just in terms of Casper development, in terms of the development team, Greg is working on Casper. Uh his work is sort of being encompassed and embodied in our chain. So, it seems like at this point, you know, obviously we're all handwavy speculative. Um, uh, it seems as though uh that, you know, that's probably going to be the VM. Honestly, actually, I I'm not I don't necessarily want to say that because I can see how that can go wrong, but but right now tenatively um the Rolang VM would be the VM that's used um

inside Ethereum. uh and so and so they would be compatible because they'd be running the same VM. How would that be beneficial to Ethereum as a platform to have the rolling VM? Yeah, I mean just the static typing analysis alone. Uh but it it's actually a correct processing model like the the current model that Ethereum uses is really the wrong model for the work that Ethereum is doing. So you part of the reason you have these reent entry bugs is because there's some confusion about um how threading works or how the interdependence of processes in the

existing EVM is not well defined. Um, and so switching the row lang fixes whole classes of bugs and and handles this by by using the correct abstraction or the correct metaphor to uh to describe um what what's actually going on uh on the network. So that's just hugely beneficial. Today's magic word is Casper. C A S P E R. Head over to let's talk bitcoin.com to sign in. Enter the magic word and claim your part of the listener reward.

So when you say uh Ethereum switching to um to a roland VM, I mean what would that mean for solidity? Would that mean uh old contracts would still uh function or those have to be ported over or like how exactly would that work? I think it's open question. Oh, those are all open questions. But uh you could I think you could maintain the old uh EVM1 code for a certain period of time. There's other features that are kind of outside the Casper scope that would need to be addressed like like uh right now your storage lasts forever. like if you put something in Ethereum, it's just going to sit there forever. That has to be addressed. Um, and then that

obviously ties into if you have uh old contracts that really can just expire on their own, then presumably um you can optimize and and and let the old the old EVM1 contract sort of die out as they become used less and less. Um uh in terms of solidity uh I think that solidity is going to be moving in that direction. Solidity is going to be moving towards being a strongly uh having a type system that's compatible with the role type system more so than the type system that it has today. And so I think that that over time uh solidity will be moving closer to the

kind of language that Rolang is designed to support because because Rolang is not really uh intended to be the final highle language as I understand it. I understand that there would be another language that's closer to solidity on top of Rolang. So then would are you saying that the Solidity would compile to Rorang or Yeah, I think that's I think that's a possibility. Okay. There's there's some pros and cons to that method and and I don't think that the solidity of today would compile particularly well um to Rolang. But I think that that when you look at who's been hired by the foundation to work on

Solidity, I unfortunately I'm so bad with names I've forgotten the gentleman's name, but he's he's doing a lot of work on type systems. Uh and so I I I think that there's an option or an opportunity there to sort of converge uh with the type system work. What would that mean for Ethereum to potentially have two or even, you know, mo more than two VMs, like multiple VMs running on the same network? Uh, I don't think it really poses any deep technical issues. Uh, it provides some confusion uh to developers, but I think you would just be telling developers to use the new V, you know, you you'd only ever be telling

developers to use one VM at a time anyway. So it, you know, like use the newest VM available, right? Just because you're maintaining backwards compatibility doesn't mean that you'll necessarily even accept uh new contracts um deployed uh in that name space. Would that imply some sort of a hard fork or can can anyone just compile bite code in their own VM and and deploy it on the network? Oh, that would definitely require uh some kind of hard fork. Um, one of one of the discussions that we've been having in the Casper community has been do you provide the network bite code as you do now, which is difficult to evaluate, difficult to verify, or do you provide um source code? So, I I'm a I'm a big proponent of actually putting the

source code for the contract on the blockchain and and getting consensus on the compilation of the contract. Um so that that's one sort of solution to that set of problems. So you mentioned a few times this issue around the typing strongly typing type systems. Now probably most people a majority of listeners won't be really familiar with what exactly that is and why it's important. So can you run us through um what is a type system and why why is this a big deal in this context?

Well I I yes I I'm happy to do that. I would also recommend that that um that people look at Wikipedia uh to to get like a more robust uh version because I'm I'm certainly not going to do it justice. But but in essence uh when we talk about variables in a computer, those variables inherently have a type. Um and a type basically is like a set of properties or a set of attributes that that apply exclusively to those variables. So a variable is just like what you learned in algebra. It's a placeholder for a type of data or a kind of data. So so so you can have the number types are are integers, floating

points, you know, uh uh rational, you know, like fractions. Um so these are all types. You can also have a string as a type. Uh you can also have um bytes. So just like you know uh strings of eight ones or zeros uh in arrays you can have that as a type and then and then these are this is a very b I've just described to you a very basic type system from these simple type systems you can develop much more sophisticated types although even saying from there is misleading you can create other type systems that are much more sophisticated. So uh Rolang is based on on on you know a very advanced system that is uh significant improvement on

like the process calculi which is another type system where the the type that you're primarily concerned with is a process which is an abstract representation of a process that happens inside of your processor. So a type system is sort of just to to sum up, a type system is a way of um defining the data structures in your program such that it allows you to do certain types of static analysis more efficiently. Um static analysis being the ability to look at the code without running it and and make statements about its properties.

Okay. So it's it's easier to say okay we see the code here and we can say this is going to give a certain type of result because it has a particular type system or particular you know attributes each variables have a particular set of attributes. Yeah. Exactly. So you can say right so if your if your type system you know is correct you can you can say hey I don't have to run this code to figure out if I'm going to get a string or not the types are telling me that I'm going to get a string. Um and that sort of verification is necessary both in sort of a general broad enterprise context uh for very high security or high

assurance applications but it's also important uh obviously in the smart contract context where you have these issues of trust right and you want to be sure that the program that you're running uh does what it claims to do I mean be because are you saying what what you have otherwise is that you you have different types or maybe it's not so clear and and then it depends on the computer and each machine what it does with that and you can't really predict it because different environments would do different things with it. Is that what you're saying?

That's part of it. But in the case of a smart contract, it's more an issue of if your type systems incorrect, it's you can't make the sort of guarantees that you want to provide your users. And when we talk about security and safety, those are types of guarantees. So for example, um the type system that exists in the EVM today, which is ultimately the EVM is operating on bytes. um doesn't really allow for you to assert as a developer that there are no re-entry bugs and so the idea would be to create a to use a type system that can say for

example the DAO hack would be impossible. Now uh recently there's been other discussions about complimentary blockchains uh working together to achieve some some greater uh good uh and recently there was an article I think it actually just came out uh today or in the last few days on Zcash and Ethereum and and how they could be complimentary. uh can you give us your thoughts on how the work that's being done on Zcash could be integrated in Ethereum and what that would bring to Ethereum as a as a network?

Yeah, I mean there's a lot of people working on that. So, uh I mean zero knowledge proofs, interactive proofs more broadly um are are super helpful. They're a great cryptographic resource. Um and so I think the sort of uh improved confidentiality of your transactions or the improved security of the various fields in your transactions that uh zeroache provides obviously is just going to provide improved security uh for the for the Ethereum network. Um and you know I I think that on these networks uh because of the link layer it's difficult to have true anonymity.

um it will certainly uh confound um certain types of analysis uh which I think is uh good for the network. And so what what seems interesting to me is that all these networks are are independent, right? So Zcash is a network, Ethereum is a network. Uh Rchain, I don't know where they are. I don't know. I know there's some talk about splitting scenarios scenarios AMP to to have an R chain coin as well. And so, you know, each of these networks has these fun their their functionalities, what would be the incentive to to continue to have Zcash and continue to have our chain. If Ethereum uh brings all of these functionalities, right, the

type strongly type functional programming language and uh zero knowledge proofs and some other things like right if Ethereum brings all these in and integrates them into the core Ethereum protocol um what what then becomes of these other networks. That's I think that's a very interesting question. I think there's for example with Zcash because it's existent there's already value in Zcash, right? So, so that value that already exists in Zcash is isn't going to go away. There may be uh reasons why people, you know, users have a preference for Zcash over Ethereum. Uh also, uh there's just it's good to have a plurality of systems in these types of ecosystems, you know, for

security purposes, for for research purposes. There's couple different reasons. So I I think that there's enough market right now um that all of these different systems will find their niche as long as they are actually providing value to some to some class of user. Right? So on one hand um I think Ethereum I don't think Ethereum is like going to steal the thunder of these of these other networks but I think that Ethereum the current thesis of Ethereum to be featureless in quotes uh gives them the ability to sort of take the best of breed of all these different features and systems and and and integrate it and and that's actually one of the things

that I really like about uh Vitalik's you know current approach is is I think that taking that pluralistic open um position is like pretty vital to having the project be successful in the long term. So Rick, you mentioned that you're working on your own product uh through your company Vulcanize, which is called Vulcanized DB. What what are you building there? Yeah, sure. Um so it's basically a Byzantine fault tolerant database. So the idea is a blockchain isn't really a database. Um in particular, it's very difficult to figure out what the current state is. Um it's also very difficult to

do things like SQL queries. And when I say do an SQL query, I mean have the runtime performance of SQL uh engines uh on a blockchain. So, so the concept the idea here between behind the BFTDB is you is you take the sort of the best features of a blockchain and the best features of a fault tolerant database and you put them together. So you get this massively scalable uh fault tolerant Byzantine fault tolerant database um that you can query that you can use for SQL queries but you don't really get uh the anonymity kind of properties that you would get from a a blockchain and

your performance uh is not necessarily going to be as tunable as a traditional database but you'll still get very good significantly ly better performance than what's available from a blockchain. I mean, of course, we've done an episode on the show before about the big chain DB, which sounds very much like that. So, can can what's what's the difference here? So I actually was talking to some of the big chain DB folks recently and they and they were mentioning that they had considered um going down this road but but they they thought that the you know it's so it's in the same space there are similar uh my system is going

to provide um uh you know vulcanized DB is going to provide uh higher security guarantees out of the box and then over time uh we'll probably be able to get closer uh to perform on the performance side of things to um to big chain DB but uh from an engineering perspective and from a design perspective it's a longer path I mean big chain DB exists today vulcanized DB does not really exist today so so you know we're just emphasizing uh different parts of the trade trade-off. Uh, also the way that you get that speed um in the vulcanized DB model

is by exposing complexity to the developers, which uh is always uh sort of a double-edged sword. Let's take a break to talk about the Ledger Nano S, the new flagship hardware wallet by Ledger. I'll pass it over to Ledger CTO, Nikolaka, who can tell you all about Ledger's security features and SDK. The Lechure Nano S is a personal security device based on a secure element, the screen and button so that you can verify everything that is done on device and make sure that you are really doing what you wanted to do.

Compared to our previous solution, this device is based on the latest generation secure element, the SD31 from SD Micro. The SC31 is an is using a secure ARM core which means that you can have the same ease of development that you would have on a generic microcontroller but benefit from the security features of a secure element. Security features include an application firewall at the lowest level that let you protect applications from each other which means that you can load multiple application on the hardware wallet even post issuance and you as a developer will be able to leverage these features to load your own application without our authorization and without any kind of authorization from the vendor. We will

be providing this device with an open SDK um that let you do anything you want with this device. We provide sample applications for cryptocurrencies, different cryptocurrencies. So, Bitcoin, Ethereum, uh uh we will also provide a ph authenticator and you will be free to add everything you like. For example, you could add some secure messaging, some encrypted chat and you'll see that the solution is quite powerful and very easy to develop with. The Nano S sets the new standard in hardware wallet security and usability.

You can get yours today at legerwallet.com. And when you do, be sure to use the offer code epicenter to get 10% off your first order. We'd like to thank Ledger for their support of Epicenter. Talk a bit about what types of complexities you're exposing. Exactly. So I I mentioned it earlier in the in the discussion that um the difference between uh a fault tolerant database and a Byzantine fault tolerant database or or one way of looking at it or is that you're exposing the replication state um to the to the developer. So so uh let me try to put this into um blockchainy terms. So it when you have your blocks coming out of your blockchain, right,

you have the transactions, the transactions go into the memp pool and then the transactions are pulled from the memp pool and they're converted into blocks. And then when someone wants to read data, uh if they're reading data that they can really trust, they're reading the data from the block. So in a normal fault tolerant database, uh you send a transaction uh to a node. That node then gossips the transaction around. Then it waits to get the result back that everyone got it and then it tells you that that transaction is valid. So that's very similar to the memp pool except uh when you're using a blockchain you can examine and inspect

the mempool and when you're using a fault tolerant database you don't get to inspect the state of your message. And so by allowing the developer to inspect the state of their message, the developer can now make their own decisions about uh whether they should believe that me whether that message is really committed or reliable or not. Um and so what that means is that you don't necessarily have to wait for blocks. If if if speed is is your primary concern, you don't have to wait for the block.

you just have to wait for some number of confirmations from the memp pool. Um, and obviously that's less secure than waiting for a block, but it can be orders of magnitude faster. And so where's the where are you at in the current state of development of organized DB? A lot of theory, a lot of thinking, um, some some some proof of concept code that that passes a couple of tests. Basically what we've done is we're we're taking cockroach DB which is a fault tolerant uh acid uh database and we're replacing raft which is the most popular or one of the mo the most popular consensus engine and we we've replaced

that with Tinder. Um and we haven't run any performance tests on it but uh but we've run some tests on it and and we've get gotten good results in terms of test coverage. Um, and so that's sort of uh where it's at today. You know, this is one of those things where every client I've ever spoken with pretty much has needed this feature. So, uh, so over the next, you know, the next couple of quarters, uh, we're going to be, you know, pushing out this this set of features to our to our clients at Vulcanize and and really sort of kicking off development in in earnest.

Cool. So, before we wrap up here, I mean, we've uh we've covered a lot of different topics. Uh and um I kind of get, you know, like to get your your thoughts on what you see as a future for for the ecosystem and all these parts sort of coming together. Where do you see Ethereum in the next five years technologically speaking? Where would you like to see it? It's it it's to me it's a very interesting question. Um you know I I do have this strong bias for federated proofofstake systems or uh however you want to whatever you want to call them permissioned uh private what whatever

um I really do think that that solves a lot of issues. I think that uh it's a better model. So I think I personally again I I I am a cynic when it comes to or a skeptic when it comes to this stuff. So I have my skeptic hat. Um I I really question uh what kind of transactions really need to happen in public and in five years we'll probably have a good zero knowledge proof system. So people will be comfortable putting some pretty sophisticated business logic on on Ethereum. It'll almost certainly be proof ofstake based. It'll almost

certainly have uh a number of sharding features. So one of the sharding features that I'm interested in that that uh one of my own ideas is basically app sharding where um the application itself requests different validators to run it uh and then those validators run that application in private um which provides you sort of the best of both worlds. You can see that your your application is bonded and public to a public validator, but only that only those validators of which you selected ever see your encrypted data. Because one of the things that a lot of people forget uh and this is a bit of a tangent, apologies, but a lot of people forget that, you know, basically if you your data your encrypted data on someone

else's machine is still less secure than your encrypted data on your own machine. Um, and so I think that this will be a vital issue for businesses as they use blockchains and they lose their keys. And so I I think that a lot of times when we talk about these privacy solutions, they're not really enough for the enterprise and they're not really enough to fully transition people onto even uh a ZKP based uh public blockchain. So I think there'll still be private blockchains. I think there'll be a lot of them and I think that you know hopefully Ethereum uh will be the sort of the the backbone for interconnecting um interconnecting these uh these various private blockchains. But I'm

also optimistic about Cosmos. I'm also optimistic about Polka Dot. Um I think that there'll be a place for all of these different networks in 5 years. Cool. Well, thanks so much for coming on, Rick, and we certainly look forward to following the the progress of Vulcanize and and all your other involvements in the projects. I'm sure in in this industry, I'm sure you're going to keep appearing in all kinds of corners and being involved there and and driving the industry forward. So, thanks so much.

Oh, thanks for having me. So, Epicenter is part of the Let's Talk Bitcoin network. You can find this show and other shows on less bitcoin.com. And if you want to support the show, then please leave us an iTunes review. That helps new people find the show. So, thanks so much and we look forward to being back next week. [Music]