Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Dan O’Prey & Daniel Feichtinger: Hyperledger Decentralized Ledger Platform

Episode Date: April 6, 2015

The cryptocurrency ecosystem is increasingly divided into different camps. There are those betting and working on the eventual mainstream success of Bitcoin. And there are those who take elements of Bitcoin’s technology and repurpose them to improve existing systems. Hyperledger is one of the projects firmly in the latter camp. They are envisioning a world where innumerable interoperable ledgers are operated by different parties. Hyperledger is their tool for the creation and management of these ledgers. CEO Dan O’Prey and CTO joined us for a discussion of the project, underlying technology and their view of where the cryptocurrency ecosystem is going. Topics covered in this episode: Why Hyperledger is trying so solve a fundamentally different problem than Bitcoin How networks consisting of known parties can have massive performance and scalability advantages over anonymous networks Why Hyperledger doesn’t have or need its own currency How Hyperledger can vary the degree of decentralization and security depending on use-case Practical Byzantine Fault Tolerance (PBFT) Episode links: Hyperledger Meher Roy’s Internet of Money Whitepaper Practical Bynzantine Fault Tolerance This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/073

This episode of Epicenter Bitcoin is brought to you by Shapeshift.I.O. With no account or sign up required, it's the easiest way to buy and sell light coin, doge coin, dark coin, and other leading cryptocurrencies. Go to shapeshift.io to instantly convert all coins and to discover the future of cryptocurrency exchanges. Hello, 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 Kutuya.

And my name is Brian Fabian Crane. We're here today with Dan O'Pray and Daniel Feichtinger. They are the CEO and CEO of a project called Hyperledger. Now HyperLedger has been sort of on our radar for a while. Tim Swanson was telling us a while ago to do an episode on that. And our interest was sort of renewed in that recently when we heard an excellent episode on Beyond Bitcoin about the Internet of Money with Tim Swanson.

and Meher Roy. So we're really excited to talk about this today. I think it's an interesting project. So Dan and Daniel, thanks for joining us today. Thanks, yeah. Thanks very much for having us. Good to be here. So to get started, can you just tell us briefly what is HyperLedger trying to accomplish? Okay, generally I would say that we're not, you know, often as a starting point, people assume that we're trying to be a Bitcoin competitor or a counterparty competitor. And I would say that we don't really generally view ourselves as being a direct competitor. We're not trying to replace Bitcoin.

It's more for different scenarios. So we're particularly looking at financial services and more private deployments where there are already groups of institutions or companies who need to have a shared data layer that need to have it more private from the public. So I hope I'm just designed to be very, very modular. It's just a straightforward consensus system where everyone, A set known of parties can participate in a consensus process and all have access to the same universal record of truth without that being more generally public to the public. Well, it strikes me interesting about this project. It's trying to accomplish one very basic thing.

The feature set is quite simple. I've been playing around with it quite a bit in the command line and everything. Actually, like even going through the source code and I was just surprised how little features there are. just does one thing and does it really well, right? Yep, that was absolutely our goal in building this, was exactly that approach. We feel some other projects kind of take on, they're very complex, very involved, very interesting, but we really wanted to, and we do want to tackle

kind of different parts of the stack in the future, but that was very much our approach was, let's just take the ledger layer, the kind of consensus process over the ledger layer and the kind of authentication and signatures, the access control over the accounts, and just really build a neat, robust solution for that before we kind of move on to different points in the stack. Yeah, we want to take a very modular approach. So, yeah, some platforms have a lot of features, and that's fantastic.

But it sort of makes assumptions over how it's going to be used. And if you need to actually, if you want to adopt the system and, and you might have to re-architect a lot of your existing systems and integrate them. So having to replace too much at once can be quite a large barrier of adoption to some entities. So by having a more modular approach, you can fit in. We really just wanted to strip it down just to the shared data layer, fit that in as a module with existing systems,

and then we can work from there to replace other parts. Personally, looking at the different projects that are spreading up, I mean, just generally in the Bitcoin space, I find that the right approach is to have that really modular approach of this does one thing, and then other people will come in and develop other feature sets on top of that or interconnect with other projects. So I mean, I think so far, projects like Counterparty, for instance,

which is nothing, there's nowhere near what you're trying to accomplish, but is one example where having so many features in there makes it complex and difficult to iterate. So, yeah, I mean, I think that's, sort of a good approach at this particular stage in the space where things are being built and we're just kind of really early on building all these modules that will kind of fit in together. I mean, one thing that strikes me about hyperledger and not just hyperledger, but quite a few of the projects that we've been having on and we've been talking about

is that they feel very, very different from the sort of traditional cryptocurrency projects and projects in the space and that they get they get rid of a lot of the ideology a lot of the sort of political ideas behind it that maybe a certain barrier right especially when it comes to getting companies and corporations to adopt that and then sort of say oh let's use some of the innovation here some of these blockchains and decentralized technologies but then let's also throw out other ones, especially the idea that it's controlled by an anonymous network of nodes and sort of pack, you know, take some of it and now create sort of consensus as a service. Now that term has often been used, so it create basically business solutions with that.

Yeah, we see it as a technology. It's not a political movement. Yeah, I'm sympathetic to the views behind Bitcoin, but, yeah, there were a wider use cases. which don't start from those starting assumptions. And the starting assumptions really is quite key, particularly with Bitcoin, where you assume that based on history with hash cash and e-gold, that the government might attempt to take it down, so it needs to be as decentralized as possible.

Therefore, you need to incentivize anonymous miners, and so you need a cryptocurrency built in. And that makes perfect sense when you start from that starting assumption. So, you know, something that people often say is, you know, we love the blockchain, hate Bitcoin, and I know that annoys a lot of people in the space because a token built in is required for a maximally distributed blockchain. But when you're not trying to, you know, don't start without assumption that you need maximum decentralization, then you don't necessarily need a cryptocurrency built in,

and you can have just that, that core technology amongst a known set of people, rather than having to have anonymous miners joining and leaving the pool. Right. So that's also one of the key characteristics of Hyperletionos is that there is no hypercoin, hyper token, nothing like that. Exactly. Just the shared data layer. No built in cryptocurrency, no built in decentralized exchange.

