Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Dustin Byington, Ethan Buchman & Jae Kwon: Tendermint – Private Modularized Blockchains

Episode Date: January 11, 2016

As blockchain technologies mature, new protocol specifications are emerging, which take unique approaches to software design and how consensus is achieved. We have talked about Multchain and OpenChain in the past, but Tendermint promises to be a viable solution for many permissioned blockchain use cases. It’s design is modular, meaning that the application layer (smart contract) and the consensus layer are completely independent. This provides added flexibility and allows for business logic to be written in practically any programming language. In addition, its unique approach to consensus, a round-robin Proof-of-Skate algorithm, is much better suited for permissioned blockchain scenarios than Proof-of-Work. Meher and Sebastien talk to Tendermint co-founders, Jae Kwon, Dustin Byington and Ethan Buchman, about this promising new blockchain protocol and how it is different from other projects we’ve seen so far. Topics covered in this episode: How Tendermint came to be and how it has evolved since its creation Smart contract programming and the Tendermint Socket Protocol (TMSP) How Tendermint makes use of the Ethereum Virtual Machine (EVM) Tendermint’s approach to PoS consensus and its scalability benefits Use case for permissioned and public blockchains Future plans and business models Episode links: Tendermint Tendermint for fast settlements Tendermint vs PBFT Tendermint specification This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/113

This is Epicenter Bitcoin, episode 113 with guests Jayquone, Dustin Buyington, and Ethan Buckman. This episode of Epicenter Bitcoin is brought you by Ledger, now accepting pre-orders for the all-new Ledger Blue Developer Edition, a Bluetooth and NFC touchscreen hardware signing device. Learn more about the LedgerBlue at LedgerWolv.com and use the discount code Epicenter to get 10% off your first order. Hi, welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kuchewa. And I'm Meher Roy. Today we are going to talk to the Tenement team who are building a consensus engine and blockchain platform. We're going to be talking to the founders of

Tendermin and they are Jay Kwan, Dustin Byington and Ethan Bukman. So before we start our interview, we'd like to have introductions from all three of them, perhaps starting with Jay. Jay, Jay, can you give us your intro and background? My name is Jay Kwan. I am the co-founder of Tenement, and I started this project in 2014 to solve a long-standing problem in consensus algorithms in cryptocurrencies.

And today, we're all evolving this to become a general blockchain platform and very excited to be here. Dustin, your intro. Hi, everyone, my name is Dustin Byington. I'm a blockchain entrepreneur. My first endeavor in the space was a project called Satoshi Talent. It's a blockchain recruiting firm.

And through that, I became introduced to Jay Kwan and immediately realized the value of tendermint and jumped on board. And it's been moving quickly ever since. And finally, Ethan. Hey, I'm Ethan Buckman, or as Mayor correctly pronounced it, Buchman. I'm considered myself an internet biophysicist. I studied biophysics and was infatuated with self-emergent properties in some natural systems. And then Bitcoin struck me as another example of one of these systems.

And I became infatuated with that. And very quickly wanted to improve on it and find superior ways for it to foster self-organization among humans. And so far, the best way I know of doing that is something like tendermint, which I discovered about a year ago and have been working closely with Jay on ever since, mostly in the context of working for Ares, who also builds blockchain applications on top of tendermint and now more directly with the new tenderman organization. Cool. So let's start with the interview. We'll be covering a lot of themes, how, like what is tenderman? what kind of smart contracting system they're trying to build and the applications that could result out of it. But first, perhaps, Jay, you could answer, what made you start tendament and what problem are you trying to solve here? Sure. In 2014, I was part, it took part in the massive rise and a subsequent crash of Bitcoin in 2013 and 2014. Of course, the price has come back up now, but at the time,

as the price was rising and everybody was super enthusiastic about the possibilities of Bitcoin, I did some knocking calculations that led me to believe that given the reward schedule of Bitcoin and the potential price increase, should Bitcoin gain global dominance as a cryptocurrency, it would have a huge environmental impact. And the price of securing that ledger would be enormous. Of course, a lot of people disagree and it's argued both ways, but either way, I set out to search for better consensus algorithms, something that wouldn't require the energy footprint. And I tried and failed many times, but one day when I was reading a paper on Byzantine fault tolerance from 1988, everything started to click, and I realized that classical BFT algorithms from academia could be adopted to secure. blockchain. And not only is it more energy efficient, it turns out, and this is something that I've

realized after, it turns out that it's much faster and to commit transactions. It's scalable. You can run parallel blockchains and also it's potentially much more secure because it doesn't rely on the, we can talk about it later. So that's how we got started. I wanted to create a plausible competitor to Bitcoin to make sure that we don't end up in some dystopian hellscape. But today, what we're doing now is a little pivot from that. We're taking the code base, we're taking the engine that we've created, and we're creating a general platform, not just a cryptocurrency, but a blockchain agnostic platform.

And a really fascinating one. And so personally, I just learned about Tendermint a few weeks ago, and I'm interested in how it works. we're also thinking about using it at stratum. And what's interesting about what you just said is that I think that for most people, including myself, we sort of have this idea that Byzantine fault tolerance just sort of started existing when Bitcoin was created or don't really conceive that practical Byzantine fault tolerance exists since, you know,

there's been research in this since the 80s. And the fact that it's only sort of coming to fruition now and that we now have open source systems that allow us to implement it. It's really fascinating. That's how long it takes for these technologies to evolve. Yeah, just a few months ago, I heard that somebody say this in a Bitcoin conference, and they expressed the same misunderstanding that Bitcoin was the first implementation of a BFD algorithm, but that's absolutely not the case.

But to be fair, Bitcoin, may there will be the first, most widely adopted BFT application. Absolutely. So how has tenderment evolved since you first started it over a year ago? We started off with a cryptocurrency application. So it was meant to be public, permissionless, but non-proof of work, cryptocurrency. And then when we discovered Ethereum, we decided, hey, Ethereum's virtual engine is pretty good. Virtual Machine is pretty good. Let's implement it.

And we did that. And then we met with, along with Eris and Ethan, we created a permission system on top, integrated a permission system into Ethereum's virtual machine. And that was just a few months ago. Recently, we've evolved to become something a little more different. We're taking, we realized that the blockchain that we were creating was this monolithic stack, where everything compiled down to one program, and it makes it difficult for application developers, blockchain developers to create new blockchain applications. So we're splitting that and making it more modular so that this engine that we've created can accommodate many applications.

And part of that is a network protocol called TMSP. So Tendermint core, the blockchain engine, speaks to the blockchain application via a network protocol called TMSP. And together, they are a blockchain. Okay. Well, we'll talk about TMSP in just a second. First, I mean, I guess one of the ways in which it's different from Bitcoin is that, like, you mentioned, it's, it's modulized, it doesn't have all the code in one, in one application, one code base. Can you tell us about other ways in which, and obviously the consensus mechanism,

