 Yes, hi. Hello, everyone, and welcome to this session. And I should say to get started, you know what to expect. We are not going to give you a demo. So if you're here for a fabric demo, literally, you're going to be a bit disappointed. What we want to do is give you an update on where we are with fabric, and then, you know, so we can have a Q&A session at the end. So in terms of, you know, the tutorials, on the other hand, it's pretty simple to get started. We put a lot of effort into both the tutorials, which we have now an extensive set of tutorials that take you from the very beginning of how to get started all the way to deploying, you know, a blockchain network in production. And in parallel to that, we have a whole set of samples. The samples went through a major revamping exercise where basically, you know, the way fabric samples came about initially was fairly organic, a bunch of different examples. A lot of them initially were based on some, the developers were writing as they were implementing features that we then turned into samples, and the whole thing didn't make much sense. So what we did is basically, we went through different features and said, okay, we need a sample that, you know, kind of takes through a progressive curve where we can show all the different features that they might want to use. And we wanted to also exhibit this because, you know, prior to that, samples didn't always do the right thing. We found out that, you know, it was misleading people. They were ending up developing the applications following what they saw in samples, and then we had to say, oh, but you shouldn't do that for production. So what we did this time is we tried to really show best practices in the samples, and so you can see some of the examples there. We believe they actually, you know, cover a pretty wide range of type of applications you would typically find on blockchain. And you may actually very well, you know, find a good starting point for your own application. Okay, thanks, Arnaud. So I'm going to segue into some of the other things we've been doing the past year. Talk about some of our releases since the last Global Forum. We've had a new big release earlier last year, version two of Fabric, and we have a version 2.2, which is the long-term support release of the 2.x stream. And there's a lot of new features in 2.x. So first and foremost, we have decentralized governance of smart contracts now. This means you can have policies that dictate which organizations must agree before a smart contract is deployed or updated, or for example, you might change the endorsement policy for a contract. So there's policies around that now. And then you can also use that same kind of architecture, same patterns for your own user chain codes as well. So you can use some of these features in 2.x to come to agreements and approvals in your own chain codes. If you want to implement, you know, business, you know, business, you know, business synchronous business processes in your chain codes, you can do that through these same mechanisms. Also, there's private data enhancements. So a lot of people might know private data collections that came in earlier releases. There's enhancements there so that you can share private data on a need-to-know basis, and you can use hashes to verify that data if you want to share that with other organizations. And then there is collection level endorsement policies that can override the chain code level endorsement policies so that if you want to protect rights to a certain private data collection, you can now do that with the collection level endorsement policies. And then finally, there's an external chain code launcher and builder. This eliminates the Docker and Docker requirements. So your peer does not have to have access to the Docker daemon to spin up a new chain code, which is a really good thing. So some vendors have added other options for building and running chain codes. Okay, and then later in November of 2020, we released a Fabric 2.3. Two major features here. The first one is managing an ordering service without a system channel. This lets you join orderers to a channel similar to how you've always been able to add peers to a channel. And you no longer need the system channel. So there is some level of centralization required there. There was some issues around private frustration where all the orders knew about all the other channels that were being created and so on. Now you can do that with more privacy, more scalability, and you can more easily manage your ordering nodes. And then the second big feature in 2.3 is the ledger snapshot ability. This lets you snapshot peer channels including things like the state database for a channel. And you can use this snapshot in various ways. First of all, you can join new peers to a channel based on the snapshot. That's a lot quicker than having a peer start from the genesis block and process all blocks, if you've got millions of blocks out there. And also, of course, doesn't take up all the storage that millions of blocks would take up if you joined from a later snapshot. And the snapshots can also let you make sure your peers are in a consistent state, both within your own organization and across other organizations. Sometimes you want to make sure that your peers are in a consistent state and you can use these snapshots somewhat as a checkpoint to make sure that everybody's on the same page. Okay, and then the release we're working on this year is a 2.4 release. We released a first version of this as an alpha in April. And the big new feature in the Fabric 2.4 is the Fabric Gateway. The Fabric Gateway is a new component that can run inside the peer. And it's similar to some of the code that was in the SDKs previously. Basically, this is the logic that handles getting endorsements from various peers and then submitting a transaction to the ordering service. All this used to be done on the client side and your application side SDK. But all this logic is now sitting on the peer if you use the Gateway. And this allows a few things. There's now a lot of consistency across the SDKs. There's no longer duplicate code across the SDKs. So the SDKs are not and your applications based on the SDKs can now be more lightweight and more manageable. Since they're working, all they're doing is calling the submit transaction and then all that heavy lifting is done on the peer side. So typically you might call your own peer, your own organizations peer or another trusted peer to do this heavy lifting for you. And then finally, the client only needs a single connection to the blockchain network and maybe that's a load balance connection into your own peers. But your client doesn't have to talk to all the other organization's peers and ordering nodes. So it's a lot easier to manage both on the application side and on the peer node side you don't have to open up all the ports for everybody's applications and things like that. Okay, and then a few other things. This kind of follows on from what you might have heard from the keynote from Karim Yousaf from IBM. But IBM has opened up, has contributed some new labs in the areas of tokens, the smart client for off-chain agreements and exchanges, Weaver for DLT interoperability, Mirb BFT for Byzantine Fault Tolerant Consensus and Fabric Private Chain Code for Secure and Private Execution of Chain Code using technologies such as Intel SGX. And then there was also the announcement this morning about the Fabric Operations Console from IBM's blockchain platform is now open sourced or will now be open sourced coming soon and a support offering around that. So that's the things that we've been working on in the Fabric world and I think at this point we can open it up to other questions. So there's the Q&A tab. I don't know, Arno, are there any questions out there yet? No. Probably people to stop posting questions because there isn't any yet. We have quite a bit of people listening in. I see almost 30 people, so... Hopefully there'll be a few questions among them. We think so. Maybe they were all here to see a demo we are not giving. Well, if we knew they weren't going to ask questions, we might have had time for a demo after all. Don't be shy. Oh, that's nice. It's just hard to digest everything and keep up with the great work you do. Thank you. It is drinking from a fire hose sometimes, yes? What's your view on NFT and Fabric? My view is Fabric has had support for NFTs since the beginning, but they weren't necessarily called NFTs. So you might know it by assets, for example. But when you store an asset on the blockchain, that's no different from an NFT. If you want to talk about the Ethereum ERC721 standard for NFTs, we also can do that in Fabric. We have a sample chain code that shows how to do that. So that's my view. Fabric is entirely compatible with NFTs and have supported it since the very beginning. I don't know, Arno, is that your view as well or do you have a different view? I didn't highlight that, but in the slide that I had at the beginning on samples, there was listed two samples, three that are talking about tokens. We have UTXO account, and we have different types of tokens that we are actually demonstrating. This is just running on basic standard Fabric offering. So there's no bias on NFTs on Fabric at all. So we have more questions in the Q&A tab now. How about official support for ARM systems, especially the Raspberry Pi microcontroller? Right. So I think there's been some discussion on that, on the Fabric mailing list. I think we helped, maybe it was this person, helped get that going in their environment. I think the biggest challenge around all these different environments that we get asked about is supporting that from the CI perspective and all the environments that we have to maintain for that. So that's been a challenge. And so we've typically said, we'll try to make the code not platform-specific so that anybody can support whatever they want. But it's not like we're going to go create Docker images for all these different platforms. And then can you chain code builder again versus execution in Wasm? Okay, so it's really a plug point so that you can execute any type of, you can execute chain code however you like. That could be in a Wasm engine, for example. But it really could be anything. So there's a plug point of what you need to do on a peer to be able to build a chain code that's deployed and then how to run that chain code. And it can run in two modes, kind of a traditional mode or a chain code as a service mode where instead of the chain code connecting to the peer, you can also reverse that and have your chain code running, for example, as a service on the cloud and then have your peers connect into that chain code. So I think that's not exclusive of doing Wasm. Wasm is definitely an option that some people have played with but there's not really official support for Wasm in Fabric at this point. Yeah, and in fact I mean getting the external builder, I mean it actually plays better with the environment like because before the chain code container is not easily recognized by the manager and you have difficulties with this which are avoided when you stop using your chain codes as a service and you have the node connecting to it instead of the other way around. When would it be in Fabric LTS? We don't have that on the road. We did not have it on a road map. Some folks did a technology preview of how that might work. I forget if that was out there on the mailing list but there's been some prototypes of it but no formal intent to put that on the road map at this point. Alright, that's it. Some people are talking in the chat. Others, what about performance? That's a bit of a vague question if I may ask. Can you be a bit more specific, James? Right, there's been some performance studies where people have done written research papers on the different factors around Fabric performance. The Fabric gateway embedded in the peer leads to some performance improvement as well just by the mere fact that some of the transaction processes today requires several trips between the client and the peer which then can be done locally so there should be some performance improvement from that. Although I don't believe there has been any measurements done yet. This is an ongoing working performance. We're always trying to find ways to improve it. To the Q&A tab. Well, it's kind of the same question. Any performance scalability number on the HLF2X? So, what are the numbers to share? No, it was the performance that ended up being about the same on 2X versus 1.4. There were some studies done on that. You know, I guess a ballpark figure people throw out is like 1,000 transactions a second, that type of thing. Maybe less if you're using CouchDB. Couch does have an impact on your performance so if you don't need to use JSON query then you're probably better off sticking with levelDB and you'll get better performance on that. James says he has managed to get about 1,000 transactions per second with levelDB, 800 for CouchDB. Yeah, that's in the ballpark that we tend to hear about. There's a few things, you know, we've gone on the roadmap to help with that a little bit, especially around private data. I know there's some additional constraints on private data that could be opened up a little bit. And then when it comes to performance, there's also a trade-off, right? I mean, so there was the university, was it Waterloo, who did that extensive analysis of fabric and they came to us saying, hey, guys, how about we increase, you know, the speed of fabric by a factor of, you know, 7 or something like, pretty amazing. But they did that to the extent where they were breaking down even further the different... and there was clearly, you know, added complexity and there's a point where you need to be able to say, well, is that really worth it? How far do I want to go? Because, you know, you may gain in performance, but on the other hand, you make things much easier to manage. And so it's not a freebie. Yeah, there's a little bit more low-hanging fruit from what they've identified, that we could do some more refactoring within the peer itself to get a little bit more out of that. But yeah, the way they really got it high was by breaking the peer into multiple components and having it more distributed. And that's something we're not quite ready to tackle that yet. Right. We did get some good input, though. I mean, there was some caching and stuff like that that were added that led to performance improvements. So that was good. Yeah. And time. Time already. We're out of time, but if there's any final questions, we could take them. We've been told that this is the last session of the day, so we can cheat a little bit on the end of the session. If anybody has a burning question, we're happy to stick around a bit. Yeah, as David Boswell is saying, we're not running into anything. I think I've lost my audio again. I cannot still, but I'll try to unplug my USB and plug it back in, but I might be gone. Okay. Dave has had some challenges. The sound was a little bit garbled at times, but for the most part, it worked fine. So hopefully you all found this session useful. Are you back, Dave? Can you hear me? Yeah, that worked. I can hear you again. All right. So I think we can leave it at this for today. Thank you all for joining us. I hope you find it useful. Thanks, Dave. Thanks, everybody. Goodbye. Take care, everyone. Bye-bye.