Implementing Privacy Pools on EBSI for Programmable Privacy & Compliance - Eugenio Reggianini

Transcript

Okay. So, welcome everybody. Thank you for the brave that are here in Sunday morning. Um I'm going to I'm going to talk uh today about something which let's say it's uh at the intersection between privacy and compliance which unfortunately are two face of the same metal we used to say. Um my name is Yojeno. I work in the institutional space. uh I have a background across policy and markets and so unfortunately I have to deal with what is here compliance a lot in my in my daily basis. Um so today we are going to see a potential application how um

privacy pools can be embedded into an institutional network that is working in the European Union called EPS um which is an institutional network that he use is used to uh provide or retrieve data from identity space. Um so I wanted to start to give like uh like a sort of in media stress. So what is the problem that we are addressing with the re with this research that I am talking about. So essentially um regulated entities in order to uh carry out uh web three services they will need to comply with some sort of regulation uh that can be

summarized in a broader concept called um uh enhanced customer due diligence or generally customer due diligence. These requires uh for those institution to retrieve data from uh the customer from the underlying different uh source of funds and combine it together. Now most of uh generally this process happens offchain but as luckily we have um institutions coming and offering more web three services and at the same time the the new generation we hope will use more and more web three tooling. This requires let's say a combined effort

which is u uh between offchain and onchain data and between different uh networks uh uh design let's say so to carry out this research I follow essentially three design process try to um having an approach as much as more adherent to privacy by design of course being compliant with rules and frame this research within in uh a jurisdictional context which is the European Union because here we are um and here I give a glimpse of the architecture which essentially has uh offchain and onchain components but we will go through it later. Um so first of

all which is the environment in which institution generally really needs to play. uh to summarize it here I collect a set of regulation which affect uh the transfer of money across uh regulated entities for instance exchange in our industry. Um the requirement for regulated entities to understand uh certain set of data for their customer to prevent uh illicit um funds to be chneled and a list of regulation which affect token economics mika but also data management so the authentication the so-called trust environment and the data process and control which is for

GDPR. So what is the stakeholder uh mapping around which uh in the European Union regulated entities have to play? Um general network uh environments uh which are composed by onchain infrastructure like EC node and off-chain governance like a consortium made of different member states which is called Europium. uh a list of general specialized EU agency which for instance uh management uh manage a requirement on uh money anti-moneyaundering uh which is for instance in Europe AMLA or other agencies like for instance for other services like uh for copyrights we

have the European intellectual property uh office um association set providers and and regulated entities which operates in the private market and of course uh telco and cloud service provider and and in here of course also blockchain service providers. Um the solution uh I would say is composed by two main layer. The first is the trust layer which is of course needed because institution needed to anchor uh offchain data to some endpoints and to some liability in terms of legal perspective. So how does this trust layer works? We have some digital

artifacts which are credentials and uh traditional EC node which are um which are composed by an uh following the hyperledger basu protocol. So it's an ethereum effective client which a specific uh uh set of consensus rule which is called pro proof of authority which determine actually the capability to the uh manage the data process through the nodes in this context through um a trusted issuer which is essentially a regulated entity which absorb the offchain trust gen give the user the capability to issue a digital certificate in form of verifiable

credential which is a uh standardized digital certificate. This uh digital credential is stored into a wallet and is used to prove we will see in in uh in which way some uh minimal element in form of onchain commitment into the epsy node. So once this data is stored into the EC node, all the EPS node across the European Union can actually verify and certify the information about uh the users that are uh require requiring the proving and if anything change of course the EC node uh keep through a list of trusted issuer a revocation registry check where they can actually um verify

if for instance the digital certificate ate of the user is expired or some cert set of of data requirement changed so it's not valid anymore. The way in which is proving uh disproving effect here it's of course uh a big part of the magic source because we use uh zero knowledge to actually abstract and reduce as much as minimum the portion of onchain data and this is a very sensitive topic for data management perspective either in terms of data minimization but also we will see in in combination with the credential storage in terms of uh data erasure Um

this is this was like the trust layer was the first layer. The second one is actually the privacy layer which affect the the money of the user. um privacy features are have a very long history in uh in Ethereum. But actually I wanted to have this uh this section to explain um how the privacy tooling evolved in a way that enabled a much more larger stakeholder to benefit from the cryptography innovation because of course traditionally mixers have issued in terms of mixing uh LIC and illicit funds. I will make it quicker here because otherwise I we don't have time.

But the privacy pools um which uh it's a solid technology which emerged a few years ago and here I have to thank the guys from expose that actually helped me to to draft this research um manage actually something which was very important for institutions. So to determine a sort of permission logic combining off-chain and onchain elements that allow institution to whitelist the funds and so to prevent to elicit funds to be used in a in a bad way. Um and the item the digital item which determine this is essentially the association set which is um um an offchain environment which essentially

