 I'm going to talk, welcome everybody, about the hyper lecture fabric and about the relation to the hyper lecture project. So this is joint work with a lot of people at IBM and beyond IBM and I'm just listed the people here that are at IBM Research in Zurich, who are my closest collaborators on this and so I'm glad to count on the help of such a big team. So let me see how, since I didn't bring a keyboard, here we go. So first of all, just as a preview hyper lecture fabric is one technology platform, a blockchain platform that is being developed inside the hyper lecture project. It implements blockchain technology for an enterprise focus. That means for those of you who already listened, is a permissioned blockchain model mostly. It uses modular architecture and it contains container technology for running smart contracts which are generalizations of the cryptocurrencies. And it's developed open source and I'll show you how to participate in this later. Before we go into this, let me give you an update or a repeat on what is blockchain. So blockchain is impossible to miss when you even turn on any daily newspaper nowadays that everyone's news about this, not only in the trade press and in the crypto press. So for many people, blockchain is something like this. You will only understand this really if you're a native German speaker, but this animal is the one that gives simultaneously eggs, wool, milk and meat. And so in many cases, blockchain is seen as a panacea for your security and privacy problems and when you sit down and understand it better, you will see what it can actually do and what not. So you're technical people here, let's focus a bit on the actual elements that are part of blockchain. Commonly you can characterize a blockchain to have four features that are, a blockchain is replicating, is about replicating state operations transactions in a distributed system. It is made secure by technology alone, by cryptographic protocols, by cryptographic techniques such as signatures, integrity preserving techniques, but also cryptographic techniques for ensuring privacy. A third element are protocols for consensus, because all these nodes that are making up the system, they need actually to coordinate their actions so that they are emulating the notion of one common ledger there and the business logic part here in this picture refers to the fact that even though blockchain was born with Bitcoin, which is a cryptocurrency, the blockchain concept itself has many applications that go beyond, such as the arbitrary smart contracts through which you could run business vehicles that are and shared code on a much more general level. That's where the industry is going, that's also where we are looking at. Why is blockchain so popular right now? Because you will notice as having expertise in cryptography that many of the protocols and the concepts in cryptography have been around for a while, especially also banks have been using cryptography for decades. There have been a driver for the development of secure cryptography in payment networks and so on, but mostly this kind of crypto that was used by the banks was for securing channels. There are a lot of types between Alice and Bob and in cryptography you have developed many notions for multilateral security for protocols that distribute trust, where many nodes are participating and the Bitcoin revolution or maybe the Bitcoin shock, the fact that you can realize a currency without a trusted entity that says a bank, an issuing bank that says this is money, the fact that this is actually something that works, that seems to have woken up the financial industry to the realization that cryptography can do much more than securing pipes and channels between Alice and Bob. So blockchain is about replacing trust by technology. So let me ask again, what's a blockchain? And now comes a personal memory in the sense that these things have been around in the past before. My answer, 15 years ago we wrote papers with titles such as distributing trust over the Internet as a representative of a broader research movement at the time, including others who tried to make distributed consensus protocols more practical. And this paper here, you can read the abstract, the first line says, this paper describes an architecture for secure and fault tolerant service replication in an asynchronous network such as the Internet where the nodes do not trust each other. And that's actually the same model that is taken up by Bitcoin and by blockchain nowadays. Except that since we are now actually more real, we need to revisit some of the assumptions that were made back then. So to be a bit more technical, here's the abstraction of the state machine that the blockchain will implement and at very simple spoken, the blockchain protocols will emulate such a state machine in a trustworthy way across a wide large number of nodes. So there's a functionality F that has operations and they define how you get from one state to the next state. And the system has to progress through this succession of states. There's also an element called validation such that not all operations are valid in each state. So when you process an operation, you want to ensure that you're only executing valid operations. This is a new element that comes in with potentially malicious clients who may submit invalid operations to the state machine. And then the blockchain state machine is essentially a sequence of such operations or transactions where for efficiency reasons we are grouping a number of operations together into a block and we are also hashing each operation together in the form of a hash chain. So for cryptographers, this is a hash chain, not a blockchain. But the blocking alone is actually only for efficiency reasons. So this is the functionality that we are trying to emulate. And in the Bitcoin state machine that was already talked about before, you have certain transactions that you have only transactions that move bitcoins between different public keys. Public keys represent owners by the fact that some user knows a private key corresponding to the public key. And so the owners are pseudonymous in the sense that they're only keys known. But every transaction in Bitcoin payment or transaction is a statement of the form that this Bitcoin fraction now belongs to that other key. And also the validation, of course, is based on the fact that you have to own this Bitcoin in the first place before you can spend it. So I'm simplifying here, but that's the gist of it. And of course, you have to make sure that somebody who is spending a Bitcoin has not already spent this Bitcoin before. And for this, you need to verify it based on the past payment history. So in terms of protocols for blockchain, we now have the task of constructing this ledger from in a distributed system where there are many nodes. The blue dots there are nodes that are producing transactions, the red arrows. And we have to order them into this one single sequence of operations or transactions. And there are different protocols that were already talked about before to do this. There are so-called permission and permissionless protocols. And the features that all these protocols have to ensure are that only valid operations are executed and invalid operations are not executed. And so the transactions, they can be not only, they cannot only be such simple statements, but they can be arbitrary code executions, which would then be called smart contracts. So consensus is there for a hot topic. And this is the kind of protocol that I have all the expertise with. And consensus has been the focus of many white papers, reports, and some of the people here have contributed to some of those reports as well. But you see there's a lot of interest in consensus protocols nowadays, and it's a bit like crypto systems in the 90s where suddenly everybody had a new crypto system and everybody wanted to have a better crypto system than others. And so it's not so clear which consensus protocol is the best possible also because there are all the startups coming up with consensus protocols. There's also trade show later this year in New York that's called Consensus, so you can hear there about consensus protocols. Or you could also have gone to a distributed computing conference of course. No, so here the consensus protocols that I will briefly touch on are the decentralized permission less, which is in Bitcoin, and then the consortium consensus, which is the traditional notion of consensus from distributed computing, and the somewhat decentralized consensus methods that are in the Ripple protocol I'm skipping over here. So in the Nakamoto consensus, which is the protocol that came up with Bitcoin, where there's a lottery race, a mining, this mining work, which simultaneously incentivizes nodes to participate in the protocol, but also forms the blockchain itself by the nodes solving a cryptographically hard puzzle such that a winner or somebody who has found the solution to this puzzle thereby extends the blockchain and executes some operations, all nodes who are receiving this block then that the node, the lucky node here, the one shown in yellow, has found all these nodes that receive this through a peer-to-peer broadcasting gossiping network, they will have to validate and verify that this block has been constructed correctly. And as was mentioned already before by Elaine, a couple of works have now formally shown that this actually gives a notion of consensus that we have already formulated and have known in the formal sense of distributed computing. The permissionless decentralized consensus protocols, they have the special feature that they are suppressed, they are censorship resistant, they arewithstanding any kind of suppression because you don't need an identity to join. The original intent was to have one CPU, one vote in these protocols. But nowadays you need to have a lot of CPU power to have an influence in these protocols. So this is actually several hundred megawatts or a gigawatt or something like this, which is huge. Also as a slight issue here in these kind of protocols is that decisions issued by the protocol are not final until you have waited for a bit longer. The total implications of this are subject to current investigation, what this means. That's not the case for the other protocols that are based on the traditional notion of consensus among a group of known peers, which actually don't suffer from this nonfinality. So this is the model of consensus that is based on distributed computing consensus, protocols such as PAXOS, BFT or PBFT, which is one protocol, but also the protocols I was alluding to with the earlier research, a lot of earlier research in this field and our research. That is the protocol based on recent in agreement. In this model, you have a clearly defined set of nodes and you have a fault assumption how many of them can be faulted. And in this case, typically not all participants are active in the consensus protocol because of the cost of such protocols. It's normally order n squared communication and even if it was only order n communication for millions of nodes participating in this, this won't work. So therefore, these kind of protocols are more seen ideal nowadays as for those consortium blockchains or for hierarchical systems where these protocols are run by a subset of the nodes. The task that they're doing is the same, they're receiving transactions that are generated by nodes in the system and ordered them together. The advantage of those protocols here that are based on traditional distributed computing notions is that we understand them. We have well-established notions for consensus definitions, textbooks, several hundred protocols have been formulated. Brief, yeah, so there is a brief advertising break here that there are textbooks that describe this also. These are not new textbooks, but one of them that I have also co-authored explains traditional consensus protocols from the world where crashes are tolerated or Byzantine faults are tolerated. The second element we need in the blockchain is validation. And this means that we have to verify that only correct operations go in. In the proof of work-based protocols or blockchains, the validation happens by every node actually executing the transactions and verifying them as well. So all the nodes in the system that receive a newly found solution to the newly found block, a newly mined block, they must verify this is actually correct. And so this is kind of a difficult work because as of last night, when I looked this up, there's almost 100 gigabytes of state needed for you to verify that your Bitcoin transaction is actually correct. This is kind of huge, so it means that already there's a natural hierarchy because your wallet and your mobile phone are not going to participate in this. In the BFT protocols, we have well-established notions of validity that are also ultimately based on nodes recreating and re-executing this, but we have formal properties of validation that you can also read in those textbooks for what it means for operations to be valid in this context. A major area of interesting area for cryptographers is that in the blockchains, since all the state is replicated among all the nodes, there is per definition no privacy. So why do we think that blockchain adds privacy? So we are... There have indeed been several or many research developments in order to add more privacy again to blockchain systems, starting with Bitcoin and earlier systems such as zero coins, zero cash, all the way to a system called HAWK, which demonstrates in a way how to do this for arbitrary computations. Yeah, so now I've talked about security properties. There is a lot more securities properties that you can address in the Bitcoin world. And now I've talked all about this in the background. I would like to come to the hyperledger fabric, which is in this industrial development of blockchain technology, which is actually in the title of this talk. So the hyperledger fabric is a technology development inside the hyperledger project. The hyperledger project is run by the Linux Foundation, has been established about one year ago with the aim of developing enterprise blockchain technology. And enterprise here means mostly financial industry, but also beyond that. There are a number of technologies proposed and being actively developed under this. The hyperledger fabric is one of them. Here is a snapshot of the memories, but since the membership in the hyperledger project is growing, as we speak, this is just a snapshot. So the fabric was originally started at IBM through a protocol called Open Blockchain. Then it was donated about one year ago into the open source and as one of the incubation projects in the hyperledger umbrella it's relying on contributions from several companies. The main developers are at IBM Research in Zurich. We are mainly focusing on architecture, but also very much on cryptographic aspects, cryptographic implementations and also on the consensus protocols and their implementation. And there are implementers in other IBM locations and also in other companies, such as those listed here, and everybody can start participating by joining the hyperledger project and start discussing this as other open source projects are developed, for example, in OpenStack by just going through GERRIT reviews and so on and so on. So as a technical detail, hyperledger fabric is a smart contract platform that runs your smart contracts that are currently written in Go, modern programming language. It uses a Docker container to encapsulate your smart contract and isolate it from others. And here is an architecture diagram of the early version that shows you that it's modular. You have membership because it's a permissioned blockchain platform where nodes need an identity and need to be admitted to it. And then there are modular abstractions for consensus and modular abstractions for building a distributed ledger. Here I'm talking about the existing version that has been there is called V06 Preview. It has been there as of last summer, last fall. All the peers participating in this blockchain platform run a Byzantine agreement or PBFD protocol to be specific. They are executing transactions by following the state machine replication paradigm I showed in the beginning. Transactions can deploy new chain code, you can invoke an operation of already deployed chain code, and you can also read state out of this. This is the kind of transaction that exists. State exists in a key value store where every node keeps a key value store with the things represented by your smart contracts. And then the model is one where we follow the textbook approach to replication, we order the transactions and then let each node execute them individually. That means also that also these transactions have to be deterministic because if they were not, even though you ordered operations, the resulting states could diverge. And you can compute the hash chain over the corresponding operations then later. There is a membership service which implements a PKI based membership that gives you a pseudonymity notion so you have to enroll a node by giving it an enrollment certificate issued by an enrollment CA and then in order to transact, you need a transaction certificate and the transaction certificate is not linkable to the enrollment certificate for the ones who execute transactions for the peers that run transactions but the CA could link you. So in that sense, you have a user-choosable notion of pseudonymity because you can choose to use this transaction certificate for as many transactions as you want, yeah. As I said, there is an issue with non-determinism so as part of past research and there is a link to the paper of this on my homepage, we have developed a modular way to sieve out non-deterministic transactions or the effects of non-deterministic transactions in the protocol. That's a contribution in the sense of protocols research looking at this in the sense that we are filtering out transactions that were demonstrably non-deterministic. I'm gonna focus also a bit on a version of one of Hyperledger Fabric which is being developed now which follows a slightly different paradigm in the sense that it will distribute some of those functions for better scalability. As I've mentioned before, all the nodes will run the consensus protocol and the execution all the same even though this may not be necessary because certain so-called smart contracts are only of interest for certain peers in the system. So the idea here behind this V1 architecture is to separate the endorsement function or the execution function of a smart contract from the actual consensus reaching on the order of transactions. And you can understand this design as a replicated database that follows design principles that have been developed in the database literature also 10, 20 years ago. It also facilitates the maintenance of confidential data makes it easier to do that. It's more scalable overall as well. The idea here would be that the yellow smart contract runs only on the yellow peers and the red smart contract runs only on the red peers and the client invoking a red transaction for a red smart contract only talks to the red peers gets an endorsement which can be specific to a smart contract itself. What does it mean? Does it mean a majority of the nodes who run it or does it need an endorsement from all of them? And then records the effect that this execution has in terms of which state variables it accesses, which state variables it updates, and then endorses this as a static piece of information. This piece of information is sent together with versioning data through an ordering service. And this is a modular consensus service that we have in the middle there that we can abstract out. That makes it possible to separate the execution of the potentially complex code from the maintenance of the ledger and from the consensus function itself. This will increase the speed and the throughput. So the typical workflow would be that the client produces this transaction, sends it to the peers that are executing it, the peers will sign it and will record a so-called read set and write set which are database technology for the values that you have read and written together with versioning information. And this versioning information is a blob that has to be signed which is in some sense endorsed and then sent through a consensus service which can be then modular and only generates a stream of ordered static state changes. Yeah, as a consensus methods we have implemented here, three versions, a solo order which is basically one box doing it which is called the ideal functionality in crypto research. There is an Apache Kafka scalable pop-up messaging toolkit that works in a crash tolerant model and there is also a traditional BFT protocol derived from PBFT which does it in a Byzantine agreement kind of way and further protocols are possible to be implemented there. Okay, in the last two minutes, one minute Agiles, okay two minutes, we have research here, we have the ideal world, what does it mean to go from the ideal world to the real world? Why does it take 15 years for ideas like this to realize, to become mature, to actually be deployed? We have had a lot of this technology for years that has been around. E-Cache has been one of the original motivations for modern cryptography and publicly cryptography but we haven't seen any of this deployed and now comes this Bitcoin and it has almost none of these fancy crypto protocols that we have developed and stopped developing in a meanwhile. And most of the concept also in Bitcoin have been around for a long time. And so I was wondering also for this audience, for this conference here, why this is the case? Why do we have thousands of startups maybe and each one comes with their own consensus protocol and each one has their own magic source and why many of them actually are re-discovering results from the past. So I would like to remind just that publicly cryptography has been out 10, 20 years before there was a need for having actually encryption on a TCP connection. So when this was recognized that we needed encryption for secure channels, Netscape created the SSL protocol which was not done by the crypto researchers but by, according to formal models that had already developed. It was done by somebody who understood the technology but then had to solve the practical problem and made some choices that turned out to be suboptimal. And then the researchers, and the same thing happened with other things like PGP and email. So it took a while. It's also often the case that it takes a different generation. It takes a different set of people to do the implementations than the research. And even though today a lot of academic papers come with research prototypes, these remain academic prototypes and they're not real systems. So when you're building real systems you have to face a lot of the product, you have to address a lot of the assumptions that you made in the academic world and it's also reciprocal. The academics are then studying the assumptions made by the practitioners that have been proven to be in practice. And we've seen some of that at this conference as well. There's a business case and a lot of the academics, for example, are studying nowadays choices made by TLS and imposed by protocols, by specific practical constraints. And ideally this process is reciprocal. And the famous quote, of course, in theory, it's the same, theory and practice are the same. In practice they are not. So to summarize here, blockchain is a golden opportunity for cryptographers working in interesting practical deployments. We are engaging in new trust models and the one line summary about what is a blockchain is about distributing trust on the internet. I have a collection of links here that should get you started on the Hyperledger Fabric as well. Thank you. All right, so maybe a very quick question until the next speaker is setting up. Thank you. Do you have any interaction with the external world from inside Hyperledger? Like any possibility for calls to external service maybe to internet or some form? Because currently this problem, for instance, in Ethereum is solved only we are asking currency requests. Do you have any solution for it? There is only possible to have async requests like this that you're saying that you have an oracle that inputs some information. That will have to be looked at in the context of specific smart contracts.