 Okay, we are live. So thank you to everyone for joining. We have a virtual Hyperledger meetup today about harmonizing cross-chain interrupt for financial market infrastructures. We have a couple of speakers today. We have Dominic Fox from R3 and Peter Moonians from Eddhara. They're gonna go over the new Harmonia Lab. I'll drop a link to that in the Zoom chat so you can check out their repo. I'll also send all of this information to everyone who signed up after the meeting as well. But with that, Peter and Dominic, I'll let you take it away. Thanks very much, Dave. And big thanks to Hyperledger Foundation for hosting this event and for hosting Harmonia as well. It's been a good partnership. So I'll introduce myself and I'll hand over to Dom to introduce himself. I'm Peter Moonians, I'm the founder of Eddhara. We primarily work, more exclusively actually work with tokenized deposits with banks and central bank settlement tokens. And we work largely in the Ethereum space, although we are platform-agnostic from that perspective and have been and continue to do work with R3 and call it to you, Dominic. And Peter, sorry to interrupt really quickly, but your audio is maybe a little quiet. So if you could speak up a little bit more. I'll try and bump that up before Dominic uses himself. So hi, everyone, I'm Dominic Fox. I'm a principal software engineer here at R3. At R3, we build the Recorder Platform, which is a private permissions distributed ledger technology. In recent years, especially everybody in the world has been asking us for inter-op capabilities and is very interested in how we inter-op with Ethereum in particular, but also that the wider world. So Harmonium is sort of us trying to come to the table, particularly looking for ways to inter-op with Ethereum in the first instance, but also kind of work out what reliable inter-op patterns across distributed ledger chains actually look like and trying to get into really into the depth of how to make that work. So yeah, it's been a great experience trying to pull together this hyper ledger lab with Adara and Peter and his team. I'm delighted with the way it's gone so far. I hope that what we can present to everybody else is an exciting interest. Okay, so things Harmonium is not. It's not this, this is a Harmonium. Nor was it that, that's a harmonica. Actually, since I put these slides together, another thing called Harmonium appeared in the world, which is a virtual synthesizer created by Cherry Audio, which is a really nice kind of modern synthesizer, but Harmonium isn't that high. So Harmonia is, came out of, shall we say, an initiative driven by a group of banks to help create common patterns and standards for interoperability between digital assets ledgers or platforms in order to simplify the atomic settlement of delivery versus payment transactions. So it's quite tightly scoped. We're working in these, with these FMI's and these banks, financial market infrastructure companies, exclusively at the moment on the publishing blockchain. Sounds like she's talking, can you hear me right? Yeah, I muted that person. I can hear you fine. Great. So, yeah, a number of banks that are either shareholders of or participants in a number of emerging digital asset platforms, either cash or securities. And the risk for those banks is that as those platforms scale, they end up managing a plethora of gateways, interfaces, data formats, and specifically, we refocused interrupt mechanisms. So the ask really was, can we provide a place where everyone can contribute to establish some standard patterns? Can we provide guardrails to platform providers to ensure that the connections to their platform and the interrupt mechanisms are well understood by the banks and easy to deploy. So that's really the ask. The, what is, what is in harmony at the moment? So firstly, how many, we chose Hyperledger because it's a very well understood open source platform. So one, there are a number of banks who are members of the Hyperledger Foundation. There are a number of other FMI's and technology providers who are already members. And generally banks and FMI's and technology providers all know about Hyperledger and certainly know about the Linux Foundation. And they also understand the way it works, which is quite important. So they understand what they can and can't contribute into that and what happens once they have contributed. So what has been so far contributed and where we think the real focus of harmony is gonna be is in putting together a set of principles. So these principles range from business principles to legal principles to regulatory principles all the way through to technical principles. So the focus is very much on what constitutes or what defines interoperability between regulated platforms that are running on distributed ledgers. Secondly, there are some requirements in there. So these once again are requirements, typically commercial requirements. So you've got kind of principles that define the framework and then within that you've got requirements that certain platforms have around what they are prepared to allow and not allow. And then finally, what we have included in harmonia is some reference implementations. And this is an area where we certainly see harmonia growing. So firstly, that's what's there. But then secondly, we not only have the repositories, we also have Discord channel and the idea is to have a place that promotes open dialogue. There's issues that already open. There's comments on those issues. There's lots of comments on the pull requests that are coming in. So it's a very much an open public place where we can discuss and reach conclusion around what these interoperable principles look like. One of the kind of guiding principles for us is we really do want to get things going quickly. I'll run through some of the principles. For those of you that are old like me, you'll remember the days of TCPRP and OSI. TCPRP was established literally over a couple of weekends in 1969, it was a very simple protocol that worked and lots of people started to implement it and the protocol itself was free to you could copy it for free back in those days. It could be fixed to you for free if you remember those days. OSI was a very well thought through, seven layer protocol stack that typically got taught in various courses but had all sorts of complications around it and was difficult to implement. So we know the success of TCPRP, what the success of TCPRP was. So the idea is to have something that is relatively simple but is being used. So some of the kind of founding principles of harmonia are firstly that is anchored in production implementation. So we don't want to build something that's theoretical. We want to have something that is immediately implementable and is already being used and that we start to get very quick feedback from the industry around it. The focus for now is on wholesale business flows. So repos or repurchase agreements, FX swaps, cross currency swaps and then equity and bond settlements. So that's the focus from the banks. So once again, you see it's quite tightly scoped. We've started off with quarter and enterprise Ethereum but that's really to get going with something. We certainly don't want to limit it to those two platforms and we've already had interest from a number of other platforms. We are trying as best as we can to align with relevant standards bodies. So harmonia is not intended to become a standards body. It's intended to provide input into those standards bodies. So the enterprise Ethereum Alliance, the IEEE has a distributed ledger intra-working group and the IETF, the Internet Foundation has also distributed ledger intra-working group. So we've provided input into all of those working groups and those standards that are being developed by those working groups. We also want to maintain the community incentive alignment. So that speaks to two things. There's various communities involved here. There's the kind of interop hyper ledger community that's already in existence. So CACTAI and various other projects that are already part of hyper ledger. We'd like to maintain alignment with those current incentives but also with what the banks are currently doing as well. So that's quite a tricky balancing act at times but what we want to do is try and pull that together within harmonia. And then obviously to have some reference of limitations, that accelerated option that people can look at and say, okay, this is how it gets done and we can see it working end to end. And one of the asks from the banks has been that the patent should be anchored around the wallet holders or the asset holders and not bridges. So that's a little bit different to some of the other patterns that we've seen out in the world. And primarily this is because banks are the ones that will be connected to these various platforms. And so the interop needs to one be visible by the banks and two potentially coordinated or synchronized by them. So they want something that is easy to deploy a bank side that can help with the interop patents. Move on. All right, I'm going to hand over to Dom to pick up looking more at some of the problems that we are addressing within harmonia over to Dom. Okay, yes. So this was the why and the what of harmonia and then there's the how. I'm going to delve a little bit more into the how and some of the issues that kind of arise when you really start thinking about how to perform reliable interoperations between two quite distinctly different platforms. Corda is very different from Ethereum in some ways we're getting to very shortly. So the kind of the basic problem is we're looking at her identity and messaging who's talking to whom and over what channels Corda and Ethereum have quite different identity models quite different ways of picturing how you might communicate between parties. Privacy and observability who can see what. So on Ethereum, everyone can see everything although you might choose to use encryption or whatever to have masks and things or transactions are in public in principle. In Corda, things are private, they're kind of broken down so that again, in principle, only people who were parties particularly with transactions should see them. Proof, trust and liability. So how do we construct and validate proofs of action? The proof of action is how do I prove to you on your network that something has really happened on my network because I've really done the things I say I have done. Where can or must we rely on trust relationships? When do you have to take my word for it? When can I give you something that you can independently cryptographically verify? And how do we minimize individual parties' liability? So that's linked to the trust question. Okay, Pisa, can you move it on? So on my density and messaging, I'm going to talk about Ethereum and Ethereum-like platforms as EVM because they're all things used to Ethereum virtual machine in one form or another. So whether it's Hyperledger, Beissu or Quorum or Ethereum Mainnet, they're all I think EVM flavored networks. So as a shorthand for that, I'm saying EVM. I'm aware that the EVM is just a virtual machine but I'm using the shorthand for that flavor of blockchain platform. So Corda and EVM flavors blockchain platforms have very different identity models. One is permissioned, one is permissionless. An EVM address is synonymous with a signing key and anybody who has that key can act as that address via any node in the network that will accept messages from them. Nodes aren't intentionally trustworthy. So even by node I mean an Ethereum client, even one that I own and operate depends on peers or I may not own and operate for information about the status of the network. So we might be being deceived by the people who were talking to us although in the large there are kind of crypto economic incentives for nodes to be honest. So that's a very different situation to Corda. With Corda, every node in the Corda network or virtual node in Corda 5 is associated with a particular identity in the network. There are centralized management to those identities and permissioning of them. Each node has its own vaults which stores the transactions that node has participated in. Each node exposes a network endpoint through which just an authorized user can access it by RPC messaging. And each node runs a particular Corda to distribute the application for the Corda network. Nodes talk to each other via peer messaging and they can actually run fairly complex workflows using the Corda Flow framework so they can kind of establish what they're going to do, come to some agreements and then create a nodes-wise of transaction that records their agreement that that thing has happened. And the Corda ledger accordingly doesn't exist anywhere except in the vaults so all of the nodes within the networks. So while the ledger itself is a graph of transactions using it by UCXO ledger model, node one may see transactions one and two, node two may see transactions two and three. It depends on who they've been transacting with. The notary, which is an important part of Corda's consensus mechanisms sees all transactions but it actually only sees one detail of them which is the hashes of their input states. Everything else is torn off from a Merkle tree so the notary doesn't actually know what's going on in the ledger, it just observes and marks off input states to transactions. So it's a very, very different identity model, messaging model, privacy model. Next slide please. So EVM based blockchains don't have any concepts of sending a message that's equivalent to Corda's peer-to-peer or Corda's Corda interlock messaging. If you want to tell the world something you can write something into the event logs of your transaction and you can broadcast in this happened events which are associated with the particular transactions and interested parties can observe those and choose to respond to them. And so things like the cross-chain function call standard, cross-chain messaging standards kind of build on this. They say, okay, if we see certain events in transaction logs, we treat that as a cue to contact somebody or to also respond. And Corda similarly can receive messages from the EVM by observing events written into transaction event logs. But in effect, you're kind of reacting to or relaying things that are kind of recorded as a result of transactions. Next slide. In terms of privacy and observability, as I said, all EVM platform transactions are broadcast to all nodes eventually and eventually consistently. So although if you look back over the history of an Ethereum measure and everything sort of happens instantaneously according to that history, data moves through the network, through sort of peer-to-peer communications between clients and it arrives at consistency through the EVM consensus model. And it may take a little while for it to settle for a transaction to be finalized such that you can say with a high degree of confidence that everybody has agreed and will agree in the future that this thing has happened. Corda transactions in contrast are broadcast only to participants. There is no centralized record of transactions. There is a centralized record of consumed transaction state hashes, which is the notary, but you can't query it directly. And you can't query the vault of an arbitrary identity. So unless you are prepared to tell me what's in your vault, I can't see into it. Okay, next slide please. So there's a kind of asymmetry of vision here. Any Corda identity can see everything that happens on the Ethereum ledger. And any Corda identity can receive a message. I observe a transaction event from any Ethereum address without needing to set up an authorized endpoint for the owner of that address to send messages to. However, on the other side, the holder of an Ethereum sign-in key can only act on information provided to it by Corda nodes as it trusts, usually that the party owning key actually owns, and can only see transactions that are visible to those nodes. So we have a very open model and a very closed model in communication with each other. So proof, trust, and liability are concerns in this area. If we have information from a trusted source, we don't need proof. We just need a signature that we can cryptographically verify in effect when this information is attested. If we can prove something cryptographically, we don't need to trust the source. So proof and trust are kind of disjoint in this way. The other thing is that if you trust me, typically in kind of commercial agreements, I am legally liable for providing you with accurate information. I might get sued if I falsify something or I accidentally get it wrong or I'm deceived by my own source and so on. So I hold some liability for providing an accurate account of things. And the owners may be on me to be a consistently available and reliable source of information. So trust relationships aren't free. You may, the person you want to trust may not want to take on the liability of being a trusted party. Okay. Sometimes complete verification of the facts depends on local knowledge. So to give an example in Corder, a Corder app can validate a draft Corder transaction. So when peers in the Corder network are sending messages to each other saying, what are we going to do? One of them can send to the other a draft transaction. That is a complete transaction unsigned that if it's signed by both parties and notarized will then be part of the ledger. That draft transaction can be read and understood by both parties in the Corder app because they have the data structures and the contracts codes needed to decode the transaction bytes and check that it has the desired properties. So the transaction is something like this will encumber on assets such that I can transfer it to myself if I meet these agreed conditions and you're trying to do an asset swap you typically want sort of meet conditions where I can take this asset if I can show proof that something else has happened. The ability to validate such a transaction depends on my being able to decode the representation of it and also run the smart contract verification function to see that it actually does what we expect it to do. It's prohibitively difficult to replicate this logic off network like in Solidity contract code. And in fact, although it's not impossible but if you do do it you end up very, very tightly coupling the two applications. So it's much easier a very final transaction does a particular thing if it's called a transaction to say, well, I will ask a call to know that I trust to tell me whether or not this does what I expect. Next slide please. Okay. To determine whether a transaction in a proof of stake Ethereum network like Ethereum main method in finalized we have to know what the proposed validators have staked which is recorded on the Ethereum blockchain. So a complete summary of the evidence involved in establishing finality would be prohibitively difficult to export and validate off chain. It's much easier to go and ask a beacon node. And in fact, for other purposes I know that I've spoken to some of the developers of Hyperledger UE. They use sync committees which provide a kind of pool of validators who observe finality and sign it so that other clients can say, okay, we have the word of these witnesses that this transaction or this transaction block has been finalized. So in cases where we require local knowledge that something has happened we can make use of witnesses who will attest to certain things of the case and then the proof from our side becomes a matter of checking witness signatures. Next slide please. So at a very, very high level you have two networks doesn't really matter what sort of thing they are. You have events going on on the network observation ports such as Ethereum client nodes that can see these events. Witnesses on the other network that have trusted links to these observation ports that can sort of look through them and see these events and then sign to say, I saw that this happened. And that's where you have the most event attestation that the local network can consume. And the idea is that you might not want to trust a single witness. There may not be a single party who's prepared to take some liability for this but you might have a pool of witnesses because it's more difficult to subvert a large number of different parties and they in turn might look through a number of observation ports if there's any question about the reliability of those. So you look in all the places you need to to see that something has happened you sign that it's happened that signature joins the pool of signatures from other witnesses and that's the pool of signatures then constitutes your evidence and see the remotes of entity in place. Okay, next slide please. So another concept that's quite important in Corda Reserium interaction is vicarious trust. And the idea here is that we trust a party on another network such as the Corda Notary because an identity that we already trust on that network like our Avalto Ego and Corda trusts that party. So I trust a notary because you trust a notary and tell me that that's who you trust. So if the identity Alice's EVM, in other words, just a wallet on an Ethereum network trusts Alice Corda, it's an identity and a Corda network. That likely means that Alice at Corda holds or is authorized to send audited request to a proxy which holds the signing king of Alice's EVM signs messages proposing transactions to the EVM network. Next slide please. So proof of action in how providing verifiable proof that something has happened on the other network has two parts really. One is what I call proof of outcome which is does this transaction do what we want? And the other is proof of finality is this transaction finalized on the target network as it really happened. And proof of action on Corda that was just already said talking about draft transactions tends to look a bit like this. Alice at Corda receives a draft transaction from Bob at Corda. Alice Corda validates that the draft transaction meets its requirements. This is proof of outcome. So I am satisfied that if this transaction is finalized this is what will happen as a result. Alice at Corda uses the Alice's EVM signing key to create an EVM transaction that locks an asset on the EVM network in such a way that it can be unlocked if you can show a notary on Corda's signature on the transaction hash of the draft transaction because in the Corda network a notary signature is proof of finality. It means that that transaction has been notarized into final. And this is equivalent to saying that Alice's EVM trusts Alice at Corda of this signature X on this hash Y proves that the desired action has been taken on Corda. Next slide please. So proof of outcome is obtained via inspection of the draft transaction by a Corda that can validate it. And this proof is not really transferable onto the EVM network. Alice's EVM kind of has to take Alice at Corda's word for it. Proof of finality is given in the notary signature on the transaction hash. And the EVM network can check the signature if it can validate Corda's signatures which unfortunately don't use the EVM's signature scheme but there is solidity co-active and the signature data have contributed to the harmonia project which will enable you to do that. But it does rely on vicarious trust. Now Alice's EVM trusts this signature because Alice at Corda trusts it. So one of the reference implementations on harmonia includes a proof that a given business transaction ID can be found in the serialized Corda transaction binary data with a given offset. And that ID is marked off on the Solidity contract on the Ethereum side. And one of the questions we kind of wrangled about this is, is this actually meaningful? Because we have to depend on a trusted relationship to establish that the ID is being used in a valid transaction because the notary doesn't do any validating. Why don't we just trust the informant that said that they gave us our proof of outcome to say, had it got this ID in it? But the argument can be made that you do get some level of additional security because it's hard off for a compromised informant to have a faker transaction that has the observed property. So it does provide a little bit of extra reliability. You can kind of look into the serialized transaction data even if you can't unpack and validate the whole thing. And that's the idea of having little windows into part of the data. So it's quite a powerful one. Okay, next slide please. So on the other side, proof of action on the EVM. The Corda node can inspect an EVM transaction receipt and look at the data directly and verifies it contains a log event. So when you perform transactions on this area, you can emit events. And what happens to those emitted events is that they are written into a log which is stored in the transaction receipt which is associated with the transaction within the block that's added onto the EVM blockchain. And then proof of finality means we have to show that a core of validators signed a transaction block which has a given root hash. And then we have to give a Merkle inclusion proof that shows that the transaction receipt that contains the event of interest is included in that block. So you've got essentially a hash which is this thing that's been signed. This is the final on this network. And then a proof all the way up to a kind of tree of values that shows the particular event we're interested in appears within the transaction receipt that hashes into this Merkle tree which is included in the transaction block structure. Showing that you have... So I can just go back a second. Showing that you have a quorum of validators is much easier on a private Ethereum network which has a fixed validator pool and deterministic finality. And in most of the cases we're concerned but we're not actually dealing with Ethereum mainnet. And you can just say there's a fixed validator pool and N of M of these are signs therefore it's final. Okay. Just a quick comment from that as well. In the same way that you can prove an event in this way on Ethereum, you can actually also prove a... If the validator set does change, once again that's an event on the Ethereum network and you can use the existing validators that you have as a trusted set of validators to prove that that event occurred and there's now a new set of validators. So using the same mechanism I can actually update the validator pool on these permission networks. So it's quite nice for maintaining also the validator set. Yes, there's a sort of succession of authority which you can validate all the value on the chain. Okay, so a few sort of concluding remarks from me on this. So Ethereum's public APIs are not really designed to expose the consensus plumbing that you need to construct offline validatable proofs. In general, if you want to know if something's happened on Ethereum, you ask a node. And there's a general assumption that nodes are honest because Ethereum's internal consensus is robust against the tax. And so many existing interrupt solutions boil down saying trust me, be there or sort of intermediate party. I asked the remote network and it told me this had happened. There are protocols such as IBC which rely on the ability to construct things called consensus transcripts which are kind of offline variable proofs that consensus has been reached on something. But it's a bit of a challenge. Ethereum doesn't make it easy for you to do this. Core does ledger and privacy model are also not really designed to expose the material needed to construct offline validatable proofs. Even notary doesn't know what it's signing beyond it's kind of minimal marking or have input state hashes. The serialized transaction format is impractically opaque to clients who can't execute the JVM bytecode of the originating cord up. And so really there's not much alternative to vicarious trust as a sort of confidence that a proof of finality matters a notary signature completes a proof of action. In other words, this transaction did this thing on this network. So because of this, we make a virtue of necessity in our architectural principles and then you can read this under the working paper in the repository which is it's actually good to encapsulate the internals of the ledger and the consensus model as far as possible. You don't necessarily want to have to look too deeply into the other network to find out what's going on because that ties you to its implementation details. And it's a generally good architectural principle whenever you're integrating systems to try to encapsulate and to keep them as far apart as you can. Where it makes sense to rely on trust relationships to simplify proof down to attestation by someone you trust. So it's an alter ego on the originating network that is an identity which you control and which is kind of paired with your identity on the other network or witness on your own network or pool of witnesses. As far as possible, this is a simplifying operation is to use trust where you can. But then you want to make attestation pluggable. So parties can agree on what level of quorum amongst what authority uses the quiet. Okay, that's it for me, so handing back to Pisa. All right, so can you hear me okay? I've switched mics. Yes, you're quite clear now. Great, brilliant. So so far, if you jump onto your harmony and we'll send the links that after this. Adara, author of Contributed Finality, which is a FMI. It's a FMI that's focused for those of you on central bank backed tokenized settlement assets. So cash, central bank backed cash for the wholesale market. So it's the cash leg of a number of different settlement layers. So FMI also contributed some principles into harmonia. And in terms of contribution, you'll see there's a lot of documentation about the principles, some working papers and then some implementations. And the implementations are also fairly well documented. So there's a lot of documentation around the current implementations that are there, which have come from these companies. In terms of a roadmap going forward. So some of the things that we aim to do in the medium term is obviously incorporate feedback from the industry. So that would include both the existing projects that are looking at interrupt as well as feedback from the implementations that are either going live or about to go live, which cross multiple distributed ledgers and getting their feedback back into harmonia. So there's quite a lot of work around working with platforms like finality and others as well and incorporating their feedback back into harmonia. You'll see if you go into harmony and now there's basically two implementations, one that was contributed by our three and one that was contributed by Adora. And our aim is by the end of this year is to do a joined up version between Corda and Enterprise Ethereum that takes effectively the best of both. So as you can see, we spend quite a lot of time looking at exactly what those proofs needs to contain and logically what we can and can't use. And then also practically from a pragmatic point of view, how do we do it? So you'll see me, for example, on the Adora contributed reference implementation, we take a order transaction, so an AQP wrapped transaction and we break that down and we effectively build up a proof, if you like, that gets serialized in a Solidity contract. So we can prove that the trade idea is there and that the signatures of the relevant counterparties are on that data packet. So there's a fair amount of understanding of what the next Corda transaction looks like in order for us to be able to verify it on the Ethereum side. And I think the aim is, and we've had many workshops over the last couple of months looking at this is, is how do we simplify that? And once we really understand the typical principles, what can we do to make that process a little bit easier? But it does work and everything that's in there is working. One of the things that Ethereum doesn't natively have is a nice signer, so a mechanism to sign transactions. And there are a number of open source signers out there. But I think one of the things that will be contributed also before the end of the year is a nice Ethereum signer just to help run full integration testing to end. We are doing a presentation in November with the Cacti project. And so one of the reference implementations we'd like to look at as well is using Cacti to do an interop and to pull together using the Cacti, the current Cacti work that's really been done and see if we can utilize that to create another reference implementation that obviously it has to all the principles and requirements that are in there and others. So we're hoping to working with many others as well. And then the third area that we are focusing on is providing input into and getting feedback from standards bodies. So lots of really good work happening in that space at the moment to provide input. So we've leaned heavily on some of those standards that are already out there and we're providing input back into the standards and seeing them being shaped. So for example, the Enterprise Ethereum Alliance standard was a very nice standard to work with but it's very Ethereum focused. And so we're working with them and the ITF too. So can't we make this a little bit more generic and as you've heard as we've gone through there the basic underlying philosophy around some of these distributed ledges is quite different. So making it generic takes a lot of work and a lot of thought it gets put into those things. All right, so if you want to assume you're here because you'd like to get involved. So some of the ways you can get involved is if you're obviously with one of these things repose FXWAPs equity or bond settlements or something related in the wholesale market across different distributed ledges you can hold the rest of your left to work with you to see how we can help assist in terms of that interrupt capability. There's a Discord channel, feel free to join us and jump on to that. I think there'll be links that go out on there. Basically also just read the harmonia documentation on comments I made if you'd like. You can comment on Discord, you can ask questions on Discord. And there are a couple of open issues. So feel free to have a look at those and if you'd like to pick those up we'd love to get some help on that. I mean, obviously some of the roadmap items that I've just spoken about would be fantastic to get some people involved in helping with those. So that's all from us in terms of representation. What we'd like to do is to really open it up and make it a discussion. So if you would like to ask questions, I'll hand back to David that we are here now to facilitate Q&A. And I think we'd love to hear from you and to hear when you would, we have to see all your comments and questions about what we're busy with. Yeah, absolutely. If people have questions, feel free to just type in the Zoom chat or use the raised hand feature or just come off mute. We're happy to have a discussion. Any questions or comments that people have? I see one question just came in on Zoom chat. If Peter Dominic, do you wanna respond? I'm happy to give it a stab. And then we've got a few others who are probably more qualified to answer that than me, but I'll give it a start. So Chainlink is obviously, their background is slightly different to your problem in case that we saw them, but we may have some very good overlaps in terms of this. So if you go back to where did Chainlink come from? So the thing that they became really good at was providing reference data in a distributed and a reliable way into various on-chain contracts in the public space. So for example, if I needed for a bus, some kind of derivative, crypto derivative, I needed price feed, for example. They can provide, for example, the coin price feed across multiple exchanges in a very nice and very clever and very secure way. So that's their background is providing data from one set of entities into another set of entities. I think where we differ a little bit with what Chainlink are doing. And once again, we know them quite well and we like working with them. They're a great team of people. We will... So one of the things that they're a little bit different is that they've traditionally worked with public chains. And so it's very easy therefore to set up these relays between, for example, a set of exchanges and the Ethereum public network. Because you can, and you can do that and you can show how you've effectively got a very nice distributed and very untrusted way of doing things. As you've seen from what we've done, when we speak about LSEC portal and LSEC at EDM, basically that is a bank. So bank X will be connected to a quarter node and will be connected to an EDM node. And that bank has a number of potentially other back office processes that also need to be involved and will understand what's happening with the interrupt mechanism. And will certainly not allow anyone to access any of their nodes. It's definitely not their quarter node. And on a permission network, there's generally not an easy way to get in to see what's going on. So that's where, we've had some discussions with Chainlink and we've had a look at what they did with Swift and we are trying to better figure out how best we can work together. Because potentially they're a good technology company to help at least advance the conversation. But with the caveat that they've come from quite a different starting points to it. We started from, I don't know if you want to add anything and I'm at least going to look at it. I think the, one of the things that kind of has come across quite strongly talking to a Hermes in particular is that the world that we're in is a bit of a walled garden world. It is private Ethereum networks, private permissions quarter networks. And there's the desire to kind of get them to interoperate without introducing kind of public intermediaries. And so the, yeah, they're vast from having kind of infrastructure which you rely upon to facilitate cross-chain communication. The question is, can we kind of go point to point almost between these sort of different walled enclosures. And establish protocols that will enable them to be brought together without having to rely on kind of centralized or mediating infrastructure. And this actually is also a point of difference with I think Cactus as it was before it became kind of cacti and other approaches were brought in. I think I might have been saying that originally when Cactus and Weaver were separate projects, Weaver was distinct in this. It was an attempt to do in a similar way with kind of point-to-point connection. And now cacti is trying to sort of involve all of these different approaches. So we're very much on that end of things. It's the attempt to bring together walled gardens and establish a kind of a network between them where maybe the ability to use kind of public relays isn't viable for any number of commercial or regulatory reasons, for example. But a good question. Any other questions? If people, again, feel free to type in the Zoom chat or come off mute or use the raise hand feature if you have any other questions, comments. While we're giving people a minute or two to ask a question, I'll just reinforce what Peter said earlier. If you're interested in learning more, we do have an in-depth workshop about harmonia and cacti coming up in November. If you're interested in that, I put a link to the registration for that in the Zoom chat. So that's very similar to this. It'll just be a longer event. We're gonna go into a very more detailed session. So that's November 16th. Feel free to click on the link in the Zoom chat if you're interested. And I see there is another question here. So the short answer is that they transmitted data was as private as the network. It's transmitted across. Again, there's this kind of asymmetry of visions that I mentioned before, which is that even when it's a private, it's gonna identify as a cerium network. If you have access to a client of that network, you can see every transaction block and every transaction that's recorded on it. So that's the usual way of getting access to the cerium network and observing that actions have been carried out. So one side of a GDP swap or whatever is to see into the whole network. And so the only privacy mechanisms available in that case are either those built into some of the cerium-like networks. I know, for example, Bayesville has the ability to separate out different privacy groups or encryption of things. But fundamentally, you're looking into on that on the cerium side, even if it's a walled garden. If you can see into it, you can see everything in it. On the corder side, there is the corder privacy model essentially entails that you can only see what a node that you own or control chooses to share with you. There is no kind of global visibility of things. And actually typically even in sending over a transaction, you may send over, because transactions are organized as merkle trees, you may tear off whole chunks of them. So you only expose as much of the data that is needed for the other party to verify that it has the characteristics that they want. If you're relying on trust mechanisms for your proof of outcome, it was to tell you that this transaction actually does what you want, then ultimately all you're seeing is a signature on a hash and all of the other details are completely included for me. So in that sense, privacy of the corder network is very strongly maintained. And yeah, and the main point is that there are no public relays involved. Other than obviously sending packets over the internet, which you secure them to use all sorts of ways. Yeah, so maybe just on that as well. So remembering that it's typically bank, internal bank communications are between the access to the corder node and their access to the EVM node. But even within next, it's typically encrypted using interlace or something else. And often those system accounts are locked down so that any specific accounts can access the containers. So there's internally within the bank, there's sidecuff boxes and various things. So it's very locked down in terms of getting the information in and out. And then I think just on the point that Dominic was making on the Ethereum network, because generally Ethereum, we're seeing a lot of cash ledges that are using Ethereum. They try not to leak information from other systems onto them. So a lot of the information is cashed. So if you would need to be account party in the transaction to be able to understand what's out there. Obviously, once you know that it's there, you can prove that the correct data is there. If you have the pre-image material yourself, which normally would get from somewhere else. So yeah, so there's a lot of effort put into ensuring that the communication between the two networks is quite well locked down. There's another follow-up question that's, can you say more to describe the kind of tech summary of interoperability mechanisms and how many assets in that? So yeah, I think Dominic covered that quite well. It's largely internal within a bank. So the transmission of the proofs or the attestations are done internally within banks. Not to say that we are, we're providing single points of failure, because typically within a settlement transaction, so what we call delivery versus payment, delivery of securities versus payment of cash, you have two banks involved. And either bank typically is able to to pick up and complete something. So if one bank doesn't transmit an attestation, it doesn't transmit a proof, the other bank can do it in order to finish the settlement off. And there are in some cases other trusted intermediaries that may get involved. So sometimes the trading platform or the clearing agent in some cases is able to to be involved into complete settlement. So there are a number of ways of making sure that we're not locked down to a single point of failure, which is obviously what some of the public interrupt mechanisms try to make sure that, there's no single point of either failure or of the data being impacted. And so there's no single point of either failure or of the data being impacted. So having multiple paths that all have to agree with each other with some kind of consensus mechanism is the way that they could resolve. So we have a much more, I suppose scaled down version of that, but then much higher level of trust because it's bank A, speaking to bank A. Yeah, I think in terms of taxonomy, one way to look at it is that the grand sort of design and promise of most interoperability solutions is to say we will define standards and protocols that will be kind of pluggable at the periphery. And through that, you will be able to plug in network A, B, C, and they will all be able to talk to each other across this set of protocols. Now, sometimes across some common infrastructure, whether it's kind of relays or whatever the mechanisms are for kind of coordinating actions between networks. But the goal is very much to try to sort of produce as the classic enterprise integration architecture where you have standardization of the level of APIs and protocols and then plug it in this year. Everybody who wants to come and play comes and plugs into this kind of network of things. We're starting at the other end here. We're starting with two quite well-defined systems and trying to work out in detail what's reliable into what between them. It's actually fitting within the kind of regulatory requirements of the banks and sort of institutions and there's a work for what that looks like. So we're solving very kind of post-glained problems in order to get one solution in detail. And I think these two approaches can meet in the middle. I think in the longer term, hopefully the work we're doing will feed into cacti and perhaps movement in both directions. But we're very much not starting from the, we're going to design the DVP protocol as everyone views. We've designed something that works for a very specific pair of parties that work in very specific ways. And then we're looking to kind of generalize out from there from what we learned as a fundamental level about how you construct proof of action from these different kind of systems, how you transmit things, how you interpret things. All of the kind of questions I was talking about in my set of slides earlier. So it's a focus on a very particular part of the landscape from which hopefully there's things that can be learned that will then be useful more widely. Yeah, I think going back to that first principle, we want these to be rooted in real-world applications. I feel that the quickest way for us to learn and for those to be adopted is to get them out there and get them processing transactions as quickly as possible, so. And the real world part of that is not only the technical constraints of the systems, but also the institutional constraints of the regulatory constraints. All of the things that actually come into play when you try to do work with banks and there's always more of it than you think there's going to be. Great, I see a few people have been asking for the slides that there is a link to the presentation. And it's all open source, so feel free to share that as well. Yeah, I will also look in your email, I'll send an email out around with the slides and the recording and other resources. So if you want to check things out, feel free to do so. But yeah, we did drop the link in the Zoom chat. There was also a discussion, or there's also mention of the discussions will be ongoing on the Hyperledger Discord channel. I dropped the link to the Hyperledger Discord channel in the Zoom chat as well. If you have any questions after this meetup ends and you want to ask people, feel free to join us on the Harmonia channel on Discord as well. Before we wrap up, are there any last comments or questions? Just for me, once again, thank you very much, David and the Hyperledger Foundation, it's been great to get this going, not just this today's event, but the whole process leading up to today. Yeah, of course. And thank you, Peter and Dominic, for your time today. Thank you very much. It's been a great experience. Yeah, well, thanks everyone. And again, we hope to see you on Discord. We hope to see you on the workshop coming up and feel free to check out the links that I'll send around an email right after this. Thanks everyone. Thanks everyone. Thanks for your time. Thanks, bye. Cheers. Dang.