stored a list of onchain commitments uh associated with the deposit of the user. So if the deposit essentially is part of the Merkel tree the deposit the funds associated with the deposit can be withdrawn. If not it cannot very simple. So how these two different layer works together? I tried to design here a quite simplistic uh architecture design where we have an off-chain and an onchain environment and um essentially the off-chain environment is where the market providers either they interact with the trust environment or the uh privacy environment. Uh

essentially in this context the banks for instance issue a verifiable credential to a user uh in order to prove that yeah this user is customer of the bank is uh located in a general member state where the bank is headquartered and so on. Now this credential is stored in the wallet offchain and never goes in row on chain. what is actually doing is actually proving some element as onchain commitment to the epsy node so that the eps node can verify the authenticity of and the conformity of the verifiable credential. Now based on this the association set uh provider which is

hosted by a multiple let's make an example set of banks can run an offchain the Merkel um the the Merkel tree in order to determine the com the conformity of the deposit which is relayed by the wallet because we have to imagine that we will have wallet storing credential but also having account balances of crypto assets. So because otherwise this will be uh quite let's imagine a future where we have 25 wallet it will be impossible. So in that context after the the relay of the deposit the ASP give the consent essentially to the user to withdraw the

funds and this withdraw is double check based on the conformance of the verifiable credential which uh have an onchain commitment stored in the in the node. So essentially what is this user proving? Uh essentially three um qualities. uh first the fact that I have made a deposit as a user of the bank so relying on a verifiable credential issued by the bank. Second through the ASP the fact that my deposit is actually clean holds legit money enter and third the fact that my deposit has never been used before and this is an inherent

capability of of blockchain. what will be look like the user journey a little bit more um uh in a little bit more details. So this user I call it like Ellis deposit some crypto and uh and the in the privacy pools through the um the privacy pools you may see may live in a application environment that is hosted by a bank or by a payment service provider or by an exchange. Okay, this application issue a verifiable credential attached to the user. The verifiable credential call the ASP that run is let's say risk engine to determine the compliance of

the deposits and so on and based on this allow the withdrawal of the user. In this context, essentially we have achieved that we have a real world identity attached to crypto assets and the real world identity is not let's say uh row disclosed on chain. We have shielded the amount and we have make a link between the withdrawal and the real identity to the user which is very very important for the institutions.

Let's see here what kind of use cases we we could have. Um on the top we see we have like u a general public infrastructure uh because uh which rely let's say on open source uh software. Um here I list either Ethereum and Absy because actually ABC has uh an important role in offloading uh liability to offchain data while keeping actually Ethereum quite permissionless and on top you may we may have let's say market providers that can have different purpose so to hide transaction of banking operation. So

let's imagine that we have two banks they have to share um they have to make an exchange of uh settling of deposits intro daily and these deposit are linked to trade operations. We don't want to have uh the two banks they don't want to have a full disclosure of the full trading operations but they want to ensure that effectively I as a bank B give bank uh I me as a bank A I give to bank B the capability to withdraw through a legitimate source of fund. So I can essentially shield use the privacy pool ASP to shield the this interbank settlement in order to allow the

national supervisor to allow to outline the operation from compliance perspective while keeping the strategy the trade strategy of my bank secret. The second is uh maybe a little bit more um let's say dayby-day oriented. We do a lot of payments inside um inside companies that have some um let's say level of privacy or sensitivity. For instance, payroll is this is one example. So the idea is actually to use uh the shielding effect of privacy pools to um make uh salary payment uh compliant and and also uh private. And uh in that sense uh this has a huge

legal implication for HR perspective and so on. Think about that. Now I think in European Union we need to the job offer needs to needs to have a range of um potential salary but of course nobody will say exactly how much you will be paid also because this is subject to negotiation but also afterwards because of privacy. So I think that this is a very valuable use case in order to unlock stable coin to uh retail day by day oriented uh people let's say and the third one is uh another one that I was thinking more from um let's say payment perspective

now that if you recall the how merchant payment happens essentially you have um Uh the merchant collecting a list of information from the banks and the payment service provider in order to um automate the process of uh payments to the different intermediary which is a shop or restaurant or whatever. Imagine in this moment you collect all row data unfiltered to all the the all the intermediaries. In this context, using privacy pools, you could actually shield those information only to the merchant.

H while ensuring the conformancy of the identity of the user which is very important for a AML perspective to uh the different uh uh payment service provider or the banks that are involved which is the owner of your banking card for instance. So we see three different use case. One are um affected to money transfer, one to privacy and data management and one to the legitimacy of the of the fund in relation to the data uh of the customer. Different use case but same technology at the end. Uh from um

um ecosystem perspective what is why what is the value of this uh of this combination? I called it before like Abs and Ethereum. Um the idea is that we merge two technology which share the same language because they are open source. Actually EC is an execution client of Ethereum uh based on Hyperledger Bizu. Uh but we are able to combine off-chain environment and onchain environment. For off-chain I mean offchain governance like there is a consortium operated by a member state but also there are institutions which are in the member states like banks and a crypto exchange and so on that hold huge amount