which is different, which we'll talk about in the show, but other ways in which tendermint is fundamentally different from Bitcoin or Ethereum? Besides the consensus algorithm? Well, Ethan, what do you think? So there's a bunch of things. So one, it's got, at least in our opinion, superior design from the perspective of like clients at least. Part of this is just a proof of stake thing. Proof of stake like clients are easier to implement than proof of work because proof of work, the like client still has to catch up on all the work that was done

and sort of process all the headers, whereas in proof of stake, as long as they come online once every few months or six months, they can just sort of jump right up to the most recent state. And part in parcel with that is the fact that the app, the app, the appellate, you know, the app, application state has a Merkel root hash that is stored in the block so that you can prove the state of any sub-state of the whole state. Bitcoin doesn't really have this. There's a lot of talk in the Bitcoin community about things like fraud proofs and different ways to prove something about the current state of Bitcoin, and the design of Bitcoin was never really such that

that could be facilitated. Interesting things are happening now with the segregated witness proposal that I'm sure everyone has heard about that should make these things more feasible, but there's a lot of sort of beating around the bush to get there, right? Whereas we've had it built in. I mean, Ethereum was possibly the first to do this in blockchain land, and we sort of originally copied a lot of Ethereum's design in terms of account structures and in terms of the importance of the state route. But now, since the application has moved outside of the core.

for blockchain, we don't force you to do anything except return a state route if you want so that you can support like clients. So now in terms of the difference, aside from the core consensus, the difference is up to you. So you could implement Bitcoin. I mean, if the Bitcoin devs have done a good enough job on their code base in terms of modularity, you can take the pieces of the Bitcoin application state, which is basically you know, transaction processing and Bitcoin scripting language.

the UTXO set and run that as an application on top of tendermint, right? Put that in its own container and have it talk TMSP to tendermint. So if you want to do that, you're free to do that. And then you have exactly Bitcoin's design on a much more performant and, you know, in our minds, possibly secure a consensus engine that doesn't require all the proof of work that Bitcoin requires. I mean, some people want the proof of work for their own crazy reasons. But basically what we have now with tendermint is something that is sufficiently modular in general that you could implement any blockchain design on top of it, at least as far as the application state goes.

Obviously, we're using the tenement consensus algorithm, and we're opinionated about that because we think it's the best Byzantine fault-tolerant algorithm out there to date, and hopefully we'll be able to prove that to you over the coming months. So for our listeners, perhaps, perhaps I can offer a sort of analogy or way of thinking about our conversation to come. So in any blockchain, we could think of three important components that must work together to do something useful. The first component is like a networking layer or a gossip layer, which is once I create a transaction and send it to one node, how do the nodes communicate that transaction to the other ones? That sort of component is the first important component that's needed in a blockchain. Bitcoin has it, Ethereum has it, and a mint will have it. The second component is, once the messages, like once my transaction has propagated through the whole network,

how do all of the nodes come to agreement on which transactions to accept in the ledger or the block? This is kind of the consensus algorithm. How do all of the nodes come to agreement on some pieces of data? The pieces of data, maybe transactions, they might be something else altogether. So Bitcoin has the proof of work consensus. And the third important component then is what kinds of things can you do with the data that is in the blockchain, which is kind of the application state? So for instance, in Bitcoin, once you have data about some transactions, you could, you could

you could run some simple scripts based on the Bitcoin Bitcoin language which is based on fourth. And in Ethereum, you could write very complicated smart contracts on the data that is already there in the blockchain. So there is three components like networking, consensus and application state. Now what tendermint, in my opinion, has done is it has innovated both on how consensus works

and how application state could work in a blockchain, right? Would that be a good characterization? Yes. We've solved a consensus. That's certainly an innovation. And we'll talk about application state and how we use Linux containers to solve that problem. But networking too, it's a problem that we solve. I wouldn't say that it's much of an innovation, except we have a very good solution

for networking as well. So if you look at the code base today, we've modulized it so much that we've created a separate library just to handle peer-to-peer. We've created a peer-to-peer library that can handle much of the details of fair communication among peers. And what we do is we divide a communication channel into multiple sub-channels of communication and we handle multiplexing. I mean, those are all things that you need to do if you want to create a secure system. And so we've done all that as well. So that's networking. But yes, we solve that.

We solve that so the application developer doesn't need to solve it, doesn't need to worry about it. Consensus, we, Tendermit was the first, we were the first to publish a white paper that describes how to use classical Byzantine fault-tolerant algorithms to, you know, to, you know, to secure a blockchain. And that happened in March 2014. This is before like Hyper Ledger was even a company. And ever since then, we've been iterating and improving it. And now it's just to the point where it's pretty optimal

and there's not a whole lot more that you can improve upon it. There are some, we have a roadmap of things to do, but practically we've solved it for 99% of the use cases. And we found a way to abstract that as well. So we've created this thing called TMSP. It's short for Tendermit Socket Protocol. And it allows you as a blockchain application developer to focus on the business logic,

only on the business logic, not on the consensus or the networking. And you can write your program in any language. And the way we do this is very different than, say, the way in Ethereum, Solidity, contract, smart, contract works, right? So in Ethereum, what you have is a virtual machine that runs on the blockchain. Ethereum is a monolithic stack that has a Turin-complete virtual machine, and the

virtual machine handles op-code counting, so it can handle the fairness of resources, such like CPU, memory, and storage. But another way to do that is to just isolate an entire process. The whole process, by process I mean like a Linux process, a process that handles the processing of logic of transactions or the business logic and contain it using Linux container technology. And so Linux container technology isn't new. It's been around for a long time, but it's now getting to the point where we can isolate a process completely so that you can run any process on it. We don't need to do Ethereum style like op-code counting because the Linux container technology can just make sure that each container, each process, gets a fair amount

of resource usage and we can limit the amount of memory use in each one. So application state-wise, you know, it's we don't we don't solve that. We create a platform where you can create any application state logic. Let's take a quick break so I can take you to Paris. There I met with Eric Larchavec, Ledger's CEO, and he filled me in on some of the new products they've recently released. On our website, ledger wallet.com, you will find all our range of products. The new NFC-based hardware wallet, they unplugged, and of course the ledger nanoes that you all

know, which also exists, by the way, on a cool bracelet wearables. You can have it with you all the time. There is the ledger HW1 for Enterprise Youth's multi-signature and a range of accessories, the ledger starter, which helps you to securely initialize a nano or HW1 and the ledger OTG on the go, with which you can connect your nano or HW1 directly on Android phone to use it in mobility.

So go to ledgerWalt.com and check out Ledger's full range of hardware security options with more to come soon. We have a special offer for our listeners. When you use the code Epicenter, you'll get 10% off your order. We'd like to thank Ledger for their support of Epicenter Bitcoin. Let's get into this team and get a deep understanding of how Tendermint differs from Ethereum. Now, like in Tendarmint, kind of one of the, in your blogs you write that with Tendomint, developers could deploy smart contracts in any, could write.

