 Hi, good morning, everyone. Good morning, good afternoon, and good evening to all the participants in the session wherever you are, from wherever you have logged in. We are going to talk about applying low-code development to chain code to expedite the blockchain adoption. And at the end of the session, we're also going to give you a brief overview and a demo of the blockchain app builder. Why we need a low-code development solution? Now, low-code development solution is increasingly a proven approach for improving productivity. If you think about the low-code development where we all need to enable the developers to have a low-code development environment, it reduces the time to market, it enables the composable business strategies, and it enables the self-service applications and democratization. Overall, it scaled the business automation. We all need to have a low-code development solution. Why do we need for a low-code solution with Hyperledge Fabric? In Hyperledge Fabric, we lack of skilled chain code developers and for the lack of skilled chain code developers, we need a low-code development environment. The lack of template, the lack of building blocks for the common use cases are the enforcing reason to have the low-code solution. Overall, the complex infrastructure requirement also requires to have a low-code environment for the developers. In the blockchain, we are addressing all these challenges through the blockchain app builder for Oracle Blockchain Platform. In the blockchain app builder comes up with these six specific steps. The first step is to specify the details in a specification file. The specification file is used to scaffold the project to generate the code. Once the code is generated, we can add the custom methods on top of it. And once the custom methods are added, we can deploy the chain code locally, or we can deploy it on the Oracle Blockchain Platform Cloud Services. We can also do the testing and debugging of the smart contract very easily. We can also package and deploy the smart contract on the OPP itself. The blockchain app builder user interfaces look like this, where it is easy to use, it's intuitive GUI delivered as the Visual Studio Code. So we have... Okay, all right. So I'll continue actually, it seems Gaurav had some technical issue on this side as well. So as Gaurav was talking about that the blockchain app builder is used to generate the chain code and make it much easier to develop the chain code and entry to blockchain, establishing a blockchain application and blockchain network. The one thing that we are, that the Hypervisor Fabric lacks and there are a number of applications that are coming up on the blockchain network for the tokenization of application. There are a number of applications out there like loyalty programs and loyalty tracking and part and document tracking, et cetera, which can make use of tokenization. Hypervisor Fabric infrastructure itself does not provide any support for token, it does not have any built-in one, but a number of applications have been developed that make use of tokens and those develop, those applications generally emulate this ARC20 for fungible tokens and ARC721 for non-fungible tokens. But there are no common building blocks and some common building blocks are emerging for these kinds of applications out there. So what we are doing here is, yes, and so what we are doing with the blockchain at Builder is we are announcing the availability of tokenization support in the blockchain at Builder as of today. In fact, if you go to the Oracle Blockchain platform and you look under the console, you would see a new release there and this new release of blockchain at Builder supports generation of code and APIs based on token specification. The specification that you use is based on the token taxonomy framework, TDF. We take the concept of definition and templates from TDF and once you specify that in this spec file, you are going to say what kind of token type you need, whether fungible, non-fungible, et cetera, what is the property for this token, what are the behaviors that you want, transferable, vulnerable and whatnot and roles. In the current implementation, we are focusing on the fungible tokens only and very soon, we would be releasing support for non-fungible tokens as well. This is something in the work. Also for fungible tokens, as of now, we are using the account-based model. That's what we have implemented versus UTXO. We believe that account-based model is much more scalable as well as it's easier to program with and once we talk about the account-based model, of course, immediate question might be that, what about MVCC errors that you see? We are also working on a solution for MVCC error to not limit the throughput, make it really scalable. So that we would be talking more about what the solution we are putting together in Hyperledger Fabric itself to avoid those MVCC errors with the account-based model. So what do you do with the spec file? You create a spec file like this, you see on the right-hand side. So basically, token becomes another asset in the spec file for the blockchain app. As Gaurav was talking about, there can be multiple assets in this spec file. So token is another asset. Here you specify what the name of your token, what's the type, whether it's a functional fungible. In this case, a number of behaviors that are specified here, invisible, mintable, transferable, and so on, and then the roles. So...