of data offchain and need to offload these off-chain data into a network which uh provide at the end some onchain uh commitment that is uh linked to the authorization that they have offchain. This is how they offload legal liability to offchain uh to offchain data. And these these happen essentially across these first two layer the governance which hold let's say the rules of the game of uh the ABCs protocol which is a permission network as I mentioned like uh having proof of authority consensus and anchor to application that hold the

verifiable credential as authentication layer and the start of uh the on boarding process. Of course, the one of the nice thing of the blockchain is of course that uh uh blockchain is composable. So, privacy pool here fits very well because they live on Ethereum which is uh permissionless and so actually can give uh great access to different additional tooling because you can compose privacy pools to call uh maybe D5 protocols and so on. Uh but why this institutional framework matters for privacy pools? Because gives at the end gives regulatory certainty to offchain

data which is where the company are liable because provide a system to minimize that off-chain data part that is shared onchain and because it helps to manage uh the way in which data is processed from uh operational perspective. I was anticipating a little bit uh this Europium Eric is uh is a digital consortium uh which operate on this EPC network which has um different list of uh nodes across different member states and is plugged as Ethereum execution client in

the Ethereum. So these from off-chain environment benefit of a set of cryptographic tooling that at the end generate the possibility to combine privacy pools with um uh with identity frameworks. Um from data management uh perspective um I wanted to summarize here uh like some some key point um the data management compliance uh it's something that I let's say already touched a little bit uh it affect um clarity on the data controller uh the right to erasure the

data because the data of the credential at the end is stored offchain so it can be revoked and uh it can break the link with the metadata of the user when it's not um when it's not needed anymore and uh the ZK proving minimize the the commitment on chain um of course as a system it has of course especially dedicated to institutional user it has let's say tradeoff in terms of uh permission and the distribution so this trade-off is balanced across off-chain environment where there is user identity and let's say the the ASP deposit through um and the onchain environment

where they all the onchain commitment essentially lives um at at level of the node management there is some uh trust that happens in terms uh that will happens in terms of key management and in terms of uh cryptographic a circuit for the ziki proving setup. Uh but still you see this offchain and onchain environment um determine the capability for institution to manage for instance their operation uh with much more flexibility in terms of uh smart contract management for upgrades or um in terms of IT security risks.

uh which are the potential um uh integration points with different u different users on the origination side and on the beneficiary side of course the wallet uh for the credential and the zk proving um then um there the regulator may have access to either um viewing keys or uh end API endpoint integration if they have uh to assess uh specific onchain data and um the ASP of course uh connects to uh I think yes it's an API here for updating um yeah so I think this is I I leave you for some question

and I hope you enjoyed >> so do we have a question. >> Thank you. Uh thank you for the presentation. My question would be on the European EDIC side. What is like the status of the cooperation with edict and how far is this actually from being used in practice? >> Well um I am not a member of EDIC so I cannot uh uh spokes on behalf of them.

Um but what is generally public is that the consortium is has been formed and so it's really operating under different member states. Uh it is true that uh is uh um network which is open source. So every administration can use in al for his own uh interest. >> Okay. So this is just a quick one. This is just a your kind of ideation of how it how it research. Yeah. >> Yeah. Because I know the other side from the European one and I know how complicated is is it there especially from >> that's indeed my research and how I see it valuable to connect with Ethereum for some services that are offered by

institutions. >> Hi, thanks for the talk. Um do you know what is the compatibility with the mainet Ethereum regarding the um included EIPs and uh for instance the op codes and so on? >> Uh well the we've I know that several L2s have implemented different projects. U so level of L2 level there is I think enough choice in terms of services. Now for uh for ABC is indeed true that ABC has let's say limited compatibility with the mainet itself because of its um consensus design. Um

but it's also true that part big part of uh the DID service which I described here can be completely uh managed offchain and actually I would encourage to do so because this minimize entirely uh the exposure of identity data of the user on chain. So the idea here was to generate the verifiable credential associated with the AD and do the verification process of offchain so that only the onchain commitment of the of the of the check that the user holding the verifiable credential is doing is posted on uh on the FC node and this can be relayed to to to the to other

Ethereum clients. >> Thank you. You also mentioned on the slides that that you need to get the approval to to actually deploy the code. >> Mhm. >> Um can you elaborate a little bit on that process of the approval? Uh there is what is described in uh this slide. Uh sorry what is happen? Um what is described in this slide is essentially here the what is described here is a set of u uh of chain rules that determine the root of trust. So there is an entity which has a legal requirement to operate some uh checks about uh some data of the user and

because of this is entrusted to issue this digital certificate. That's why this design requirement fits very well with a network design which has a permission authority on top because the the distrusted issuer is also entitled to at the end check the revocation on the revocation registry and allow the you the wallet to post approving results. >> Thank you very much Eugenia. Uh unfortunately we don't have a room for any further questions but if you do have a question please reach out Eugenia.

Happy to take you >> again.