 Okay, we are live. We'll just start, David. Oh, yeah, I can't, sorry, Igor. I thought you were gonna kick it off and I'd say a few words. Thank you for organizing this event Igor. And thank you to everybody for joining. These meetups are intended as a way for you to learn more about what's going on in the hyperledged community and to ask questions and then make connections with other people. And hopefully, you know, you'll find out something that's interesting for you. And as an open source project, if you do see anything that's interesting, you can get involved. You know, this meetup is just one event, but we have a lot going on in the hyperledged community. There are other calls, you know, other ways for you to engage. So if you are interested in what you hear, we would love for you to, you know, get involved in the community. So I can drop a couple of links to where you may go if you are interested in learning more. But with that, I'd like to hand it off to Igor to announce the speakers and we'll listen to what they have to share. Yeah. Hello, everyone. I would like to introduce Danny and Yov from IBM Research. Now we'll talk about hyperledged Orion, which is, which is the Orion is a standard database with the blocking properties that provides the temper evidence, provenance, data, lineage, autistic, city, non-reprediction and multi-seq capabilities with standard data model and transactional API. So Danny and who is a manager of the Blockchain Technology Platform at IBM Research and Yov, who is a research staff member in the same company, they will tell us more about hyperledged Orion. Please feel free, ask a question at the end of the presentation and enjoy, enjoy this time. Okay, so hello everyone and thanks for the invitation to the Hyperledged Labs event. It's a real pleasure to meet with you today. In our talk today, Yov and I will present you our centralized trust blockchain database technology named Orion developed by IBM Research that was recently accepted to the Hyperledged Labs community. I hope that by the end of this session, even those who are less familiar with centralized blockchain approach will understand how this technology can play a key role in building trust in your business ecosystems. So let's start with the short background. As you probably know, trust is crucial to the growth and success of business ecosystems. According to the study by Boston Consultant Group, trust was indicated as approximate factor in the failure of more than half of unsuccessful ecosystem and matter a great deal of success in more than 70% of the successful ones. However, it's important to understand that business ecosystem vary in their topology and the intrinsic level of trust between participants and therefore has different trust requirements. From the topological perspective, the ecosystem can be divided into centralized ecosystem with at least one party highly or partially trusted by all participants and decentralized low trust ecosystem with no single trust party. In highly trusted ecosystem, it may be enough to ensure independent, consistent and crash tolerant recording of the data. While in limited trust environments, we may also want to verify the correctness of the recorded data, ensuring authenticity and providing temporary evidence and data lineage. Finally, in low trust environments, we may need to control the transaction execution by supporting multi-party approvals, parallel execution of smart growth drugs and even reaching a consensus in presence of malicious parties. There are three major types of technology that can help to close the trust gap in business ecosystem. First of all, the classical database with the basic recording features usually sufficient for proper operation of highly trusted centralized ecosystems. While blockchain databases that extend classical database capability with proofs and controls are the best choice for limited or low trust centralized ecosystems. Finally, decentralized ledger technology that usually provide a full stack of trust features should be used in low trust decentralized environments. It's important to emphasize that support of advanced trust feature usually result in higher complexity and may impact the performance and increase the operational cost of the entire solution. So why and when should you consider using blockchain database technologies? Look, most of the business ecosystem today and probably your systems as well operate under centralized trust assumption which means that there is at least one trusted party like cloud provider, government organization or some big player while the other participants doesn't have to trust each other. For example, organization usually trust the cloud provider not to block their clients intentionally from accessing services although they can easily do so. However, having a trusted party doesn't mean that the other participant should blindly trust it. And as our experience shows there is still plenty room for further improvement of trust in centralized ecosystem. For example, participant can benefit from having transparency into data lifecycle and the ability to prove the integrity and consistency of data which is very important to streamline the auditing process especially in highly regulated environments. Ensuring authenticity of data is crucial to prevent potential authorship disputes in the multi-party interactions. Finally, even trusted parties often want to restrict the power of their privileged user to prevent mistakes and fraud. Well-known classical databases that are widely used today in centralized ecosystem do not provide out-of-the-box capabilities needed to guarantee and prove the required trust features while the use of decentralized blockchain technologies for centralized systems is usually highly inefficient and doesn't justify the increased cost and complexity. Hyperlegiororians combines classical database with blockchain properties specifically targeting centralized ecosystem. Such blockchain database technologies according to Alibaba can reduce the deployment cost by at least 75% compared to decentralized blockchains. And according to Gartner we'll replace most of the permission blockchain users. By 2025, the addressable market of such ledger database is expected to reach 2.2 billion dollars. Now, let's better understand what Orion is. First, Orion provides a trust layer on top of standard database with the blockchain features like authenticity and non-repudiation that can be used to prove that the data was received exactly as it was sent by the source preserving ownership disputes. It's also provide temper evidence which is the ability to detect changes to the protected objects even if done by privileged user. In addition, it enables provenance and data lineage which includes recording of all transactions of the data along the way. Finally, we provide a multi-seq mechanism to improve transactions only when signed by several designated parties which is very important to ensure trusted multi-party interactions. And all that comes with the classical database capability such as queries, resilience and scale, standard key value JSON store and transactional APIs to ensure that the set of read write operations are executed as an atomic transaction preserving consistency and data integrity. At the high level, Orion is implemented as a cryptography based layer on top of classical database. That is with a highly secure and replicated distributed database with temper proof immutable legend. It also enables history queries to extract information and proofs of integrity using GraphGP based provenance engine and provide read write key level access control to support privacy and multi-seq capabilities. You are welcome to join our open source community and contribute further advanced our technology and the following things should help you to get started. Now to better understand the applicability of Orion, I would like to share with you some of the key use cases that we have encountered in our work and provide the references to a few public projects that we can share. So in addition to the auditability use cases which is highly available in the regulated industries, there is a set of unique scenarios across different domains that Orion can help with. For example, the multi-seq capability can be used to automate many business contracting processes and easily support notary services. Orion can help to ensure authenticity and protect the integrity of the evidence collected through the insurance claims process. It can significantly simplify the management of lives and certificates, educational records, property ownership rights for government organization. It can be used to securely digitize the COVID vaccination status which is extremely important these days. And of course to trustfully reflect the provenance of goods and compliance to maintenance requirements in supply chains. Orion can be applicable in financial sector to support central by digital currencies and securities and can even be used as an off-chain store for the decentralized ledger ecosystem to preserve the financial data integrity across the hybrid environment. In less regulated environments like entertainment, for example, Orion can be used for media tokenization and even for a trusted reputation management. After a detailed examination, it was decided to use hyper ledger Orion as a blockchain platform in three EU projects. C4 IoT to build an IoT cybersecurity framework, Copa Europe to build a media trading platform and I4Q project to support smart manufacturing. Now I will let Yov to take you through the more technical part and demonstrate the ease of use of the hyper ledger Orion. So thank you and Yov, the stage is yours. Thank you, Danny. Let me share my screen. Let us take a look at the main components of Orion. The Orion database users have to be onboarded by an admin. Onboarding means adding the user's identifier and the certificate to the user's registry orion as well as setting the user's privileges. Users sign every request, both transactions and queries, which is used to implement authentication and authorization as well as non-repudiation. The state database is composed of multiple named database tables. And each of those is a key value store. Each row in a database table contains a key, which is a string, a value, which can be binary or a JSON document. A version, which is monotonically increasing on every right and is used for concurrency control. And finally, an access control list or ACL, which is used for fine grained access control. Multiple database tables are useful in order to manage user access, as well as in order to define custom indexes according to the schema of the JSON documents in them. The data in every transaction that mutates the state DB is also stored in a graph database. The provenance store holds the history of key value pairs, as well as the relations to users and transactions. This provides an easy way to query and retrieve historical data and explore the complete data lineage. The component that gives Orion its blockchain properties is a set of append-only authenticated data structures. Orion uses a hash chain augmented with a skip list, a hash skip list, in order to bind blocks together, a mercury for the transactions within each block, and the Patricia Mercury on the states, like Ethereum. These data structures allow Orion to provide succinct proofs of two aspects, the existence of a transaction in the ledger and the existence of a state at a specific ledger time. In Orion, as in a hyperledger fabric, transactions are batched into blocks and the blocks are signed by the server. The server also signs every response to a client request. The combination of these features provides immutability and temper evidence and allows Orion to serve as a trust anchor to establish trust between users. So far, I describe the single-note perspective of Orion. However, Orion is based on a cluster of servers, which relies on raft consensus for replication. Clients can connect to the database via REST API or using an SDK. So far, we have fully implemented a Go SDK and we plan on providing SDKs in other languages too. The administrator can connect via REST or use the SDK as well. The admin set of APIs allows the administrator to manage users, database tables, the cluster configuration, and certificate authority information. Let us now take a brief look at the programming model using the Go SDK. Our main goal was to maintain the simplicity of the key-value store. Every database session starts with creating a database instance, which loads the connection details of the cluster. A specific user will then create a user session using his credentials, that is his private key and certificate. The session serves as the starting point for transactions. We support two categories of transactions. Admin transactions and user transactions. They all look roughly the same way. Database management transactions are used to create, delete, and query the existence of a database table. User management transactions are used to add, update, delete, and get the credentials of users. Cluster configuration transactions are used to add or remove cluster nodes, manage the parameters of consensus, etc. Admin transactions can be executed by admin users only, and are recorded in the ledger like any other transaction. This makes admin actions and config changes traceable, just like any other piece of data. Data transactions are what concerns most users. Here we support multi-key, multi-database transactions. A transaction starts by creating a transaction object, data tx in the figure to the right. That object can be used to create, read, update, and delete multiple keys for multiple database tables, all in the context of a single transaction. When the user finishes manipulating the data, it calls commit, which creates a transaction envelope that captures all the reads and the writes on the data, signs it with the user's key, and submits it to the server. Transactions provide the ACID properties and are serializable. As I've said earlier, each key value pair has a version. The transaction object records the read set, where each read is a key and the version, and the write set, where each write is a key and the new value. Each key value pair is accompanied with an ACL. Readers is a set of users that have read access, whereas writers is a set of users that have both read and write access. As I've already mentioned, users sign each transaction. The transaction will be valid if and only if the signer has read and or write access to the keys involved in the transaction. In addition, we have a flag called sign policy for write, which determines how many writers need to sign in order for a transaction to be valid. Any means that any user from the writer's set is enough, whereas all means that all the users of that set must sign. The addition of a key-level ACL and the write policy provides fine-grained access control and opens up a lot of possibilities. For example, setting just readers and no writers creates a read-only immutable key value. Setting two writers with policy any means that either Alice or Bob, for example, can write the key value. And setting two writers with policy all means that both Alice and Bob are required to sign the transaction in order to make it valid. All this while granting read access to a third user, Charlie. The last example is an instance of a multi-signature transaction, which is extremely useful in some business flows, as we'll show in a few minutes. The values in a database table can be JSON documents, and if so, it is possible to define an index on their fields and execute range queries. Orion supports the JSON queries index in a format very much like CouchDB. So the learning curve should be easy to manage for people familiar with it. The last set of APIs exposes the provenance information Orion maintains. It allows you to answer questions like, what is the evolution of the values of this key? Or which users have read or written this key during a transaction? Or even which keys were read or written by this specific user. And this is just a partial list. Now, let's demonstrate some of these features using a simple example on a car registry. In this example, an imaginary department of motor vehicles runs the registry that keeps track of all the cars in the country and their ownership. This is, of course, an oversimplified scenario for ease of presentation. The first role in this scenario is that of a DMV officer which approves transactions that bring new cars into the system, what is sometimes called minting transactions. The DMV officer also approves transactions that transfer ownership between the users. The second role is that of a car dealer which submits mint requests to introduce a new car into the system while becoming its owner. The car dealer later sells the car to a new owner transferring ownership to her. The third role is that of regular car owners which can transfer ownership between each other in the process of buying and selling. Note that we assume that the DMV is required to be part of every such transaction by law. There is another role here, that of the service provider, database as a service, for example, but we will not address each role in this example. The car minting procedure goes as following. First, the dealer executes a mint request transaction inserting a mint request record with the required information. The record which identifies the dealer and the car is accompanied with an ACL which allows only the dealer to write to that record and allows the DMV to read it. Next, the DMV reads the mint request record, inspects it, and compares it to the actual car and then insert a new car record into the database. The car record is again accompanied with an ACL but this time it lists both the owner and the DMV as writers, and requires that every change in that record be accompanied by the signatures of both. Let's take a look at the code of one of these transactions. This is the mint request transaction. The data transaction is started from a user session, in this case the dealer user. It then prepares the record, verifies that the record does not exist already in the DB, and then writes the data with the put method. The commit method then packs the transactions read and write set into an envelope, signs it, and submits it to the server. The result of the commit is a transaction receipt signed by the server. The user can then save the transaction envelope and transaction receipt to his local storage as evidence of the transaction execution. As you can see, it's very simple to understand and very intuitive for database developers. The transaction receipt is basically the block header of the block in which the transaction was committed and the index of the transaction within the debt block. You can also see that the header contains the hashers for the hash keep list, the Merkle tree, and the Merkle Patricia tree. In the next step, the current owner, the dealer, sells the car to Alice, the buyer. The transfer of ownership is implemented as a multi-signature transaction. First, the car owner prepares the transaction, just like we saw earlier. It reads the car record, which is captured in the reset. It then changes the owner to Alice and changes the ACL to Alice and DMV. It then adds Alice to a field in the transaction called must sign users, which allows the initiator of a transaction to require additional user signatures. He then signs the transaction, but instead of submitting it to the server, he sends it to Alice. Alice, the buyer, will inspect the transaction content. For example, checking that she is indeed the new owner and then add her signature. She will then send the double sign transaction to the DMV. The DMV will again inspect the transaction and validate the details, the new ownership, the new ACL, and the signatures. The DMV may also run provenance queries or add custom logic, such as checking that the owner, buyer, or car are not on some blacklist. The DMV officer will then add her signature to the transaction and submit it to Orion. The Orion server deems the transaction valid, only if it is correctly signed by all three parties. The owner and the DMV are required because of the current record ACL, and the buyer is required because it is specified in the must sign user set. I will not show the code for this transaction. Instead, I will refer you to a self-service demo with detailed instructions in our Go SDK repo. The example cars package allows you to deploy an Orion server and run car registry transactions, as I just demonstrated. After the completion of the ownership transfer transaction, the Orion server will contain this virtual dependency graph between transactions and records. The transaction, the transactions, which are signed by the users, are producing records via the right set and in turn are consuming records via the read set. The provenance API I had shown earlier allows the user to easily traverse this graph and extract insight on its evolution. Now let's assume that Alice wants to sell the car to Bob. However, Bob is suspicious. He asks Alice for a proof of ownership. As I mentioned earlier, after commit, the users may save the transaction evidence, which is the transaction receipt and the transaction envelope. Alice, or the DMV for that matter, can give the evidence of the ownership transfer transaction to Bob. Bob can inspect the transaction content, and then with the evidence, Bob will ask the Orion server for a proof of the transaction's existence in the legend. The server will reply with the hashes of the skip list path and the hashes of the market repath. Bob can then verify these proofs locally. The complexity of getting and validating the proofs is all hidden by the SDK, and the developer generally does not have to go into these implementation details. However, let's dive a little deeper and see, how does Bob verify the proofs? Well, he simply verifies the hashes of the has skip list path from the last block to the blocking question and from the blocking question to the Genesis block, the first block in the legend. Note that the size of these proofs is logarithmic with the number of blocks. Next, he recomputes the Mercury root from the respective hashes that were given to him by the server. And again, the SDK has utility methods to help the user do all that. In a similar manner, Bob can use the transaction evidence and ask the server for a proof that the states in it in our case the car record that the states are still valid with respect to the latest block. The server uses the Merkel patriciatry to construct the proof. And again, Bob can use utility methods in the SDK to verify the proof. The transaction and state existing proofs achieve two goals. First, they allow Alice and Bob to establish trust between them by using Orion as a trust anchor. Second, they allow users of Orion to detect tempering in the blockchain database by periodically requesting proofs of existence to pass transactions and states that they know should exist. For further details, please take a look at our online documentation. To summarize this presentation, Orion is a database with blockchain properties. As a database, it has a standard data model, transactional APIs, queries, resilience, and scale. The blockchain properties, it provides our temper evidence, provenance and data lineage, authenticity and non-repudiation, existing proofs for a transaction and a state, as well as multi-signature transactions. This concludes our presentation. Thank you for listening. And now we'll open the stage for questions. Thank you very much. Thank you very much, Dani and Joff. That was a great presentation. Any question, please? You can turn on your microphone or you can ask a question in the chat. Also on YouTube, feel free to ask a question. No, I have a question. So Orion, it's on GitHub. It's available. So it's open source, right? So it's a standalone node. You cannot understand the loan on premise or does it connect to some online services? It's a standalone node. Actually, it's a standalone cluster. And that's it. It's self-contained cluster database. And in GitHub, we have two repositories, one for the server and one for the SDK. And in the SDK, we have extensive examples and the demo is there also. And basically you have a SDK for Go and REST APIs, right? Right. The cluster API, the server API is REST and the Go SDK rides on top of the REST API. That's correct. Thank you. Great. Thank you. We've got two questions on chat. Can you please share again the link, for example, to the demo for Cardio. Please put it on the chat. And the next question was, Rohan, can you give an example of application in supply chain space? You mentioned supply chain application in a previous slide. Sorry. Can you repeat what types of examples? The question is in the chat. I'm just trying to find it. Of course, supply chain. Okay. So in supply chain, it usually may be very important to have a provenance of goods through the supply chain. So in classical supply chains, there may be interaction between multiple parties, starting from manufacturing through the delivery companies, through retailers, all sellers, and at the end also potential even customers who own the goods and may in some cases even need to maintain them. So all the information that can be related to a specific asset can be recorded within the Orion database and keeping all these records in a secure and signed manner with all the capabilities to get the provenance of ownership and the state where it was, when it was maintained and so on, enables and provides full visibility into the entire lifecycle of the asset. So in supply chain is one of the classical examples for the use of blockchain capabilities and in the environments where we have a strong central party or a trusted provider like cloud provider in infrastructure company, we can definitely use and leverage Orion as a blockchain solution for that. Thank you. Danny, would you like me to read questions or you can check on the chat? Yeah. Is there a use case for punks? No example. You know, the performance question. Joao, do you want to take the answer on the performance one? Yeah, the performance, we are still in the early stages of, you know, productizing the silver. So we haven't done rigorous performance tuning, but from early testing, we can say that performance is better than blockchain, like fabric, naturally. But it will undoubtedly be lower than traditional databases. But I don't want to commit to numbers. I can say that the ballpark number is 10,000 transactions per second. At this early stage. And we still have a lot of work to do on performance tuning and improvements. So that's with respect to performance. Yeah, I see question on the bank or regulated space. So, look, as we said, the financial sector is one of the sectors that usually leverage or one of the, you know, pioneers in trying various types of blockchain technologies. And, you know, if we are talking, for example, about central bond digital currency, so different countries take different approach for central bond digital currency. So in some cases, they are going and trying some decentralized approaches for that. And some countries goes with centralized approaches. So we believe that for those who, you know, want to go with a centralized approach, Orion can be definitely something that they can leverage. And of course, in these specific situations, it can provide better performance alternative solution. But again, as you have mentioned, you know, you pay for additional features. So if it's compared to classical databases, yes, without all these trust features. So we will, you know, have a lower performance, but compared to the centralized blockchain technologies, that, you know, Orion can be the best fit in, if we are talking about centralized solutions. And also it can be, you know, in the regulators, just like the DMV example. Again, if you have a regulator, which is usually a highly trusted participant, not fully trusted, but maybe highly trusted participant in the ecosystem. So I also believe that in these kind of scenarios, use of Orion could be beneficial for these environments. There is another question. Is there a use case available for telcos, DSPS for blockchain hyperledger? For telcos. For telcos. So I'm just thinking loudly. I don't remember specific use for telcos. I know that, you know, many industries investigating the use of blockchain telcos or, you know, IOT space, which, you know, usually requires high performance and, you know, big volumes of data may try to find, you know, Orion more applicable than classical databases. But I don't think that at least from those that I can, you know, expose publicly the negotiations we can talk or refer to in the telcos space. Okay, so I will add from the hyperledger side that we've got a telcom special interest group. So I will share a link in a second. So telco is definitely a grow area. So it would be very interesting to hear what are the trust challenges in the ecosystem and also show how this kind of technologies can potentially be applicable in these domains. I must admit that we also investigate various types of hybrid environments. The hybrid environment is an environment that may include multiple Orion servers, which may interact with each other at some point or the interaction between hyperledger, Orion, for example, a classical decentralized blockchain databases, potential is enough chain store to preserve the integrity through the entire life cycle. So these kind of scenarios can also be interesting for us. So if you see any ecosystems that the combination may make a lot of sense, we'll be glad to know and be involved. There is a question here from Angelina about technology at the heart of the replication component. And how does it relate to fabric, for example? So yes, many of the design decisions here are inspired by fabric and that's not by accident. Three of us are fabric developers. One of the team members is a fabric maintainer and we know fabric very well. And the component that we are using, the style of replication that we are using is inspired by fabric. It's not exactly like fabric, but it's similar. So we try not to invent the wheel. And we are using the same library, the same ATCD rough library for replication. I hope that answers the question. And there is a question from Hubert about is it possible to connect Orion with Ethereum? So I don't have a food developed answer to that, but as Dani said, one of the use cases we thought about is using Orion as a verifiable off-chain storage in order to speed up things that happen in slower blockchain platforms like Ethereum or Bitcoin or whatever, or fabric. It's kind of an alternative to the off-chain transactions. You can do transactions through Orion and then do a netting transaction once in a while into the public blockchain or the slower blockchain. I see another question about the... Do we aim to have Orion as a pay for service and so on? So first of all, as you can see, it's an open source project so everyone can go download it and use it in their environment and so on. We're considering various ways of taking this technology and exposing this to the users. And of course, one of the potential threads is to provide it as a service for clients. And of course, in cases where clients or potential users or partners would like to have also some additional support capabilities on top of just using an open source project. This is the areas where we can, as an IBM see a way for potential collaboration. So I hope that it answered your question. I can add also about the CBDC project and Hyperledger that we are involved in the many CBDC projects. So please check on our YouTube with a couple of videos about the CBDC and Hyperledger. Also, share now one of the link. So please feel free. Yeah, I can just relate. We have an ROI team generally involved in other activities beside Orion. One of them is around tokens and support for CBDC stage space. So token SDK is also a Hyperledger project that we as an IBM and our colleague from Zurich has a place there. And it is used today in various interactions, especially for those that requires decentralized approach. But we also considering various ways of integrating these capabilities to enable tokens support on whatever underlying blockchain technology you decide to use. It can be Hyperledger Fabric and Orion based on your client needs. So that's the wider answer for the CBDC space. And there's two more questions and let's make them the last two questions. There's a question about a question from Arsanti. Can we consider Orion as a distributed network like Fabric? Where can we use it as a permission blockchain? So the architecture of Orion is very similar to the ordering service in Fabric. It's a rough-based cluster and you interact with it. And the users are, of course, everything. The users are, of course, permission. They have to be onboarded with a certificate. The difference, however, is that Fabric comes ready to have the ordering service hosted by multiple organizations. It's built that way from the get-go. And Orion does not do that. The cluster is managed by an administrator, which typically belongs to a single organization. And the nodes are... We think that typically they will be hosted by a single organization. They will be full tolerant and highly available, of course. But still, it's a single organization. And we think that this organization can be trusted. And it does not take part in the business interaction that the users do via Orion. I hope that answers the question. Hi. This is Prashanti. I just posted this question. Thanks for answering my question. Ideally, this can be chosen in a high-level, which is useful for public. Maybe kind of a voting system for a government. So it can be most suitable for sub-scenarios, but not within the kind of organizations. Like, suppose we have something called reward exchange program. And we have built one ecosystem where the parties can participate in that... I mean, whoever wants to exchange their points, so they can participate in their blockchains. So we can consider Orion maybe kind of a public, in a government-wise kind of use cases. So as a permissioned, maybe... I mean, as a permissioned blockchain, maybe we can consider this approach. But in a high-level, same like public blockchain, we can consider this well with an authority and with an authority. So am I right? So more than the... Yes, yes. I mean, what you said is exactly true. When you have an authority that... I mean, users are naturally, by design, are required to trust or have to trust, like government or maybe a big company that provides a service. Then that could be the anchor for trust among users. So we trust the market, like the New York Stock Exchange. And that enables us to trade stocks, right? It's a centralized system, but you and me don't have to trust each other in order to trade stocks. So that's kind of the analogy. Okay, okay. So can I ask this question? So are there any... We are already live with anything or we are building it now? We are already live with any... in partner or... Or we are... Sorry, I... No, no, I'm just asking is this project... product got deployed to any client or we are developing this? I just wanted to understand if somebody is using already and how this is working on production? This is not yet officially released. It's not production ready yet. But we hope it's good enough right now. It's good enough for a group of concepts for initial ideation for testing. And we are right now working on productizing it, testing, making it robust. We hope to get there in a few months. Yeah, it's really a good idea. Many projects or many clients, they don't like to keep entire blockchain node on their private network, on their own laptop or on their own system. So having one centralized and keeping the trust on that particular server is really very good. Appreciate for your work. Yeah. Right. As we said, there are many use cases that may go with a centralized approach and this kind of technology looks like the best fit for them. And again, I'm just repeating that we are encouraged everyone who believes that they can contribute to this effort. You're welcome. And we'll be glad to get you on board to work with that. So we'll be very appreciative. And I think there is one more question. You have the last one. Which one? Thanks for answering. Okay. One more, please. That's the definition of a new JSON schema data model coincide with the deployment of a smart contract on the background. If yes. Is this the job of an administrator or all participants can achieve this via the SDK? Okay. So first of all, there are no smart contracts in Oreo. It's not a smart contract abstraction. It's a data abstraction. It's like a database. So in a sense, the code that runs this thing runs on agents which are outside of the database. So for example, in the car example and the car demo, the flow that the dealer does or the flow that the DMV does would be implemented by smart contracts in things like fabric or Ethereum, right? But here it will be implemented by client-side code maybe by the service that envelopes the database, like in the traditional free tier architecture approach. So the code that envelopes the database is actually plays the role of the smart contract. So with respect to permissions, the schema of the database and the creation of the database itself is controlled by an admin. So you prepare the database, you define an index because you expect the type of documents that will be in there and you grant users a privilege to read or write or create documents in a particular database and then the users do their own thing. I hope that answers the question. Thank you so much. Thank you so much, Danny. Thank you for all participants today. That was so great. Great session, great questions. Thank you so much. I hope we all know more about Hyperledger Orion who would like to be involved. You've got links on the chat. Also, you'll find a recording on our YouTube so send this recording to all, link to the recording to all our participants. So thank you so much. How we can stay connected with you, Danny and Joff? I can write my email and I think Joff can share. Yeah. And through the GitHub we are there and we'll soon open a chat and a messaging channel. Okay. Thank you so much. Thank you again. Have a nice day, evening, whenever you are now because it's a Hyperledger London meetup but we are around the world and so happy about that. Thank you again. Please find more nice events, meetups on our meetup profile as well check our website. Thank you again and see you soon. Thank you. Have a nice day. See you soon, everyone.