Hyperledger Foundation Fabric, 6 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Creating a Retail CBDC Prototype With Hyperledger Fabric - Imre Kocsis, Budapest University of Tech

Description

Creating a Retail CBDC Prototype With Hyperledger Fabric - Imre Kocsis, Budapest University of Technology and Economics

While the debate about CBDCs has been going on for years now, there are very few publicly accessible implementations. This was even more true in 2021, when in a research cooperation with the Hungarian National Bank (MNB), a team at the Budapest University of Technology and Economics (BME) set out to create one - as a prerequisite for researching the future applications of CBDCs in smart contract ecosystems. Join for this talk Imre Kocsis, a lead expert of the team who created this hybrid CBDC prototype, who gives a tour of the design goals, design decisions and the implementation. The technical highlights include an Ethereum-style pseudonymous CBDC ledger over Hyperledger Fabric; financial institutions acting as CBDC minters (by conversion) and end-user transaction relays; and financial institution based "bridging out" of a CBDC to a permissioned Ethereum network, using Hyperledger Cactus. Performance figures are also provided. Maybe even more importantly than a proof-of-feasibility for a Fabric-based retail CBDC, many open questions became apparent; e.g., the regulatory compliance of private blockchains "trusted" with CBDCs. An overview of these challenges will be also given.

Sessions Details & Slides (if available): https://sched.co/14H67
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)

A

Hiyo, so this is I believe the last session for today. So thank you for all the marathoners who who are still here.

A

um My talk is about creating retail cbdc prototype with Hyper lateral fabric, I experienced report of sorts, if you like so disclosure and acknowledgment, this work was performed performed under and finance through a research project at our University by the Hungarian National Bank, meaning that this research was done in cooperation and under this framework, but not actually at the National Bank of our country. The participating departments were R1, the measure Department of measurement and information systems and the department of telecommunications and media informatics.

A

Now the context of our work is actually not cbdc directly or only on its work per se. Our work stream is more about the smart contract ecosystems in general, industrial and financial use cases benefit ecosystems, and certainly the impact of enabling the usage of coming cbdcs in such use cases, but to assess analyze the impact of cbdcs in industrial, smart contracts. It would really be beneficial to have a cbdc actually at least on the technical level, so as part of our work, something like that was created and I will share that today.

A

So what I will talk about today is very briefly what we see, at least in academic literature, on the industrial usage and requirements of smart contracts and specifically payment modalities. What are the possible no force in payment models for distributed? Ledgers and I will showcase present a hyperledger fabric based cbdc prototype with the twist that we are actually bridging out cbdc to dlts of industrial cooperations from that cbdc ledger and as closing remarks, I will talk a bit about sidechain auditability and what we already see the little that we already see about compliance requirements.

A

So we've performed a somewhat extensive literature review on Industrial or industrially aligned, so not purely Financial smart contracts, smart contract ideas, models, topics and explicitly filtered those use cases where some kind of financial settlement is to be performed, and we see quite a number of Indus of interesting use. Cases which, for most of you may not be new, certainly in machine to machine scenarios.

A

People are talking about payments micropayments for industry, 4.0, business processes, those are certainly business processes, but at the end of the day, some bonds somewhere pays in the process. Actually. Otherwise, it's not necessarily that that interesting in the digital twins, space and now there are ideas emerging about making digital twins of Commodities, and when we are talking about Commodities, then commodity exchanges come up forward contracts and the like, and even the more classical digital twin Concepts, do involve in the life cycle of various payment operations and aspects and the construction economy.

A

Building uh building uh Industries are beginning to talk about various dltbs based schemes, for instance.

A

It would be supposedly very nice to be able to create the lt-based based project bank accounts, where the financing for a project is put in escrow and everybody is paid at the same time from the still existing funds when, when the building is actually created,.

A