It's purely just the straightforward layer that anyone who wants to have, yeah, just a blockchain as it is, can take and use. So it seems another project that is trying to sort of target the more business use case and financial use case is Ripple. Do you guys think you're trying to accomplish something similar or do you think HyperLedge is a very different project? Ripple are probably the most similar to us in terms of both in terms of the consensus process and the general approach to the space. Yeah, the key differences, obviously, they've got XRP, the cryptocurrency built in as a native asset, and we don't. They are very much focused on the correspondent banking side of things. To do that, they have one big public network which links up all the gateways and institutions to allow exchange between Nostra accounts and international settlement between banks.

We're looking more at this on private side where people don't want that on a big public network. they don't want all their accounts and balances and open positions and trades to be visible. So it is similar, but I would say the focus is very different. It seems besides the issue of compensating anonymous miners and sort of paying for the decentralization in that way, another function of native tokens is paying for transaction fees. And I guess sort of related to that is also the issue of kind of spam protection. to make it actually cost something that seems very sensible.

Is there a role for that in Hyperledger? So by default Hyperledger doesn't have any transfer fees, so if you set up your own pool, you can just transfer freely within that. The notion that the pools will be spammed makes sense when you, again, when you have an open network like Ripple where anyone can join and create an account and create IOUs and do worthless transfers and that, that could be an issue. be an issue. When you are looking more at the private side, if you've got a group of banks or a group of partner companies who are known, either they're spamming each other money, which will be

perfectly acceptable, or there'll be, you know, there isn't really any incentive for them to try and spam. So really, if you, again, it's the starting assumptions, if it's restricted to just known identities and people who are collaborating and already trust themselves in the real world foot to some extent, then the likelihood of spam is a lot less to zero. And I'd say also beyond that, just charging for transactions isn't necessarily the best way to get rid of spam. I know the popular example is around sort of email coin. You know, people get a lot of spam.

If you just charge a little bit per email, then spam will go away. But that's not necessarily true. For example, you know, with sending postage mail, you have to buy a stamp, but you still still send a lot of spam and then also with email newsletters where you need to send out mass emails to charge just a little bit for that can add up to a lot so I don't think just charging is the solution necessarily to spam and there can be more sophisticated technological approaches through software through blacklisting and gray listing and you're barring known spammers I'd say as well one of our differences from Bitcoin is that

that once you kind of, if you give up some of the massive decentralization, the kind of massive anonymity and you get rid of mining and things, you know, you can actually processing a transaction becomes very cheap, very easy to run one of these servers is, it's a pretty lightweight process. In fact, we're hoping that kind of one server could be engaged in multiple of these kind of consensus pools, you know, kind of completely independently at the same time on the same machine. So I'd tell you the other side of our thing is the other side of our vision is that we'd rather get transaction processing and, you know, checking accounts and validation and all that down to be as simple and lightweight as possible. So our threshold for what we can tolerate and what counts as spam on our system should be, you know, relatedly a lot lower.

So that's interesting. So you mentioned that potentially you could have multiple nodes on the same system. Yeah, so the same server could be engaged in, you know, through the use of virtual machines or something could be participating in the consensus process for multiple different pools at the same time. Oh, okay, so for multiple pools of assets. Okay. So just to sort of sum up what you were saying, so the fundamental difference with a system like Bitcoin, for instance, is that your starting assumptions are different. Your starting assumption is that rather than being in a completely in a trustless network, you are in a network of participants which you trust. And so the assumption is that people working together are not going to be spamming each other.

That might work in some cases, but it may not in others. So in some scenario where transaction fees could be desirable, is it possible to implement those, to fight spam, for instance, or to limit the amount of transactions? Yeah, absolutely. It's one of those situations. We've not built it into the protocol, because depending on what assets you're dealing with, it doesn't always make sense to kind of cut it up

and apportion it around to combat spam. But you could certainly build in either some sort of native asset or some sort of a bunch of, different assets which are required in order to make transfers. But again, that's something that we didn't want to build into the protocol because it's so domain specific. It really depends what you want to do. But yeah, that's absolutely something you could do should you want to.

I think one of the interesting things here as well is the kind of vision for the future, because here if we have, you know, because there's the idea, especially for example, connective side chains. And we can talk about these big pictures questions a bit more later. There's the idea that there will be sort of one unitary system where Bitcoin and side chains, etc. are used for all kinds of things, right? For microtransactions to Bitcoin to perhaps shares, etc. Whereas it seems to have hyperledger, you guys see more a world where there are all kinds of

ledgers and all kinds of different consensus networks for a variety of use cases. So it seems like you guys are seeing a world where there will be thousands of different ledgers and consensus systems in the future. Is that correct? I believe so, yeah. I think the idea that everything will share the same blockchain or essentially the same database, whilst it may sort of sound good on the face of it, isn't very practical or even desirable. For example, you know, if you want to have very, very different types of assets, Why do they need to be on the same pool and limited to the same number of transactions and have all the same participants?

And again, also in the case of Bitcoin, I have that all completely public. I think it makes a lot of sense. Obviously for the trustability and auditability of the Bitcoin blockchain, it needs to be public. And that makes sense for sort of the Bitcoin token, where you can hide who the ownership are through multiple accounts. but for institutional usage, you know, it's too easy for, you know, if you're Goldman Sachs, to have Morgan Stanley doing data analysis and finding out which accounts are yours and how much of what assets you own and seeing what trade you're doing. And that's just sort of not acceptable to larger institutions.

So we do see very much a world where there are multiple consensus pools. I still think the Bitcoin blockchain will be, you know, one of them and probably one of the largest. I don't think we're not trying to replace Bitcoin and don't believe it will go away. I just don't think it'll be all-encompassing for every type of value and every type of transaction all across the world, across the board. So yes, definitely there'll be, what we believe, there'll be different consensus pools for different types of assets with different participants. So you can have sort of more of a layered structured approach where it's similar to the current system where you may have an underlying international pool for transfers, but then more local

