Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Rick Dudley: The Future of Ethreum as a Strongly Typed Proof-of-Stake Blockchain Network

Episode Date: January 31, 2017

In the last year, blockchain protocols have matured at an exciting pace. Open source projects like Ethereum, the Eris stack and Tendermint are behind much of the experimentation being conducted at leading companies. These protocols would not be where they are today if it wasn’t for the hard work of dedicated open source developers.One of those people is Rick Dudley. An opinionated and passionate developer, Rick is involved in multiple projects. He works as a DevOps at Monax, works closely with Vlad Zamfir on implementing Casper in Ethereum, is a leading member of the Coala organization and is Founder and CEO of the startup Vulcanize. Rick gives us insider insights on Ethereum and on how the project may evolve, in particular, once Casper is implemented and when more robust, strongly typed language VMs are made available to the protocol.Topics covered in this episode:How Rick got involved with blockchain and EthereumHis views on the Ethereum’s planned transition to CasperThe risks and benefits of moving to CasperThe subtle differences between Casper and TendermintThe recent break up of the Synereo projectGreg Meredith’s work on Rchain and Rholang, and how that relates to EthereumPotential synergies between Zcash and EthereumVulcanize and VulcanizeDBEpisode links:Time waits for no one (Medium post)"Method for portability of information between multiple servers patent"Vulcanize.ioCoalition of Automated Legal ApplicationsEpicenter episode with Vlad ZamfirStrong and weak typing - Wikipediaπ-calculus - WikipediaThis episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/168

This is Epicenter, episode 168 with guest Rick Dudley. This episode of Epicenter is brought you by Jax. Jax is the user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to J-A-A-W-X.I-O and embrace the future of cryptocurrency wallets. And by the Ledger NanoS, the hardware wallet which sets the new standard in security and usability. Get it today at ledgerWallet.com and use the offer code Epicenter to get 10% off your order. Hi, welcome to Epicenter of the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Sebastian Kru.

And my name is Brian Fabman Crane. We're here today with Rick Dudley. I've known Rick for quite some time because I used to work at Monax and he used to work. He does still work at Monax as well. And Rick is one of the most opinionated people, I think, in the blockchain space, the most vocal and also knowledgeable. He's been involved in all kinds of projects. has a really wide knowledge of many different projects, so we're really excited to have them on today.

So besides his work at Monax, where he's focusing on DevOps, the upper 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 Vulcanize DB.

And he's also very involved in a koala, which is the, I actually don't remember remember what it stands for, but they've been running blockchain workshops and doing a lot of work around legal policy and blockchain technology where he's been very, very involved in. So thanks much for joining us today, Rick. Thanks for having me. Well, I guess to get started, can you tell us? What's the story of how you first heard about blockchain, Bitcoin or whatever it was back then and how you got involved in this area? So in chronological order, I was helping some friends play video games for money.

We were writing scripts and automating the process of playing video games. This was in 2006, 2007. I was studying computer science at the time, so I knew that there should be a way to make that not possible. So you could prevent people from writing these bots and playing with these bots. And so I filed a patent for that process. I was awarded a patent for that. If you look at that patent, it's very similar to Provably Fair Gaming. And I wrote that patent before the Bitcoin paper was published. Then I read the Bitcoin paper very early on. I thought it was kind of weird. I wasn't super interested in it. It was too risky and speculative for me.

I couldn't figure out how I was going to keep my keys and all these sorts of issues. Then fast forward to November, I'm so bad with the dates, November 2014, I believe. I had some friends from the hacker community who were 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 meetup in New York with, I guess, a lot of the core devs, Gavin and Vitalik gave a presentation. And Joe Lubin was running it. And I asked the first question after all the talking was done. And I was basically like, you know, 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. And then I went to another meetup later. And eventually I started working with Joe Lubin at Consensus February of 2015. 15. And that's basically how I got started to being really active in the blockchain space.