smart contracts in any language they could they they want to like C C++ whereas in Ethereum they have languages such as Solidity and LLL and smart contracts must be written in only those languages because only those languages can then be transformed into or compiled down to the Ethereum virtual machine bytecode now so the questions become why would first for the first question is why would a developer want to write smart contract in C or C++, what's the advantage for it? And the second question, which is perhaps less important at this point is how do you do it?

So the advantage is familiarity and the tool set. Solidity is a brand new language. It's a very nice language. It has its quirks and a lot of those quirks are related to the underlying virtual machine, which is the design Ethereum went with, which certain people have trouble with. We've We've struggled with it at ERIS trying to do certain things. We've made our own necessary changes. And a lot of times when, you know, I'm teaching someone about how to use blockchains and the state of the art is deploying contracts on Ethereum, they get kind of frustrated that they have to use this new language, right?

And some of them, depending on who they are. I mean, some of them love the fact that all they have to do is write a few lines of solidity. Others want a much more low-level control. Maybe they want to do particular optimizations. Maybe they know the hardware the machine's going to run on. and so on. And Ethereum doesn't really allow that at a level under the application developers control, right? They'd have to dive into the particular blockchain implementation and tease that all apart.

So what this enables, what TMSP enables is you to write the application, still just the business logic, in whatever language you want, and write your own testing suites, your own debugging tools, or you can use ones that have been around for 20 years that were used to build Linux, you know, things like this. you could have the most powerful software today working for you while you build your app. And then once you're ready, then you can link it up to the blockchain over a TMSP connection. Very simply, just by implementing a simple interface, which allows the blockchain to pass transactions to your app, and allows your app to return hashes back to the blockchain. And with this very simple back and forth like this, you can have arbitrary applications written in whatever language you want.

and go from there. And so since it's a generalized platform for arbitrary applications, you can, of course, write an application that is the Ethereum virtual machine. So you could run the Ethereum virtual machine over TMSP, and if that's how you want to spend your time, then you can continue writing solidity contracts, deploying them just as you would, only now it's running over TMSP and on the tendermint CORE

instead of on Ethereum. And ultimately, you know, that's the kind of thing that ERIS will be doing, sort of in the short term is taking what was currently all in process, like ERISDB, ERIS's blockchain is all in process with tendermint, right? And so it sort of confines you to using the particulars of the ERIS stack, but maybe an application that wants some of the features, doesn't want all the features, or they want to have a fork, but they don't want to deal with all the complexity of maintaining a fork, right? So by splitting it up into containers and having those containers talk TMSP, you get a lot more modularity and a lot more control

over what you want to do and what you want to use and how you do your development and so on. And so it's all about giving flexibility to the developers and sort of taking a step back. I mean, blockchains, when Bitcoin was introduced, even though all the pieces were there before, the way of putting it together was so out of the blue and so unprecedented and so like anything else that people really took it as like this really unique brand new thing. And what's happening, you know, Ethereum sort of built on top of that and out of this generalize ability layer. But now what we're doing is going back to the lower level components and sort of breaking them apart to see how, you know, a lot of what's here is really very similar to what organizations like Amazon and Google have been using to maintain very highly available networked systems. The differences are, you know, we want Byzantine tolerance because we don't necessarily trust everyone or we want, you know, greater tolerance to software errors. We want Merkel trees because we want to be able to provide simple proofs. We want to use elliptic key signatures because that's the state of the art in cryptography.

And we want to use a peer-to-peer network. And you take those four things together. That's really what blockchains are. And sort of teasing it apart gives you a better idea of sort of how they relate to systems that have been around forever, how they innovate and improve on them, and how they'll fit into existing infrastructure. And so we feel that the tenement application platform and the TMSP really get at the heart of those questions and sort of make it easier to understand blockchains. I mean, one thing you touched on there is something we've talked about on the show before is, you know, how the Bitcoin client came out as this one piece of software.

And I think you mentioned this, I don't know if this is a term that's widely used, but spaghetti code is like, you know, all the code is all munched together and you don't have clear separation between the different components which, you know, like you mentioned is this, this is the way you write software. This is the way infrastructure is written. You have like different components that talk to each other and the code is clearly separated. and, you know, companies like Google, Amazon, and all enterprise companies write code like this. So it would be interesting if Bitcoin had been written like that to begin with, if we'd have something completely different today, what that would look like.

But I want to come back to the TMSP. So I'm trying to get a better idea of what this really looks like. So you have the consensus mechanism running on, on different nodes. And then you have your application talking to the consensus mechanism through this socket protocol. Does your application say it's written in C++ with your business logic, with your smart contracts, et cetera,

talking to the consensus protocol through the socket, is that logic on every one of the nodes? Or is that running on a centralized server? Can you walk us through a bit more like how this actually, what this actually looks like? Sure, I'll take this one. It's the first option that you mentioned. So at Tendermit Core, the blockchain Consensus Engine, speaks to the application via TMSP,

but this network socket connection is not exposed to the Internet. Those two processes that are connected by TMSP runs in a secure container, well, two separate containers, but they only speak to each other except the core, which is also exposed to the greater Internet. So those two pieces run on each machine, and the app only speaks to the core, their respective cores, while the core, determined cores, speak to each other, as well as the app.

And when there's a transaction or when there's block being committed, each core will speak to its application, which is kind of like a black box that it owns and it'll run the transactions and get a hashback. But otherwise, the application is meant to be isolated from the rest of the world. Okay, so the smart contract logic then exists on every one of the machines that is node. Simply the smart contract logic is in one container,

the consensus layer is in another container, they talk to each other through the soccer protocol. Yes. One of the big advantages is we believe there's going to be a whole new sort of epoch of multi-block chain design. So with this container architecture, it's very easy to allow these blockchains to speak to one another. And so new applications right now, we're going to see like single one-off applications

to be built, but pretty soon there's going to be this multi-blockchain application design, which is going to really, really shake things up. Okay, so coming back to virtual machines then and the Ethereum virtual machine, particularly because it is the one that Tendermit uses, you mentioned one in your blog posts that the Ethereum VM is one of the potentially many supportive virtual machines. So I guess two questions. And so the first is, if you can write your business logic in your own preferred language,

having access to libraries you already are used to testing libraries, et cetera, if you have that, then why on earth would you want to run a virtual machine? And secondly, if this isn't the only one, which other virtual machines could we potentially see being compatible with tenterment and are there advantages or would someone be better for certain things or whatnot. Sure. There's two advantages to having a blockchain with its own virtual machine, and these are very good reasons for Ethereum to exist.