trading, more local markets and more private pools and dark pools for trading just amongst particular types of participants. Well, so which presents to our next point of interoperability within the space, right? So this is something we've discussed quite a bit on the show and between Brian and I as well. also the idea that we have all these different currencies. And also, so Mayor talks about it with regards to the Internet of Money, his white paper. So this idea of multiple currencies at some point, you know, they have to become interoperable. They have to be able to operate with each other.

How does HyperLedger fit into a world where there are multiple currencies, multiple assets, distributed across multiple countries, perhaps with different regulatory frameworks, etc. How would Hyperledger help in creating or eliminating the gaps between them? Yeah, that's definitely something we're looking at. So as I say, I mean, just internally within Hyperledger, a particular pool can have as many assets as can be supported by the servers. So in that sense, you know, you've kind of an unlimited number of assets that could be recorded in one pool. On beyond that, between multiple hyperledger instances, we're working on some solutions. It becomes a little bit more complicated when your consensus process is kind of operating on two completely disparate networks.

But there are some sort of synchronization things that you can do to ensure that, let's say, like I want to make an exchange. on in one pool, you know, and as long as an exchange on another pool happens or transfer on another pool happens, there are some ways that you can do that. You mentioned having multiple assets in one pool, so does that mean, you know, let's say a bunch of banks or something, they set up one of these pools with these nodes, then they could have any number of assets like traded on that or is it yeah okay yeah you can have as many as you want and in fact our system so we conceptually within the hyperledger model we consider a ledger to record you know all the balances and all the accounts of one particular fungible asset so that's you know

something like a currency is is something that you know can be cut up and moved around quite freely. Where I think we differ from some other projects is that obviously it depends, let's say you're setting up a system which is representing bank liabilities. So, you know, my bank liabilities might have an account at Bank A and I can have account at Bank B, both denominated, say, in euros. But we would rather model those and set those up as two distinct ledgers. There's the one ledger is the liabilities of Bank A and one ledger is the liabilities of Bank B, even though it's the same currency to you, because even though that may trade at, you know, a parity most of the time, there are situations in which, say, a bank has some sort of issue or it's in a different

jurisdiction where, you know, we can see it in the kind of in the Eurozone at the moment where it's happened, where, you know, a Euro in perhaps a Greek or Cypriot bank, may not always be worth the same as a euro than another bank. So our system, in fact, we tend to push the modeling to be, to have quite a lot of ledgers to represent all these different liabilities between these different issuers. So let's say I have some euros on my bank ledger in Germany, and Sebastian has some euros on his and France.

And now he wants to send me euros. And I mean, how do I know if I can trust, those euros on some other ledger that, you know, I have no visibility. And furthermore, how do I, how would I transfer euros from my ledger to his? Because from what I've done playing with the command line tool, just the sort of basic, the alpha version, it didn't appear that there was anoperability between ledgers where I could send assets from one to another. Yeah, in, so in that command line alpha at the moment, there was, there is kind of

it's possible but it's it's not exactly made user-friendly so in that situation I mean again we're getting back to the state where we're kind of attempting to model you know this this stuff has existing setups and existing structures so in this simple example it would probably be that the banks maintain correspondent accounts with each other Nostra and Bostro accounts and in this situation it would kind of go through, it could be a single atomic process, let's say, if it's all running within the same pool, let's say. It could be a single atomic process that I can transfer to the, kind of, to the,

credit the nostro account, well, it depends which way it's going around, but the nostro bank of the receiving end, with then instructions that that nostro bank then credits the recipient at the other end. So that's kind of how money moves around the system at the moment, except that it might take, you know, when it goes to the ACH systems, it can take, you know, anyway from a few hours to three days, depending on which jurisdiction you're in and which sort of clearing ACH you're using. So, yeah, I mean, it's, it's, it's, there are, there are ways that this is set up already. And we're just looking at sort of, maybe, you know, making it very quick and easy to kind of model these existing. So let me be a bit contrarian here and ask. I mean, it seems like what you guys are doing here is you, I mean, it sounds like you're just replicating the existing system, right?

So how is that better? Is it just a more modern implementation of it that's much more efficient? Yeah, as a starting point, we are trying to mimic the existing system as much as possible to make it easier for existing institutions to adopt. and there are, you know, reasons why the existing system is the way it is, other than, you know, long legacy reasons. You know, as your point about transferring euros, a euro has a counterparty, right? You're holding, it isn't just that you have a euro and it's a euro bill sitting in your pocket, that euro's counterparties the European Central Bank,

or if you've deposited in a bank, the counterparty is the bank. So, yeah, there are, you can't just sort of get around this. when you're mapping assets on the ledger to the real world, they have to follow some sort of structure, which makes sense to represent what those assets are and whose liabilities they are to you as well. So, yes, it is very much trying to mimic the current system and improve it and make it more efficient.

That is a starting point. I don't think we're going to see central banks just sort of give up and adopt Bitcoin. And certainly Bitcoin will run, in parallel to these systems, but we are very much trying to improve the current system whilst Bitcoin tries to replace it, shall we say. Yeah, very interesting. I mean, I have to say one of the things I really like about this, that makes a lot of sense

to me, and that's also one of the things I've been sort of struggling with and having doubts regarding Bitcoin, is that with Bitcoin, right, we have this mining, right, and all this expenses to secure the Bitcoin blockchain. and it doesn't, you know, the sort of security provided is the same regardless of, for example, the value of the transaction, right? So I send one euro to Sebastian. That's the same security backing that as if I was sending a hundred million dollars in a Bitcoin transfer, right? And that just seems kind of inefficient to me. I mean, the only world in which I think this would make sense is if you can sort of get absolute security at no cost, right? Because then obviously

you'd want to provide absolute security to everything. But as soon as sort of, you know, more security has more cost. And well, you'd think like, ah, in that world, you'd want to provide less security and have a cheaper system for those things that need let security. Yeah, I think you've hit the nail on the head there with, there is a sliding spectrum between centralization and complete efficiency and lower cost and complete and utter decentralization and being a slower system and more expensive system. So when you've got, you know, if you've got a green grocers trading, you know, loyalty points and you've got Apple issuing shares that those two systems, you know,