Now, what was your role there, and then how did you transition to Monas? That's interesting. So at that time, at Consensus, I don't know what it's like now. People didn't really have roles. We just sort of rift on whatever. I mean, there's just a lot of activity, a lot of meetings were going on. I wanted to develop Proivably Fair Gaming ideas So if you look at the gaming ideas that have been announced

from consensus today Not Dow Wars That was Peter Orro But like if you look at Virtue Poker That was an idea that I had Almost as a

Well frankly almost as a joke But I was developing Provably Fair gaming stuff there and then I just wasn't really happy working there in terms of just sort of inside baseball stuff. And then so I stopped doing that. And then I was just doing like I had been an IT consultant before, so I was just like picking up consulting gigs. And then a friend of mine asked me to help them pitch an idea,

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 blockchains interact with each other. And then I just applied for a job at Monax and I got the job and started working at Monax. So you mentioned that when you were the first meetup with, you know, Gavin and Vitalik and all that. You were very skeptical about 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 looks towards reasonable solutions and tries to like make. things that actually work. And so that was my main concern. I remember I was having a

conversation with the friend who took me to the meetup. He was like, why are you going to start working on Ethereum stuff? Like you don't think 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 computer enthusiasts have wanted to see these things happened 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 I'm still very cynical. I think I think

a lot of the things that were broken thin are broken now. 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 to the meat of you know, into those things that you mentioned. Tell us about what your involvement is right now in Ethereum and sort of projects around the Ethereum ecosystem. Sure. So I work on Casper. I would say primarily with Vlad, but obviously with Vlad and Vitalik and Greg and there's a whole team of people now working on Casper. And I provide my strong opinions and insights into the different portions of that development. I work at Monax, where we deploy EVM-based blockchain for a bunch of different clients.

I have my own clients at Vulcanize. All of those projects are EVM-based at this point. All of them have some EVM component to them. So that's mostly what I do with Ethereum. I mean, notably I'm not paid by the foundation for anything, and also notably, 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.

I know this is something that we've talked about privately. 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 at least helps with the optics of neutrality. 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 it helps to have outsiders. And also, I don't really hold a lot of cryptos. Like, I try to hold as little cryptocurrency as possible.

I'm pretty risk-adverse. And since all of my business is based in that, it would be weird to then, like, double down on that risk. So 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 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 working on.

Right now, as it stands today, Ethereum came out quite a while ago now, I guess, in blockchain years. There's an ecosystem of projects that are being developed on Ethereum. There's been a lot of industry support. Quite notably, Microsoft is now investing massively in sort of the ecosystem, the Ethereum ecosystem. We've seen enterprise come in and want to experiment with Ethereum. I'd like to get your thoughts on what, what, you think is sort of 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 Casper. I'm actually optimistic about the type system additions to solidity. There's also like they're doing some sort of abstraction to solidity in terms of how it's executed and compiled. I'm optimistic about those things. and obviously sort of the scalability promises that are going to come along after the transition of proof of stake. And I think that the enterprise developments are good. I think that they help the community. I mean, I don't have any problem. I mean, obviously I think enterprise is fine and good, and I'm not like dogmatic about pro or con enterprise.

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 to the people who are funding it almost exclusively. So I don't have particularly strong opinions. That's such a big space. I don't have a lot to say about it in particular. So regarding Casper, of course, for those who don't remember, 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 sake, it would be that people essentially kind of vote with their coins and so that you don't need mining anymore and you 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? 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 through halt. if they hadn't done a hard fork by then, and the idea was that this would sort of force people and set a time limit to move 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 sort of explosive device in there so that there's more time for Casper. But then the project has been Casper, and of course,

we have done some podcasts with Flat Samphir about that as well, which is the Ethereum Foundation's efforts, the research effort to figure out how to exactly do that. So I would love if you could kind of run us through, you know, what Casper looks like from a very high level and what are some of the challenges in making that transition work? Yeah, so from a very high level, there's Casper, the consensus protocol,

which is basically correct by construction, and there's a very simple phrase about betting, where you're betting on who do you, 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, because they're so often spoken about in the same breath,