One is that you might want to allow arbitrary logic to be uploaded by users to the blockchain. Maybe you don't trust their code. You don't know how long their code is going to run. And you certainly don't want that smart contract to loop forever and waste resources, for example. And so by having a virtual machine, you can have a simple environment where anybody can upload their smart contracts. Of course, you can also do this with Docker. It's just that you can do this with Linux containers, but it's not as lightweight with Linux containers.

if you're going to have a lot, many, many of these smart contracts, especially things that are one-offs, then you'll want something like the EVM. The other reason is because solidity, well, the EVM is a deterministic virtual machine. So when you program in C++, Java, you know, Golang, not everything is necessarily deterministic. For example, when you iterate over a key value, map in GoLang. By default, the language will randomize the order of the keys for you.

But the central tenet of blockchain is that everything needs to be deterministic because that determinism is what allows all the notes to know that everybody is in the same state. So when you're writing an application on tendermint using TMSP, you have to be cognizant to that. Of course, we'll be developing tools to make this easier for you, but it's something that people can already do because, and we know this because that's what blockchain developers are already doing. We know that game developers do this to create lockstep multiplayer games. So it's not impossible. It just requires thinking. And so it's a different kind of tradeoff between having to learn solidity and program and that and be semi-locked into that kind of environment

versus having to program in a slightly different paradigm, but using the same tools that you're familiar with. And there's a few additional things, one of which is compatibility with Ethereum. Maybe that's a goal of your blockchain design for a whole host of reasons you want to hook into a public economic chain, but you want to be able to do things on the side with your own permission sets. Other reasons are that Ethereum solidity is it comes with a bunch of features that are still being fleshed out. Some of them are pretty solid. Things like encoding formats for arguments, things like how the state

is managed and stored so that you don't have to think at all about how you're going to prove to someone the state of one of your contracts, Ethereum sort of deals with that for you under the hood. Whereas if you're implementing from scratch in TMSP, you know, the advantage is, yes, you have the flexibility and you have the control, but the disadvantage as well with great, you know, with great responsibility comes, or sorry, with great power comes great responsibility, right? To accidentally misquote Spider-Man. So we can provide the tools to make it easier for people, but some people, you know, depending on what they want,

it makes sense to have something where it's all just pre-packaged like the Ethereum virtual machine is and works right out of the box with solidity. Other things solidity is doing is trying to implement formal verification through comments. So they're building out a system so that you can comment your code in a way that can be verified by the compiler, so that it's more like English and can guarantee invariance of the code. So, for example, you can guarantee that someone's balance is never going to be negative or something like this, right?

And having to have the expertise to implement that yourself and your own language can be, you know, more than most developers are willing to bargain for, and there are only so many languages that actually do that already. So, again, Ethereum, the EBM provides this sort of all-in-one package, and if you want to escape that, you have the flexibility now with TMSP. And if you don't, you can even use Ethereum's mechanisms and data structures

on top of TMSP as well, alongside possibly other things you're doing on TMSP. So it really just gives you the ultimate flexibility to use whatever pieces you want from anyone. Yeah, this is one of our goals has shifted in the early days. Jay was very focused on consensus and building a better, faster, cheaper Bitcoin, but as of the last six months or so, we've become very focused on building tools for blockchain developers. And so what you see is that we are extracting away all of the complexity,

as well as giving as much freedom and choice to the developers. So just, you know, what we're really trying to do is lower the bar for blockchain development. When you're talking about, you know, all of this low-level plumbing that's involved with doing something like forking, Ethereum, there's probably like 100 people on the planet that know how to do this, this kind of work. And there's no reason, yeah, Ethan J happened to be two of them. But there's no reason that every single application developer needs to do this in the same way that if you're like an iOS application developer, you're building an iPhone app, there's no reason that you would need to recreate the operating system. And so where we reside in the stack is very low. And what we try to do is

just make that as accessible to application developers as possible and to make it as powerful as possible as well. You mentioned something that just wanted to be clear, I understand this. So you mentioned that Ethereum could be a means to communicate with some public block, with the outside world with some public blockchain like Ethereum or Bitcoin, perhaps. I just meant that by using Ethereum's data structures, you're using Ethereum's data structures so that any tools Ethereum build will be more, it will be applicable to you. And then once we're in a world where blockchains are talking to each other,

it'll be easier for your blockchain to sort of talk to and understand Ethereum and vice versa because all the data structures are the same. Okay, right. So you could also, I mean, if you wanted your application to also talk to, say, the Bitcoin blockchain, you could use a Bitcoin library within your application that you write in your own language and then talks to the consensus mechanism with this. And you can do that in your own language, and Ethereum has even done it in Serpent. They've built like a Bitcoin node.

It's not a full node. It doesn't process the whole chain. It's basically a light client. But they built it in Serpent and it runs in the Ethereum virtual machine. I'm not sure how much gas it costs to run anything there, but they've done it. So it's a very powerful engine and development environment, but it does have its quirks. and there's there are reasons to use it and reasons not depending on your circumstance. So, okay, let's go into an example to just kind of flesh out this discussion.

So like in Switzerland, the two big banks that people use are like Credit Suisse and UBS. And let's imagine a scenario where Credit Suisse and UBS together want to build a blockchain. and for ease of assumption, let's also think they don't want to maintain the infrastructure. So we have two scenarios, two banks are in both scenarios, and they want to build a blockchain in both. In scenario one, what they want is

any customer of UBS should be able to write any smart contract and deploy it to the joint blockchain and the blockchain will run it. So for instance, if there was a way, which somebody could write I don't know a smart contract that allowed me to track the value of an Apple share by holding Swiss francs anyone can write it on that blockchain that's scenario one anyone can push any code they want to this bank blockchain and scenario two is the opposite the other one where the banks want to restrict the functionality of the blockchain to only a few elements like the

elements might be okay the customer can can send money to another customer on the blockchain, the customer can exchange the UBS Swiss franc for a credit Swiss franc, the customer can deposit this Swiss franc to get interest, and let's say there are only five or six defined functions. So in one case you want to build a blockchain where you want that to be very open like a Swiss army knife can do anything, and in the second case you want the blockchain to only do a specific set of things. Now what you're essentially saying is, If you want like the Swiss Army knife kind of scenario, go for the Ethereum virtual machine architecture. And if you want to go for the restricted function scenario and the developers of the blockchain want to optimize the performance of the blockchain for those scenarios, then they should go for smart contracts in some other language.

Would that be a good way to look at it? That's sort of it. So I want to clarify that the platform that we're building out is not restricted in the sense that if you build an art platform, then the business logic that you can write is necessarily limited. Okay, so what I mean is you can actually launch multiple parallel blockchains and have isolated functions that are each. their own blockchain. So if that fits within your model, you know, let's say you're a bank, you might have, you know, you have like Forex, you have syndicated loans, all these capital markets functions, you might need 100 blockchains to manage all that, but you probably want to have each blockchain be, you know, the code be very specialized in each regard, rather than having