those two assets will cost the same underneath and have to go under both under the same trade-offs between efficiency and decentralization. Hyperledge is very much designed to be flexible where a group of shops, say, just in San Francisco, can set up a, starts issuing a loyalty scheme, and that's just operated between themselves, and it's fast and cheap to operate, whereas if you want to have a global securities market in stock exchange, then you want to have much more security over that network. The assets being traded on are so much more valuable. Well, this is all very interesting.

And there's lots more to talk about. Before you do that, I'd like to take a break and talk about our sponsor, Shape, shift. So I challenge you to go out there and try to buy, take some Bitcoin and buy some Jogcoin. And come back to me and tell me how long it took you to do that. It probably takes anywhere between half an hour and an hour if you have to go through in exchange and create an account and get a verified and perhaps even send them some personal information to do that. Well, there's an easier way.

In that way, it's ShapeShift. You go to Shapeshift.io and use their currency conversion tool to convert just about any coin into just about any coin. So you can convert Bitcoin into like coin. You can convert light coin into Dogecoin. You could convert unoptenium into BitShares, for instance. So Shapeshift is the fact. an easy way to buy and sell all coins.

They support about 25 different coins, and they're adding new coins all the time, and you understood the best thing about Shapeshift is that you don't even have to create an account. You don't have to give them any personal information, not even an email address. They just use a very simple currency conversion tool that I'll show you. And it's with no confirmations.

Usually with an exchange, you have to wait for a few confirmations. Shapeshift does it unconfirmed. Exactly. So you go to Shapeshift.i.O. and you use the currency conversion tool, which looks a lot like Google Translate for cryptocurrency, so you have the currency you want to convert. So let's say I want to get some name coin.

So let's say I have Bitcoin and I want to get some name coin. I'll just put my name coin payment address right here. Hit start. I don't have a payment address right now, but I would hit start. That would get a QR code. And with that QR code, I'd send some Bitcoin and I'd get some name coin in what, about 30 seconds, just the time for them to get the transaction and get zero confirmations,

and that's it. So go to shape,shift.io, give it a try. Tell us what you think, if you like it, and we'd like to thank them for the support of Epicenter Bitcoin. So we've talked a little bit about the issue of the question of security and cost and decentralization. How does that work with HyperLedger itself? Is it also the case that as you perhaps scale the network and scale the security requirement, let's say you do that example of a global stock market where you have a lot of requirements and maybe a fairly high degree of decentralization,

does that also, for example, impact performance in a negative way? Yes, yeah, it does. We're working as much as we can to make. mitigate against that too much. But yeah, broadly, the more widely distributed your nodes are, the more of them there are, the more latency that there is between them, that is going to impact how quickly a transaction gets confirmed. Yeah, as I say, there are ways you can mitigate against it, but that's a sort of, that's

a tension which I think will exist in any decentralized or distributed system. So again, that's just another reason why we think that independent deployments of these pools makes a lot more sense because your requirements for kind of throughput may be, you know, at one extreme end, you may need all the machines in the same rack, in the same data center. I mean, they could be technically operated by different service providers, but they need to have the highest level of connectivity between them. And then at the other end, you may get, you know, something looks a little bit more like Bitcoin with a lot of participants and the kind of global distribution.

But yeah, you're going to get a trade off there in terms of performance. So are you saying then that just, are you saying that Bitcoin cannot be performant no matter what? In it's, there are lots of very clever proposals around, I'm not too familiar with all of them, but you know, around channels and I guess the whole side chains thing is another, there's another effort to kind of tackle this kind of problem. But I mean, fundamentally at the core of Bitcoin is, it has to be, each block has to be fairly slow and expensive to create, right? Because that's kind of a security model. If it was quick and cheap, then it would be too easy to attack a particular block. So I think inherently that's, that's, that's, that's, that's, that's, that's, that's, that's, that's, that's, that's, that's, it's a kind of, it's a slow, steady protocol, which just keeps chugging along and doing what it does quite well.

But yeah, they've made the trade off already and it sits at kind of one extreme end of the spectrum. So I presume still in this case it's going to be much, much, much faster. And the performance is going to be much higher, even in a decentralized system where you may have, I don't know, let's say at the extreme case, maybe a thousand different nodes that control the network. Yeah, I mean, I think that's the number of nodes is certainly going to have an impact. Again, it's the problem's kind of slightly limited by the kind of quorum threshold that you need, the number of nodes that need to respond. So the very slowest nodes on the network are not going to impact you too much, which is nice.

But there is still a kind of degradation when you get up to a lot of nodes, as well as a lot of data you need to store for all of the, the signatures that are coming back that are confirming each of these transactions. Now, touching on security, so HyperLedger doesn't use any proof of work or any of these others, sort of more, I guess, traditional consensus algorithms in the space. Can you talk about security and how HyperLedger assets are secured? So in what type of scenarios would there need to be coercion in order to make an attack on the network. So, yeah.

So, yeah, I mean, it's interesting you say the more kind of traditional consensus algorithms, obviously, that the space of crypto consensus algorithms is, what, six years, six years or so old. And obviously, consensus algorithms outside of crypto go back a lot longer. So, yeah, we actually, our initial implementation is built on kind of a, a, core protocol in this field, which is practical by Zantine fault tolerance. The first paper on it, I think, was published in 99 out of MIT by, I think it was Castro and Lyskov, who published the paper. So it's about 16 years old now. I'd consider it

at the root of a kind of family tree of process. which take that as their starting point and make slight modifications to it depending on the, you know, increasing efficiency in particularly high latency networks or, you know, making it more robust in certain failure scenarios. So things like that. So there's a, there's a kind of a broad pool of protocols that we can sort of draw on here. So yeah, I mean, it's quite different from Bitcoin. I mean, Bitcoin came along and and rejected a lot of the assumptions that were going on in consensus systems. And I think there's been quite a lot of academic interest as well in what Bitcoin has changed there.