um Certain similar services are provided by certain banks, for instance in the UK, but this is a Specialized Service and even when a bank provides it, it's quite rigid and certainly many people have been talking about circular economies for a while the asterisk is there because I don't think that we really see that what will work and what won't work from those ideas, but still those will need some kind of payment, and actually what this distills down to is that the important part is automated and final settlement according to agreed upon rules and distributed Ledger technology is not the goal, just the actually first feasible looking means to provide such services at scale in a generalized manner.

A

But if you look at the uh all the papers that you can find, um the exact payment modalities or payment rails are actually typically left quite under or outright unspecified. So what would a payment difference? Infrastructure look like for a distributed Ledger which conducts industrial business in the very broad sense. Ideally, it should be some kind of digital currency or easily and almost risky free or risk-free convertible to digital currency.

A

It should have some tolerable platform level, financial and Technical risks, so stable coins are not necessarily a good match for incumbent non-digitally native companies should have low transaction costs and settlement delays. Smart contract control settlements should be there, so this is basically a wish list. Let's see what we can do, there's a rather good paper on the current near future and further out options for payment.

A

Rails, essentially for dlts for smart contracts in mostly permissioned settings, and there should be nothing really new in that you can always do trigger Solutions. The smart contract decides to do something: the smart contract issues, a CPA transfer or whatever else transfer, and it has to wait for confirmation. Someone has to bring the confirmation back to the smart contract, so the logic of the contract actually gets quite involved quite fast, and it's not really true that when we decide that a payment should happen that it really happens. So we can forget about atomicity.

A

uh We are beginning to talk about Euro referencing e-money tokens, but those are still a bit further out. Mica is edging to actual implementation. Let's just say that, but until that arrives everywhere at the national level, that's a bit questionable synthetic cbdc's will be something that will be possibly available.

A

So a bank has some amount of cbdc and uses that as a one-to-one backing to issue some token on a DLT Ledger and the fourth category cbdc's in general is what is possibly the furthest out and possibly the most interesting, because we don't really know yet how those will be integrated into dlts permission dlts, and this research was to simplify about that. We did have a hard and quite long look at the at those retail cbdc implementations that uh seem to be shaping up.

A

Let's just put it this way, so there are at least some technical, architectural documentation is available and there are a few takeaways from this one. We all know this. Everybody is experimenting with various models and it's all well and good. At that level, we have all kinds of Technologies. Hyperledger is uh uh quite overrepresented rightfully so, but when you begin to look at the architecture and smart contracts, the picture that begins to shape up is that one?

A

um Not not. Everybody is actually thinking about decentralized Solutions at the highest level, at the authoritative Ledger level and the smart contracts, in the sense that smart contracts that that serve the general public as well as businesses are not really on the table.

A

So those are not actually do not seem to be a primary concern of the central banks at the moment that are thinking about issuing retail cbdcs I'm speaking about retail, because in a strict sense, wholesale cbdcs are for the financial sector, and this is not strictly about the financial sector and we did filter out such projects where we couldn't find any meaningful technical documentation and also commercial platform offerings due to the nature of our research efforts and as a source.

A

Let me just pitch here the hyper-ledger cbdc paper, because it's really good if you're interested and haven't checked it out, do so so takeaways, no smart contract support on the top level cbdc Ledger. This doesn't mean that there will not be programmable money, but the programmable money. Smart contracts are actually are actually the smart contracts of the central bank or of various State bodies, so heavily controlled pieces of code.

A

They can be expected to be, um and it's actually quite understandable, that wide scale smart contract support is not planned right now for the top level, cbdc Ledger B, it's centralized or decentralized. We all know that there are hard to avoid performance issues if one begins to allow various smart contracts to live on a sizable, Ledger and those things actually don't really belong conceptually there either. One can argue on that side, and what we see is that in most cases where the architecture is well hashed out, there's some mechanism for Distributing Downstream.

A

The asset from a ledger in the Euro area is actually in a quite special position, because there's a there's Market infrastructure at the Euro levels. So we shouldn't really expect that the tip system will be replaced so most probably something building on that will arise and almost all architectural models are being mag about, except the one that I will show here, which is bridging out cbdc into a decentralized system from a decentralized system.