that we kind of conflate them together. So one of those is the VM that would be required, one of them is sort of the language on top of that VM, and then one of them is sharding. And so 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 consensus algorithms

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. 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 proof of stake algorithms, pre-tendermint, were these weird bastardizations of proof of work, and they were very, in my opinion, low quality

because they weren't grounded in sound research, and they were fundamentally based on this misunderstanding of how consensus systems work. So after tendermint, there's tendermint and there's Casper, and these are very different security models than the proof-of-work security model, and they're fairly different security models from each other. And so I think that when we talk about improving the security, it's important to understand that although I do think it will improve security, it's a pretty big set of tradeoffs.

Right. So you mentioned there are different security models here. So can you just run through very quickly? 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 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. And Casper,

you believe statements because if the validators are equivocating, they lose their bond. The same thing with tendermint. In addition, with tenderment, you also sort of rely on the fact that some percentage of the validators are known. Either you are a validator yourself or you trust that these named entities that are validators. Whereas in Casper, the goal is to not have that requirement to be more like Bitcoin or more like proof of work

and provide synonymous validation entirely. So those are kind of the major differences. As a consequence of this, Casper provides better security against

oligarchs or like like mining cartels, than tendermint does. I mean, tendermint 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 of a proof of stake system. Let's take a short break to talk about Jacks. Jacks is a multi-coin wallet created by the people at the Central. Now, in the past, if he 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 within side 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 the other devices. Jax works with Windows, MacOS, Linux, Android, iOS, and has browser extensions for Firefox and Chrome.

So go to Jax.io, that's J-A-W-X.I-I-O to download the wallet and get started today. We'd like to thank Jacks for the support of Epicenter. What are the challenges in getting the best of both worlds? No one's ever created an algorithm that works that way before. So there's just that challenge. I do agree with Vlad that it needs to be correct by construction. And so that's just a challenge, just making any sort of algorithm correct by construction. That means that...

you have mathematic proofs that are explaining why the algorithm is the way it is not just some tests or some like hand-wavy explanation but you actually have a proof

that you can walk through that shows that the algorithm you're presenting satisfies the requirements of the people asking for it that it was constructed correctly. You had an analogy to building a

like a building, right? And then one building you would have windows, and the building you would have Windows. I thought that was pretty spotting. 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, 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 then you build a third, floor 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 in 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. And the difference

here, I mean, 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. And I think that 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 correct by construction approach can be a real challenge.

But I do think that when security and safety are a priority, 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 extremely high quality. Yes, I'm certain it is. So perhaps talk about, you know,

I think that it's clear to everyone that tendermint 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 tradeoffs there. I think it was Vlad that said in the Reddit post once, tendermint favors consistency over availability and Casper favors availability over consistency. So what applications can we derive from this? In what context will Tenry best and what context will Casper? 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 think that that characterization, although true, kind of misses the point. So censorship resistance is a form of availability. 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 I would say that there's actually a different trade-off, which is the relationship between finality and availability.

And this is actually an interesting point about Casper, where Casper provides finality, client-definable finality, in its availability. And that's actually one of the major innovations of Casper. So why would I use Tenderment over Casper? I would use Tenderment because it's easier to reason about. It's available today. There's tests.

You can run it. You can download it and use it. It's much easier to reason about. It provides a very simple finality model, which is very important for an application developer to understand when the data is actually in the log. Like, when is the data truly irrevocable? It's much harder to tell in Casper if your data is truly irrevocable. You can end up in weird states in Casper. And of course, Casper's 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. And so, I mean, it's almost like not a fair comparison because Casper, because, you know, I run production. I run systems with the goal of putting them in production that run Tendermint, there is no code of that level in Casper. But the goal of Casper is that the users are able, the applications are able to decide or the users of the applications are able to decide when a piece of data is actually finalized, which is a very fascinating property that I don't think any other system really has. You can sort of put that into Tendermint, sort of.

So one way of thinking about the difference between a BFT database and just a merely fault-tolerant database is that a Byzantine fault-tolerant database is exposing the replication state to the end user. And so both Tendermint and Casper have the ability to do that, but 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 huge change, you know, to go from proof of work to proof of stake. How do you think that change as a network will be possible?

