Improving Privacy Pools and Blockchain Governance: BGIN Frameworks

Transcript

[Music] Hello. Hello. Good morning everyone. Uh it's good to be here. I hope you all enjoyed Edicon as I have throughout. Um today we we have a bit of a hybrid format uh cuz Keegan wrote the research paper of the improvements on the privacy pools. Um so please bear with us when we make the swap. Um but I'll be presenting on improving privacy pools in blockchain governance with Aentic enabled cryptography. So just a quick brief on uh what begin is the blockchain governance initiative network. Uh we're a sort of global think tank standard setting body uh coming out of Japan and um supported by the JFSA. Uh we host

meetings twice a year uh to discuss blockchain governance. So everything from identity key access management with of which I'm the co-chair of the working group for identity key access management uh as well as financial and social economy applications of blockchain uh and there's a few things that we discuss in the the forum uh we receive uh regulators we we have um industry practitioners cipher punks cryptographers um it's a really good uh sort of mixed group uh so we're able to get into the details of of what's going on. And um our work item for the past almost two years um has been observing the privacy pools uh paper and then

trying to make improvements uh using the experts in the room uh sort of improving the protocol and in other words creating association set providers through um governance organizations. Um more recently uh I've written a agentic framework for begin so to build a aentic workforce alongside the governance activities uh and the the forum that we create. Um so there is actually a convergence between uh governance AI and um privacy pools aka uh the cryptography which protects your privacy on chain. So without further ado, um throughout the the time as a chair of the begin

organization, I've noticed a lot of uh difficulties in in governance. Um one in particular that that I find um struggling is temporal blindness. Uh so temporal blindness is uh this issue where people when they have focus and energy on a particular subject, they provide a lot of value in that moment. However, over time, uh, there's decay and it's it's diminished because people are busy. They they have other things that they want to do. They, um, have other activities. They run businesses.

Um, so being able to capture that essence when it happens and then use it to train an agentic workflow, that's what we're trying to do now at at Begin. So then, um, we don't have this issue of um, sort of blindness over time. This also leads to the knowledge fragmentation issue, similar issue where a lot of governance insights are actually siloed amongst lots of groups. I think this is particularly a problem in blockchain because we have lots of chains that all have their own governance that all look very similar and there's a little bit of crossover between the two and a lot of them have the same problems. Don't really talk to each other all that much unless there's a person that sort of is that bumblebee that navigates between the different blockchain networks. Um, scaling is

always an issue. Ethereum loves talking about scaling issues. Scaling is also an issue in governance. Um and of course there's privacy um trade-offs as well. One issue that we've discussed a lot at the begin organization is um around sort of onchain transaction monitoring compliance. uh and when we get organizations uh like elliptic chain analysis and these sort of transaction monitoring firms that create nifty huristics for um demixing funds uh it's their competitive advantage for them not to tell us how to do that however when we look at fighting crime and trying to solve the AMLCTF issue around the world uh information sharing is critical so I actually see those two um things at odds

uh so what we've developed at in is what I call an agentic chat house um framework where uh people are able to provide contributions but the attribution is not listed to them or their organization. Um and then using sort of AI as the privacy vehicle here um we could potentially get more information sharing. Um so we've designed three different agentic workflows uh to make this all happen. An archive agent is the institutional memory of any given subject or organization. So see it as the rag where people are able to contribute information and intellect and um their sort of access to this knowledge store.

A codeex agent converts a lot of this information into into code. Um so you could imagine a standard like a ISO standard. Uh what we're able to do is use that ISO standard and support organizations in converting their policy and adopting that standard. And then finally the discourse agent. Um it's a sort of a median for the human interaction uh with the agentic workforce. Um we use discourse which is a forum space. Uh so it kind of has a double meaning here. Um discourse is also of course dialogue. Uh, and what we're able to do is have the prompt inputs through discourse and have this ready forum that constantly goes through

and then the agent actually acts as this um, as I mentioned before this chat house median where the discourse agent posts the insights and the information but doesn't attribute it to those who provided the insight originally unless they would like to and that's where the privacy pools um, uh, comes in. So, let's just jump straight into privacy pools. I know it was a little bit of a divergence on the agentic framework here um from the topic. However, I I'll tie it all together in the end because and I'll just leave this with you to think about like what is value? Well, value in the blockchain space is represented as data. So value to AI agents is information and data. Value to humans is tokens and what we prescribe um value

