 Hello everybody. So we're going to do a quick hyper ledger fabric update instead of a actual demo. We didn't think we could do an actual demo in five minutes. So we're going to give a couple updates on what's been going on the past year since the last global forum. Our notes going to kick it off and talk about the new samples and tutorials. Yes. Hi everyone. So welcome. So we actually went through quite a bit of revamping of the tutorials and samples. If you haven't seen this before, even if you haven't looked at it recently, you'll see quite a bit of a change. There was in terms of the tutorials, we have a really complete set now that go from the very beginning on how to get started. And, you know, quite frankly, you can get a test network running in literally like three comments or so. Of course, there are some prerequisites such as having Docker installed curl and things like this, but pretty standard stuff. And then when it comes to the samples, we had a really thorough pass through all the samples. Initially, the samples are kind of grown organically. And we had like a bunch of disparate stamp samples and a lot of them actually came, you know, historical. They initially came from like some tests and things like this. We actually took a very deliberate approach and trying to have a very progressive road towards, you know, taking you through all the different features in I predict your fabric, starting with a very basic examples of asset transfer and then going to a lot of different aspects such as, you know, private data and so on. So I think with what we have now, you should be able to actually take this as a starting point for your application. You should be able to find something that's close enough to get started. And other things we did as part of this effort was to make sure that the samples were actually a good basis for something that could eventually be in production. Initially, there are things we're taking a lot of shortcuts and and obviously showing best practices. So the samples were rewritten within my best practice to get people on the right start so that they wouldn't, you know, open holes, security holes and so on. So with this day, keep them going. Okay, sure. So I'll give a quick update on what we've been doing in the project the past year in addition to the samples and tutorials. We released a fabric 2.2 in July of 2020 last year. This is actually the long term support release that most production customers are on currently. Most users are moving up from 1.4 to 2.2 these days and 2.2 provides a lot of good things. First and foremost, the decentralized governance for smart contracts. This allows you to set up policies for which organizations need to agree on a smart contract deployment or update. And you can use those same types of patterns in your own chain codes, your own smart contracts for setting up, you know, agreements and approvals and that type of thing using some of those same patterns in your own use cases. There's also private data enhancements in 2x. For example, you can share and verify private data on a need to know basis. There are collection level endorsement policies that lets you restrict which organizations right to a certain private data collection in addition to the chain code level endorsement policies that you might know. And there's also new support for external chain code launcher so that you can build and run chain code in the technology of your choice. You don't have to use Docker. This eliminates the Docker and Docker requirements that a lot of people do not like. So that's the long term support release that's out there now. More recently, we've been doing some other releases 2.3 came out in November 2020. It has two major things in it. You can manage an ordering service without a system channel. So this allows more decentralized nature of the ordering service. You can now join ordering nodes to a channel similar to how you've always joined peer nodes to a channel. It has improved privacy, scalability, administration and so on. And then ledger snapshots allow you to take a snapshot of a channel, including all the state of that channel. And you can join new peers from that snapshot. So this is going to be much quicker than, for example, joining a new peer from the Genesis block so it doesn't have to process, you know, millions of blocks that came before. And you don't have to store those millions of blocks that came before either if you don't want to. And you can also use the snapshots to ensure peers have a consistent state, you know, within an organization or across organizations. And you can come to agreement on the snapshots and state and essentially use that as a checkpoint for your consortium. And then more recently in fabric 2.4, this is the release we're currently working on. We put out an alpha of this in April of this year. And we'll be, you know, taking this to a real release later this year. But basically this release has the new fabric gateway component in it. The fabric gateway runs in the peer and it basically does all the heavy lifting that the client SDKs used to do in terms of getting endorsements for you for your application and submitting a transaction to the ordering service. So it's a very similar programming model to what you might have known previously with the submit transaction function call, for example, that did all of this for you under the covers, except that logic has now moved from the SDK side to the peer side. And it makes the SDKs this much more lightweight and consistent across the different language SDKs. So this will be coming with a new set of lightweight SDKs for go and for Java and for node. I think at this point, though, we'll open it up to any questions that people might have about fabric. So this is an ask me anything style. So go ahead and ask anything. So hold on. So there was a question. Would we share the slides? So I'd actually think everything is shared in the end, but we can also provide a link and make. I think I can attach them today and people can see them. So that if people want to look into the chat, you'll find the link to the documentation and all the tutorials, you know, can be found there. And from there, you'll be able to find the repose and how to get started downloading all the images and finding the samples, etc. So we have more questions coming in. So can you share, can you please share more insights of including the gateway in the peer? But it means that it will work implications. So people may be familiar with the gateway actually, right? Because this is a concept that was brought into the SDK to provide a higher level API than was initially available in the original SDK. And now we are moving into the peer, which I honestly find that interesting in the sense that it kind of gets us back to the original model. We had with the fabric, you know, zero six version where the peer actually provides a much higher level API for the client. There are actually some advantages to this. The fact that, you know, the SDKs can share a lot of the code that's now in that's actually in common where they do a lot of the same operations today. We had different SDKs. There's a lot of, you know, technical depth involved in maintaining all these different SDKs in different languages that essentially do a lot of the same thing. And here we can have a much thinner SDK, which makes the application lighter. And there are some operations can be actually optimized in the peer because before it would require civil roundtree between the client and the peer. And now this can be done locally. So they're actually better performances as well. And from a maintenance point of view or network management, you only need a network connection between the client and the peer you happen to talk to, as opposed to in the, you know, without the gateway in the peer, you would have to connect to multiple nodes to get all the endorsements, collect the endorsements and then connect to the ordering service. So it also makes the maintenance much easier. But Dave, you want to add something? I think that was a good summary. You want to see if there's other questions there? Oh yeah, there's plenty of questions. So we're not going to be out of here soon. Any major changes planned for future versions? I'll let you take that one. So no major changes, as you can see with some of the features that we've been adding, they're more additive. So no fundamental changes to the architecture or programming model, that type of thing. Some of the things we are looking at next is other private data enhancements to make it more suitable for GDPR type scenarios. We're going to do, like I mentioned, the peer snapshot for the channels. We're going to take that to the next step, which would be ability to archive old blocks, that type of thing. So we're just adding bells and whistles to make operating fabric easier, but not really changing the base architecture. So the base architecture is pretty mature and we're pretty happy with it. So no major changes in that area. No, and I think looking beyond. So with the snapshot, we'll be able to do pruning. That's something that we're talking about, but there is other things like we were talking about. I just lost my thought. Sorry, I was checking the Q&A at the same time. Never mind. I'll get back to it later if I remember. So there is a next question, which is private data collections. Do you know of what is the practical maximum number of private data collections in the production network? Right. So there's, in theory, no bounds on that. The private data collections end up being stored in the database, either level DB or couch DB, and they're pretty lightweight structures. So there's not a real limitation there. But I would say it's more of a limitation in terms of how you manage your private data collection. So that can be a little bit difficult. So as you add private data collections, kind of what I would call the old static, statically defined private data collections, you'd have to define those for each set of organizations that want a private data collection. And that can be a maintenance hassle rather than an architectural hassle or problem. And so one thing we ask people to take a look at is the new implicit collections that came out in Fabric Version 2. The implicit collections are basically, there's a pre-existing collection per organization. And so each organization has a place to store their own private data. And if you want to store a piece of private data between two organizations, you can basically just store it in each of their implicit collections. This also allows the patterns I talked about in terms of sharing private data. You might have a piece of private data that you've got. You can then share that with another organization on a need-to-know basis. And basically it would get saved in their implicit private data collection. So that's the way to get around some of these hassles around maintenance of the private data collections. So when you were talking, I remember the other piece I wanted to mention was MIRBFT. So a lot of people want to have the FD support in Fabric. So there was actually a recent contribution by IBM called MIRBFT. It's in the form of a Hyperledger Lab today. But it's actually usable in the form of a library that's meant to be usable by other networks as well. But so the plan is that eventually we will have a support for this in Fabric. And we don't have a firm roadmap for this or timeframe. But that's the kind of things you can expect moving forward. That's one of the things incubating. I just thought I'd share the slide and we won't necessarily talk to it unless people have questions. But these are some of the things we're incubating in the Hyperledger Labs. So there was a question about administrative capabilities in the Node SDK. Are they going to come back? I have to admit I don't know that. So administrative capabilities, things like deploying a chain code. Right. So those were intentionally moved out of the SDK so that the SDK could focus on applications. It's a very different role doing this administration versus a regular application that just interacts with Fabric. And so we don't see those coming back into the SDK, what I would call the SDK proper. There might be other SDKs that do those types of things. But for now, you know, we have the CLI tools to do some of those types of utility things. We also have a, in Go, if you use in Go, we have a config library that lets you create applications. Basically, you can create your own SDK for doing these types of things. All right. We're officially out of time, but you know, I invite everybody to follow up and join the mailing list. We have a very active Fabric mailing list where you're welcome to join and contribute and ask questions. And we also have a civil rocket chat channels. It's chat.iperleger.org where you can ask questions. So sorry for those who ask questions we didn't get to. But thank you all for joining today. Thank you Dave for waking up in the middle of the night. Thanks everybody. Goodbye. Bye.