And do you believe that's actually going to happen? And, you know, would that, for example, mean that different clients like GF would all? also transition to that or would they kind of then just have one client? How do you see that playing out? Yeah, so I would assume that all the existing clients would migrate to proof of stake. I think that it's actually fairly easy to one of the benefits actually of the theory I'm currently running in proof of work is that you can use proof of work to establish the canonical nature of your

second genesis block or your proof of stake genesis or whatever you want to call it. And so I think that that helps. I don't know 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 switchover. So that's an interesting question and an interesting challenge. I think there's some interesting questions too, right? Like if you run EVM 1, while you're running the Casper EVM, whether it's

rolling or whatever, where those other EVMs may be 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 proof of work part of it?

Do you need to replicate? I don't think you need to replicate that, 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 interesting technical challenges there. But I think from a policy standpoint or from an operational perspective, it's fairly straightforward that we can just switch to proof of stake 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 almost 100% certain that would happen within three years, and I'm pretty certain it would happen within one and a half or two, depending on how aggressive we are with the testing. 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, we've touched on Rolang and type languages, and this is actually something that I wasn't really aware of until you mentioned it to me last week. So Scenario, which is a project that we've covered on the show before. We've had Greg Meredith on a few months ago to talk about scenario. That project is sort of splitting up. So Greg has left the scenario project and is now working on his own. thing which is called R-Chain that would implement a Rolang VM. And of course, Rolang is a functional programming language that is typed.

So very much better for sort of high-end, secure enterprise applications. Now, you mentioned that Rolang 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. 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 hand-wavy speculative. it seems as though that

that's probably going to be the VM honestly actually I'm not I don't necessarily want to say that because I can see how that can go wrong but right now tentatively the rolling VM would be the VM that's used inside Ethereum 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 Role Ambium? Yeah, I mean, just the static typing analysis alone, but it's actually a correct processing model. Like the current model that Ethereum uses is really the wrong model for the work that Ethereum is doing. So part of the reason you have these reentry bugs is because there's some confusion about how threading works or how the interdependence of processes in the existing EVM is not well defined. And so switching the row laying

fixes whole classes of bugs and handles this by using the correct abstraction or the correct metaphor to describe what's actually going on 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 you're part of the listener reward. So when you say Ethereum switching to Roland VM, I mean, what would that mean for solidity? would that mean old contracts would still function or those have to be ported over? Or like, how exactly would that work? I think it's an open question. Oh, those are all open questions.

But I think you could maintain the old 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 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. And then that obviously ties into if you have old contracts that really can just expire on their own, then presumably you can optimize and let the old EVM1 contract sort of die out as they become used less and less. In terms of solidity, I think that solidity.

is going to be moving in that direction. Solidity is going to be moving towards being a strongly, having a type system that's compatible with the Rowling type system, more so than the type system that it has today. And so I think that over time, solidity will be moving closer to the kind of language that Rowling is designed to support. Because Rowling is not really intended to be the final high-level language.

As I understand it, I understand that there would be another language that's closer to solidity on top of rolling. So then would, are you saying that the solidity would compile to Rowling? Yeah, I think that's, I think that's a possibility. Okay. There's, there's some pros and cons to that method. And I don't think that the solidity of today would compile particularly well to Rowling. but I think that when you look at who's been hired by the foundation to work on solidity,

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

You'd only ever be telling developers to use one VM at a time anyway. So, you know, like use the newest VM available. Just because you're maintaining backwards compatibility doesn't mean that you'll necessarily even accept new contracts deployed in that namespace. Would that imply some sort of a hard fork, or could anyone just compile bytecode in their own VM and deployed on the network?

Oh, that would definitely require some kind of hard fork. One of the discussions that we've been having in the Casper community has been, do you provide the network bytecode as you do now, which is difficult to evaluate, difficult to verify, or do you provide source code? So I'm a big proponent of actually putting the source code for the contract on the blockchain and getting consensus on the compilation of the contract. So 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 what is the type system and why is this a big deal in this context? Well, yes, I'm happy to do that. I would also recommend that people look at Wikipedia to get like a more robust version because I'm certainly not going to do it justice. But in essence, when we talk about variables in a computer, those variables inherently have a type.