A

We don't see open code, typically, there's only architecture, descriptions and the obvious exception is certainly by now open cbdc, which is a project that I'm somewhat of a fan of, but that's a very different Beast, so that transaction processor is at the moment, is not really comparable to all these initiatives. So what did we create to experiment with, and hopefully we'll also make more widely available than how it is now? One uh first design decision was that we will create a cbdc where there are ethereum style, pseudonyms and balances.

A

Read we are we created ethereum addresses and balances, and we did that over fabric. You can do that. You can Implement many things over fabric, famously even you take those as one can read in the hyperledger fabric design paper um these. This is good because there are readily applicable privacy, preserving techniques. If we want to have private handling of assets, then, as long as zero knowledge proof schemes remain to be applicable, they are not broken. We can just copy over technology from the ethereum bird to create privacy enclaves for handling assets.

A

If you like, but that's just one example, there's enough design room for kycaml I will show one simple solution: there's enough design rule for implementing a travel rule, if that's applicable at all, because when private parties are sending cbdc each other, we are not sure that the travel rule applies and there's enough design rule for wallet attestation schemes schemes where a independent party continuously checks, whether the volatility Integrity of a user is still intact. Professor Horton from MIT is publishing some nice results and thoughts on that.

A

It's easy to bridge to ethereum and it meshes very well with SSI simplest approach. One can register a ethereum address, Sid ID. We can get a verifiable credential for that. We can even get a verifiable presentation. Zero knowledge proof verifiable present presentations for that. As a matter of fact, we are thinking about SSI based schemes where we could make the cbdc so inconvenient to handle so slow that it's as inconvenient as cash. So possibly we could keep up the existing privacy guarantees.

A

We don't know that and that's a tangent but SSI mesh is very well with this world if you use pseudonyms. So our core Ledger is implemented. It's finished, it was a feasibility experiment, and why did we choose that well to see whether it's feasible and we get out of the box? Dlt guarantees, certainly- and we did a cactus-based cbdc breaching to permission the E3.

A

You essentially, you have an ethereum address your private key in your wallet and the idea was to be able to frictionlessly shift the money on that address from a cbdc ledger to a sidechain ledger and back using the same private key, which is also a technical simplification on our side. Now most design work during was done during the first part of 2021. Since then, we've been doing small stuff. That has to be done so some extant results that appeared since then are not reflected in this work. Yet The, Logical architecture looks something like this.

A

We have a cbdc ledger and the Central Bank does not mint the asset on that ledger. It just gives financial institutions and allowance to convert Norm other forms of digital money to cbdc. So it's a conversion based asset, and it also has the power to perform legal seizure and freeze operations. In reality, somebody else would do that, but we wanted only to have a single regulatory party in the model.

A

Now the members of the public and businesses have direct pseudonym's legal claims on the cbdc simply put I have the if I have the private key, then the money at the accompanying ethereum address on this Ledger is mine period period uh to prove that I don't need any financial institution. Financial institutions instead do do things. They are the gateways in a technical and monetary sense to the system, so I as a client can convert other forms of digital money to cbdc and the financial institutions, and they are Decay by saying parties.

A

So they give my account. Some level of cable I see that they say that they gave me that level of kyc and the personal information below remains with the financial institutions, meaning that the central bank and other parties who may operate this Ledger don't see readily Who's Who, and that may be a requirement on the part of the issuing party.

A

Now uh this is a legal relationship, identity, custodian and kyc provider and authorized cbdc mentor on a technical level. What we came up with is that the financial institutions should be also gateways so in fabric, they will have fabric level identities and they are the ones who bring in the ethereum style, signed transaction requests of the clients counter assigned by their fabric identities, and this is pretty much necessary to keep the performability and possibly also the security of the system intact.

A