one general blockchain that anybody can upload arbitrary code too, because that's, that's, you know, from a bank's perspective, impossible to audit, right? There's no way you can audit an arbitrary code. You'd have to limit the functionality anyways. So it's not like a Swiss Army knife versus restricted. It's more like Swiss Army knife versus a more, it's a different kind of Swiss Army knife. It's one, okay, so where Ethereum. Like a Swiss Army Knife versus a toolbox.

Versus a toolbox. There you go. Yeah, yeah. I mean, our platform is still turned complete because we're using Linux containers. It's just not exactly. Right. So here's a case where in terms of performance, like Ethereum might make sense. If you have many one-off smart contracts where users can have, you know, each user might have their own specific kind, completely different one-off smart contract, then it doesn't make sense to use, put all of those in Docker containers today because each one-of-of-threaters.

will be their own process and you don't want to be running like a billion processes, right? So for that case, you might want Ethereum. But for most use cases, that's not going to be the case. So you might want to use TMSP. You can also have a blockchain that is for the most part restricted, like you said, like it's a blockchain that does very specialized things, but occasionally invokes the EVM, Ethereum virtual machine, in cases where you need to invoke arbitrary contracts.

You might get something like that when you have something like a payment channel system where to close out the payment channel you can, you know, you have a variety of options for dealing with conflicts. You might want to ask an Oracle or induce something, or you might want to run an arbitrary contract. And, you know, it might be that most of the time you don't have to call these EVM functions. So you don't want to build your application to rely entirely in the EVM, but only invoke it when necessary. So it's very complicated. You know, from a high level, censorship resistance is very expensive. We saw that with Bitcoin, and, you know, that's sort of people become to realize as they've been moving more and more towards blockchains.

And but that's true of Ethereum as well. And so when you have a virtual machine that anyone can upload code to, the underlying infrastructure required to support that inherently, I think inherently means that you can build systems, like if that's not an assumption, which isn't for most permissioned use cases, that you need censorship resistance, it logically makes sense that you could build a system that is more efficient, and that's what tendermint's trying to do. There's a quote, I read it, it was one of Tim Swanson's. I'm not sure it was him or Robert Samms or somebody, but it was essentially that censorship-resistant use cases will gravitate towards censorship-resistant

systems, and non-censorship-resistant use cases will gravitate towards non-censorship-resistant systems. And so I think that's a big part of the market that we're going to go after and trying to cater towards. So, you know, yes, we are restricted in the fact that, yes, you can't just upload any arbitrary code. But in other ways, that really opens us up to being able to be much more flexible. Okay. So, yeah, that clarifies the situation. In my mind, in my mind, I see it like with, if you have some something like an EVM and a couple of banks build a blockchain like Ethereum, the problem might be that somebody, let's say, uploads a Ponzi scheme contract onto their blockchain,

and then their blockchain executes that, and that gives them a hard time with the regulators. So they might not want to open up the general functionality. And this thing is, if you want to open up such general functionality, it costs a lot in terms of resources. You need a specialized EVM that needs to count cycles. There's a lot of administrative overhead for actually building such a general blockchain. So for a bank that wants a blockchain in which it can do a few things and keep adding on those things as they want to, but not necessarily allowing the people to put smart contracts of their choosing into it.

They can use like your architecture to do that. And your architecture will be more efficient because it. can be designed, like purpose built for exactly their application, their set of applications, right? Yes. OK. And it's not even that the blockchain is immutable. If you want, just like you can choose to run the Ethereum

Virtual Machine and make it permissionless and censorship resistant, you can also upload a new kind of application. You can have nested Docker containers. So you can have an application running on TMS where if you want to extend it, you submit a transaction that has a code that gets compiled and spawns a new sub-doctor container and you can manage, well, sub-applications. Maybe at that point they should be called smart contracts. There's a lot of ways to do it.

You can have different configurations like that to handle upgradability, mutability of the blockchain function. Exactly. So at the end of the day, TMSP basically gives you the best of both worlds because you can take any conceivable blockchain application state and build it on top and put multiple ones together like Jay was just saying. If you want some purpose built contracts, but you also want the EVM and you also want your EVM to be upgradable and your purpose built contracts to be upgradable and possibly to have multiple versions running at once and so on, we could build a TMSP app and probably will that is basically a Docker orchestration app. so that people can send transactions that bring up new Docker containers and use that to manage the contracts. And then if they want to do specific contracts on the EVM, then they can do that and we don't have to launch new containers, but if they want to write a contract in Haskell or whatever language of choice, then we can support that too. So at the end of the day, the flexibility is enormous here and it's really up to the particular

use cases of what they want. Yeah, that seems very clear and awesome. I mean, that's certainly, I think, the most unique approach I've seen in this space until now. And it wasn't so clear from the blog, but now from this conversation, it really is. So, I mean, we should move on to the second interesting topic of our podcast. And because Jay has worked so much on consensus, and he wanted to initially build a better consensus system. for cryptocurrencies.

Perhaps we should go into what is special about tendament consensus and how it works. So, Jake, could you give a short intro of how consensus in tendament works? Sure, I'll try. I just want to mention it's not just me. Ethan has done tremendous work in verifying the algorithm and also refactoring it and re-implementing it to be much more modular, understandable, and deterministic. But I can give a start and maybe Ethan can jump in too. So in your consensus algorithm, you have, it's a round-based algorithm, right?

Where you have lots of validator nodes and they communicate with each other to build blocks. So how does it work and how is it different from Bitcoin? Okay, sure. A high-level review, we don't use electricity, like we mentioned. And it's not about how much cost went into producing this blockchain. That's not how people come to agreement. Rather, there's a set number of voters who should, in an ideal scenario, all be online dedicated to committing blocks together.

And a high level is that, let's say there's 100 of these validators. They all have a public-private key pair, and you need a quorum, a set at least. least two-thirds of them to sign a block for it to be committed. So it's a round-based protocol, and what we mean is that every round, so let's say we have a blockchain and we need to decide on the next block. There's going to be a designated proposer. Based on the past history on the blockchain, there is a proposer who is decided unanimously decided. to be the next proposal for the next round. And we start at round zero or round one.

So the first round, there is a proposer who proposes a block. That block gets gossiped to everyone, and then there are two more phases. The first phase was proposal. The second phase is pre-vote. That's what we call it. It's a vote-signing phase. And the third phase is another vote-signing phase that we call pre-commit. So by the way, block is just a list of transactions.

And so let's get into it. After the block is proposed, the next step is pre-vote, where all the validators check to see if the transactions are valid. They run the transactions and see if the box is good to them. And then if two-thirds or more of pre-votes are seen by a validator, and the third step, in the pre-commit step, if they see two-thirds or more pre-votes, they go ahead and pre-committed.