to. So let's think about tornado cache. um just briefing on the privacy pools concept and then we'll get Keegan um who's online to share how he has improved on the the framework and the protocol tornado cache many of us know um it is a privacy solution where you're able to deposit a certain number of um coins so typically 100 Ethereum uh and then make a a withdrawal which is unlinkable now there was like a lot of controversy and issues around this um in the industry as it was OFAC sanctioned um and there was that's recently been lifted um but it does sort of raise some concerns. So one of the iterations on

the tornado cache was this privacy pools concept where we're able to build association sets and now imagine how do we build an association set provider and that's where begin is looking to take a role. So we're enhancing the privacy pools. Um, one critical vulnerability that we identified is that it is very easy at the moment to build an malicious association set provider because there aren't really very many association set providers. Um, oxo is one of the only examples in the market. Uh, and they have a fair amount of liquidity in the system. Uh, and we do trust them. Uh, but how are we going to trust a burgeoning association set provider ecosystem? Uh, this is where sort of begin could play a role in building

different types of association sets for different use cases. Uh we did some research called the accountable wallet framework. Uh and this uses onchain attestations uh for compliance. So imagine checking if you're on a sanctioned list. Uh you then receive a proof saying that I'm not on a sanctions list and that informs the association set. So when you go into a privacy pool, you can transact with other people who you can be assured um through the cryptography that then also not on a sanctions list. Um now this builds sort of almost like a fragmented liquidity ecosystem which will have its ramifications in of itself. Um however it does get us closer to this real world asset realization on on chain. um where

you do have these checks and balances that exists in the traditional finance space um such as KYC. Not as much of a fan of KYC, but I suggest that with association sets, we'll be able to build different sort of credentials um which are a little bit more closer to the human and a little bit less reliant on bureaucratic identity and more reliant on other things. Um so this is where the original accountable wallet idea comes in. um and we proposed it at the financial cryptography workshop. So the core idea was um wallets undergo KYC or some sort of proof. You then have this generation of proofs over time um where one wallet has a credential which then

layers into another wallet which has a credential um to build this sort of layered approach. Now this is highly complex and that was some of the feedback after we published the accountable wallet um paper to financial cryptography conference FC. um it was a little bit difficult to envisionage this being a a real use case because of the complexity behind having multiple proofs behind multiple wallets. Um adoption would be difficult. Um so this is actually where Keegan steps in and over the last year or so he's done some more research in simplifying um the accountable wallet framework um and improving the privacy pools um association set creation. So um if we would be able to Keegan jump in if

you're there. >> Can you hear me? >> Yeah, we can hear you. >> Sounds good. Yeah, thank you for introduction. I'm Kea and Okay, let's see. I think we are kind of running out of time. So let's quickly see like how we how we can simplify the accountable idea. Uh and so we can simplify this you know the complicated proofs into two proofs for first. So the proof of the wallet owner being unsanctioned and the proof of the legitimacy of the coin providence. So when the Alice transact with Bob I'm sorry that you're going and and the Alice providence proof consists of upstream sender Carol her unsanctioned proof and the providence proof and this recursive structure continues to the end of the transaction history and the end will be the exchange

deposit or coinbased transaction and we want Bob evaluate Alice legitimacy by just verifying the proof sent by Alice. So to further simplify the recursive this is recursive structure let's compress the transaction history as the accumulated compliance score uh simple scalar value then Bob just needs to verify Alice's compliance score and the unsanctioned proof next. So however there's a still an scalability challenge so the accumulation of all proof leads to exponential growth in proof size and the verification time and delegating to centralized authority. This costly calculation also enables censorship perpetuating the problem we are trying to solve. So the solution we propose involve these three components. First

their verification related records, second the chain of trust and third watcher network. And let's take a closer look how these components work together. So before transaction the sender presents like locally calculated wallet compliance score and moment budget proof of the crypto watch list. Recipients then decide whether to proceed to the transaction based on the verification result of the score and the proof. The important thing is here the recipient only checks the immediate sender score calculation and nomi proof trusting upstream sender score. So the red rectangle here uh shows the recipient side and the malicious attacker can forge a score and deceive the recipient easily by having the multiple