But from the more traditional consensus system approach, we know that the lower bound on a number of identified, when you've got a consensus system between a number of identified nodes, we know that the upper bound on malicious or, just failed nodes in the system is one-third. So we can tolerate up to, over some given window, we can tolerate up to one-third faulty or malicious nodes. This is with the practical Byzantine fault tolerance.

Yes, yeah, correct. Algorithm, up to one-third. Yeah. So beyond that, the system basically becomes unavailable. And we can detect that it's unavailable, and we can, you know, you can have your alerting or monitoring tools, let people know that the system's not working for them to fix. And beyond that, once you get up over two thirds,

then you've kind of, you know, which maybe say malicious in this case, then there are some attacks that could be done to not include or order in a particular way the transactions, although it will be seen consistently by the rest of the system, it could be kind of, you know, forcing some participants out or into kind of, if they kind of order their transactions in particular ways and maybe particularly unhelpful to them. Having said that there is some work that we haven't included yet, but there is some interesting work on increasing that, I mean, that failure threshold is a third. I mean, that's a known lower bound in these types of systems, a known upper bound, sorry, in these types of systems. no, in upper bound, sorry, in these types of systems. But there is some work that you can kind of then move in,

depending on which operations you're trying to do, there is a certain operations that you can take when the system's under attack or unavailable in some sense. There are still some operations that you can kind of push through, but that's not an optimization that we've made at the moment. So, yeah, I mean, there's still, there's, I mean, there's no double spend at any point, right? the system either confirms a transaction or it's unavailable.

And in the severe case where it's kind of completely controlled by malicious nodes, again, there's kind of no capability of double spend. They're just, all they can do is kind of omit or reorder transactions to be a little bit less convenient. So, yeah, I mean, that's, again, it's a slightly different setup from Bitcoin. But yeah, so what is interesting here. So I organized a big meetup in Berlin and we had a talk a few months ago by a guy named Trent. He does a startup in Berlin called The Scribe and he comes from sort of a machine learning background

I think and he's not, he's, I think he has quite a lot of experience with technology, but not so much. You know, he doesn't come from the cryptocurrency space necessarily. And he gave a talk on sort of coming from consensus systems and databases, because he was familiar with that. And he was like, why is nobody using this? And specifically he was talking about Paxos. He was like, it just like seems it would make so much more sense to me if somebody

built a cryptocurrency based on that. And, you know, that would be so much more efficient, et cetera. And it seems like you guys are exactly doing that. So it's, yeah, I mean, that was kind of one of our, I was really interested. in the kind of cryptocurrency space for a long time. But yeah, one of my issues with it was just the overhead of all the mining and kind of that there were protocols out there which could solve this. Having gone into it, you know, as far as we have done now,

you can understand why Bitcoin makes the trade-offs that it does. It's a really neat system when your starting assumption is that there are a lot of anonymous nodes who are kind of coming in and dropping out. It's a very clever system. and there may be small tweaks and improvements that could be made to that core protocol. But on the whole, it's been remarkably resilient and does what it does very well. But again, as we've always said, if you've got a different set of starting assumptions, then there's a broad range of literature and a lot of academic research,

which has been done on this stuff, to draw upon. You don't have to go back and reinvent this stuff. And you shouldn't, because the minute you try and kind of reinvent the... consensus protocols from scratch without having you know a really good grounding in this stuff you're you're gonna make you're gonna make some errors or you're gonna there'll be some edge cases where it's where it doesn't work so you know practical Byzantine fault tolerance has a nice formal mathematical proof to show that it is correct so you know there aren't too many consensus

protocols which can make that same claim so that's you know that's why we've we've if I come with that is our starting point. Today's magic word is ledger, L-E-D-G-E-R. Go to let's-talkbitcoin.com to sign in, enter the magic word, and claim you're part of the listener award. So coming back to the attack scenario, you know, we're looking at something that's completely different than the Bitcoin network because we have known nodes

rather than unknown nodes. So given that's in a scenario where someone's trying to attack the network, would those nodes be visible? Would we be able to identify the nodes that are trying to attack the network? Yeah, you would. Nodes have to are identified by their public key and they sign any transaction that they're processing according to this protocol. So all of that information is broadcast the other nodes and logged made visible. So there's very little incentive to attack the network. I mean, because first of all, the assumption is that we're in a system where people don't have the incentive to attack the network.

And then on top of that, it would be known that they were attacking the network. Exactly, exactly. So it's fairly, yeah, I mean, there could still be reasons why you'd want to, but it certainly cuts it out to a certain extent. Can you go into some of those reasons? Because it's unclear to me, if you can't double spend. like it sounds clear to me if there are any attack vectors that are actually plausible in a type of scenario like what hyperledger is trying to achieve well again being able to to reject transactions you know if you have full control kind of above two-thirds or something of the network and you can

get to the point where the system can run but you're rejecting operations then it may be that you know you're looking to punish some particular actors in the system so that they just can't use it at all so that I mean the incentives are reduced but I mean there are still a few so it also seems like one thing one could do you know because all the actors the Asians can be known is you could actually have legal contracts that sort of say all certain actions and types of behaviors are illegal yeah absolutely I mean as a fallback you're yeah you've got the technical proof that people can't double spend. But for example, if Brian were sending Sebastian, Brian had 10 units in his account and he was

sending Sebastian 5 and then he was also sending me 10, Daniel could, you know, depends on which one goes through first and which one gets confirmed. If Daniel had over two thirds or Daniel's group had over two thirds of the network, they could reorder that. So your transfer to me went through and then to Sebastian failed. So that's one sort of reordering attack. But yes, you can have terms and conditions since everyone's known and the identity of the nodes are known, you can have conditions to participate in that network and as a fallback, you do have the legal system. There will always be certain degrees of ambiguity over contracts in the world. I think they can't necessarily all be hard-coded and technically solved. So yes, having known identities