So The Ledger is rather simple. We have ethereum style accounts, those have a kyc label issued by a financial institution. We also introduced a number of further simple Financial Primitives, based on an analysis of well the most widely used, crypto Financial Primitives from Bitcoin and ethereum. We have hashlog transfer time, lock, transferred transfers, the combination of which should enable also Atomic swaps, although we don't really want it to go in that into that direction, and we have direct withdrawal.

A

Authorization I can give an authorization to the utility company to take away the appropriate amount each month at a technical level. We implemented this Ledger model in hyperological fabric. Smart contracts chain code created a Gateway layer for the financial institutions in this system, who do not necessarily have a node themselves in the fabric Network. That's a policy and deployment decision. We were not in the position to make, but this wasn't necessary to make.

A

Actually, we created a Gateway for backend application for the central bank, that layer communicates directly with fabric using a fabric API and in turn the user applications talk to a rest, API, so no fabric stuff there. On the contrary, we have ethereum Style transaction signatures and you can Implement their whatever identity, checking and authorization that you would like to do.

A

But, importantly, given that this layer in this layer via the client is not tied necessarily to the financial institution as a client, it can happen that I cave IC at a financial institution gets some funds, but for performing transactions. Posting transactions into the system I'm actually going to somebody else, whether there's a payment mechanism behind we left this open too. But this is a another point where this architecture allows allows for some agility I. Don't really want to go further into the technical details.

A

One point where we didn't spend too much energy is creating a wallet, so this this is something very simple just for demonstrational purposes if it has any. uh If it has any meaningful message, is that what the end user Sees at the rest API that's pretty much in line with the functions that the financial institutions proxy into the fabric-based cbdc system?

A

Okay, how performant? Is it not too much, but we are hopeful. Let's see what we did: cbdc micro benchmarking. What we had is a for a university Cloud, sizable system of many virtual machines. All of those lilac colored boxes are separate virtual machines. Each VM had 8v CPU, 16 gigs, one gigabit per second Network so well could be better but already good to make experiments. We did implement it.

A

Two forms of benchmarking, hyperledger caliper can issue open loop, lobes and that's nice, because we can hit the system irrespectively of how it answers and they also implemented some measurement in jmeter because, on the contrary, it's able to simulate users who are waiting for transactions to come back because they want to do the next.

A

Only after that, and now we are doing pretty much constant load, which is defensible because blockchains Implement, a kind of latching mechanism transactions come into a block and only go further than the block is full or when the block time is over. That being said, it would be very nice to have an open representative load model for cbdcs. So if anybody is with a standardization body, then that would be nice. We know for a fact that such models exist for the Euro area. We haven't had the chance to have a look at them.

A

They are not easily accessible, latency wise. We are good, but I think we all know that with fabric one can go under 500 milliseconds, easily module or network network traffic. But well, if you are operating a fabric Network, then you probably should make sure that the connections between your nodes are highly are high bandwidth, low latency, what's possibly even more interesting is the throughput for which 300 350 transfers per second can work. Now for this Hardware, this is actually good. There's much room for improvement.

A

If we look at reference sizing guides for hyperledger fabric, those are actually stronger. Hardware and the sky is the limit. Scaling out up should not be a problem, and I would like to make the slight remark that we are not hypothesizing either the Euro or the dollar area. So, even though this is a research prototype, we are in Hungary a country of 10 million people, so the magnitudes are not the same.

A

We created some nice visualization for analyzing our performance, the end result of which is that the various sub tasks that are being done during transaction processing are quite evenly weighted.

A

There's no bottleneck right now, with stronger Hardware, stronger single core performance, and certainly after a while some tricks with the validation phase the performance can go up, should be able to go up scale up quite easily now the somewhat Noble aspect, bridging logical architecture.

A

So what we say is that we will have a side chain and we can do the industrial collaborations. They are just as we saw with KBC bank, because I really love that presentation, because that rhymes with this pretty much and we have a financial institution who had the logical level orchestrates this bridging I as a member of the public or as a business log down some funds on The, cbdc Ledger. Those are my funds: I, don't give them over to the financial institution.

A