self-custody wallet. A sanctioned coin owner may send a coin to the other newly made wallet and the claim the recipient wallet conduct necessary verification and also you know force a frauden score between them. So if this happens out of the owners recipient site then recipient has no way to notice this fraud to prevent that attacker successfully compromise the integrity of the score on this trust chain. uh we have uh ver verification data record VDR in short and watcher. The sender leaves the VDR uh which includes the compliance score proof and the recipient signature uh to show the consent of receiving the fund.

Also this VDR enables watcher to detect the false efficiently uh by reverifying it. Also watcher can identify the fraudulent transaction. more more importantly more importantly uh the recipient can use VDR to prove their good fate of accepting the funds. So, so we're delegating the, you know, fra detection to the watcher. Is the screen fine? May I keep >> just a just a moment or >> Yeah.

>> Yeah. We're back. >> Okay. I I can't see the screen, but yeah, I think you can switch it properly. Yeah. So uh so we're delegating this fraud detection to the watcher and we can think of two models for watcher verification. So the first model is what we call decentralized compliance scoring and the second model is called optimistic verification. So the next slide. So let's see the first model. So decentralized compliance scoring. So as already explained the sender calculates its compliance score and show it to the recipient with the nonbush proof. The record of this negotiation is store as PDR.

And so what what the water network do is uh detect the fra detect a fault in standard score calculation or recipients budget proof verification through periodic PDR verification. Also they identified a fraudulent transaction and add add actors detected to crypto watch list. Also they correct the affected score uh through attestation issuance. Also they operate with the mutual monitoring and economic incentive like of slashing deposit to penalize the malicious water in the network. So the watcher may be like companies like chain analytic companies you know chain analyis elliptic trm and so on or even

include the reg regulatory body itself. They also may be incentivized by you know getting paid from seats properly properly uh when they detect the fraud also the water network guarantees the score integrity to ASP. So let's go to the second model. So we call this second model as optimistic verification because it looks like optimistic rollup. So in this model uh user make assertion of the compliance score uh when they try to make a deposit. So then the depository request is pended for 7 days and watcher will submit the fault proof pointing out the fraudulent transaction or fraudulent wallet claiming the wrong compliance score in the transaction history. So we

can call this watcher as a challenger in this model like following the optimistic rollup terminology. Uh so if no fault proof submitted within seven days the deposit request go through the ASP and added to the transaction set. The important thing is the fault proofs will be verified by EVM smart contract. So it relies on L1 consensus to resolve the dispute game. So therefore the verification data record uh need to be stored in the smart contract readable manner. Also uh there needs to be the compliance score correction mechanism uh triggered after the fraud gets proven. So the next slide. So one of the possible format to store the VDR uh is like using a schema

like ERC7812 called CK identity registry. Uh it proves the stand it provides the standardized uh onchain database entry point access control and the isolated name space. So it is supported in the sparse micro tree structure which is compatible with nash proof. So therefore we may store WDR as a sparse marker tree uh in the recipient's name space. and ERC uh 7812 is originally designed to store the commitments of the private data to later prove its validity uh via general via general proof. Therefore, this schema will be also useful for original accountable idea to connect the offchain attribute information uh as you

know verifiable credential and onchain executable ASB verification of the deposit inclusion. Okay, that's my part. Thank you, Keegan. Uh so what we find with using or progressing towards enhancing the privacy pools uh concept is that we can do some compliance scoring around deposit verification. Um association sets are an emerging thing. Uh so management around that we suggest it should be a government or non-government organization, think tank organization. Um zero knowledge proofs are also essential here. Um and then of course there'll be withdrawal um verification and fund tracking um after which the adoption of sort of Keegan's

research. Um so the road map for getting this all to happen uh we're actually leading towards block 13 in Washington DC in midocctober. Um and block 13 is uh where we're going to experiment with some of these concepts uh using that sort of agentic workforce that I was mentioning. So training agents on be being the verification um systems and the create uh credential um systems as well. Um so we'd like for the Ethereum community to be involved in that process as um as much as possible.

Uh so the convergence what is value? So data is value to AI tokens are value to humans. uh and if we're able to build these sort of value um privacy pool systems on chain, I suggest that we could actually have uh privacy pools for um decentralized governance as well. Um so if you could imagine making inputs um in sort of governance activities and that going through a privacy pool concept too. So the beginning of constellations, we can have institutional wisdom, privacy and accountability as well as quality at scale. Um using the privacy pool concepts for both money as value,

onchain value, but also intelligence as value. Thank you so much. [Music] >> Thank you very much. [Music]