and a type basically is like a set of properties or a set of attributes 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 you can have the number types are integers, floating points, you know, rational, you know, like fractions. So these are all types. You can also have a string as a type. You can also have bytes, so just like strings of eight ones or zeros in arrays. You can have that as a type.

And then these are, this is a very, 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 Rowling is based on a very advanced system that is a significant improvement on like the process calculi, which is another type system where 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 sum up, a type system is a way of

defining the data structures in your program such that it allows you to do certain types of static analysis more efficiently. Static analysis being the ability to look at the code without running it and make statements about its properties. Okay, so 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, a particular attributes, each variable has a particular set of attributes. Yeah, exactly. So you can say, right, so 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. And that sort of verification is necessary both in sort of a general broad enterprise context for very high security or high assurance applications. But it's also important, 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 does what it claims to do. I mean, because you're saying what you have, otherwise is that you have different types or maybe it's not so clear 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 system's 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, the type system that exists in the EVM today, which is ultimately the EVM is operating on bytes, 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 Dow hack would be impossible. Now, recently there's been other discussions about complementary blockchains working together to achieve some greater good. And recently there was an article, I think it actually just came out today or in the last few days, on Zcash and Ethereum and how they could be complementary. Can you give us your thoughts on how the work, work that's being done on Zcash could be integrated in Ethereum and what that would bring to Ethereum as a network.

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

It will certainly confound certain types of analysis, which I think is good for the network. And so what seems interesting to me is that all these networks are independent, right? So Zcash is a network, Ethereum is a network. R-chain, I don't know where they are. I know there's some talk about splitting scenarios AMP to have an R-chain coin as well. And so, you know, each of these networks has their functionalities. what would be the incentive to continue to have Zcash and continue to have our chain if Ethereum brings all of these functionalities, right? The strongly type functional programming language and zero knowledge proofs and some other things like, right, if Ethereum brings all these in and integrates them into the core Ethereum protocol, what then becomes of these other networks?

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 that value that already exists in Zcash isn't going to go away. There may be reasons why people, you know, users have a preference for Zcash over Ethereum. Also, there's just, it's good to have a plurality of systems in these types of ecosystems for security purposes,

for research purposes. There's a couple different reasons. So I think that there's enough market right now. that all of these different systems will find their niche as long as they are actually providing value to some class of user. So on one hand, I think Ethereum, I don't think Ethereum is like gonna steal the thunder

of these other networks, but I think that Ethereum, the current thesis of Ethereum to be featureless in quotes, gives them the ability to sort of take the best of breed of all these different features, systems and integrate it. And that's actually one of the things that I really like about Battalox's current approach is I think that taking that pluralistic open position is like pretty vital to having the project be successful in the long term. So Rick, you mentioned that you were working on your own product through your company,

Vulcanized, which is called VulcanizedDB. What are you building there? Yeah, sure. So it's basically a Byzantine fault-tolerant database. So the idea is a blockchain isn't really a database. In particular, it's very difficult to figure out what the current state is. 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 engines on a blockchain.

So the concept, the idea here behind the BFTDB 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, fault-tolerant, Byzantine fault-tolerant database that you can query, that you can use for SQL queries, but you don't really get the anonymity kind of properties that you would get from a blockchain, and your performance is not necessarily going to be as tunable as a traditional database, but you'll still get very good, significantly better performance than what's available from a blockchain. I mean, of course, we've done an episode on this show before about the Big ChainDB,

which sounds very much like that. So what's the difference here? So I actually was talking to some of the big chain DB folks recently, and they were mentioning that they had considered going down this road, but they thought that the, you know, it's, so it's in the same space. They're similar. My system is going to provide, you know, Vulcanized DB is going to provide higher security guarantees out of the box. and then over time we'll probably be able to get closer to perform on the performance side of things