means you can take traditional action for breaking terms and conditions and participatory agreement. I mean, we did an episode recently where we talked about your possible attack on Bitcoin. And that's sort of one of the things that personally find kind of a worrying. And that's a possible scenario. Somebody could attack Bitcoin, and it would be perfectly illegal. Like, let's say somebody takes over a majority of the network and mines all empty blocks. That's a sort of a very simple attack we talked about.

It's like, what's illegal about that? nothing, right? Like, it would be, I think, impossible to get any kind of legal, you know, lawsuit against a party like that, even if it, even if that party is known, right? But of course, here it's completely different. If you have a known set of an oath, you have a contract there that very clearly states of rules, and then they violate that, you know, you have that as a basis. So it seems to have a quite an advantage there also from a security perspective. Yeah, I think that, yeah, in Bitcoin, things like fraud and theft will still be covered by, you know, current laws. But, yeah, the example you gave, that's, you know, that there isn't really a current legal paradigm for a legal precedent for something like that.

And it would be very, very difficult to have action. So, so, yes, actually having, you know, identities known. And that's very important to the participants, not just for the legal background. but if they want to know who's processing the transactions and where they are. For example, if you have a Bitcoin mine in North Korea and they're processing transactions and getting minus fees and you're paying those fees, are you then breaking sanctions and then you're breaking the law? But yes, so in actually having those identities and locations known

that does mean there's legal recompense if someone does break those terms. So diving into specific use cases, I'd like to, so we've talked about implementing this at sort of the banking financial sector level. I like to, I always like to have sort of simple examples. Can you perhaps explain the scenario where someone might want to use this for loyalty points? Like, I don't know, maybe there's a local grocery store down the street and they want to implement loyalty points for their customers and use this. system like hyper-legit, how would they do that? Yep, so we're actually talking to companies doing just that in the Bay Area. So they've got a group of small independent shops and chains and even some large

supermarkets who currently issue loyalty schemes. So they're, I mean, I won't go into specifics of their particular solution, but each business can have its own ledger or multiple ledgers. So one, say, could be a USD prepaid ledger, another could be. be, if they're spending to give them free, you know, free sandwich or whatever it may be. And then those businesses can receive the funds, issue onto those ledgers, issue their own those tokens, and also group together that create, you know, interoperability and accessibility that they have one loyalty scheme that can be used across, you know, everyone in Berkeley, for

example. So that would be, you know, an example where you've got a few smaller partners, not all of them necessarily have to run nodes. The attack security required is not as high as it would be with securities. So they can all run their own private pool or have access to that data, but it could be hidden from the public as to which users have what, how much in their accounts, but all the businesses participating in that would be able to see and accept the loyalty programs for themselves and for others that they've agreed to.

So what would the advantage of a system like this be from a centralized system? I guess a centralized system you need to have some party, maybe all these different stores would need to trust one. And here you'd have sort of visibility between them. Yeah, so interesting, they all do currently use a central party. And in the typical Bitcoin world, people sort of think that, you know, we're trying to get rid of central parties. and it would be, so that the group of participants who are getting together to eliminate that central party.

In this circumstance, it's actually the central party who's adopting hyperlegia to sort of disrupt themselves. They see that being a central party means that they have to operate their own database in accounting software, which can be very, very complicated, whereas essentially outsourcing that to a hyperledger pool and getting all the benefits of our development automatically without them having to build their own proprietary system. It also means that it's a lot more open to the ecosystem so people can build different types of tools on top

that will be if someone builds something, if something completely unrelated and open-sources it, they can make use of that and having that sort of shared platform that everyone can build on top and share the ecosystem. And also, yeah, for other types of assets, it could be traded between, different pools so you could change your, while they might be operating a loyalty scheme pool,

there may be an air miles pool that people can transfer across to and it opens up the possibilities for liquidity in the market and exchanging these points for other things. So they see a lot of value there and the future potential of having a permissionless platform. Now could one use this perhaps for doing crowdfunding and issuing tokens, would that even be desirable? You can do. In the case where actually they are also looking into that, that same company, so you could crowd fund a new restaurant or business.

Hyperledger does very much take the starting assumption that you're not doing anything illegal. If there's anything sort of legally gray area or blatantly illegal, then some Bitcoin-based solution probably used. is a better fit for that. Because of the decentralized aspect. Because, yeah, that's why you want that, you know, higher level of resiliency and decentralization and reduce trust as much as possible.

But, yeah, but certainly if you're, you know, following regulations and you're, you're complying to local laws, then the hyperlegia could be used for that. Certainly if there were no risk of attacks on that scale. Well, it seems like in this case, even using a decentralized system is not going to help you in any way, right? Because it will always be known, you know, that business here in San Francisco that did crowds sale, it's no problem for the government to just come in and shut down the business, the rest of you, et cetera. So whether or not the share trading can still go on and they can't do that, it's fairly irrelevant.

Yeah, and that's a great point. Whenever you're, you know, dealing with assets in the real world and what's on the ledger is actually, map into real world assets, whether they're gold or shares or anything else. Ultimately, governments can go and seize the, you know, whether gold's being stored or shut down the business or take whatever real world asset is being mapped. So unless you have something where something on the ledger is actually the asset that it represents as Bitcoin is, which has no counterparty, or you have shares issued directly onto that ledger that are the official record, which, yeah, things built on top of counterparty or bit

shares are. But when you have a physical presence or a physical commodity or item in the real world, you're never going to get around that just with a technical solution. Especially if you're in the US, right? I mean, you may help you if you're abroad, right? But if you are where the law is going to be enforced, then that's not going to protect you. Yes, exactly. Could you go a bit more in detail about how a company or group of organizations would implement private pools?

So it's, I mean, the source code is freely available. It runs as a fairly standard web server. You have to set it up with an initial configuration of the other initial nodes to start with. and yeah but from there you can you can you can you can you can contact the nodes and start it'll start to replicate the system so yeah I mean there's no need to to fork the code or anything like that to to set up your own unique configuration it's kind of it's ready to go having said that at the moment there's there's not a particularly user-friendly onboarding process to get

