Migrating from a Private Blockchain to Ethereum: Engineering Lessons

Transcript

[music] [music] Thank you for the presentation and yeah, hello everyone. My name is Bian Placencia and I'm the technical lead in the technical foundations team at the Ethereum Foundation and I'm going to talk about migrating from a private blockchain to Ethereum and the engineering lessons we learn. So this is the structure of the presentation. I'm going to start with what it is what is the technical foundations team. You may have heard of

it but may maybe not because it's quite new. I'm going to also introduce the project we have been working on and it's the project that we are going to use like I'm going to use to for the lessons learned and I'm going to also explain the flows in this project and also cover four lessons learned. They are all technical and one main takeaway from all of them. So the technical foundations team is a team inside the Ethereum foundation is the technical part of the work with institutions is focused on working with institution helping

helping with advice and also creating proof of concepts to integrate Ethereum and introducing the project we work on is called coordination network. So coordination network is a a project is a proof of concept that was created after talking with many organizations working on aid and they are all humanitarian organizations and this project covers the decentralized identity privacy preserving payments on Ethereum and it covers also shared governance while keeping all the private data the

offchain. These are the main flows for uh in the project. So you can create the identity. So uh every there are different parts like the retailer beneficiary and the organization. Usually organizations will help beneficiaries and then retailers we will offer services to these beneficiaries and in this project we are covering mainly retailer and organization part and the retailer will we they will generate their keys and the these are seldon the ones that we will save onchain that they will also receive

credentials because an organization can issue credentials And these credentials can be presented as CK proofs. These retailers will also be registered onchain but just a seldon with their meta address. And for all this process h we use also sponsor gas and in a privacy preserving way. In this project, you can also send payments in a privacy preserving way using fresh sales addresses and as I mentioned sponsoring with the the gas with in a privacy preserving way and the payments you can find the payments using an indexer similar to yeah fluid key

project in this case uh using stealth addresses and in this case finding the payments for retailers. And the last one is that you can revoke credentials. These credentials that you issue you can like this the organizations will issue they can also revoke the credentials and coordinate uh in a way that they they don't duplicate payments or they don't duplicate identities of retailers registered. So these are the main flows for to have the general idea of the project so that you can better understand the learnings.

Here is a diagram showing the flows and yeah you can see here the organization the retailer phones and in this case each organization will have some private data in their servers and they they have their issue key which is h the signing key which which is used for to sign the credential. Then the retailer will have their phone with their own data. So they will always save the data in their own private data in their device and and also the credentials. So all this private data is

on is offchain in their [snorts] phones and then h the what we save on Ethereum mainly the registries like all the members registry these organizations the retailers identities like sale donims and the revocation registries and the parts regarding pay master two and to verify the credential then everything can be done offchain but talking like to the onchain registry like reading reading the onchain registry. So the retailer will create the secret proof and then the verifier

will verify it by verifying the proof and also reading the registries to get the fruit. I'm going to cover that a bit more in the lessons learned. So starting with the lessons learned. So that was the context for the project so that you get an idea of what is happening and now I'm going to cover what we learned this um we learned a lot of things so I'm covering four the most important ones that we saw. So the first one is h keeping personal data offchain. The challenge is that public data can expose who you are. And in this case since we had to migrate from a private blockchain to a public one, we had to to

rethink privacy. And an example was that retailers need an identifier on chain so that the organizations could know that is if it's duplicated or not. And in this case what we did was to use a keybased sodonym for this coordination and yeah you cannot use private data you use this kind of of of sodonyms so that people cannot yeah external viewers cannot see what is happening to have a better idea of this part there is the retailer's phone and the phone as I mentioned before they generate h in this device. You can generate all the identities and then the

organization will be the one approving this and sending the transaction that is a privacy preserving a sponsor privacy in a purpose preserving way using STS addresses too and it will be storing this identity registry just the cell that was created not any other personal data even hashed not hash data no hashed personal data And then this is very useful because know since it's a public blockchain and it's privacy preserving another organization can can check this registry and prevent duplications.