I just put them into custody into a custody upon which the bridging financial institution can act. Let's put it this way, so it's not exactly the same, like notary schemes in their strict definition and I still have my indirect claim on the bridge cbdc. But after it's been breached out. This is simply a simple, two-way pegging.

A

If it's familiar uh this way, then I can begin to use them on the side chain and give it over to somebody and when somebody wants to bring back out of this cooperation the funds, then they can just simply Bridge back burn the assets on the right side and see them being released on the left side to their address. Now our initial implementation was based on hyperledger, Cactus and token bridge and some custom contracts on the left side.

A

So the logic is that the end user issues a request to one of the financial institutions that they want to do some bridging they act post, the post, the transaction into the fabric Network and after that they tell Cactus operated by a financial institution, not necessarily the same that there are some funds logged there. Please Bridge them out.

A

The bridging happens to a private, ethereum Network and a mishmash of top contracts from the token Bridge Project receives them is used them as erc20 tokens, and you can do smart contracts with settlement in electronic Hungarian foreign, which we hypothetized for this use case. After that we didn't well, we we have a very bright Young guy from Lisbon who's, an incoming student, PhD student I. Think at the group of Rafael Bell here, Andrea Gusto. He did the improved approach. Actually, there are standards for bridging assets between trusted, pretty much private consortial blockchains.

A

In the drafting phase it used to be called odep open, Digital asset protocol. Now it's called secure, ASA transfer protocol. They are in drafting status at the internet engineering transport task force. We will see what comes out of this. They are shaping up very nicely. The end game is that these this protocol will provide asset properties for asset transfers under the assumption that I can trust, The Ledger a and Ledger Bay Ledger B. They both have gateways, and it is the gateways who are doing a resilient protocol.

A

There is a prototype for available for cactus, so the idea was that let's wrap that and Andre did, that under our guidance, it's uh still more of a notary scheme than a trusted relay Cactus is called a trusted relay because, under the assumption that there's a permission, consensus on this Source Ledger as well as the target one can do such schemes where some parties sign some known parties assign a transaction on the source Ledger and the target Ledger can actually look that action, whether it's true and in the reverse.

A

So the trust that I have to put into my Cactus instance to be specific is much lesser than what would be needed in a classic on permission. Word notary scheme for the further details see the great article of back here at on, but we are actually for this use case. Okay with that, because really putting a regulated institution in between a DLT and a cbdc ledger, that's not a too far-fetched idea.

A

We believe and anyhow Cactus will allow for validator consortia in the future, so that bridge layer will be able to do consortial like decision making. Hopefully it's not able to do it that yet so what Andre created in his mentorship is uh seems to be a bit complex, but it's not that complex at all. There's the implementation for the Oda protocol pre-existing implementation for the other protocol in Gateway, One Gateway, two with a connector for bizu, with a connector for fabric and that's the magic there. We don't have to deal with the details there.

A

On the left side, we have fabric one channel. In this case we have a single Organization for Central, so for simplicity's sake, where Alice and Charlie have fabric identities and can hold cbdc um and there's a asset reference layer. The Oda protocol in the other protocol Leach asset, has to have a specific, explicit, sl3 friends. So that's the technicality. We have to wrap a essentially non-fungible asset transfer protocol to make it able to transfer fungible assets, but it works and it's nice and uh if.

A

We want to see it in action, then it actually works works so what's happening here. Is that vrs growing the cbdc that we want to bridge out that goes into escrow? You see the bridge is holding the bridge, account. Identity is holding that in a chain called, and we say that we want to bridge out the previously created escrow with that ID and after a while it appears there and we can transfer over a bizu. The usual ethereum way the funds and we can Bridge back.

A

So it's essentially that so in our system we also created a demonstrator there's a EU wide, quite large project called Arrowhead the narrow head tools where our colleagues from the other department very involved and their industrial cooperations, supporting local Cloud software and solutions for industrial cooperations is being created, and one of the last stages of that project was to create smart contract support for the various cooperations of the very, very, very industrial parties involved in such Muslim manufacturing activities, and they created contracts for asset exchanges for for forward contracts and a few other similar Financial operations, for specifically for the manufacturing sector and without involving any heavy machinery and logos of well-known Swedish car makers.

