 Okay, Nikolai. Nikolai is going to present Hyperledger Fabric. Thank you. Thank you very much for introduction. So my name is Nikolai. I work for IBM in the blockchain garage here in Singapore. And the topic is Hyperledger Fabric version 1, which is the new version that is coming very, very, very soon. So before going... Before going to version 1, just a quick recap. Why we decided that we are ready to move to the next version. So what we've learned from version 06, there are a number of limitations and that's the current architecture of version 06. As you can see, there is an SDK that implements the client. There is a membership service, which is a kind of centralized service and there is a peer in the network which is doing lots of stuff. You see it's quite busy. So the centralization of membership service is one week thing and then this peer is doing too many things at the same time. It's the throughput, I mean, the number of transactions that we can perform is quite limited. Now the other limitations that we found and we took into consideration for version 1, it's the privacy of transactions. Here, for example, there is a network of car manufacturers and lease companies. Car manufacturers are blue, lease companies are yellow and there is a regulator in the center. So they want to perform a transaction and say there is a Nissan who wants to sell the car to Laze Plus with 5% discount. In the current implementation, if all of them will be in version 06, this transaction will be visible to all of the data peers running on all the data centers of all these companies. But definitely we don't want to be possible. We don't want everybody to see what exactly was the discount that Nissan gives to Laze Plus. Then the world state. The world state in the current version 06 is a key value store implemented on top of ROG's DB and it is quite restrictive as you can imagine in terms of queries that you can perform since the key value store. We wanted to basically have a plug-able key value store, a plug-able storage and we want to perform an SQL like queries in order to do a more interesting analysis of the data. So this is the list of all things that we want to do. Reflect how the business is working in terms of transaction endorsement policies and making sure that the transaction goes only through the parties as supposed to know that this transaction is happening and the details of this transaction. Scaling is another problem. Right now it was limited because of the way how the consensus algorithm was implemented. Eliminate the non-deterministic transactions where the world state basically goes out of sync on some of the peers. Sometimes it happens in the current version 06. Enable a plug-able data store and be able to upgrade the fabric and chain codes because right now if you ever worked with 06 it's a huge headache if you want to update the chain code in the network production mode. Finally, remove the single point of failure which everybody is pointing to and that's membership service. So the roadmap. So we are here in March and this is the month where version 1.0 is supposed to be released at the end of this month actually. There's going to be a huge conference in Las Vegas next week held by IBM and we expect to have a number of announcements made there. Let's go into the architecture overview for version 1. Now as you can see, architecture has changed. We have much more boxes here. The application as the case stays where it was and performs the same thing. The business logic for the application and the keys, okay, wallets with the private certificates of the users. The membership service becomes also either plugable and we can have a number of membership services now so we remove the single point of failure. The peer can perform two different roles. It can be an endorser or a committer. Committer peer just commits the transaction. Endorser peer performs transaction validation and we will look into this on the next couple of slides and see what exactly happened. But we actually decoupled this from the peer so they can perform different roles and that's how we can scale. Another thing that we did in order to be able to perform transactions in parallel we introduced this ordering service over here. So ordering service does only one thing. It takes all the transactions from the network, orders them and then creates a block for that. So that makes it possible to do a transaction validation in parallel on different peers and then they all send those transactions to ordering service in order to create a block. And this ordering service can be decentralized so there can be a number of servers performing this particular role and they all will be choosing the leader every time they need to create a new block. Okay, so I will be skipping some of the slides because I have way too many of them as usual with IBM. So let's have a look at how transactions happen in the new version. First, we have a client which is like outside of the network itself and then we've got two types of the peers like the bluish kind of E peer is the endorsement peer and the gray peer is we call it either like a B peer or a commuter peer. And we've got the ordering service which is also represented like a network in the architecture. So first thing that client does it sends the transaction proposal to either the nearest peers or the peer that he likes. The proposal includes the usual thing like the function of the chain code that I wanted to trigger as well as the input parameters. So I send in that and the endorsement peer executes this transaction, creates the output and then signs it and sends back to the client. Then client takes this thing along with the transaction proposal and according to the policy which is another new thing that we have in the new architecture it sends this transaction proposal and the signature to other endorsement peers. So the policy is basically a configuration it's like a business rule. It defines that we need to get an agreement from this, this and this peer in order to perform a transaction or it can be like one big peer or somebody like a regulator, somebody very important that needs to approve the transaction. So it's more like a business rule that defines who needs to approve the transaction before we define that it's valid. So client sends this transaction endorsement to other peers that's supposed to approve it. They execute this transaction, they repeat that the output is correct and then send back their transaction valid signatures. After that client takes this transaction and sends to the ordering service and then ordering service creates a block along with all the other transaction that it received during this particular time period and then sends it, replicates to all the peers that's supposed to get it. As you can see the architecture becomes very decentralized and finally of course they validate and then commit that into their world state and create a new block in the blockchain. So as you can see the architecture is very decentralized now. We can have a number of different endorsement peers a number of commuter peers, ordering service, etc. and it allows us to perform a number of transactions in parallel which is quite nice. We can also move lots of logic to the client itself. It doesn't mean that the client has to do all of this. It's good if it will do that but again with the configuration we can say is it going to be the client or the nearest peer who does all of this dense with transaction approval process according to the policy. The endorsement policies are actually connected to the chain code so when you deploy the chain code the endorsement policy is something that goes along with the deployment itself. This is just the example. As you can see the endorsement policies basically look like a business rule. We have the endorsement set like that's everybody in the network in this particular channel. I will talk about the channels on the next slide. Then we are saying that the new car transaction needs to be validated by the DVLA which in our case is a regulator and a Nissan as a manufacturer so only they can validate or we need to get the signature from both of them in order to create a new digital representation of a car in a world state. Similar example with the change ownership transaction that it needs to be moved from the car manufacturer to the lease company as well as needs to be approved by the regulator so all of them needs to agree first and that's what we define in the policy. There can be and or statements as well so that allows to create quite complicated rules and policies. Another important thing that we are going to have in new version is channels. You may think of a channel as a blockchain so right now in version 06 we've got only one blockchain or ARCA one channel. With the new version we can run parallel channels on the same network. Some of the peers can perform transactions on two or more channels some of them can perform transactions on one channel etc. So here in this example E1 is on two channels at the same time red and blue and E0 and E1 is only on channel red that means that E1 will never get any transaction from the blue channel and that's how we can establish this privacy of transactions so the peers that are not supposed to get a transaction will never get it because they are not part of the channel at all. Order in service as I mentioned already it just performs the ordering of transactions it doesn't look into transactions that don't need to execute the transaction it just takes it and then orders in the block because the order is important since we are creating a hash for every block. There is a number of consensus algorithms that we use in the ordering service itself because it in itself creates a small network the first two are going to come with the first release Solo is for development purposes just one order in server Kafka, the Zookeeper is going to be another one that basically it allows to tolerate just the crash faults or bideen faults and it's going to be part of the first release and maybe to tolerate bideen faults it's going to come later maybe like one point something version it's currently under development okay so in the new version we can create the same architecture as we used to use in version 06 so this is an example just one channel everybody, all the peers are executing the same chain codes so exactly the same kind of behavior that we are getting here on this kind of architecture ordering service in the center, etc in a multi-channel network the picture will be a bit different so we've got endorsement peers 0 and 3 on the red channel and 2 and 1 on the blue channel and they will never intersect but then at the same time they can use the same ordering service and as long as this ordering service doesn't see the transaction itself it doesn't compromise the privacy which is quite good so we can reuse the same service for different channels without compromising the privacy which I believe is just great Plugable wall state we've got, remember I mentioned that currently we use ROXDB with the new version out of the box so we will get a level DB again it's a key value store but then there will be an option to switch to the CouchDB which is a no-SQL database based on the JSON documents that actually brings us lots of options to create complicated queries rather than right now we are limited to either using a key or using a composite keys kind of thing so imagine everything that comes to the data analysis and all this crazy stuff that our business people want to do with the data and last but not least is the Fabric Composer it's the kind of third version right now it's not necessarily going to be it's not part of the 1.0 the current version works with 0.6 but that's the kind of thing that a new tool that IBM contributes into the Hyperledger project and it's meant to be it's meant to simplify the development of the blockchain applications because right now you need to do a number of things you need to create a chain code you need to deploy it you need to then create a client-side application with either Node.js or some other programming language so lots of manuals tabs and you need to keep everything in sync in terms of which functions you implement on which side and how do they interact with each other with the Composer we are supposed to get a number of tools that help us to develop things much faster it's coming starting from the common-line utilities the simple business-oriented language to design the data model and the transactions web-based playground and web-based user interface let me show you a couple of examples that's the development playground and this specific screen shows you the example of the what is this the asset creation this tool is oriented on automating business processes mostly so there are a number of concepts that are built into this business language that they use to create the participants of the network first we define them as objects and it's a swagger-like language scripting language then the assets that we're going to put into the world state also you can see quite simple just the type of the property and we can mark some of them optional, etc and then the transactions which are basically the definition of operations that we can do on our data model and then finally we can implement those transactions using the processors and in JavaScript because right now as you probably remember we can create chain code in Go language and this is an option for develop the chain code in JavaScript which is also quite cool because it's one of the most popular languages at the moment ok so once we do all of this ok, the process the development cycle would look like this we install the tool we define the business network assets and transactions using this swagger-like language then we implement the transaction processes so basically the business logic within the transaction then we generate the application and deploy it to the server and then after that we basically can generate the REST APIs using the loopback connector and as well as Yeoman Generator can generate us some simple Angular 2 code application and we are good to there can be a good point to start link is down here, it's all open source just go download, learning it's currently an early stage of course but that's definitely something that is going to evolve quite fast, it gets lots of traction at the moment so with this, thank you very much and I open for Q&A about 5 minutes for Q&A if anyone has any questions Justin so for the client the client APIs it's going to do the controlling of communication between the endorser to the to the orderer so there are the two options the client SDK can perform all of this dance with transaction endorsement and collecting the process itself or it can move this logic to the peer so it just endorses the transaction and then peer will do all of these approval processes for it, there will be two options to do that configuration it will be configuration for the channel and then for the yeah, please go ahead for the channels you say you have multiple channels right now so from a channel perspective where do you create the channels can you create it dynamically or to pre-define the channels upon creation of the chain channel is a chain and you you don't need to create it with the whole network like right now with the peers you have to pre-define the peers in the very beginning but in that sense you can create them dynamically on the way and there will be yeah, if you want to isolate all the transactions that will be performed and and put number of smart contracts into this channel so that's the thing that you can do dynamically great, time for two more questions you mentioned that the policy can be pre-defined in the beginning you define it for the chain code when you infiltrate the chain code can the policy be changed later or can it be defined for a specific contract I want to use this policy and for another contract is it possible? policies will be contract specific so when you deploy the contract you define the policy for it and then if you need to update it you will need to redeploy the contract the contract redeployment will be a supported feature I mean it's going to be a feature in version one in version one on which blockchain network is it working? it's Hyperlegifabric it's the blockchain network by itself it's the implementation of the blockchain no I mean the network can define how they want to operate do they want to have pros and fias and that's the difference with the other networks you probably can think of like Bitcoin or Ethereum where you already restricted with something I mean there are pros and cons for all but here the idea is that it's a private network where you control the access who can do what what kind of transactions people can perform and so you don't need you can relax a little bit the consensus requirements you don't need proof of work you can use PBFT which is a kind of relaxed version of consensus and you don't need the things like paying for transactions in order to stop people from performing too many transactions at the same time you can do it in different ways because you have access control and you basically control access to the network and to the transactions they can perform great if anyone has any other questions you can perhaps step outside and continue the conversation otherwise thank you very much