to Big Chain DB but 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 you know we're just emphasizing

different parts of the trade-off. Also, the way that you get that speed in the Vulcanized DB model is by exposing complexity to the developers, which is always sort of a double-edged sword. Let's take a break to talk about the Ledger NanoS, the new flagship hardware wallet by Ledger. I'll pass it over to Ledger's CTO, Nicodabaca,

who can tell you all about Ledger's security features and SDK. So Ledger NanoS is a person. personal security device based on a secure element, a 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 solutions, this device is based on the latest generation secure element, the ST-31 from ST-3MICOR. The SC-31 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. The 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 applications on the hardware wallet, even post-issurance, 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 that let you do anything you want with this device. We provide sample applications for cryptocurrencies, different cryptocurrencies, so Bitcoin, Ethereum.

We will also provide a Fido 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 NanoS sets the new standard in hardware wallet security and usability. You can get yours today at ledgerwallat.com. 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 mentioned it earlier in the discussion that the difference between a fault-tolerant

database and a Byzantine fault-tolerant database, or one way of looking at it, is that you're exposing the replication state to the developer. So let me try to put this into blockchainy terms. So when you have your blocks coming out of your blockchain, right, you have the transactions, the transactions go into the mempool, and then the transactions are pulled from the mempool, and they're converted into blocks. And then when someone wants to read data,

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, you send a transaction 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 Mimpool, except when you're using a blockchain, you can examine and inspect the Mimpool. 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 whether they should believe whether that message is really committed or reliable or not. And so what that means is that you don't necessarily have to wait for blocks. if speed 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 mempool. And obviously that's less secure than waiting for a block, but it can be orders of magnitude faster.

And so where are you at in the current state of development of OrganizedDB? A lot of theory, a lot of thinking, some proof of concept code, that passes a couple of tests. Basically, what we've done is we're taking Cockroach DB, which is a fault-tolerant acid database, and we're replacing Raft, which is the most popular,

or one of the most popular consensus engine, and we've replaced that with Tendermint, and we haven't run any performance tests on it, but we've run some tests on it, and we've gotten good results, in terms of test coverage. And so that's sort of 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 over the next, you know, the next couple of quarters, we're going to be, you know, pushing out this set of features to our clients at Vulcanize and really sort of kicking off development in earnest. Cool. So before you wrap up here, I mean, we've covered a lot of different topics. And I kind of get, you know, like to get your thoughts on what you see as a future 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?

to me it's a very interesting question. You know, I do have this strong bias for federated proof of stake systems or however you want to call them, permission, private, whatever, I really do think that that solves a lot of issues. I think that it's a better model. So I think I personally, again, I am. a cynic when it comes to or a skeptic when it comes to this stuff so I have my skeptic hat I I really question 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 of stake-based it'll almost certainly have a number of sharding features. So one of the sharding features that I'm interested in, that one of my own ideas is basically app sharding, where the application itself requests different validators to run it.

And then those validators run that application in private, which provides you sort of the best of both worlds. You can see that your application is bonded in public to a public validator, but only those validators, of what you selected ever see your encrypted data. Because one of the things that a lot of people forget, and this is a bit of tangent apologies, but a lot of people forget that basically

if your data, your encrypted data on someone else's machine is still less secure than your encrypted data on your own machine. 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 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 a ZKP-based public blockchain. So I think there will still be private blockchains. I think there will be a lot of them. And I think that, you know, hopefully

Ethereum will be the sort of the backbone for interconnecting these various private blockchains. but I'm also optimistic about Cosmos. I'm also optimistic about Pocodot. I think that there will be a place for all of these different networks in five years. Cool. Well, thanks so much for coming on, Rick. And we certainly look forward to following the progress of Vulcanized and all your other involvements in the projects in this industry.

I'm sure you're going to keep appearing in all kinds of corners and being involved there and driving the industry for, it. So thanks so much. Oh, thanks for having me. So Empercenter is part of the Let's Top Bitcoin, or can find this show and other shows on Let's Talk 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. I look forward to be back next to you.