They sign a vote that says, this is a pre-commit vote, and yes, I saw two-thirds or more pre-votes for this block, and they sign it. And if two-thirds pre-committed, then the block is committed. So ideally, the whole process happens in one round. Most of the time, that's what will happen. But when there's latency in the network, or when the proposer is offline, or when the proposer proposes an invalid block, then it's possible to have to go on to the next round, where the next designated proposer is chosen. It's predetermined, actually.

It's not chosen, but rather the next proposal in line proposes a block, and we do this thing again. There's more detail involved with locking and timeouts that it's very difficult to get into, in a podcast. If you want to learn more, then I suggest going to the GitHub Wiki for Tendermint, where we have a specification of the consensus algorithm. So there. Today's magic word is socket, S-O-C-K-E-T.

Head over at let's-stock-Betcom to sign in, enter the magic word, and claim your part of the listener award. So with Bitcoin, we have proof of work where essentially you put up electricity and computing power in order to mine a block. And based on the amount of computing power you have, you have a probability, your odds of winning the block will be proportionate to your amount of electricity. I don't think I need to get into your amount of computing power. I don't think I need to get into how proof of work works. But with proof of stake, it's different. So you have something to lose, and that is that you're putting up a deposit.

Can you explain how that's fundamentally different from Bitcoin in tendermint or perhaps even other proof of stake systems? How is tenderness different from those? Well, from a high level, remember that we don't have this assumption that you need censorship resistance. And that's why you have all this complexity around Proof of Work or Nakamoto Consensus. It's actually a pretty clever solution under the assumption that, you know, anyone can submit a transaction, anybody can validate a transaction. One of the problems are kind of derailing just for a quick second is that the financial institutions face is a thing called OFAC, Office of foreign asset control. It's actually a subset of the Department of Defense. And so, and what OFAC does is it says, hey, certain countries, certain companies, certain people you can't deal with.

And if you do, you've got the Department of Defense to answer to. And so a lot of financial institutions we talk to are worried, hey, if I use Bitcoin, what happens if someone processes a transaction in North Korea, digist, violate OFAC? And so, you know, censorship resistance is not only is an actual problem for many of the financial institutions who very much like to know who their counterparties are. And so if we're operating in this world where we want to know who our counterparties are, it's pretty simple that, like, you can just leverage the existing legal system. And so just the way that, like, financial institutions or enterprise clients will hire

software manufacturers to perform certain duties with them and they have legal contracts and if you break those contracts, then there can be ramifications. So now we also have baked in this monetary guarantee that is a little bit more fundamental to our system that doesn't require. It can but doesn't necessarily have to require the outside legal system. So essentially what happens is if you don't act appropriately, then you get punished. To be a validator in the system, you need to put, you can require validating. to put up a bond. And if you don't validate properly, then you lose that bond. And so we kind of envision this world where validation will be very specific to different regions and different

circumstances. And we think it could be quite likely that, you know, regulation could even be passed that requires validators to put up bonds in the same way money transmitters have to put up surity bonds. But a lot of this is sort of unclear right now where the world will evolve to. We're pretty flexible in regards to, you know, how we kind of fit into that future landscape. So I just want to add that's a very good point. Bitcoin, you know, is censorship resistant because it's anonymous, but it comes with, you know, characteristics like it's slow to commit blocks because you have to burn a lot of electricity over time in order to have any kind of guarantee that there was cost associated with it. Okay. But when you have validators who are public

or pseudonymism even, but if you know who your validators are, and if in order to attack the blockchain, you require a significant proportion to collude, and when that happens, you can figure out who did it, so it's accountable, those three combinations, knowing who the validators are, even pseudonymity, requiring a significant fraction to attack the network, which is provided by the BFT algorithm, along with being able to know who caused the attack, those three properties together is what makes proof of stake secure. So that's the way it's different. And I would say that high-level overview of the security characteristics, like Bitcoin requires

continuous burn of electricity to ensure security, whereas in proof of stake, in the kind of model that we just talked about. It don't require a constant burn. You can come to complete agreement, a final commit of a block in as little as under a second. It's really just about two rounds of communications among the validators. And you can have final commits without having to wait. And that's because the security doesn't come from burning, but it comes from collateral. So in essence, to come back on what Dustin was saying, you could have a tenderment blockchain where there is no collateral to put forth. Simply all of the nodes are taking turns validating blocks. Is that right?

Like you could have a system like that. Okay. So then on the sort of spectrum of fully permissioned blockchains, where all the actors know each other, let's say, for example, different branches of the same bank, and then moving towards less trust between actors, so perhaps like two different banks working together, and then the fully untrusted... Permissionless. Because permissionless, which is like Bitcoin, basically.

where does tendermint best suit like for what use cases is tenement best suited and in what where on that spectrum does this proof of stake algorithm

excel yes I would say that it's the first two that you mentioned that we're specializing for today so So for banks that are identified and trusted, they can have collateral that is held off the chain. It could be maybe even just reputation-based, perhaps, if you're talking about the Federal Reserve or something.

Or consortiums where members post-collateral on the blockchain or possibly on another blockchain, or it might be off the blockchain with legal contracts with distributed or centralized depositories. That's what we're building for today because that's what business wants. And those are the business cases that exist today. That said, we can also, tenement, the consensus algorithm can also work for the latter case that you mentioned. That's more permissionless. It's just that we're not building our own public blockchain today. The pain point is definitely, currently is in areas that, where there's high stakes of financial institutions

and where there's limited trust also happens to be quite frequently financial institutions, particularly those looking to create consortiums. So, you know, obviously the idea there is just cutting out the middleman. So all these banks can work and interrupt and work together directly. But it's quite interesting. We thought a lot about the reasons behind permission blockchains. And we knew quite early that there was an opportunity to support permission blockchain developers. However, we really dug into.

the why, okay, yeah, you want to build a permission blockchain app, but we can help you, but why do you want to build one? And that was a deep, deep rabbit hole that, and one of the things that came out of it was that, you know, even a single organization can benefit from a permission blockchain, particularly large organizations, where you have regions or departments that don't fully trust each other and with their data. And remember, in this new world, data equals assets. So, you know, for to kind of, you know, Bitcoin, this is digital bearer asset like cash. You know, you hold the Bitcoin, the private keys, you own the money. Similar to I hold the $20 bill, I have access to that money. It's not an IOU. And so right now,

what will, I think we'll see movement towards us more and more digital bearer assets, chains doing some great work in this department. And then once we have this world where, you know, data equals assets, then trust becomes infinitely more important or actually the lack of trust, even within these organizations, because they don't want to necessarily want to trust their assets to other departments or other regions. And so, you know, that's how I think it'll kind of evolve into the non-financial space. And really, it's, blockchains are essentially very high-performing databases. They're not, and so there's a lot of interesting use cases that are going to come out of So I think the business models and the use cases are the topic we want to handle next.

