 So my project is about building a capture sample between logic parking for hyperledger captures. And my name is Zhiceng Wang. I currently in Taiwan, enrolled in Texas A&M University. My mentors are Raphael, Professor Lu, and Peter. So for the project description, I would like to build an old-dev open digital asset protocol, denoted at old-dev here, as a business logic parking. And since I have captures to standardize the cross-chain transaction. And most works and pathways with blockchain interoperability only realize the technical layer. So we integrate old-dev with captures to realize both technical semantic layer, which the technical semantic definition will be discussed later. For the project objective, first, I would like to understand the architecture and tools of hyperledger captures, then write code of old-dev. Lastly, write a paper. For the developer, both a GitHub branch of old-dev hopefully will be able to merge into characters that will reach me of how to use the old-dev than the paper. So exclusion accomplishment, I have written code for old-dev protocol and written code to enable cross-chain asset transfer in old-dev and write the paper, though still editing. I'm proud of learn to write code in a test-driven fashion. Let's just write in test first, then write code. And the most challenging part for the code is I have to constantly keep up and merge the trends of hyperledger captures, then branch, since sometimes the tool would be changed. So my code may not be compatible with lead. And also, when using some external library outside of characters, they may have some problem. For example, when I'm using the fabric node SDK, they miss the typescript declaration. So I make a pro request for lead. Unfortunately, lead haven't been done yet since I'm busy reviewing this project. So my thanks for my mentor, Peter, to teach me how to bypass the problem. So I'll give you a quick access intro. KXL have some main components and improve the technical layers of blockchain interoperability. First, the component is ledger plugin enable to transact on different ledger. Let the business logic plugin improve the application business logic, interact through ledger via the ledger plugins, then the API server. Enable the old plugins including ledger plugin and business logic plugin to register their service API on the API server. Then the end user can call the business logic plugin API to the API server. However, what lack of character is there is no standardized way for the business logic plugin to make cross-trend transaction. So here comes all that. The quick intro of it and improve the schematic layer which is lagging characters. It's defined the format of exchange in message and asset profiles. Also define the stacker format for visualization over the security parameters and asset profile. Also some application profile visualization and type of access to assets on the ledger. Lastly, ODEV also define the format of transaction received so we can make a more general proof of the ledger state. Then this is the ODEV best-of-secrets diagram. I'll go quickly through it. It's mainly composed of three phase. The first is transfer initiation which ODEV gets with Nigel TS or the asset profiles and some security parameters. You can view this as the overhead or deal with the overhead of the protocol. Then with the lack evidence phase the client ODEV gateway will prove that it has lucky the assets on the source ledger. Then lastly is the commit final phase. A client ODEV gateway prove that it has deleted assets on the source ledger. Then the server ODEV gateway prove it has created assets on the target ledger. Then this flows for this flow trust. Unfortunately, I see the slide is too small to show. So I give an important point here to make cross-transaction atomic the client ODEV gateway lacks and delete assets on source ledger if and only if the server ODEV gateway creates assets on source ledger. Sorry, this error is moving on target ledger. And we all know it is hard to revert a ledger state especially in the cross-transaction. So instead of directly revert in the ledger state we decide to having a revert operation or call opposite operation. For example, for the lack operation the opposite operation will be unlocked and delete opposite will be created. So when we have defined the action of a smart contract we need to make sure that you also define and implement the opposite operation. So we can have a atomic cross-transaction. And the last part is ODEV log storage to store data and log in ODEV. Traditionally there's cloud storage and local storage but we choose to do in addition to the IPFS fashion way to do this IPFS is a peer-to-peer file system and we address the file like not via some URL or something but via the content of the file, the hash of a file. And for the cloud storage we give a disadvantage here it's quite obvious that centralization is a big disadvantage since we should usually always avoid centralization when use blockchain. Then is the local storage. Well, sometimes if the business logic product execution process is not complicated if we rely on the local storage then the news participate in the execution process will be heavy weighted. And also we need to consider maybe there's not only two characters or two ODEV loops involved in the process. If there are many lots of loops then the number of verification will be dependent to the number of the nodes. Seems for every rule we need to keep a copy of the data. So here we go through utilisation of the IPFS. The first thing is to remove the centralization and the centralization. Since if we store a fixed number of vacation on IPFS, we could reach for the linear dependency through the number of the nodes. Therefore, we bypass both the disadvantage of the cloud storage and local storage. And recommendation for future work. First, I think the recommendation will be finish the implementation of right ahead log of ODEV to provide crash recovery tolerance. And since we are talking about crash recovery tolerance we should also talk about vitamin tolerance though not a traditional environment of vitamin team. Since cactus and ODEV will not be for the public execution process but we should also design how ODEV could receive malicious node. And the last one is the dynamic ODEV node execution. We will consider the process will be very long and complicated. It is natural to think that some node will join and leave in any time. So we need to deal with that. And also utilise IPFS to help data integrity. Well, this one is I just put in here in one or two hour ago. This will work in the scenario that when the node will want to join the ODEV node execution and if the node will need to get the data to verify the transaction or execution then it should get from elsewhere. And since IPFS could have, could have, could recall all the changes of the file content. I think about this if we could have the data and grade T to help the newly joined node quickly get the data is needed. And project output of the results first is the GitHub branch of the ODEV and the second is the package of the Rhythmia to help to use the ODEV package. And last is we will have a paper about this implementation and architecture design. And some insight gain and advice. The first is you should constantly keep up with the main branch since the main branch will be trained some code or tool. So if you don't keep up with the main branch then your code may be not compatible with the main branch. And also don't afraid to reach out if there are some questions and ask your question most specific so other could help you also most specifically. And thank you for my mentors and the Hyperledger community. And thank you for everyone this on this. Any question and feedbacks? Thank you, Jason. As one of the mentors, I just wanted to say that I think you did a really great job and it was an honor to be the mentor, one of the mentors. And the ODEV plugin is definitely an important milestone for cactus in terms of the actual foundational goals of the project. So thank you very much. Yes, thank you also for mentoring me. Yeah, thank you so much. You know, I hear again and again and from your experience as well that the community is very welcoming and sounds like all of your gaining confidence to ask questions and perhaps ask questions in a way to solicit the kind of a productive feedback. So I think those are all really great learning outputs that we're looking for as well. I know so the paper that you're gonna be writing is that gonna be an academic paper that you're working with, really? Is that what the paper is? It's not a documentation, it's more of a academic research paper. Hopefully it should be her academic paper. Yeah, let us know when that gets written and published. We will be happy to read and see if there's a way to promote as well. Yes, thank you.