A

This is a conveyor belt with two robots where the two robots are actually paying for each other on the DLT for the handling over of the little yellow rubber ducky. So as soon as the second robot takes over the asset, the payment also happens in the DLT okay. So after this small, hopefully a bit at least a bit comic relief. There are certainly open Regulatory and compliance questions, most of which we are actually not able to answer yet because uh which Central Bank has already cbdc, for which the bridging compliance requirements have to be defined.

A

So this this is a bit far-fetched, still I hope. There are a few uh thoughts that are worth to consider so Shifting. The money out to another Ledger also shifts a whole bunch of responsibilities to the other Ledger and most probably the central bank, as well as certain regulatory. But these are fine with that and actually will want to have that shift. There are anti-money laundering and cfd regulations and there are regulated activities for EMR CFT. There should be some certainly proof of compliance mechanisms and, on the other hand, for regulated activities.

A

There are permit obligations simply put. We won't just really nearly allow cbdc to be breached out to adlt, because we really don't want people or companies to begin to engage in, say, shadow banking activities. Most probably we don't want to do that.

A

So, although on-demand auditability will be in theory present, so we can say that the DLT the side chain has to submit time-to-time cryptographic commitments about its current status and the regulator can go there and look into the books in both fences into the blockchain as well. The actual books, um some form of continuous compliance management, probably will be necessary, but the specific requirements are still unclear. That being said, having a heavily regulated party as either a compliance Gateway or as a compliance, enforcer and there's a whole will be probably necessary.

A

So this is one of the one of the reasons for us going for a architecture where we have a financial institution performing the bridging for some small fee, certainly now mathematically continuous confidentiality and privacy, preserving compliance, and proofs of that seem to be also somewhat doable. But it's still quite early days with that I mean that I have a DLT. The DLT doesn't want to show that who does what? Who owns whom? How many millions of Hungarian foreigns on that ledger?

A

Many of the business confidential aspects are simply not the business of the regulatory bodies. Still can we make some proofs over handling the money, the way it should be handled? There is actually some priority for that with different angles than we are doing. Zk, Ledger and zika IRP chain are two which have to be cited. What we did a initial prototype for is an AML CFT related challenge. Let's show that only transactions between hello, listed addresses have happened on that DLT. So, however, we are passing around on money in the DLT.

A

It touches only hands that have been fingerprinted to drive the uh parallel a bit further than I should how it should be done for general purpose requirements. For instance, have you paid your vet if you have to pay vet on that chain that that we don't know yet, but you can create nice, zero knowledge, proof based audit protocols. For this we had one prototype for interactive zero knowledge proofs in zilch that has quite serious limitations. So now we are putting together something in the Socrates toolkit with ZK snarks, still somewhat costly.

A

So on the order of magnitude of the transaction testing tax in Hungary, that's depending on your point of view, not necessarily trivial. Most probably, the solution will be to move away from ketchuk and sharp based um hashing algorithms in the transactions and use something zkp friendly, but that's that's all fully technical for this presentation. So in summary, we created this a hyperledger fabric based cbdc Ledger, with ethereum style addresses pseudonymization.

A

We created a financial institution, operated bridge that falls somewhere between notary schemes and trusted relays and should be able to move toward trusted relays, and we have shown, unsurprisingly, that if we can breach out cbdcs, which Remain the uh which remain in the hand of the original owner throughout the way, then we can do very useful stuff using uh this scheme.

A

Okay, thank you and thank you for staying with me until yes, six o'clock on the second day of this, certainly very great but quiet dance conference.

A

Do you have any questions.

A

Thank you so much. Yes,.

A

A

No, um our prototype supports privacy in its current manifestation, and this is a bit dirty engineering trick as much as ethereum supports privacy. So a end user can create multiple pseudonyms and register them, possibly with different financial institutions.