So the second one I will say is designing for lowend funds. So this is very important that you will see in all the CK protocols. But in this case too because when you have since you have privacy in the blockchain you also need to to run the privacy preserving part that is offchain and in this case the retailers will have their own phones. So they need to generate the CK proofs. In this case the generating the cate proof is like very expensive in general in phones because it's time and memory consuming. So, so then the solution that we that we

decided here was to try to make as efficient as possible this CK solution the circuits and the CK parts so that retailers with low-end phones they can actually generate the CK proofs and we optimize like we change the isure behavior to use the optimized yeah ed so that is optimized for CK and also use proving system like you know uh ultra honor ecosystem and yeah baby jip jube open AC inspired credentials so you may have heard of open IC from previous talks and last year so we used

open IC as an inspiration and also using lina for issue hiding and lin plus for vocation to make all the great flow flow of the credentials to support is reure hiding and revocation and make all the flow privacy preserving and actually open AC+ which is the new version that will be released soon contains these two ways too and so here are some mobile benchmarks. So for low low-end mobiles you can see that is around 9 seconds which is pretty good like it's very good for real world usage and for mid French is around three and for more advanced uh phones is around

two. So two seconds is is great. is very efficient and in this QR code you can find more more benchmarks for that with different phones and other type of benchmarks. The third one is that authorized onchain actions without revealing identities can be hard. Um and you need kind of like a gating mechanism so that external in this case the organizations h can reveal who is acting on a specific registry. So for this we we we had to apply this kind of idea of

gating processes in the registries and also to to to pay gas fees in the pay master part. So every action that is done onchain and should be privacy preserving should have this kind of gating mechanism. In this case we have two examples for the registry and for the pay master. And for all of them we use the sema for protocol since we have group of people. We use the sema for protocol which is a privacy preserving C protocol for for this kind of things like to prove membership in a group without revealing who acted uh who was creating the proof.

This is an example here. You can see how it's done. the the member the organization will will create the the CK proof to create an action on chain and then the the registry will check if it's if it's a valid membership proof if it's correct that they can do this update in the registries and it will be approved or not and if it's approved it will do the actual action and to do to check if it's approved or not. It will check the in the group and then that's done with the roots also the second the that was the first

example like to write in the registry and the second example is to sponsor gas. So similarly so the organization will send will use a secret proof to so that the pay master can check if this entity can actually use the fees and if it's if it's approved using the root and checking the the group root then it will it will be the pay master will pay the the the gas fee. So in this article you can you can learn more about it.

And the last one which I think is the probably the most important one. I think it's the most important one h because it's about preserving privacy in the whole protocol. So the challenge here is that a privacy preserving tool, a CK tool, a protocol can can lo can lose their privacy like their you can and you can lose the the good guarantees of privacy if it's integrated incorrectly or not in the best way into a system. And in this case I'm going to mention an example which is uh the issue when we were creating the credential we needed to

have issue hiding and revocation and for the revocation part the normal way to solve it is that each issuer will have their list of credentials that are revoked and then that's the normal way for the CK proof and then you can anonymously proof that your credential is not there. So what is happening in this case that we also wanted to support and because that was one of the requirement we needed to support issuer hiding and what happens when you integrate all these CK components. So in this case the issuer was not we needed the issuer to to query

their list and in this case you will be exposing the issuer and that that's not what you want. So integrating a new component you will be breaking the other one. So what we did was to have a share registry for like a share set for the all the credentials that are revoked and then this way we can keep the issue um the feature of hiding. So to see better here. So it's the same idea of the phone that there is a the retailer phone there is a verifier checking the proof it will check the root and the all the registries are on Ethereum and in

this case it's a share registry because if we use a reger per user we will need to query the user registry even if it's onchain and then you will be breaking the privacy of which you're hiding. That's why we use the share registry. So in this article you can learn more about how was designed the credential and also about this part. So this is the main takeaway from all this talk and all the things we built and this is that using CK and privacy tools is not enough because how they are integrated into the system is very important. This is the summary of the