that up and running so that's something we're going to work on very soon so that kind of when you start it, you will be asked to set up your initial configuration and all that. Yeah, and then the clients again connect just through standard HTTP messages. So we'll be releasing a couple of reference clients for that. And there's a command line implementation. And yeah, beyond that, it should be fairly simple and straightforward to integrate with in a bunch of different ways. So anybody can do that right now. So right now you go to the GitHub page,

you can install the command line interface tool. It's just a Ruby gem, and then you can create ledgers, you can create assets, you can issue them. That's running on a pool of nodes that you guys have up right now, which is basically staging nodes. Yeah, I think that's still running on our alpha implementation, so that's shortly to be updated

with a to be updated with a beta implementation, which is a lot more robust and should be a lot more performant, but it'll look pretty much exactly the same to begin with. So the server side, the server side, when you're running a server, is you're running a node. And then you're, so you're hosting the database locally on your system.

And you talk about web server. What is that web server output? Is it just, is there an interface there? Is there? So at the moment it's just a JSON API. So designed for sort of, yeah, more like an API exposed over the web interface. But yeah, we will probably be working on some sort of administrative, I guess you call them kind of blockchain explorers or, you know, something like that.

I was curious about that because I didn't see that anywhere in there. And I was wondering if that was going to be part of the beta or even the final release with some sort of an explorer. Yes, yeah, I definitely, I think so. That's something we're very keen to get in because, yeah, again, like with this setup, it will just make it a lot easier for people to get up and running with if they can go through and kind of see it all happening and get to groups with how the system is processing these transactions.

Yeah, at the moment it is kind of exposed, but it's just as an API, so we just haven't written the tool yet. And so is the idea that then that, so, you know, we'll have these private pools, most likely, you know, companies will onboard this and start using it. And then you may also have, so I suppose the business model for HyperLager, and we can talk about this a little bit for a few minutes afterwards, is that you guys would also propose pools.

But then is the assumption that we'll just have people running hyperledger servers out in the wild. And so you may have like, maybe, I don't know, like 500 people running HyperLegger servers and just anybody can create assets, given that they have no specific requirements for security. I don't know, maybe I want to create an asset to trade things between like my friends and I. Is the assumption that there'll just be some servers out there in the wild?

Do you mean kind of open access that you don't have to run? Yeah, open access service. Like right now you have a couple of nodes out there that people have created assets on. So yeah, we've, so I think we'll probably kind of formally get that down and kind of separate that staging. probably into a test net where the information will probably be wiped periodically. And then yeah, we'll work on a sort of more public implementation where there will be probably some, the public pool will be a lot more open, but obviously there'll be no guarantees and kind of quality or performance because we can't necessarily guarantee that it'll be running

on the highest quality infrastructure. But that, well, we're planning to get a public implementation is up as well. So in this world in the future, right, where we have like tons of different ledgers. I mean, I think one interesting thing to come back to is the question, like, what will that feel like and look like when you actually interact with that, right? So obviously, wallets are going to be essential. And I presume we will see wallets, right, that handle a lot of things. So, you know, they may have Bitcoin in it, maybe feel.

currency and you know maybe a whole bunch of also let's say hyper ledger assets um how would that work sort of from a from a on a wallet level how would that be implemented would that be complicated to get each wallet to you know let's say understand five different um hyper ledger consensus systems that do know actually i i've received the transaction now and it's valid because it seems like that's one of the advantages of some of the bitcoin basis solutions, right? Because it will be perhaps easier to build those things. Well, I'd say, I mean, on one level between Bitcoin and ourselves, well, there are some definitely some larger differences in how the consensus process works. The whole kind of

public key infrastructure, you know, the idea of creating your own local, you know, key pair and using that or multi-sig to authenticate transactions, all of that stays very, very much the same or kind of as similar as we can. So, I mean, from the wallet point of view in terms of key management and signing transactions and submitting transactions, all of that looks very similar. So there may be some slight differences in the API, although we'll probably release probably sort of a Bitcoin D wrapper so that we are as kind of drop-in compatible with kind of existing Bitcoin implementations as possible.

On the other side, I'd say, you know, if they are going to extend specific support for Hyper Ledger, then it should be fairly straightforward, given that your starting assumption is that there are multiple pools out there. That, you know, you would assume that the wallet creator has some sort of way to say which particular pools I want to add, you know, I'm a member of and, you know, given my public keys here, look up. my addresses on these different pools. So, yeah, I mean, conceivably, there's, we could even have some sort of global, if you wished, public name registration system, which would kind of look like the domain name system or something like that.

But if I did want to check which, given a public key, which kind of pool is this on, there's conceivably something we could do there, but I'd say that's a little bit further off. Okay, great. Well, let's spend a few minutes before we, before we we developed a bit more into the Hyper Ledger project itself, to hear a bit about sort of view of vision of the cryptocurrency ecosystem of the future.

Where do you see this going and where do you sort of see the place of Hyper Ledger in that? So yeah, as I said earlier, I don't think Bitcoin will go away and we're certainly not trying to replace it. So I do see that still remaining a currency, particularly on the currency side. as a niche, but as a very large niche, you know, the $3.5 billion as it is is still absolutely tiny. I think that will grow regardless of the success of other projects. I see, yeah, there being multiple pools and probably multiple protocols for different use cases. If you want something which is completely trustless entirely where you don't trust anyone and you don't want anyone to know who you are, then something like Bitcoin or that,

dash dot coin will still have a place. But in terms of institutional users or companies who have to operate under certain conditions and need to have identity, need to know who they're operating with and where the nodes in that network are, there will be a variety of sort of private implementations and interprivate pools. So I can see financial institutions adopting something like Hyperledger between themselves for say trading. They may be adopting Ripple for the payments or correspondent banking side.

I can't see existing large incumbents adopting something as revolutionary as Bitcoin and Bitcoin-based platforms in the near future. And I can't see it eating into their the current business that much in the near future, but potentially 10, 15, 20 years down the line, it's hard to predict. But I definitely do see a world where there are multiple different protocols, platforms for different scenarios.