A

A

A

A

The parties operating the Royal Ledger I didn't want to go into that because that's a quite contentious point for other cbdc Solutions too. What we envision is that this is the Central Bank and a very limited set of parties who descend most probably State parties, State bodies who the Central Bank trusts. Okay. So this is defense layer, one if you like. The banks won't won't, have full read access on The Ledger, because why would they have? They are clients of this? Of this Ledger.

A

You can see in the clear the ethereum style, pseudomized transactions and accounts. You can see the amounts you don't readily know who owns how much.

A

I was planning to.

A

I was planning on doing that. Definitely that's why I'm I'm! Actually, why I'm straying for staying for tomorrow, but the last time we looked at the fabric, token SDK, so more than half a year ago, I think or almost a year. It wasn't there yet so.

A

I mean from other aspects, so we we discarded that quite early, but now I will learn the specifics. Okay, but as I said, there are schemes for through privacy in the ethereum world which were available. uh I, don't want to make a mistake, but Stark there I think Stark bear had a nice privacy Enclave.

A

Yeah sure but sorry yeah, but it's not the verification. That's the problematic part Computing. The proof.

A

Yes, so long story short there are, there are actual schemes we left it at that when we have pseudonyms and then we can have ethereum size transactions and why couldn't we have because over fabric we can create that and we will see what you actually created you can plug.

A

It in part of the question is that you can't say in advance that what's the style and level of privacy that your central bank will want to have and up until that point it's in this kind of research, it seemed to be a better, better decision to take a point where we can from where we can start in many directions: okay, I'm, not, maybe there are a bunch of privacy models.

A

If you look at the, if you look at the Canadian model, X challenge or sorry challenge X, they had some very nice ideas about the users being completely private, but businesses who are receiving the money being completely unprivate, so there's a whole range of options until a central bank decrease that we want this privacy model. Who knows this? This is a safe play. Okay, we. We are interested in that aspect, but we were content with this for now.

A

Yes, it was a quite long-winded answer. Sorry, any more questions. Yes, we can.

A

A

A

A

A

To be able to go.

A

Yes, they'll give you, if you have a million dollar loan, I I, doubt whether the.

A

They will probably take, but with cbdc such friction does not exist because you can act.

A

A

A

A

It's a question for economists, I love economy, but by trade, I'm, a computer engineer, I, don't know, I really don't know as Jackson, but.

A

You know obviously, we've had all these problems. I read very nice analysis from the FED St Louis. They had nice papers on pricing, the classic money and cbdc and showing that they run to cbdc should not be, should not be possible under the correct pricing to me. It checks out, but I'm a simple computer engineer. I I see the need to introduce limits to conversion.

A

So absolutely that's in there to me, the finer details are at the monetary level. Are somewhat intractable, I, don't know so. Yes, how this will look like in in action. Not this necessarily how CB this is, and creation conversion destroying pricing will look like I, don't know: yeah, yeah, yeah, sorry.

A

In a sense is the price of the money, but again I'm I'm, an armchair economist at the best yeah.

A

A

A

Look actually what we did is also a sneaky way to trying to integrate what already happens right now with the banks, because what we say is that we have a financial institution, they are already doing K by save.

A

Yes, you can do this even remotely and I know it's a big challenge, but the good banks have already risen to that challenge practically so they can attest that who is who then in the cbdc context, let's, let's make them a test to who is who and from that point of view, let's let lying Ducks lie, I think the English say so, yes, that can work, but that pretty much plugs in into this, where the kyc information comes from. That Banks already incumbents already know that.

A

A

Great question: yes, yes, indeed, Okay! So three things, you know! Yes, one! um You have to trust your central bank to at least some extent anyhow, because why are you a bank? If you, if you don't trust your Central Bank, you know so you can't. This is not the world when you can make everything on permission and everything based on distributed. Trust because it's it's not that world, because the state brings the money period. And I could put it nicer, but that's that's the gist of it. Two based on authenticated data structures.

A