previous point I was mentioning. Even if you use CK everywhere, I have CK here. All these uh other privacy preserving protocol here. Even if you have all these privacy preserving tools, you need to find a way a correct way to integrate them because if you do other things before or after using each one in your system, you can break the privacy of one of these. So I think that was the main thing that uh I I found in the whole while building the the whole system. Here you can learn more about the the project. So here here is the documentation the the QR code and the GitHub repo with all the code and the

website of the team to know more about the team and the email that you can use to contact the team. So thank you very much. Great. So now um let's have some fun with questions. Uh we got couple um and I want to start with the first one. What's the benefit for migrating from private blockchain to Ethereum for this use cases?

>> Yeah. So there are a lot of benefits and in the article I shared at the beginning you can find all the the context and why but I will say that one of those is that in a private blockchain is true you have more privacy in a server but in a public blockchain anyone can access to it and you have a more way to interact other like in this case other organizations can just query that And another thing is that if you have a private blockchain, you need to run the full infrastructure and then that's costly and also it's not that secure because it's in yeah you don't have to too many nodes. So in this

case using a public blockchain is much more secure of course there are a lot of a lot of nodes. So and and also the updates of the protocol. So if you if it's private you don't usually get as many updates. If it's public, they get all the updates. So is th I would say those are very important ones. You can find more in this article, but those are the main ones. >> Great. One more from the audience uh mentioning L2 and asking what's the benefits of um deploying on Ethereum or migrating to Ethereum comparing to L2?

>> Mhm. if there any. >> Um yeah, so Ethereum is gonna like is pretty fast and and in general like it's true layer tools uh are faster but in in this case we wanted to to use Ethereum like as proof of concept and to benchmark the gas and also you get all the privacy and all the security by default directly. Cool. Okay. And another one um asking about the the use cases if there are any any specific use cases that more a fit for uh migrating

uh private blockchain or generally that using Ethereum will be better than using private blockchains >> and maybe there are some that it's better to have on to keep on private blockchains. Yeah. So I think is uh for the for what I mentioned before I see more benefit on on using the public one because of these things and a lot more and so so all these kind of uh things for coordination is better to use a public one and in the public uh blockchain anyone can verify anything if it's built correctly anyone can verify anything and in a private one you cannot uh make sure that you can verify

that so not everyone can do it because yeah it's not public so they don't have access to it or if they have they cannot make sure that is true that it can be verified correctly. >> Thanks for that. Uh for the next one how do we prevent unauthorized modifications during the migration window? if it's doable if that even doable I know sometimes it's not >> so the question is like how to prevent to prevent >> like the the assumption is like when you have a migr a migration on some time

window you have both coexist right >> yes so yeah I see yeah we were not focused on that part we are showcasing that is possible and how it will be done but we we are we were never focused on like what what will happen so that's another process that we will need to think about and and I know it's very important but the first part is to showcase and see if it can be if it can work and if it has good benchmarks and then the second part is to see how they yeah how to solve this >> great okay and um and do you like what do you see uh by the like um

enterprise customers what they most afraid of [snorts] from this migration or for using public blockchain? What are the like most pain about what they think what they see as the the most um uh the part that is most um um challenging for them? I would say privacy because people don't really know the cryptography part of CK and they don't really understand it. So when they see that it works and it's true that is privacy preserving the solution the public one then it it's fine but at the beginning it's like if it's public is public so yeah it's like difficult for them to to understand that

it can actually be public but at the same time privacy preserving using CK because CK is a term not very famous in in the world in general it's more it's very popular in the web 3 ecosystem in Ethereum ecosystem but not in in the war in general. >> They all managed to get it or some uh some some part of the team that is like more technical say that like yes we can do that and there's like follow or you manage to to get all of them on the same page where they understand that is still >> [snorts] >> uh a public blockchain but the data is private.

>> I see. Yeah. I'm not the person doing that. So I'm more the technical in the technical part. So I get the requirements and see what is happening and then help like with the technical part. So yeah I I don't follow that process. >> Gotcha. Okay. >> Cool. Okay. So uh we we kind of out of time. So thank you for this uh uh very interesting talk about uh um enterprise as an organization privacy on Ethereum blockchain. And uh >> [music]