 Hello everyone. Thank you for being here. It's a real pleasure to be here physically after a year and a half of talking to cameras. So I don't know how many of you are more technically oriented. Part of my presentation at the beginning is very high level. The end is more technical oriented towards more developers. There are other people who actually want to try the technology but there should be enough for everybody to enjoy. So you may have seen the description of my presentation. I actually talk about blockchain as being a new type of database. And quite frankly it's a bit of a provocative statement. There are people, hardcore believers into blockchain being a completely new, revolutionizing technology. Maybe I'm a bit boring, I'm old, but for me it's just yet another technology. It's an important evolution, but at the end of the day it's a system that you use to store data and retrieve data from. And to me that makes it a database. Of course it has very different characteristics than traditional databases and we'll get through some of this. But I still feel like it's reasonable to call it a database. So let's get to this. First let's talk about, you may have heard of blockchain being also referred as a decentralized ledger. So what is this all about? First let's start stepping back and talk about ledgers. What are ledgers? Ledgers have by no means new, right? They've been around since the 15th century and they've been used by businesses to keep track of what's going on with their business. So we typically refer to two key aspects related to ledgers. There's a notion of transactions which are typically, you know, they refer to asset transfer of one kind or another. These things that are either coming out of your business or getting into your business that you will record those events, those transactions into your ledger. And traditionally this is done with big books that were used to store information. And then there's this notion of contract. So you basically, you know, as a company will enter into some kind of business contract with another company, whether it's a supplier or a customer. And you basically agree on some kind of transactions with certain conditions and transactions being executed for a given outcome. And so these are like the contracts that we are talking about that basically governs the transactions that are taking place with your business in and out, right? So of course, you know, the evolution with the digitalization of the business has been to move from these paper ledgers to computer IT systems that basically replicate this kind of systems into, you know, digital systems. The problem we have with this first step of the evolution is we end up with a situation which is depicted on this slide where essentially you have a network of business partners who are interacting with one another under those contracts. And each participant in the network is basically recording their versions of what's going on in their own ledger. All the different ledgers are being maintained completely independently by each participant. When everything goes as planned, it's not a problem. Everything works well. The problem happens when there is something that doesn't happen the way it was expected. So maybe you were expecting to receive some order, something that you ordered from your supplier, it's not happening. Or there is a payment that didn't come in on time. And so there is a breach of contract somewhere. But the problem is to be able to come to an agreement with the other party on what happened, what went wrong. At that point in time, each party has their own version of what's happening or what has happened to that point. So you go into what we call the reconciliation exercise where basically the different parties involved in the transaction have to compare notes. And you try to find where things went wrong and come to an agreement. This is actually a very costly and time-consuming exercise during which typically assets will be frozen. And it generally creates a lot of friction in the network. So it's quite inefficient and an expensive process. What blockchain and decentralized ledgers are about is to try to solve that very problem. So that instead of having all these different ledgers being maintained independently, we create a system which will keep all these different ledgers in sync with one another. This is what I like to call reconciliation upfront. So essentially, instead of saying each party is going to write their own version of what's going on, their own transaction, their own record of the transactions that are taking place, we're going to have a system where we submit the transaction to the network. When the network agrees, yes, this is what's happening. We cannot record it in our own copy of the ledger. So we still have our own copy of the ledger, but now it's being kept in sync with everybody else. So when things goes wrong, well, we don't have to go through this reconciliation exercise anymore because we all have the same version of the record. This is what we call the universal source of truth. So it actually saves us this trouble of trying to figure out what went wrong. We all know there is no dispute, so resolution can come up much faster. What's really important is this notion is, you know, so we have this shared replicated ledger. We'll talk a little bit more about the permission aspect. That's actually a different dimension. What's really important in the scenario I'm describing is the notion that we have to have consensus in the network to come to an agreement on what needs to be recorded or what it is to record on the ledger. And there is this notion that, well, we can tell which transactions come from where. And the ledger is such that it's immutable. So once something is recorded, you cannot change it, especially not unilaterally. The problem with the before picture that we saw earlier is also that anybody is in control with their own record, which means they can change their record if they want to. You would have no view on what happened with their ledger. So in that way, it's only worth what the people claim it is to be. And the other aspect is finality. So again, because this is shared by everybody and nobody can change anything without the consensus from everybody else, it means you have a final record of what happened. This is what really blockchain is all about. There are different types of blockchains. And you probably have heard about Bitcoin unless you've been living under a rock. Bitcoin deserves a lot of credit because it's really at the origin of the blockchain movement. However, it's important to realize that in fact, Bitcoin is a specific application of a technology which is much more broadly applicable. And this is why IBM got interested. Of course, as you can imagine, IBM has a big research center. We had researchers looking into Bitcoin from the early days, especially people involved in cryptography and all this stuff. They were really interested in what was going on. At the same time, from our point of view, this was not so interesting in and of itself until we realized that, as I was saying at the very beginning, fundamentally what we're talking about is a system of record that is shared among a network of business partners. And this is broadly applicable to any kind of data. In the case of Bitcoin, they use this system to record exchange of coins, this new digital currency. And they can keep track of who owns what. If I have a coin, I can give it to somebody else or a fraction of a coin. And this is being recorded so at any moment we can tell who owns what and where each coin came from because you can see the history of the coin with all the transactions on the ledger. Now, you can imagine that you can expand on this instead of recording transactions of coin related to a coin. We can record transactions related to the ownership of a house, of a car, or anything we really want. So what's fundamentally important about blockchain is this notion that we have this distributed ledger that provides an irrefutable proof, right? We have this set of transactions that is being recorded. So why do we call it blockchain? Without getting into the details, basically it's a way of encapsulating all the transactions into a set of transactions which form a block and the block itself is hashed. So we have a cryptographic signature of the set of transactions which is then embedded in the next block. And so it's kind of like Russian doll type of system where by definition if you change anything in any block you break the signature and all the other blocks behind. So the more you add blocks, the harder it becomes to change anything in the ledger. So I did talk a little bit briefly. There was a mention of permission ledger. Let me talk a little bit more about this. Bitcoin is a permissionless blockchain network which means that there is no access control to the system. Anybody can join. There's actually a program you can download it on your machine and start writing Bitcoin. You will join the Bitcoin network. Immediately nobody is going to stop you and you can start participating. You can start downloading all the transactions, seeing all the transactions that happen and possibly submit transactions to the network. On the other hand, it's meant to be anonymous, although it's really synonymous. You actually use some kind of ID that is associated with you to do all your transactions. Nobody can really see who is behind each ID, which is why it's so commonly used in ransomware because once the money is transferred to some ID, we have no way to know who is behind this. At the same time, there is no privacy because if two people exchange transactions, we have to reveal our IDs to actually make the transaction happen to say, I'm exchanging Bitcoin from this ID to this other ID. Over time, you can actually build basically a directory of all the IDs of the people or the parties you're interacting with and because the ledger is public, you can actually trace all the other transactions that those IDs are doing or have done. So in terms of privacy, it's actually fairly weak. If you think about the way business networks function, it's pretty much the opposite. Businesses typically work in a network of partners. They actually know who they are. Nobody is hiding behind some fake identity or not fake, but some digital identity that you don't know who is behind. And on the other hand, they want privacy. They don't want all your suppliers to see how much you're buying from each supplier and so on. So this is what actually has motivated IBM to start working on this and develop a solution. There was no system that actually did address those problems. So let me give you some concrete examples before I go further into what the solution is. TradeLens is one of the early platforms they've developed with a company called MERSC, which is like the biggest container shipping company in the world. And their problem wasn't so much keeping track of where the containers are when they are shipping from point A to point B around the world, but it's all the paperwork associated with this. There's a huge amount of signatures and stamps they need to get along the way. And so there is a paper trail that actually obviously follows a different path entirely from the container itself. And this is actually their biggest burden because it involves many different parties. It is going to involve people like, of course, the actual transporter, but authorities, insurance companies, customs and so on. So all along the way, they have to ensure that they get all the right signatures, all the right authorizations. So basically we developed a system that allows all these different companies to join this network so that when they're starting to ship a container from one place to another, there's a record associated with that container or that shipment. And every time one party or another has to sign, they can just add to the ledger associated with that shipment. And at any point in time, we can always go back and do an audit, see what happened. Another system we developed initially with Walmart, it's now extended throughout the food industry, is IBM Food Trust, which is a platform to keep track of provenance of food-related products. So you can do things like, you may know that for instance in the industry, there is like Ecoli breakout every year, almost it seems. And what happens is the stores are being informed that there is a breakout in some form, but nobody knows where the letters from that form are. There is actually the information is somewhere, but it takes so long to actually figure it out that it's safer to just take out all the letters. So there's huge amount of waste because we are throwing out all stuff letters, it's independent of where they come from. So basically we have been able to develop systems now that will allow us to keep track of the provenance of all the food items throughout the food supply chain so that we can actually identify very clearly which item comes from which producer on the shelves. So when there is a case like this, we can actually do a much more narrowly sculpt recall. One of the newer examples that we have, we have developed the digital health pass which with the COVID, we actually some of you probably use different applications today to show that you got the vaccination for COVID. And so IBM actually developed a platform to do that and is actually used by different governments around the world, New York, the Excelsior platform is based on the IBM DHB. And essentially it's a system that allows verification of credentials and it's specifically targeted for health. It's not limited to vaccination, it could be anything that's health related. But the idea is to allow verification of credentials while the user is actually in control of what gets disclosed and who to whom and where the supplier, the issuer of the credential is not involved at all in the verification process. So the naive application, the implementation of the system like this is you have a central system, the supplier sets up and every time you go check your vaccination, basically it's going to make a query to the issuer to verify this is valid. With this kind of decentralized system, we can store the keys that allow the verification of the credentials without the issuer being involved. It's also important to know despite all the crazy stuff people are saying, this system do not store any personal data on the blockchain. They actually store basically cryptographic keys associated with the issuer. This is like your lab or your health provider who's been doing the vaccinations on the chain so that the credential that's given to you that's stored in your electronic wallet can be verified with those keys. But it doesn't contain any personal data whatsoever. So these are the kind of examples of applications that we have been developing with this kind of technology. So let me get now to Hyperledge of Fabric. So as I was saying, once we realized there was a need and we actually did a fairly extensive survey of all the different systems that existed at the time. We were talking back in 2014-15. We realized there was no system that existed, so we embarked into developing our own with different principles that were really tuned towards the needs of the enterprise. So we developed Hyperledge of Fabric, which was then contributed to the Hyperledge project, which is now developed in open source. So there are different characteristics, some of which you will recognize. I've talked about permissions so that we can control who has access to the network to start with. We have enforced privacy so that not everybody sees everything. We have finality. There are a lot of systems like Bitcoin where you actually don't really know when the transaction that has been submitted that is actually accepted by the network will stick to it or not. I would have to get into two low level details to explain, but you have just enough to say that some transactions can be revert afterwards. In the business case, this is difficult to deal with, so we design a system where there is no such thing. So once your transaction has been accepted and recorded, it's never reversed. So it's final. We also wanted systems that are preferment, and then there is notion of smart contracts that basically implements the logic of the application, that it will be application-specific. There are different systems that make different choices. Some that have developed specific languages. So if you know about Ethereum, for instance, they have their own language. They have defined for writing smart contracts. Such as Solidity. And we made the choice to allow enterprise developers to use whatever programming language they wanted. And there are things like mining and cryptocurrency are not part of the system at all. You can use it to develop an application that is dedicated to digital currency, but it's not part of the system. And I won't go into the detail, but the rest is a bit more technical. But one key aspect is that we thought that this is fairly new innovative technology where a lot of new things will still be coming up. So we made it very modular so things could be changed and evolve over time. So as I was saying, this is part of a bigger organization, a consortium, if you will, called Hyperledger, which is technically a collaborative project of the Linux Foundation. And it was one of the fastest growing organizations in the history of the Linux Foundation. We had over 200 members just a few years ago. It's come down a bit because the hype is over, which I think is a good thing. But we still have a significant number of members. I know it's very small, but it's just to give you an idea that you're supposed to say, wow, there's a lot. That's the message of the slide. So Hyperledger Fabric, the technology that I'm going to be talking about, is now available, you know, provided on all the different major cloud providers today. So now let me tell you a little bit more about, you know, the evolution of fabric. So we started in 2015. In 2016, we had the, you know, a first version of within Hyperledger. It was called Fabric 05 and 06. Then we had a major redesign because by then we had already engaged with customers and realized, okay, this architecture is too limiting. We had a major redesign. And so in 2017, basically one year after the launch of Hyperledger and the contribution of the code to Hyperledger Fabric, we released version 1.0, which created, it was very unique at the time and introduced a lot of different aspects that were really not common into the blockchain space. For instance, we introduced the notion of channels. So initially we thought, well, to provide participants in the network privacy, we'd make it permissioned. So they were saying now we control access. But we realized, well, even in a network, if the network is big enough, people don't always want to share everything within the network. So we created the notion of channels, which allows us to segment further the network into subgroups so that within the network you can have different subgroups that can actually intersect in many ways and provide people with more privacy. I'm not going to get into all the details, but we had some major milestone and I actually removed a lot of this slide as it evolved over time. And it's a lot simpler than it used to be because it was getting way too crowded. But some of the big milestones is, in 2019, we had the first LTS version. This is long-term service when the community said, well, you can use this and we will keep maintaining it for quite a while. It was actually, the commitment was for a year and a half. We did a bit more. But then we had a version 2.0 in the early 2020. And we took a couple of iterations, 2.1 and 2.2 before we created new LTS. There were several big changes, and I'll talk more about the axis of development next, but we had some major changes that justified increasing the version number, the major version from 1x to 2x. And basically, we have evolved since then both versions, the 1.4 branch and the 2 branch. And we just actually recently ended the 1.4 branch saying, okay, this is the last LTS on the 1x branch. So everybody, please agree to 2x is the message we're telling because, you know, of course, there could be some major issue and we might feel compelled to fix the 1x branch. But essentially, we don't want people to keep developing with or using 1x in production, and everybody should be transitioning to 2x. So now we have a new LTS with the 2.2, and this is what people should use in production, and we are working on the 2.3 and now 2.4 are the latter versions that we're working on. There's actually 2.4 alpha and beta that were actually already released, and our goal is to have the 2.4 released by the end of this year with some of the letters development. So rather than going through all the details of all the different features, what I thought would be interesting is to give you a kind of high-level on how the software has been evolving over time. This is what I call the axis of development of fabric. So we have seen many different development related to privacy and confidentiality. As I was saying earlier, we started with one network, then we created this notion of channels that allows you to segment the network, then we actually introduced a notion of private data which allows to go even further than that and encrypt some data so that there is auditability and so on, but not everything sees everything. You can decide who gets to see what, and there is further development happening in that space. It's actually thanks to a lot of advancement in cryptography, we can do a lot of things that just weren't kept... We couldn't do... they were not practical. There's a lot of things in cryptography that has been possible for a long time but they would take so long they were just not usable in practice. Now they become usable and so we see more and more development happening in that space thanks to the evolution of computer capabilities. In terms of decentralization, we've also seen several improvements. So we started with a system based on a Kafka which is crash fault-tolerant which meant that the system you could actually run different peers for each participant so that if one were to crash or a few you could still resist to this. However, they were part of the system that were fairly centralized and it's not all of it and some people are very critical saying, ah, this is not decentralized but it was actually much more decentralized than they want you to believe. But this is something like related to the consensus process and I'll talk a little bit more about this on the next slide or so. But this is part of the system that was actually designed to be pluggable so that consensus algorithm is an evolving science. There are people that see what they do. They keep working trying to invent new algorithm that will be more efficient and that will be more scalable more resilient to different aspects. And so we actually designed fabric so that we could change the algorithm used without tearing apart the whole system. So we started with a system based on Kafka which is actually an outside library it's not developed within fabric but we actually recently moved to Raft which is crash-fold tolerant but is also decentralized so that different pieces on the network of different participants I should say can participate in the consensus process. And there is actually work underway so for those who are not very familiar with this there's some big categories of consensus algorithm there is what's called crash-fold tolerant and there is what's called Byzantine-fold tolerant. Byzantine-fold tolerant is designed so that you can actually resist to attack by some players a certain amount of participants who are actually compromised and are trying to impact the system negatively. And so we actually have development in that space now as well. So I'm not going to get too more into this serviceability is another aspect so just to give you an idea at the very beginning when we started with fabric if you wanted to change anything you basically had to shut down the whole system change some configuration and restart. Obviously when you have a system in production that's not an acceptable state of affairs so we evolved to a system that are much more dynamic and much more serviceable overall. We also keep making a lot of progress in terms of performance even though it's very performant compared to many other systems out there there are still people there are actually a lot of there's a big community and we regularly have people from the outside who come and made some studies sometimes universities come with report and say hey look you can do this and that and you'll get that much more performance. And so we're always open to trying to make it more performant. Sometimes it's actually changing some components that we're actually using that we didn't develop like the database actually being used underneath ease of use so I'll talk a little bit more about the letters development here which is the embedded gateway but this is the systems initially were very low level so like at the very core what we're storing the data is in the form of key value pairs and so everything that is more complex in structure has to be you know packaged in such a way that it actually fits in a key value pair but you know over time we have been improving the system so that the APIs are much higher level and easier to use for the application developer and then there are different types of extensions being done I'm not going to talk about this now but you know there is a lot going on I want to do a little bit more deep dive in the fabric gateway because that's the letters development so if there's anybody who's involved or has looked into it before want to know kind of what we've been working on essentially in some you know in a fairly recent past we actually updated the API provided by the different SDKs there are different SDKs, different languages and to make them higher level and we ended up with SDKs that were very heavy and that did a lot of things and on the client side which made the client heavy and a lot of network communication going on and so the letters development that is you know already available as a beta and which will be part of the letters version 2.4 by the end of the year is to basically move a lot of that code into the peer itself so that it's much easier for the application it makes the application much lighter there is there a slide on the benefits to the users so from a programming point of view the good thing is the API itself doesn't change it's mostly an implementation detail so application developer that I've been writing on the previous versions won't see much of a difference in terms of you know their programs but the implementation moves a lot of these code that's in the SDK into the peer directly and I have a slide that will show that it actually has many different positive side effects one of which is the whole consensus process requires actually getting your transaction submitted to the network getting enough participants in the network to approve the transaction to say ok I accept this transaction to then be able to submit it for commitment basically writing it onto the ledger so that everybody has agreed and in the version to this date the client basically has to contact the different participants and collect all these endorsements and then you know issue the transaction so with the gateway the peer will actually do all this work for you which means that the application only needs one connection to the peer it ends up talking and it's the peer that will have the connection to the rest of the network which already has anyway so it means that from a system administration point of view it's also much easier I have it in a graphic form which may be a bit more telling and which will give me an opportunity to give you a little bit of insight into the architecture so at the very top we have what we call membership services so we are in a permission network which means we have to control access which is done by controlling identities of the participants and the different components in the network the system is again very plug-able so there is a standard built-in fabric CA which is certificate authority that you can use but you can also reuse a lot of the legacy system most companies don't want to create new ideas so they want to be able to reuse what they already have if you have an SDAP system already running you can reuse all your identities and not create new ones but then the main components are you have the client which through some SDK will talk to the network there are two main components there is the peer which will actually store the copy of the ledger and will run the smart contract which is this piece of application-specific logic that will validate the transaction and then there is what we call the ordering system which is where the consensus takes place among the network to decide the order of the transactions and create the new block that will be written so in the new version we have simplified things so there is actually a swap but that's irrelevant it's just because it shows the flow of the transaction a bit nicer than having lines that go around but you see the new block, the gateway in blue in the middle is an important piece so basically now the client talks to the gateway which is built into the peer and it's that gateway that does all the work with the other piece in the network and the client just submits the transactions and basically it records an event handler associated with the transaction and it will be informed when everything has been done and then it will be completed into the network it will be informed the transaction has been written oops, sorry, let's keep one so now that's a lot of details that honestly most people, application developers don't need really to worry about what's more important for the application developer is those two components that are in green on that slide at the top, so you have the client the part where you have the application where you're going to do something specific and the other side is the smart contract and the smart contract, as I said earlier it basically runs in the peer and this is not actually a very new, novel concept going back to my analogy with databases we have these systems in databases as well so essentially it allows you to specialize the application on the back end this is the back end basically of your application and the client is the front end so when you submit transaction it actually is going to execute some function in the smart contract that will validate specifically for your application that the transaction is valid it will typically check on things like well, do I have all the information that I need to make sense of this transaction so imagine you're in an application we keep track of the ownership of a car well, you need to know if you're transferring the asset from one owner to another well, I need to have the identity of the seller and the identity of the asset that I'm transferring so you will want to check this kind of stuff but you also want to check on the state the logical state of the application as that given time because if I say, oh, I'm transferring this asset from one owner to another well, are they actually the current owner? so that's more like the logical state of the application so all these things are going to be checked in the smart contract so as an application developer that's what you're going to focus on you're going to focus on those two aspects the smart contract and the client the client issues the transactions and the smart contract validate those transactions then of course the smart contract is not run only by you it's actually something that will be installed on the network by the different participants that will take part into the consensus process the validation of all the transactions something that's shared among the participants and the peer itself will actually have locally two versions of the data there is the actual blockchain which you can see there on the right but it also uses what we call the world state which is basically the instant representation of the blockchain because it's a bit like the balance on your bank statement you can recalculate the balance anytime by taking all the transactions from the very beginning but it wouldn't be very practical to recalculate everything every time from day one so you also maintain the current state of your balance more really so the world state is basically contains that from a smart contract point of view all you have to do is get and put and delete kind of things and yes there's a delete I said it's immutable it doesn't mean that you cannot delete and change information what it means is that every time you make this kind of modification they will actually in turn generate more transaction just like with your bank account if there is a bad transaction you can reverse transaction they don't go and remove the previous transaction they just reverse it by creating a new transaction that reverses the transaction it's exactly the same here so it's immutable doesn't mean you cannot change anything it just means the ledger itself cannot be changed so let me move on because I also want to highlight a few other aspects Hyperledger as I said is a consortium there are many different projects going on and Hyperledger Fabric to be fair is only one of six different ledgers today but it's the most popular one and it's definitely the most commonly used in the IT industry but outside of the Hyperledger Fabric project itself there is a whole bunch of labs labs is something we created a few years ago to allow the community to experiment with different developments and there are actually many different labs so they're not officially endorsed by the Hyperledger project yet but there are potential future projects or pieces of some of this might actually eventually migrate to Hyperledger Fabric itself but I wanted to point out there's a lot of activity going on in that space so we have an operation console that actually provides a user interface to more easily manage the network it's actually been contributed by IBM recently and it's actually what the IBM Blockchain platform offering is based on so it's actually been in production for several years we have other aspects Fabric smart client I'm not going to get into the details of all of that the token SDK is of interest to a lot of people we don't have built-in support for digital assets in Fabric but it's actually possible to have tokens I mean people often say oh why isn't there built-in support so we actually look into the samples in Fabric you'll see we have actually provided several samples that implement different standards tokens like ERC20 so it's definitely possible but you can do more and so the Fabric token SDK which is in the labs right now is one of those it actually shows how you can do more we also have different projects going on I should say Hyperledger Weaver is actually a lab and Cactus is a project it's a bit subtle the difference but I'm not going to get into this now but what's important is this is a hot topic in my opinion right now and this is where a lot of the focus is going to be because for several years we have had different blockchain technologies being developed and there are different permission networks that are being developed independently and then the next thing people want to do is actually join them because for instance you have one network where you track asset ownership and on another you do payments and guess what you want to sell a car and you want to pay so you want to pay on one end and exchange the asset on another and in fact you want to make sure those two things happen at the same time so that if I'm buying a car either the payment happens and I get the car or nothing happens but you don't want one or the other to happen not the other so there's a need for interoperability between the different networks and there are different technologies Fabric is only one of them as I said there are many others and so there are several efforts now going on to try to bridge those gaps between the networks so you can actually have like atomic transactions across different networks and the difficulty is to do that without adding centralization because it's very easy to make a central gateway gateway that actually is the central point but that defeats the purpose I did mention BRBFT you may have seen that earlier when I was talking about consensus and the evolution it's actually been developed by some of my colleagues who are experts in cryptography and consensus algorithm in Zurich lab at IBM and it's a much more efficient type of Byzantine fault-tolerant algorithm that has ever existed until now and so there's a lab that actually provides an implementation that would then be leveraged by a hyperledger Fabric but it can be used outside of Fabric as well I'll leave it at that if you are interested just keep an eye there are many of those going on I just wanted to finish give you a couple of pointers if you are interested in playing with it I can give you two and three key points the first one is well we have an extensive documentation and there is a whole set of samples we actually just last year did a complete revamp of the samples because initially they were kind of developed organically and it was a bit all over the map and so we actually had a very thorough look at the samples and eliminated some and created new ones so that actually provides a whole progression showing all the different main features of Fabric so that you can actually see how to use them what they are good for and the documentation keeps being expanded the latest addition which is significant is a whole chapter on how to deploy a production network because a lot of the documentation is often like this in open source it's very developer oriented but then it's good enough to get started but it doesn't take you to the last mile of going to production and the last piece is the Visual Studio Code extension it's developed by IBM but it's freely available and it's a great way to get started it provides you with a complete framework where you can even create so you can develop your smart contracts and your application with this extension it will actually even run a local network in your system so you can actually test, exercise the smart contract and the client and you can even debug your smart client which is a great feature so I provided the information there and the slides I have updated uploaded the slides so you can find them so with that I'm just on time so I'm going to stop here I don't know if we have time there's coffee break now maybe there's time if anybody has a question otherwise I'm around all day yes the latest is actually pretty good yeah everybody heard is asking about which branch to start from if you want if you go to production it's always better to go with the LTS but if you're just starting to develop you might as well use the latest branch and use the new gateway and so the change for those who may have done this before the change from the old gateway to the new one is basically just the package names are different but essentially the rest is almost the same so there is very little impact on your program alright well, yep so I'm biased but you know I'm part of IBM and so there is actually extensive documentation also on the IBM site and we actually have higher level use cases that are you know being developed they're available where you can actually go through this you can find the one that's closest to your use case and start from there and typically it will be a bit easier yes Daniella so for those who are online and may not have heard what Daniella was saying there are six special interest groups in Hyperledger and several of them actually focus on different aspects different use cases and get into developing reference architecture and things like this on how to use the fabric to implement their or address their problem their use case alright I'll respect everybody's time I'm going to leave it at that but again I'm happy to stay around and talk to people so thank you very much