 Welcome everybody, this is the session to show how to make fabric even faster, I mean, even easier to use, because fabric is already very easy to use, right? Okay. So we're going to look at a demo of FarFly component. It's part of the FarFly ecosystem. It's a component called FabConnect. I don't have any slides, but I do have two architecture charts to show, and then we'll look at a demo of FabConnect. First off, who knows FarFly or has been using FarFly? Yes. Okay. A few hands. Nico here, if you don't know him already, he's our community lead and lead developer on FarFly. So after the session, if you have any questions about FarFly, make sure to seek him out. That's right, unless it's about FabConnect. So FarFly is a collection of many components working together to make blockchain much easier to use. That's basically what FarFly is. Supports many protocols, both permissioned, also public. So in fact, I'm not going to steal Nico's thunder. He has a session on FarFly dedicated to FarFly at 430 along with Steve, our CEO of Kaleido. But I'm very happy to tell you guys that the 1.1 version just got released 15 minutes ago or something like that. So it's a major milestone for us. You will hear more about it in his session. I'm Jim Zhang, one of the co-founders of Kaleido. So FarFly is, as you can see, a core component FarFly is the central microservice that coordinates all the things that happen around the other components. On the very bottom are the ledgers. You can see there are flavors of public chains like Ethereum. We actually support as of 1.1 of FarFly, all different flavors of EVMs on different public chains are all supported. You can go to Ethereum, Polygon, Arbitrum, Optimism, even Polkadot, Moonbeam, for example. There's a whole range of them. Wherever EVM and standard JSON RPC are supported, you can use FarFly to connect to them and manage your tokens, manage your digital assets, and then on the permission side, Fabric, Quorum Besu are all supported, and there's partial support for Quorta as well. So on the very bottom are the Perl calls, and IPFS is also useful for file sharing. Then on top of that are the connectors. This is where FabConnect belongs to. So the connectors will do protocol translation so that the high-level FarFly API requests will be translated into native JSON RPC or GRPC requests, and events will flow in the other direction. Then on top of that, you have the Transaction Manager. This is not very applicable to Fabric, because Fabric is very efficient. You're throwing a transaction, it'll be there in one way or another, either successful or failed, but it'll be there. But that's not the case with Ethereum, especially if you are talking to a public chain. If you've all attempted to work with Ethereum, especially in the public chain, you will know there are many hundred ways to fail for your transaction to not end up in the block, even both before it gets accepted by the note or even after it gets accepted by the note. So we have a Transaction Manager that manage all kinds of errors that the server gives you, and try to compensate to make your transaction have a much higher chance of getting onto a block. On top of that, we have the Token Connectors that understands Token Standard based on the underlying protocol. So we have built-in support for ERC-20, 721, which is for fungible token, non-fungible token, as well as ERC-1155, which is a combination of fungible and non-fungible. At all these layers, each layer is pluggable. So if you have other protocols, if you have other token standards, you can plug those in as well. At the very top is the brain that orchestrate everything. So each of these boxes is a standalone microservice that work together. So that's a very quick overview of Farfly. I can't do it just enough justice, but that's not the focus of today. Today's focus is on this component called FEP Connect, which connects Farfly to a fabric network. It supports fabric CA and fabric order and peer nodes. What it does is it gives you a RESTful interface. So you can post JSON payload to it at various endpoints. So you can create identities with the fabric CA, enroll them, and then submit transactions to it. You don't have to worry about lining up the transaction parameters. You can use a strong typed JSON structure to send to your transaction endpoints, and then you can create subscriptions for events. So when certain types of events are happening on the peer, you get notified either through WebSocket connections or through a WebHook endpoint that you implement yourself. Transaction submission are supported both in sync and async mode. Sync mode means your request is blocked until the transaction gets mined into a block and it returns at that point. Async mode, you just send it in and forget about it. You have a receipt endpoint to query for the status of that transaction, whether it succeeded or not. So that's the high-level overview, and we're going to spend most of the time of the session looking at FabConnect in action. I could be doing this in my local environment, so you can use Nico's fantastic tool to bring down all the images that you need to build a local far-flying environment, including the underlying ledger. So we will stand up a Ethereum blockchain locally or a fabric blockchain locally. When we do fabric, we will give you order and peer, create a channel, deploy some chain code for you. So I could do all that in that way, but that will be all mostly commit line, which could be a little boring, especially after lunch. So instead, let's look at this graphical experience with Kaleido. Kaleido is a commercial platform that allows you to manage blockchains. So we support all the major flavors of enterprise, DLT protocols, Corum on the Ethereum side, Corum Hyperledger Bessu, Go Ethereum, Hyperledger Fabric, and Corda. Recently, we just added Polygon Edge, which is a new entry in the permissioned blockchain side. You can easily create a blockchain network on Kaleido, just add your own node. For example, in this fabric environment, I have two organizations, each one have their own order node and their own peer node, and each have their own CA. To add a new node, you can just add an order node and then give it a name, and then you can click Go. In about 10 seconds, 15 seconds, sometimes 30 seconds, you have your node running in the started state. So we don't have to do that. We already have this network up and running. So let's deploy some chain code. I've already got some chain code compiled locally. So what I can do is let's see. So let's create a new chain code, let's say it can be Golang or Node.js. So we'll pick Golang. So now let's upload a new version. So on my laptop, I already got a bunch of chain code, each slightly different version. So I'm gonna just pick a random version, and then for this implementation, we don't need chain code to be initialized. So leave that check box unchecked. So now this has been uploaded to Clido. We can now promote it to the fabric environment we have. So the target, because within each consortium, you can have many, many blockchain instances. So this step is to say, push the chain code that I just uploaded to my network, to my consortium, to this particular blockchain network. So now, so the nodes on this network have received it. So next step is to deploy it to a channel. So all fabric networks created on Clido have a default channel. This way, you add your nodes and you already have a channel ready to go. You don't have to worry about defining channels, think about the different channel policies or that. This is a very quick way to get started. Of course, if you wanna create your own channel with your own policy, you can do that with both the UI and the API. We'll just go with the default and you can see this is gonna be installed on the various peers in the channel and it'll be approved for the org and then committed. Because this channel only has two memberships, these two memberships don't have any approval, but it's ready to go because all the memberships in this channel have approved it and have it committed. So this chain code, as far as the demo is concerned, is ready to be invoked. Now, finally, we're getting to FabConnect. So FabConnect is a one-to-one binding to a target order and a target peer. So we have our peer one. So if you go to the REST API gateway, this is a fancy term we give of FabConnect on Kaleido, but this is essentially all the endpoints you get when you fire up a FabConnect. So under the cover, what the platform have done is in order to launch a FabConnect instance, you need to give it two configuration files. One is a simple configuration that tells it a few high-level parameters, but importantly, it tells it where to look for the CCP, the common connection profile that tells the node, because under the cover, it uses fiber SDK, so it needs to use the profile to know how to talk to the endpoints. So these are the REST endpoint that FabConnect supports. For example, let's try to see what identities we have already created. Before the demo, I created a user, user one as a signing identity. Let's go ahead and create a new one. So we will just do a post and we call it user two. We don't need any of these others. You get the secret, so go ahead and copy. So now you can do a post. So now this user will be rolled, so it's got an enrollment certificate, and we're ready to use that to send in some transactions. So as I mentioned, if you do sync equals to true, then this will log until the response is back. So we can use the signer as user two. The channel is default, function is this is a create asset demo. And it is false, so it says, we must have misspelled it. What was the name? Of course, this has never happened, right? Until you do a live demo. The time is up, but if you try this yourself, you can create a free account on Clido. So we have perpetual free tier, quit in the account and just try this yourself. We have a demo video on Clido channel in YouTube. Just follow along, try yourself. The demo also shows you how to do event subscription. We do a chat with any of you guys, and thanks for coming. Correct, yeah. Nico, do you want to take this one? So the question is, is there a place to compare the features between open source version of Farfly versus enterprise version? I know it's in your head, but yes, sir. The question is, can Farfly connect to permissioned and permissioned list blockchains? Yes, so the answer is yes. The same Farfly instance can be connected to multiple blockchains. In fact, if you go to Nico's demo, it's at 430, he will show a demo where a Farfly instance is configured to connect to a chain running on Clido, I believe. Okay, a permissioned chain somewhere running, and to Polygon, which is a public chain. The isolation is by namespace, and namespace is top level construct on Farfly. You can say this namespace is dedicated to this blockchain. It can be permissioned or permissionless. The next namespace is dedicated to another blockchain. So fabric 2.4.3 is what you get on Clido. Farfly itself has been tested with 2.3 and 2.4. Yes, sir, I'm being kicked out. So happy to be around in the hallway, and we can chat more.