They don't know which process there are means to counter check what the Central Bank there should be means to counter check what the Central Bank says about the current state of The Ledger. So they can make cryptographic commitments about its state and give you some material to check it. Think about Bitcoin, simply simplify the payment verification.

A

It has its limits. I, don't know to what to what scale it works, but should be doable. Actually, it was classically. It was called authenticated data structures. This network has morphed so cryptographic magic, that's a solution to and the what was. The third part I forgot.

A

If you have access to the state commitment, State commitment and a path along the miracle tree, essentially so you don't have to have the whole Miracle tree, you may have the hole actually because we won't help you much about the funds of the other people. Just you are doing the hashing.

A

Yeah and now I know that yeah.

A

Yes, almost yes, yes to the financial institutions is no different, and that was the third part of the answers to your question. um Dlts are resilient infrastructures. Okay, so if you begin to think about the requirements for a truly critical Financial system, then you begin to introduce such requirements that a DLT not fully but pretty much checks out and you would have to build into a non-dlt solution. Anyhow. This is a very bold statement.

A

I know and vipin, who has quite a bit of experience in that world may may reprimand me for that, but I'm the central, let's say: I'm the central bank I have Department a department, B Department, C geographically distributed uh put a fabric. Note there there there make them all different organizations.

A

Then, if I have a single malicious party inside my largest organization, who wants to do something with the Ledger, they won't really be able to do that because they are doing it from one side. I know that using that there are database Management systems and server systems mainframes where there are physical and software defenses.

A

Against that you know, a DLT makes sense, not necessarily for the reasons uh that they were created originally and if there's a such a privacy setting where we can apply privacy, preserving techniques, actual privacy, preserving techniques, Over The Ledger, then it becomes possible to distribute that layer, the fabric layer across the financial institutions, and then it's a true DLT.

A

Okay, again tell me your central bank's privacy requirements, because if there, if the requirement is that we should be able to see that who's, transferring whom, what money after collecting the kyc informations legally from the FIS, then you won't really want to include the FIS in the network, because there's such a thing as transaction graph analysis, because, yes, there is so, let's not give them the whole graph. Yes,.

A

A

Again, policy question and I'm: not a central Banker.

A

I think it will be possible.

A

Central Bank is a very bad.

A

So they all came with money.

A

They only printed to distribute it to their second job.

A

If this becomes possible, then the banks will scream obviously because.

A

What about 20.

A

Maybe you can have it at home.

A

Actually, in this model, all sorts of interesting things, at least to an engineer, become possible, so financial institution right now here means something regulated classic Bank, but there are other somewhat trustworthy companies already handling significant amounts of money. Tech operator there may be a level of kyc where you just use your phone, you can have a million foreigns on your phone, so you don't have to go through a uh through a classic financial institution channel to have and access digital money.

A

Now the problem with that certainly is smurfing, and that's where I at least personally I see immense potential for SSI, because if you have a single government issued.

A

Let's just say uh generator key from which you can instantiate your pseudonyms, but are cryptographically linked back to that one source that you are that your state gave you then, at the systemic level, again too many shoots, but we should be able to see that how much money does that person have exactly across his or her keys, and there are zero knowledge.

A

There should be zero knowledge approaches to that too, but that that leads provide far and I'm constantly looking for cbdc, plus SSI results and right now, what's out there is yes, the two should be connected. That's what you can see in various official Communications.

A

So but again there should be some quite interesting models and bokong is actually doing that with cell phones in the account I think Cambodian cbdc.

A

So that's in and of itself. That's not not my idea. In our system. Offline things would be a bit tricky because, due to the ethereum model, we are also technical detail using the nonce mechanism of ethereum. So offline payments are somewhat tricky, but that should be also doable so it it will be a if and when it arrives. This will be a potentially a very interesting ecosystem made with multiple layers of players. So why couldn't your talk operator be a cbdc payment service provider? Let's call it what it is.

A

So I think we are past the time. It's it's. So thank you so much for being here again and hopefully it was useful thanks.