And yeah, there will be the ability to be interoperable and move between them. But whether that is desired or not remains to be seen. And what's the view of the sidechains project? Because that also seems to kind of... offer this perspective of having, you know, customised chains for all kinds of use cases? Yeah, it's a very interesting project and, you know, mostly seen that you get it implemented, but they probably will. The questions that we have are that when we get asked about it from banks is that they're interested in this idea of private chains or the outside chains,

but they don't necessarily need that two-way federated peg to Bitcoin because there isn't really the interest in and out of Bitcoin. That to me seems more like going backwards from the starting point of Bitcoin to make it fit into that world, whereas we've just started in that world to start with and building a solution for that world. So I think that's actually sort of happening across the board in Bitcoin generally. There's, you know, you've got the sort of live.

libertarian crypto enthusiasts initially and as more business and banking people move into the space they're trying to rein it back in and that's creating a bit of a conflict within the Bitcoin world But yeah Trying to use something they're trying to use Bitcoin for something it wasn't designed with But design for in the first place Might present quite a lot of issues and doesn't actually necessarily bring the benefits of the reasons why the people want those things in the first place So I'm not convinced that having a two-way peg with Bitcoin actually adds a lot of value to institutions adopting it, more so it adds value to

Bitcoin by having the ability to do those things. Yeah. So it's a pro-Bitcoin move rather than a pro-customer move. So, you know, we've talked a bit about what you may be envisioning as part of a business model. Can you elaborate a little bit on how you guys plan to make money in the future? Yeah. So, yeah, as a young startup, it is still evolving. And then, Anything we see now will probably be different next week. But essentially, hyperledger is going to be completely open source. We don't want to monetize the protocol. No cryptocurrency built in.

So anyone is free to take that, use it. They don't need to fork it or do anything. They can just do what they are like with it. So once that is, it becomes more of a standard. And there is more widespread adoption from the people speaking to at the moment. There's plenty of opportunity to provide higher level products and support services. around that. So if there's a particular, say,

and then derivatives, which can be very complicated and need a lot of customization, something that doesn't apply to the general platform, we may build proprietary solutions on top of the open source hyperledger base specifically just for that particular use case and license that to institutions. We can provide support and customization to them.

We are also, looking for companies that want to set up a consensus pool themselves but don't necessarily want to run the infrastructure themselves you know that we're looking in more of a sort of cloud utility model where we can have a a marketplace of authorized verified hyperledger providers that we've actually done tests on and they can select say I want to have a maximum of three nodes operated per per entity the company I want them all inside the EU and I don't want them all to be in data centers which are compliant for this and that and that.

Then they can just spin up a pool as large as they want across the existing hyperledger providers and pay on a per node basis, of which we would take a cut in order to provide that verification and marketplace functionality. So that's a sort of consensus as a service angle for the smaller to medium-sized companies. Cool. Very interesting. And what about timeline? So you, I mean, there is some type of release here, but what do you envision happening in the next 12 months? So, yeah, the alpha was released last July. That was always designed to be, you know, just a test, and we always plan to throw it out away.

So the debate is actually up on GitHub now. It's been completely rewritten from scratch. It's much more perform and stable. And the goal is to have that production ready by early April, just with the core feature set. Beyond that, it is very much market-driven. From the potential customers we're talking to, there are specific requirements and weighing up which of those are most generally applicable to go across the board.

We'll get the highest priority. So we will have a proper sort of feature map and roadmap up soon, but it will likely change based on user feedback, very rapidly. Cool, fantastic. Well, thanks so much for joining us today, guys. It was very interesting talking about this project, which I think is definitely showing an important sort of movement that's happening in the cryptocurrency space, the attempt to take a lot of

innovation and a lot of the sort of breakthroughs that have happened here and try to apply them to existing system and see what one can sort of do with that. I I see my my thoughts on this is that you know we're finally starting to see some real world applicable infrastructure that can be used for business and you know people will will look at that as some people you know will look at that as not necessarily as progress but as going in some direction that is contrary to the belief of bitcoin and you know so the essential ideological ideas but you know when it comes down to it, this is what we're trying to do, right? We're trying to implement decentralized and somewhat distributed technologies into everyday life.

So anything that we can do to enable that for businesses is, I think, a step in the right direction. Yeah, absolutely. I mean, they're not mutually exclusive. Exactly, right. You can jump ahead and try to create the perfect world, which is a perfectly reasonable thing to do. or you can try and take the existing world and bump it in that direction more slowly. So different approaches.

They can run completely in parallel. We're not harming the Bitcoin world or Bitcoin's chances of success because the people we're talking to aren't going to use it anyway. So yeah, you know, just we can bump the... Bitcoin can sort of break through the current

system and we can, as it does, we can sort of bump up behind it and try to push it and make it more efficient and more usable and bring a lot of benefits to consumers at the same time. Absolutely. And one of the positives for Bitcoin may also be that, you know, once there's, of course, a much, much higher extent of interoperability

when you start having hyperlige and those kind of systems, for some assets, let's say it's via currency or whatever, with Bitcoin, then with existing systems, right? Because existing systems, they're just completely incompatible. And so I think there's a lot, a lot to be said for that and that also offers a lot of possibilities for Bitcoin. Yep, it's still pushing the public-private secret, public-private key infrastructure.

So once that is, and that's a big thing, not just for the Bitcoin world, but for the internet and banking and everything in general. So helping push that forward as a greater industry is beneficial. Everyone who's using that technology. And as you say, it does make it easier for people to, once they are used to being in control of their own assets and having those private keys, and that makes the jump to Bitcoin all the more palatable. Cool.

Well, yeah, thanks so much for joining us today. It was a pleasure. We will have links to the project, also to the forum and to the blog, perhaps, where people can read more about the project, also get in touch with you guys if they're curious. I encourage people to, if you're comfortable with the command. line like install the command line tool it's really easy and uh you know just try creating a a ledger and assets and fooling around with it it's really cool absolutely i should do that as well yeah we're trying as well okay well thanks much and thanks for listeners for listening it was a

pleasure as always you can follow us on twitter we're at epicenter btc and we will be back next week thanks and we'll see you then thanks for having us thanks so much guys Thank you.