But just before we jump to that team, unless I like Ethan or Jay to chime in and give an example of how fast and how scalable these blockchains are. Like what are the performance characteristics? Can we illustrate to an example? So in tenement, we've been benchmarking pieces of the stack recently. And the main figure we're throwing around is that we can crunch 10,000 empty, like, non-processed transactions per second. So you're not doing anything fancy. There's virtually no logic.

You're just moving around transactions that are, I don't know, maybe 100 bytes. I forget what we actually used. And we can get around 10,000 per second. And this is before we do any optimizations, including some very low-hanging ones, that we already know about. So we expect that with those optimizations, we could get that number up to 30, 40, maybe 50,000, maybe even higher, and then go from there.

So the sort of benchmark for, or like the lowest level for hitting practical Byzantine fault-tolerant systems, I think people usually put at around at least a few thousand transactions per second, maybe 10,000, and we're hitting that easily. So in terms of throughput of transactions, the bottleneck will probably be on the application side. So depending on the, you know, we can't just answer that question because it really depends on the application, what the logic is, how many users there are. For example, if you have a mercilized, you know, binary search tree, it's that self-balancing or a patrician tree, and you have a a billion accounts or a million accounts or a billion accounts, then there's going to be overhead,

especially when that tree is accessing disk for every, for every, you know, update or read, right? But on the other hand, you can actually stick all of that in memory if you have a terabyte of RAM and your application logic, your business logic is very simple, and it's just, for example, a very simple cryptocurrency for a billion accounts. You can stick a lot of it in RAM and optimize the logic so that it doesn't use an advanced Merkel tree, but still with Merkelization. And you can get up to like 50,000 transactions per second on commodity machine.

It really depends on how you code the application and what the use cases are and how much data there is in it and what your persistence model is. So moving on to use cases, and this is something that, I mean, I constantly think of and we all, I guess, constantly think of is like, where is this going? What are going to be the prime use cases for blockchain technologies, whether it's in a permission system or permissionless, or somewhere in between. Obviously, we talk about the financial sector a lot.

Obviously, we talked about coding business logic into a decentralized system. We talk about fidelity points. We talk about IoT. But all these examples are yet to be demonstrated. We're still just sort of thinking about how we could do it. and there's a couple of proof of concepts, but, you know, nothing like on a massive scale where, like, we can just clearly show this works

and we've saved so much money or we saved so much time. I'd like to ask you, perhaps all three of you, what you think are the most obvious use cases for blockchain technologies and which ones will get implemented and we'll see, like, okay, this is a clear pain point that blockchain can fix? There's, for the first production use cases we're going to see are ones that sit on top of

legacy systems. So there's, there's a company that we're working with. We call them Block Street companies like Blockchain Wall Street. So it's a Block Street startup that what they do is in the, I still prefer Wallchain, by the way. Yeah, he likes Wallchain. So what this startup does is they're in the foreign exchange space. So imagine you have two banks called Barclays and UBS. And they engage in a foreign exchange swap, the U.S. dollar and the yuan.

So right now they record all that on their own independent databases. And so what they're using is they're using the blockchain as a triple entry accountant. So now in addition to recording the... trade in their own databases, there will be an additional entry into a blockchain database that says, you know, how much was transacted, the day, the time, the strike price, et cetera, and they both cryptographically sign it. And then if there's ever a dispute after the fact, they can look at this, you know, perfectly auditable ledger and determine, you know, sort of fixed the, so it just creates

a lot more security in the system. And those are easy to implement because you don't have to rip anything out. you're adding on to the current system, I think the next wave, what we'll see, are then moving towards the, like, the aforementioned digital bearer assets. Now, those are interesting because you hear a lot of talk about reducing time to clearing and settlement. And so, first, like, what is clearing and settlement? When, if I want to send, Sebastian, if I want to send, if we want to trade stock, right now what basically happens? is I send you a message and says like, hey, I want to buy the stock from you. And then you say, sure, okay, and then we engage in the clearing and settling process.

And where, you know, moving assets from my bank to a clearing house, your bank, it's a, and it takes a few days to complete that. But if you, in the world where you have a digital bearer asset, and so, and I have some sort of token of value, whether it's a Bitcoin or, you know, Clear Maddox guys, and there's a few other talking about the settlement coin, which is basically just like, like loading some value into the system, then we can just like atomically swap your digital bear asset that's your stock with with my value token of whatever kind. And boom, we just traded.

And there is no clearing and settlement because it just atomically swaps these assets. So I think that's kind of, but that's going to take a lot more time because there's a lot that goes into that. There's like all of these systems are, it's a hornet's nest diving into this stuff. And you have to, not only the swap itself, but all the reporting mechanisms that go into it. And so, and it's, so I think it will come. It just will take longer. And then the third phase is getting more into the database plays with kind of just the broader community outside of finance.

So that's kind of like how I see it in from a high level. Yeah, I think, I think it helps to have a little more context, at least in terms of, I mean, blockchains are really, I almost want to stop using the word blockchain because it's so, I mean, many things to so many people. I mean, it's like using the word God and having to have a trying to have a reasonable conversation at this point. It's like not possible. But anyways, like blockchains are, what Bitcoin introduced two things. One was this data structure we call a blockchain, which is really this combination of Byzantine fault tolerance, Merkel trees for compact proofs of the state, state-of-the-art, you know, public key signatures, and peer-to-peer

networking, right? There had always been peer-to-peer networking. There had always been, you know, Byzantine fault tolerance, but they weren't all put together. The thing that made Bitcoin really take off was the fact that in addition to putting these things together, it had a unique solution to Byzantine fault tolerance, which was this economic solution where, you know, people pile blocks on each other and try to do the one with the most work. And, you know, it's a brilliant solution to Byzantine fault tolerance, but of course it involves all the economics. Now that we've gone down this road of seeing where Bitcoin can take us and they're starting to try and step backwards and deconstruct the Bitcoin stack and put it back into context, we realize that,

you know, this combination of these four pieces is very useful, basically anywhere consensus systems are used. And consensus systems are ubiquitous. I mean, every major internet service on the planet today is using a consensus system at the bottom of their stack one way or another. Most of those are Paxos, which was the first really popular consensus system. It's not Byzantine fault tolerant. Nowadays, a lot of people are switching to RAF, which is a new consensus system that came out a couple years ago, which is much easier to implement than Paxos and a lot easier to understand. And there's a huge community around RAP. People are very excited about it and about using it, and we're seeing all kinds of new applications built on top, and everyone is starting

to use RAF as sort of their consensus layer. I think what's going to happen is, in much the same way we're seeing that with Raft, we're going to start to see the same kind of thing with things like tendermint and other blockchains, which are just combining PBFTs with the Merkel and the elliptic curves and the P2P for any internet service that needs to be replicated across multiple machines. I mean, whenever you're replicating data, you have some kind of consensus engine to do it. And in an age where, you know, post-Snowden world, where trust has become so much more of an issue at the forefront, people are mistrusting of the government and finances and each other and,

