EB113 – Jae Kwon, Dustin Byington & Ethan Buchman: Tendermint - Private Modularized Blockchains
11 Jan 2016 · 1:18:37
Tendermint co-founders Jae Kwon, Ethan Buchman, and Dustin Byington join Epicenter hosts Sebastien Couture and Meher Roy to explain Tendermint's modular design, which separates the consensus layer from the application layer so smart contracts can be written in any language. They cover Tendermint's round-robin proof-of-stake consensus, its socket protocol for smart contracts, compatibility with the Ethereum Virtual Machine, and use cases across both permissioned and public blockchains.
Speakers
Topics
Transcript
[Music] this episode of epicenter Bitcoin is brought you by Ledger now accepting pre-orders for The allnew Ledger blue Developer Edition a Bluetooth and NFC touchscreen Hardware signing device learn more about The Ledger blue at Ledger wallet.com and use the discount code epicenter to get 10% off off your first order hi welcome to epicenter Bitcoin the show which talks about the Technologies projects and startup driving decentralization and the global cryptocurrency Revolution my name is
Sebastian K and I'm M Roy today we are going to talk to the tenderman team who are building uh who are building a consensus engine and blockchain platform we're going to be talking to the founders uh of tender and they are J Juan Dustin Bingington and Ethan buhman so before we start our interview we we'd like to have introductions from all three of them perhaps starting with Jay Jay can you give us your intro and background uh my name is sh Quan um I uh am the founder co-founder of uh tender Min and uh I started this project in 2014 uh to uh solve a long-standing problem in uh in consensus algorithms in
cryptocurrencies and uh today uh we're all evolving this to become a general blockchain platform and uh very excited to be here Dustin you in true hi everyone my name is Dustin Bingington I'm a blockchain entrepreneur uh my first Endeavor in the space was uh a project called Satoshi Talent it's a blockchain recruiting um firm and um through that I became introduced to jquan and uh immediately realized the uh the value of tendermint and jumped on board and uh it's been uh moving ever since and finally Ethan I I'm Ethan Buckman or as mayor correctly pronounced it buhman um I'm uh considered myself an internet biophysicist I studied
biophysics and was infatuated with uh the self- emergent properties in some natural systems and then Bitcoin struck me as another example of one of these systems uh 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 um about a year ago and have been working closely with Jon ever since um mostly in the in the context of working for ARS who also builds uh blockchain applications on top of tendermint and now more directly uh with the new tendermint
organization cool so let's start with the with the interview um we'll be covering a lot of themes how like what is tender uh what kind of smart Contracting system they're trying to build and the applications that could result out of it but first perhaps J you could answer what made you start tender and what problem are you trying to solve here uh sure uh in 2014 um I was a part it took part in the massive uh rise and uh a subsequent crash of Bitcoin in 2013 and 2014 of course it's the has come back up now but uh at the time um as the price was rising and everybody was super enthusiastic about the uh possibilities
of Bitcoin um I did some naping calculations U that led me to believe that given the reward schedule of Bitcoin um and uh the the potential price increase um should Bitcoin uh gain Global dominance as a cryptocurrency um it would have a huge environmental impacts and the price of securing that ledger would be enormous um of course a lot of people disagree and uh there's you know it's it's argued both ways but either way I set out to search for better consensus algorithms something that uh wouldn't require the energy footprint and um I tried and failed many times but one day when I was reading a a
paper on Byzantine fa tolerance from 1988 uh everything started to click and I realized um that classical bft algorithms from Academia could could be adopted to uh secure a blockchain and uh not only is it um more energy efficient um it turns out this is something that I've realized after um it turns out that it's much faster and uh to commit transactions it's scalable um you can run parallel blockchains and also um it's um potentially much more secure because it doesn't rely on the you know we can talk about it later but uh so that's how I got started I wanted to create plausible competitor to bitcoin to uh to
make sure that we don't end up in some dystopian hellscape and uh but today what we're doing now is uh 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 and so I personally I just learned about tender a few weeks ago and uh I'm been interested in you know how it works in fact you know we're also thinking about using it at stratum and what's interesting about 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 you know don't really conceive that uh practical uh Byzantine Fulton exist since you know there's been research on this since the ' 80s um and uh the fact that it's only sort of coming to fruition now and that we now have open source systems that allow us to to to to to implement it is it's really fascinating that you know how that's how long it takes uh for these Technologies to evolve yeah you know um just a few months ago I heard uh that uh somebody say this in a Bitcoin conference and they expressed uh the same um misunderstanding that Bitcoin was the first implementation of a BF algorithm but that's absolutely not the
case um but U to be Fair Bitcoin may very well be the most uh the first most widely adopted bft um application um absolutely and so how has tendermint evolved since uh you first started it over a year ago um we started off with um u a cryptocurrency application so it was meant to be uh uh public permissionless but uh uh non proof of work cryptocurrency um and then when we discovered uh 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 uh along with Aris and Ethan we
uh created a uh uh permission system on top and integrated a permission uh system into ethereum's virtual machine uh and uh that was just a few months ago uh recently uh We've evolved to become uh something a little more different uh where we're taking we realized that uh the blockchain uh that we were creating was this uh monolithic stack um where everything compiled down to one program and and it makes it difficult for uh application developers blockchain developers to create new blockchain applications so we're splitting that and making it more modular uh so that uh we can this this engine that we've created
can accommodate many applications um and uh part part of that is a network protocol called uh tmsp so tender core the blockchain engine speaks to the blockchain application via a network protocol called tmsp and together they are a blockchain okay well we we'll talk about tmsp in just a second first up can you I mean I guess one one of the ways in which it's different from from Bitcoin is that you like you mentioned it's it's modularized it doesn't have all the code in one um in one application one code base can you tell us about other ways in which uh and obviously the consensus
mechanism which is different um which we'll talk about during in the show but other ways in which tender is fundamentally different from Bitcoin or ethereum besides a consensus algorithm well um Ethan what do you think so there's there's a bunch of things um so one it's got uh at least in in our opinion um Superior design from the perspective of like clients at least uh part of this is 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 um but and part and paral with that is the fact that the the application state has a a meracle root hash that is stored in the block so that you can prove the state of any any substate 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 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 um 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 like beating around the bush to get there right um whereas we've we've had
it built in I mean ethereum was possibly the first to do this in in blockchain land and we sort of originally copied a lot of ethereum's design in terms of account structures um and in in terms of the importance of the state the state route um but now since the application has moved outside of the core blockchain we don't we don't force you to do anything except return a state route if if you want so that you can support like clients so now in in terms of the difference aside from you know 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 codebase in terms of modularity you can take the pieces of
the Bitcoin application state which is basically you know uh transaction processing and Bitcoin scripting language and the utxo set and run that as an application on top of tendermint right put that in its own own container and have it talk tmsp to Tender so if you want to do that you're free to do that and then you have exactly bitcoin's design on um a much more performant and you know in our minds possibly secure uh consensus engine that doesn't require all the 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 uh sufficiently modular in general that you
could Implement any blockchain design on top of it as at least as far as the application state state goes obviously we're using the tener consensus algorithm and we're opinionated about that um because we think it's the best Byzantine fault tolerant algorithm out there to date and you know hopefully we'll be able to prove that to you over the coming months so um so for listeners perhaps um perhaps I can offer a sort of analogy or way of thinking about about uh about our our our conversation to come so in any blockchain we could think of three important components that must work together to to do something useful the first component is like a networking layer or or a gossip layer which is once
I 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 a blockchain Bitcoin has it ethereum has it tender Min will have it the second component is um once the messages like once my transaction is propagated through the whole network how do all of the nodes come to agreement on uh which transactions to accept in The Ledger or the block like this is kind of the consensus algorithm how how how do all of the nodes come to agreement on some pieces of data the pieces of data may be transactions they might be something else altogether so Bitcoin has the proof of work consensus and the
third important component then is um what kinds of things can you do with the data that is that is in the blockchain which is kind of the application state so for an for instance in in Bitcoin once you have data about some transactions you could you could um you could um run some simple scripts based on the Bitcoin uh Bitcoin language which is based on Fourth and in ethereum you could uh write very complicated smart contracts on the data that is already there in the blockchain so there is three components like networking consensus and um application State now what what tender 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 um we uh We've solved a consensus that's certainly an innovation um and we'll talk about application State and uh how we use Linux containers to solve that problem but um networking too it's 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 um if you look at the codebase today uh We've modulized it so much that um the we we've created a separate Library just to handle um peer-to-peer we've created a
peer-to-peer library that can um handle much of the uh the details of um Fair communication among peers and uh what we do is we um divide a Communication channel into multiple subchannels 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 um so that's networking but uh 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 um we uh tender was the first uh we were the first to um publish a white paper that describes how to use classical Byzantine fa tolerant
algorithms uh to uh to secure a blockchain um and that happened in March 2014 this is before like hyperledger was even a company um and uh ever since then we've been iterating and improving it and uh now it's just to the point where it's pretty optimal there's not a whole lot more that you can improve upon it um there are some we have a road map of things to do um but in practically we've solved it for 99% of the use cases um and we found a way to abstract that as well so um so we've created this thing called tender uh tmsp uh it's short for tendermint socket protocol and uh it allows uh you as a blockchain
application developer to to uh focus on the business logic uh only on the business logic not on the consensus sort of networking and you can write your program in any language and the way we do this is um is it's very different than say the way an ethereum uh solidity contract smart contract works right so in ethereum uh what you have is a a virtual machine um that runs on the blockchain um the ethereum is a is a monolithic um stack that has a tur complete virtual machine and uh the virtual machine uh handles uh uh op code counting so it it can handle um the the fairness of uh of resources
usage like CPU memory and storage um but another way to do that is to just isolate an entire process the whole process uh by process I mean like a Linux process um a process that handles um the the processing of logic of transactions or the business logic uh 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 um um create uh isolate a process completely uh so that you can run any process on it um we don't need to do ethereum style like op code counting because uh the uh Linux container
technology can just uh make sure that each container each process gets a fair amount of resource usage and we can limit the amount of memory used in each one so uh so application statewise um 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 lar Ledger CEO and he filled me in on some of the new products they've recently released on our website leder wallet.com you will find all range of products the new NFC based Hardware wallet the unplugged and of course the Ledger Nano that you all know which also
exist by the way on a cool bracelet where so you can have it with you all the time there is The Ledger hw1 for Enterprise 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 Ledger wal.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 let's let's get into this theme and get a deep understanding of um how tender differs from etherum now um like in in tender uh kind of one of the in in your blogs you write that um with tender developers could deploy smart contracts in any could write smart contracts in any language they could they want to like C C++ whereas in ethereum um they have languages such as solidity and llll 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 bite code now
so the questions become um why would first for the first question is why would a developer want to write smart contraction C or C++ what's the advantage for it and and the second question which is perhaps less important at this point is how do you do it so uh the advantage is familiarity and the tool set solidity is a brand new language it's a 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 um which you know certain people have trouble with we've we've struggled with it at at AIS 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 much more lowlevel 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 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 um in whatever language you want and write your own you
know 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 power ful software today working for you while you build your app um and then once you're ready then you can link it up to the blockchain um over a tmsp connection very simply just by implementing a simple interface which allows the blockchain to pass connection pass transactions to your app and allows your app to return hashes back to the blockchain and with this this very simple back and forth like this you can have arbitrary applications written in whatever language you want um and 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 over tmsp and on the tender core instead of on um ethereum and ultimately you know that's the kind of thing that that AIS will be doing sort of in the short term is uh taking what was Curr ly all in process like ssdb ais's blockchain is all in process with with tendermint right and so it sort of confines you to using the particulars of the era 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 it's all about giving flexibility to the developers and sort of uh taking a step back I mean blockchains when 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 that people really took it as like this this really unique brand new thing and what's H and you know ethereum sort of built on top of that and added this this generalizability layer but now what
we're doing is going back to the lower level components and sort of breaking 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 uh Network systems the differences are you know we want Bustin 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 per Network and you take those those four things together that's really what blockchains are and sort of teasing it apart gives you a a 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 the tenament application platform and the tmsp really get at the heart uh of those questions and sort of make it easier to understand blockchains I one thing you touched on there is something we've talked about in 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 it's like you know all the code is all uh is all munched together and you don't have clear separation between the different components which you know like you mentioned 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 um you know companies like Google Amazon and all Enterprise companies write code like this so it would be interesting to you know if if if Bitcoin had been written like that to begin with if we'd have something completely different today what that would look like um but I want to come back to the to uh to TP uh sorry tmsp um how so I'm trying to get a better idea of what this really looks like so you have the consensus um mechanism running on different nodes and then you have your application talking to the consensus mechanism through this socket protocol
uh does your application say it's written in C++ with your business logic with your smart contracts Etc uh talking to the to the consensus protocol uh through the socket is that logic on every one of the nodes or is that so is that running on a centralized server can you walk us through a bit more like how this actually look what this actually looks like sure um I I'll take this one um it's it's the first option that you you mentioned so uh at tendermint core the blockchain consensus engine speaks to the application uh via tmsp but this network uh socket connection is not exposed to the internet um those two processes that are connected by tmsp uh
runs uh in a in a secure container uh well two separate containers but they are uh they only speak to each other uh except the core which is also exposed to the greater internet so those two pieces uh uh run on each machine um and uh the app only speaks to the core their respective cores while the cores tenament cores speak to each other as well as the app um and uh when there's a transaction uh or when there's a block being committed uh each each core will uh will speak to its uh application which is kind of like a black box um that only that that it owns um and uh it'll it'll run the transactions and and
get a hash back U but otherwise the application is meant to be isolated from the rest of the world okay so the the smart contract logic then exists on every one of the machines that is a node uh simply the smart contract logic is in one container the consensus layer is in another container and they talk to each other uh through the uh the socer protocol yes one of the big advantages uh is we believe there's going to be a a whole new sort of um EP of multi blockchain design so um with this container architecture um 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 be built but uh pretty soon uh 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 and the ethereum virtual machine particularly because it is the one that that tendermint uses you mentioned in one of your blog post that the ethereum VM is one of the uh the potentially many supported virtual machines um I if so I guess two questions so the first is if you can write your business logic in your own U you know preferred language having access to libraries you already are used to testing libraries Etc uh if you have that then why on Earth would you want to
run a virtual machine and secondly um if this isn't the only one which others which other virtual machines could we potentially see being compatible with tendermint and are there advantages or would some of be better for certain things or whatnot sure um there's two advantages to uh having a blockchain with its own virtual uh machine and these are very good reasons for ethereum to exist um one is that you might want to allow arbitrary uh logic to be uploaded by users to the blockchain um maybe you don't trust um their code um you don't know how long their code is going to run
you certainly don't want that smart contract to to uh loop forever and waste resources for example um and so by having a virtual machine you can have a a simple environment where uh anybody can upload their smart contracts of course you can also do this with Docker it's just that um you can do this with Linux containers but it's not as lightweight with Linux containers um it's it's if you're going to have a lot many many um of these smart contracts especially things that are one-offs then you'll want something like the evm uh the other reason is because uh solidity uh well the evm is a deterministic virtual machine so when you program in C
C++ Java you know goang uh not everything is necessarily deterministic for example when you uh iterate over uh a key value map in golang um by default um the language will will randomize the order of the keys for you but the the central tenant of blockchains is that everything needs to be deterministic because that determinism is what allows all the nodes to know that everybody's in the same state right so when you're writing an application uh on tender using tmsp you have to be cognizant of that um of course we'll be developed Ving tools to make this easier for you um but uh it's something that people can already do because and we know this
because uh that's what blockchain developers already doing um we know that game developers do this uh to create lock step multiplayer games um so it's not impossible it just requires uh thinking and so it's a it's a different kind of trade-off between having to uh learn solidity and programming that be U so semi locked into that kind of environment versus having to um program in a slightly different parad but using the same tools that you're familiar with and there there's a few additional things um one of which is is compatibility with ethereum maybe that's a goal of your blockchain design for you know 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 is uh it comes with a bunch of features that are still being fleshed out some of them are pretty solid things like um encoding form ATS for arguments things like how uh 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 of one of your contracts ethereum sort of deals with that for you under the hood whereas if you're implementing from scratch in 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 um
so uh 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 prepackaged like the ethereum virtual machine is and uh works right out of the box like uh 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 like more like English and can guarantee invariance of the code so for example you can you can guarantee that someone balance someone's balance is never going to be negative or something like this right um and having to have the expertise to implement that
yourself in your own language can be you know more than most developers are willing to bargain for and there are only so many languages um that actually do that already so again ethereum the evm 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 could even use ethereum 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 one of our goals has um shifted in the early days Jay was very focused on consensus and and building um um a better faster
uh cheaper Bitcoin uh 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 um as well as giving as much freedom and uh Choice uh to the developers just you know what we're really trying to do is lower the bar for blockchain development um when you're talking about um you know all this low-level Plumbing uh that's involved with doing something like forking ethereum there's probably like a 100 people on the planet that know how to do this uh this kind of work and there's no reason yeah e happen to be two of them uh but uh um there's no there's no reason that every single application
developer needs to do this in the same way that if you're like um an iOS application developer or you're building an iPhone app there's no reason that you would need to recreate the um operating system um and so where we reside on the stack is very low um and uh what we try to do is just make that as accessible to application developers as possible and to uh make it as powerful as possible as well you mentioned something that just want just want to be clear I understand this so you mentioned that ethereum could be a means to communicate with some public block with the with the outside world with some public blockchain like ethereum or 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 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 but so but you could also I mean if you wanted your application to also talk to say the Bitcoin blockchain uh you could use a Bitcoin Library within your application that you write in your language and then talks to the cons mechanism with absolutely and you can do that you know in own language and ethereum has even done it in serpent they've built uh like a 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 not sure how much gas it costs to to run anything there but uh they've done it so it's a very powerful uh it's a very powerful engine and development environment but it does have its quirks and you know there's there reasons to use it and reasons not depending on your circumstance so so um okay let's let's go into an example to to just kind of flesh out this uh this discussion so like in Switzerland the the two big banks that people use are like CR s and UBS and let's let's imagine a scenario where c s and UBS together want to build a
blockchain and for for like for for ease of assumption let also think they don't want to maintain the infrastructure uh so we have two scenarios in and two banks are there in both scenarios and they want to build a blockchain in both in scenario one what they want is um any customer of UBS should be able to write any smart contract and deploy it to to the joint blockchain and the blockchain will run it so for instance if there was a way by which uh somebody could could write uh I don't know a smart contract that allowed me to track the value of an Apple share by holding Swiss Franks 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 oppos the other one where uh the banks want to restrict the functionality of the blockchain to only a few elements like the elements might be okay the customer can uh can send money to another customer on the blockchain the customer can exchange the UBS swis Frank for credit Swiss frank the customer can deposit thiss Frank to get interest and let's say there are only five or six defined functions so in one case you have you want to build a blockchain where you want that to be very open like a like a Swiss army knife can 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 um 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 is would that be a good way to look at it that's uh that's sort of it so uh I want to clarify that um the the platform that we're building out um is not uh restricted in the sense that uh
if you build on our platform then uh the business logic that you can write is is necessarily uh limited okay so what I mean is you can actually launch multiple parallel blockchains um and have uh isolated uh functions that are each their own blockchain so if that fits within your model uh you know let's say you're a bank you might have um you know you have like Forex you have uh syndicated loans um all these Capital markets uh functions you might need 100 blockchains to manage all of that but you probably want to have each blockchain be uh you know the the code be very specialized in each regard um
rather than having uh one General blockchain that anybody can upload arbitrary code to because that's you know from A bank's perspective impossible to audit right there's no way you can audit arbitrary code you'd have to limit the functionality anyways um so it's it's it's not like a Swiss army knife versus restricted it's more like uh Swiss army knife versus uh a more it's a different kind of swis armi knife it's one okay so where ethereum knife versus a toolbox versus a toolbx there you go yeah yeah um I mean our platform is still turning Complete because we're using Linux containers it's just not kind right um so here's a 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 uh completely different oneoff smart contract then it doesn't make sense to use put all of those in in in Docker containers today because uh each one of those will be their own process and you don't want to be running like a billion processes right um so for that case you you might want ethereum but for most use cases that's not going to be the case so uh you might want to use tmsp um you can also have a blockchain that uh is for the most part uh restricted like you said like it's a blockchain that does very specialized things but occasionally invokes the evm ethereum
virtual machine uh in cases where uh you need to invoke arbitrary contracts you might get something like that when um you have something like a a payment Channel system where to close out the payment Channel you can you know you have a variety of options for uh dealing with uh conflicts uh you might want to ask an oracle or or do something or you might want to uh run an arbitrary contract and U 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 into evm but only invoke it when necessary so uh it's so it's very complicated yeah you know the from a from a high level censorship resistance
is very expensive we saw that with Bitcoin and you know that's sort of uh people become to realize as they've been moving more and more towards blockchains and uh but um that's true of ethereum as well and so when you have a virtual machine that anyone can upload code to the the underlying infrastructure required to support that um inherently I think inherently means that um you can build systems like if that's not an assumption which isn't for most permissioned use cases that you need censorship resistance um it logically makes sense that um you could build a system that is more efficient and that's what tender's trying to do now there's a quote I I read it was one of Tim Swanson's I'm not sure it was him or Robert Sams or somebody but it was essentially that uh
censorship resistant use cases will gravitate towards censorship resistant systems and non- censorship resistant use cases will gravitate towards non- censorship resistant systems and um so I think that's a that's a big part of the market that we're going to going after and trying to cater towards so you know yes we we we are restricted in the fact that yes you can't just upload any arbitrary code uh but in in other ways that really opens the up to being able to be much more flexible okay so um yeah that that clarifies the situation um yeah in my mind in my mind I I see it like um with if you have something like ethereum like like an evm and a couple of banks uh 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 then that gives them a hard time with The Regulators so they might they might not want to open up the general functionality and the this thing is if you want to open up such General functionality it costs a lot in terms of resources like you need a specialized evm that needs to count cycles that needs there's a lot of administrative overhead for for actually building such a general blockchain so for a bank that wants a blockchain in which it can do few things and keep adding on those things as they want to but not necessarily allowing the people to uh
put smart contracts of their choosing into it they can use uh like your architecture to do that and your architecture will be more efficient because it can be designed like purpose built for exactly their applic their set of applications right yes okay and uh and it's not it's not even that the uh the blockchain is immutable if you want um just like you can choose to run the ethereum virtual machine and make it permissionless and censorship resist um you can also uh upload a new kind of application you can have nested Docker containers so you can have an application um running on tmsp uh where if you want to extend it you you submit a transaction that has uh
a code that gets compiled and and and spawns a new sub doer container um and you can manage uh uh well sub ation maybe there maybe at that point they should be called smart contracts um there's a lot of ways to do it you can have um different configurations like that uh to handle uh upgradeability uh 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 want your evm to be upgradeable and your purpose built contracts to be
upgradeable and possibly to have multiple versions running at once and so on we could build a tmsp app and and probably will that is basically a Docker orchestration app so that people can send transactions that bring up new Docker containers uh and use that to manage you know 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 you know to write a contract in hasal or whatever language of choice um then we can support that too so at the end of the day it's it's the the flexibility is enormous here and it's really up to the particular use cases of what they want yeah that's that seems very clear and awesome I mean that's that's certainly I think the most unique
approach I've I've seen in this space until now and it it wasn't so clear from the blog but now from from this conversation it's it really is so I mean um we should move on to the the second interesting talk topic of uh of of of our podcast and uh because J has worked so much on consensus um and he he wanted to initially build a better consensus uh system for uh for cryptocurrencies perhaps we should go into what what is special about tender Min consensus and how it works so Jay could you give an could you give an a short intro of how consensus intendment Works uh sure I'll try I just want to mention it's not it's
not just me uh Ethan has done tremendous work in uh in uh verifying the algorithm and also refactoring it um reimplementing it to be uh much more modular understandable deterministic um but uh I can give a start and maybe Ethan can jump in too so so in your consensus algorithm you have U it's a round based algorithm right where you have like lots of validator nodes and uh they communicate with each other to build blocks so so how does it work and how is it different from Bitcoin okay sure um a high level review um it we don't use electricity like we mentioned um it's not about how much cost went
into producing this blockchain um that's not how people come to agreement rather uh there's a set number of uh voters who uh uh should in an ideal scenario all be online um dedicated to committing blocks together and uh high level is that um you know let's say there's a 100 of these validator uh they all have a public private key pair and uh you need a quorum a set at least 2third of them to sign a block uh for it to be committed um so it's a round based uh protocol and what we mean is that um every round um uh so let's say we have a blockchain um and we need to decide on
the next block um there's going to be a a designated proposer uh based on the uh the past history on the blockchain uh there's a uh proposer who is decided unanimously decided to be the next proposer for the next round and we start at Round uh zero or round one um so the first first round uh there's a proposer who proposes a block that block gets gossiped to everyone and then there are uh two more uh phases the first phase was proposal the second phase is uh prevote U that's what we call it it's a it's a vote signing phase and the third phase is another vote signing phase that we call pre-commit so uh by the way
block is just a list of transactions um and uh right so let's get into it um after the block is proposed um the next step is prevote uh where all the validators check to see if the transactions are valid um they run the transactions um and see if the if the good to them and then uh the if 2third or more of uh of prev votes are seen by a validator in the third step uh in the pre-commit step they uh if they see two-thirds or more of pre votes they go ahead and pre-commit it uh they sign vote that says uh this is a pre-commit vote and yes I saw two-thirds or more of prev votes for this block and
uh and uh and they sign it and if two-thirds pre-commit it um then the block is committed so ideally uh the whole process happens uh in one round um most of the time that's what will happen but when there's latency in the network um or when the proposer is offline or when the proposer proposes an invalid block then uh it's possible to have to go on to the next round where um the next um designated proposer is chosen it's predetermined actually it's not chosen um but rather um the next proposer in line proposes a block and we do this thing again um there's more detail involved with uh with locking and timeouts that uh it's very difficult to
get into uh in a podcast um if you want to learn more then I suggest uh uh going to the GitHub Wiki um for tender where we have a specification of uh the consensus algorithm um so uh there today's magic word is Socket s o CK head over to Let's stock bitcoin.com to sign in enter the magic word and claim your part of the listener [Music] reward so with Bitcoin we have proof of work where essentially you put up uh electricity and computing power in order
to um to to mine a block and based on the amount of computing power you have you have a probability uh your your your odds of winning uh the the block will will be proportionate to your amount of electricity uh I don't think I need to get into uh your amount of computing power I don't think I need to get into how proof of work Works uh but with proof of stake it's it's different so you have something to lose and that is that you putting up a deposit um can you explain how how that's fundamentally different from Bitcoin uh in um in tender or perhaps even other uh proof of stake systems how how is tenament different from those well from from a
high level remember that we don't have this assumption that you need censorship resistance and um that's why you have all this complexity around um proof of work or you Nakamoto consensus it's actually a pretty pretty clever solution uh under the assumption that you know anyone can submit a transaction anybody can validate a transaction um one of the one of the problems uh kind of derailing just for a quick uh is uh that the financial institutions face is this thing called ofac office of foreign asset control um it's actually a subset of the Department of Defense and so and what that what ofac does is it says Hey certain countries um certain companies certain people you can't deal with and um and if you do uh 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 uh someone processes a transaction in North Korea did I just violate ofac um and so um you know censorship resistance is not only um uh is an actual problem for many of the financial institutions who very much like to know who their counterparties are um and so if we're operating in this world where uh we want to know who our counterparties are um what it's pretty simple that like um you can just leverage the existing uh legal system um and so just the way that like um financial institutions or Enterprise clients will hire um software manufacturers to perform certain duties
with them and they have legal contracts um and if you break those contracts then there can be ramifications um so now we also have baked in this monetary guarantee uh that is a little bit uh more fundamental to our system that doesn't require it can but doesn't necessarily have to require um the outside uh legal system so and essentially what happens is if you don't act appropriately then you get punished uh to to be a valid in the system you need to put you you can require um validators to put up a bond uh and uh if you don't validate properly then you lose that Bond and so we kind of Envision this world where um 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 a Bonds in the same way money transmitters have to put up City bonds um but a lot of this is sort of unclear right now where the the where the world will will evolve to um we're pretty flexible in regards to you know how we kind of fit into that future landscape so um I just want to add that's uh very good point um Bitcoin you know censorship resistant because uh it's Anonymous but uh it comes with uh 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 um okay but when you have validators who are public and uh or pseudonymous even but if you know who your validators are um and uh if in order to attack the blockchain uh you require a significant proportion to collude and when that happens you can figure out who did it so it's accountable uh those three combinations the knowing who the validators are even sud sudon imity um requiring a significant fraction to attack the network which is provided by the bft algorithm uh along with uh being able to know who uh caused the attack um those three properties together is what
makes proof of stake secure so that's um the way it's different um and uh I would say that high level overview of the security characteristics like uh Bitcoin requires continuous burn of electricity to uh to ensure um security whereas in proof of stake uh in the condom model that we just talked about um it don't require a constant burn you can you can come to complete agreement a final commit of a block and it's little less under a second you know it's really just about two rounds of communications among validators and you can have final commits without having to wait and that's because uh the the security doesn't come from burning but it comes from uh
collateral so the in essence to come back on what um Dustin was saying you could have a tender blockchain where there is no coll there is no collateral to put forth simply all of the nodes are taking turns validating blocks um is that right like you could 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 uh branches of the same bank and then moving towards um less less trust between actors so perhaps like two different banks working
together and then the fully uh untrusted uh permissionless e permissionless which is like Bitcoin basically um where does tender best suit like what for what use cases is is tender best suited and in what where on that Spectrum does this Pro proof of stake algorithm um ex Excel yes um I would say that uh it's the first two that you mentioned that we're specializing for today so uh for uh banks that are identified and trusted um they can have collateral that is held
off the chain um it could be maybe even just reputation based perhaps if you're talking about the Federal Reserve or something or consorti consortiums where uh uh uh members post collateral on the blockchain or possibly on another blockchain or or they it might be off the blockchain with legal contracts with uh distributed or centralized depositories right that's what we're building for today because that's what business wants and that's uh those are the business cases that exist today that said uh we can also uh tenit the the consensus algorithm can also work for the latter case that you mentioned that's more permissionless um
it's just that uh we're not building our own public blockchain today yeah the pain point is definitely currently is in areas that um where there's high stakes of financial institutions and and where there's limited trust also happens to be quite frequently financial institutions um particularly those looking to create consortiums uh so you know obviously the the idea there is just cutting out the middleman so all these Banks can can work and interop work together directly um but but uh it's quite interesting we thought a lot about the the reasons behind uh permission blockchains and we knew quite early that there would there was an opportunity to support permission blockchain developers however we really dug into the like the why the okay yeah
you can you want to build a permission blockchain app and we can help you but why do you want to build one and that was a that was a deep deep rabbit hole that uh that and one of the things that came out of it was that you know even um even a single organization can benefit from uh a permission blockchain um particularly large organizations uh where you have uh regions or departments that don't fully trust each other um and with their data and remember in this new world data uh data equals assets so you know for to kind of you know Bitcoin is a digital Bearer asset like cash um you know you hold the Bitcoin the private Keys you own the money some I hold the $20 bill I have access to that money it's not an IOU um and so right now
what we'll I think we'll see movement towards is more and more digital Bearer assets Chain's doing some great work in this department um and um and then once we have this world where uh you know data equals assets then trust uh becomes infinitely more important um or actually the lack of trust even within these organizations U because they don't want to won't necessarily want to trust uh their assets to other departments or other regions and so um you know that's how I think it'll kind of evolve into the the non-financial space and and really it's blockchains are essentially uh very high performing databases uh they're not and so there's a lot of uh interesting uh use cases that are going to uh come out of it so um I think the
business models and the use cases are the are topic we want to handle next but just before we jump to that theme uh I Le I'd like Ethan or J to chime in and give an example of how fast and how scalable these blockchains are like like what are the performance characteristics can we illustrate to an example so in in tender we we've been benchmarking um pieces of the stack recently uh and the the main figure we're throwing around is that we can crunch 10,000 empty like nonprocessed transactions per second so um 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 um and we can get around 10,000 per second and this is before we do um any optimizations including some very lwh hanging ones that that we already know about um so we expect that with those optimizations we could get that number up to you know 30 40 maybe 50,000 maybe even higher um and then and go from there so B the the sort of Benchmark for or like the lowest level for hitting you know practical Byzantine fault to systems I think people usually put at around at least a few thousand transa transactions per second maybe 10,000 uh and we're we're hitting that
easily so the in terms of uh throughput of transactions uh the the bottleneck will probably be on the application side so depending on the you know we can't just answer that question because uh it really depends on the application what the logic is how many users there are uh for example if you have um uh a uh merized you know binary search tree that's self-balancing or Patricia tree and you have uh a billion accounts or a million accounts or a billion accounts then there's going to be overhead especially when that tree is uh accessing dis for every uh for every uh you know update or read right but um 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 um and optimize the logic so that it doesn't use an advanced Merkle tree but still with merization um and you can you know get up to like 50,000 transactions per second on commodity machine uh it really depends on how you code the application and what the use cases are and how many how much data there is in it and what your persistence model is so moving on to uh use cases and this is something that I mean I I constantly think of and you know we we all I guess
constantly think of is like where is this going where where 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 um you know obviously we talk about the financial sector a lot obviously we talked about um coding business logic into into a decentralized system we talk about Fidelity points we talk about iot but all these examples are have 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 clearly show this works and we've saved so much money or we saved so much time um I'd like to ask you perhaps all three of you uh 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 a clear uh paino that blockchains 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 um there's a company that we're working with we call them Block Street companies like blockchain Wall Street and so um it's a block block street startup that um um what they do is uh in the by the way yeah you likes wall chain uh so what what this uh the
startup does is um um they're in the foreign exchange space so imagine you have two Banks called uh Barkley and UBS and they engage in a foreign exchange swap uh the US dollar and the Yuan um so right now they record all that on their own independent uh databases and so what they're using is they're using the blockchain as a triple entry accounting so now in addition to recording uh this trade uh in their own databases there will be uh an additional uh entry into a blockchain database that says you know how much was transacted the date the time the strike price Etc and they both cryptographically sign it and then if there's ever dispute after the fact they
can look at this you know perfectly auditable uh Ledger and determine you know sort of fix 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 uh the pro you just you're adding on to the current system uh the I think the the next wave what we'll see are then moving towards uh the like the aforementioned digital Bearer assets now those are interesting because um you hear a lot of talk about uh reducing time to clearing and settlement um and so what first like what is clearing and settlement um when if I want to send um Sebastian if I want to send if we want to trade a stock um right now what basically happens is I
send you a message and says like hey I want to buy uh the stock from you and then you say sure okay and then we engage in the clearing and settling process um and we're you know moving assets from my bank to your Clearing House your bank it's it's a and that's it takes a few days to uh to complete that but if you in the world where you have a digital Bearer asset and so um and I have some sort of token of value whether it's a Bitcoin or um you know clear madx guys and there's a few other talking about settl coin which is basically just like loading some value into the system then we can just like automically swap your digital bear asset that's your stock with with my value token of whatever kind and boom we just traded and there there is no clearing
and settlement because it just it just atomically swaps these um these assets so um I think those 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 a like all these systems are it's it's a hornets nest into this stuff and you have to not only the the swap itself but all the reporting mechanisms that go into it and so and and it's so I think it will come it just will take longer and then the third phase is getting more into the the database plays with kind of just the broader um 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 um I mean blockchains are really I almost want to
stop using the word blockchain because it's so it means so 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 um it's like not possible but anyways like blockchains are what bit Bitcoin introduced two things one was this 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 Network networking right um 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 of seeing where Bitcoin can take us and they're starting to try and step backwards and and deconstruct the the Bitcoin stack and and put it back into context we realize that you know this this combination of 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 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 uh nowadays A lot of people are are switching to Raft which is a new consensus system that came out a couple years ago which is much easier to implement than paos and a lot easier to understand so and there's there's a huge Community around rap people are very excited about it and about using it uh and we're seeing all kinds of new applications built on top and you know everyone is starting to use raft as sort of their 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 with with things like tendermint and and other blockchains which are just combining
pbfs 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 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 Bus in 08 and all the 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 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 this natural transition in 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 tender and all the 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 um having sort of you know better functioning Democratic systems uh 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 the reason democracy I mean democracy doesn't work as it's been implemented now we all know but you know theoretical democracy um 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 in consensus technology is moving in the same direction from you know this the monolithic everything on one machine towards these non-byzantine fault tolerant trusted consensus algorithms towards real Byzantine fault tolerant ones with cryptographic audit trails and I can just see you know everything being repositioned on top of that by virtue of the fact that almost everything needs to be replicated across uh multiple machines and uh especially the thing that that gets me really excited you know is the when we talk about I mentioned in my introduction um self or self- emergence and self-organization in physical systems that's what let me led me to Bitcoin in the first place because it's like the self-organizing you know
internet system uh what really gets me excited is about the applicability of this kind of stuff to government or as we call it now government right um and and the way that the transparency and auditability and participation and feedback loops are going to be so much better um so much more fluid and so much more functional in systems running on top of on top of uh Byzantine fault tolerant you know cryptographically auditable consensus networks and and that and that's the kind of thing that you know that that I get out of bed in the morning and I'm just you know excited to overthrow the government and replace it with a government uh yeah well you tell us tell us a bit
more about this about this project uh sure so yeah so along along that route we've started building a tmsp app that we're calling government um you know mint and it's it's a very very simp what we're trying to do is establish the the absolute most basic pieces we need for a a self upgradable governance policy over the Internet um so you know the way the way it starts now is it's just a it's just an application for proposing things and voting on those proposals um and the the proposals can be you know arbitrary proposals that the protocol knows nothing about and you know have everything to do with uh you
know things happening offline or and some of them can be related to the protocol itself um so maybe you have a proposal that you want to you want to upgrade the app right maybe there's some new feature you want uh instead of coding it in from 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 you know in many different directions and and end up with um you know government applications that are sort of suited for them rather than upfront 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 you know to their own their own needs and and voting voter preferences over time and we're hoping
to use that um to actually manage live blockchains and validator sets so for example something like validator set changes we could use this this so-called board you know it's like 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 this sort of you know self- emergent governance model uh starting with very basic building blocks and and I I think there's a a lot of potential for that kind of approach and we're going to see more and more of that uh moving forward one one area we're
moving towards is what kind of um I know we're kind of short on time here so one just one point to get in before we go is uh the the high level business model is that we're giving away uh free tools resources um to to build blockchains uh and then the business model comes in in terms of uh having uh creating um proprietary tools for deploying and monitoring uh blockchains now some of those will open source as well but um that's uh there's a there's a big market in terms of um a lot of problems to be solved that um people haven't even really begun thinking through in terms of the deployment and management of blockchains and uh you know we have a we have a pretty already in our Short
History have uh shown a great uh uh track record for solving big problems in the industry whether it's through consensus itself um through um the refactoring with tmsp um through now um with the deployment uh with minnet and uh there's lots of other really intriguing things that we're going to be uh launching and announcing here in the coming uh months so stay tuned cool uh well I I'm really looking forward to this uh government uh uh idea and you know maybe this could be a topic for an entire other episode because I think there's quite a bit to talk about there um and uh you mentioned earlier that you guys were uh raising funds you want to
mention that yes yep yep we uh we've been very much in the code don't talk uh kind of phase of existence here and so we've had our heads down uh working uh uh for the last uh since well I guess J's been working on this for a year and a half quite heavily uh 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 uh and part of that also is kicking off our fund raise and so we are doing a uh a preed round right now and uh so far the uh uh the reception on all fronts has been quite strong both from you know developers to investors to um Enterprise clients um so it's uh I think 2 2016 is going to be a
good year for tenderman I'm sure it will be and uh I'm definitely looking forward to diving in deeper and perhaps even working with you guys CU um because we we have been looking at tender at stratum as as one of the one of our sort of private blockchain solutions that we want to implement so uh we'll be looking we'll be looking closely at tender um well thanks a lot guys for joining us today it was a really fascinating discussion about some really fascinating technology um and uh yeah we'll have to dive in deeper I think into this government idea at some at some point so thank you for joining us and uh episode of Bitcoin is part of the LTB Network you can go to letop bitcoin.com to find a whole bunch of shows about Bitcoin
blockchain Technologies cryptocurrencies a whole 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 uh but usually it's Mondays and you can subscribe to episer Bitcoins on iTunes SoundCloud um or wherever you get your podcast could be on a on a podcast or app on Android or iTunes and you can also get the videos on YouTube at youtube.com / 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 reviews I'm not really sure um where else but anyway Stitcher or some other platform and if you do so send us an email at show bitcoin.com and we will send you a T-shirt and some stickers and many
thanks uh so of course you can ALS leave us a tip and the uh tipping address will be in the show description so thank you so much and we look forward to being back next week n [Music] [Music]