you know, the big bust in 2008 and all the lying and escaping of audit trails. As all that stuff becomes more like prevalent and prominent in culture, it's just going to further motivate the need to run, you know, BFT consensus algorithms rather than just consensus algorithms, the same way, you know, 30 years earlier, when we started having multiple network machines, it motivated the need to have a consensus algorithm at all instead of just having it all in one machine, right? So I think it's kind of this natural transition in consensus itself where we move from

everything on one mainframe to things distributed across multiple machines using something like Paxos to things distributed across multiple machines using something like tendermint and all the cryptography to make it auditable and traceable. And I think sort of re-engineering major pieces of society on top of that

is going to go a long way towards having sort of, you know, better functioning democratic systems. One thing, one sort of quip I like to make is that, you know, people are always like, oh, why use a blockchain when you could just use MySQL because it's so much, it's so much more efficient, right? And I like to say, well, why bother with democracy when you could just have a dictatorship because it's so much more efficient, right? I mean, if you're a dictator, you just say what has to get done and then it gets done,

whereas democracy, you have to fuss about with all this nonsense of voting and so on. And ultimately the reason democracy, I mean, democracy doesn't work as it's been implemented now, we all know, but, you know, theoretical democracy. The reason it's this powerful thing that we all sort of strive for is because over the long term, it leads to a much greater efficiency in terms of, you know, sustainability and quality of life than a dictatorship ever could. And I think this sort of progression in consensus technology is moving in the same direction from, you know, the monolithic, everything on one machine, towards these non-Bisantine fault-tolerant trusted consensus algorithms towards real Byzantine fault-tolerant ones with cryptographic audit trails. And I can just see everything being repositioned on top of that by virtue of the fact that almost everything needs to be replicated across multiple machines.

And especially the thing that gets me really excited, you know, is when we talk about what I mentioned in my introduction, self-emergence and self-organization and physical systems, That's what led me to Bitcoin in the first place because it's like the self-organizing internet system. What really gets me excited is about the applicability of this kind of stuff to government, or as we call it now, government, right? And the way that the transparency and auditability and participation and feedback loops are going to be so much better, so much more fluid and so much more functional in systems running on top of Byzantine fault,

you know, cryptographically auditable consensus networks. And that, and that's the kind of thing that, you know, that get out of bed in the morning and are just, you know, excited to overthrow the government and replace it with a government. Yeah, well, tell us a bit more about this. Sure. So, yeah, so along that route, we started building a TMSP app that we're calling government, you know, M-I-N-T. And it's a very, very simple, what we're trying to do is establish

the absolute most basic pieces we need for a self-upgradable governance policy over the internet. So, you know, the way it starts now is it's just an application for proposing things and voting on those proposals. And the proposals can be, you know, arbitrary proposals that the protocol knows nothing about and have everything to do with things happening offline. And some of them can be related to the protocol itself. So maybe you have a proposal that you want to upgrade the app. Maybe there's some new feature you want. Instead of coding it in from the beginning,

you make a proposal within the app to upgrade the whole app to include this new feature. And so over time, people can upgrade in many different directions and end up with government applications. applications that are sort of suited for them, rather than up front us trying to build the ultimate government application and have everyone try and use that. We're trying to build something very basic that people can upgrade according to their own needs and voter preferences over time. And we're hoping to use that to actually manage live blockchains and validator sets. So for example, something

like validator set changes. We could use this so-called board. It's almost like the validators or the people make up a board, a board of directors or something, they vote using this app, which runs on the blockchain, and it can have a trigger so that they can vote to add new validators, remove validators, change some rule, whatever the case may be. And over time, you get this sort of self-emergent governance model, starting with very basic building blocks. And I think there's a lot of potential for that kind of approach,

and we're going to see more and more of that moving forward. One area we're moving towards is what kind of, I know we're kind of short on time here. So there's one point to get in before we go is the high level business model is that we're giving away free tools, resources to build blockchains. And then the business model comes in in terms of having, creating proprietary tools for deploying and monitoring blockchains. Now, some of those will open source as well. but there's a big market in terms of a lot of problems we solved that people haven't even really begun thinking through in terms of the deployment and management of blockchains. And we have a pretty already in our short history have shown a great track record for solving big problems in the industry, whether it's through consensus itself, through the refactoring with TMSP, through now. with the deployment, with MintNet, and there's lots of other really intriguing things that we're

going to be launching and announcing here in the coming months, so stay tuned. Cool. Well, I'm really looking forward to this government idea. And maybe this could be a topic for an entire other episode, because I think there's quite a bit to talk about there. And you mentioned earlier that you guys were raising funds. Do you want to mention that? Yes, yep, yep. We've been very much in the Code Don't Talk, kind of phase of existence here. And so we've had our heads down working for the last since.

Well, I guess Jay's been working on this for a year and a half quite heavily. Ethan for the past year or so, and I've been for three or four months. And now we're really ready to kind of let the world know what it is that we've been working on and where we're going. And part of that also is kicking off our fundraise. And so we are doing a pre-seed round right now. And so far, the reception on all fronts has been quite strong, both from developers to investors to enterprise clients. So I think 2016 is going to be a good year for tendermint.

I'm sure it will be. And I'm definitely looking forward to diving in deeper and perhaps even working with you guys. Because we have been looking at tendermint at Stratom as one of our private blockchain. solutions that we want to implement. So we'll be looking at what we'll be looking closely at the time of that. Well, thanks a lot, guys, for joining us today.

It was a really fascinating discussion about some really fascinating technology. And yeah, we'll have to dive in deeper, I think, into this government idea at some other, at some point. So thank you for joining us. And episode of Bitcoin is part of the LTV network. You can go to less top Bitcoin.com to find a whole bunch of shows about Bitcoin, blockchain technologies, cryptocurrencies, all bunch of other stuff. We release episodes of Epicenter Bitcoin every Monday,

except for sometimes when we have little issues, as you've noticed recently. But usually it's Mondays, and you can subscribe to Epicenter Bitcoin's on iTunes, SoundCloud, or wherever we get your podcast, could be on a podcatcher app on Android or iTunes, and you can also get the videos on YouTube at YouTube.com slash epicenter BTC.

And if you're a loyal listener and you appreciate the show, you can always leave us a review on iTunes, or anywhere else that you can leave us for reviews. I'm not really sure where else, but anyway, Stitcher or some of the platform. If you do so, send us an email at show at ephicynabitcom, and we'll send you a t-shirt and some stickers and many thanks. So of course, you could also leave us a tip and the tipping address will be in the show description. So thank you so much, and we look for to being back next week. I'm