Deep Dive into DAVINCI

Transcript

Okay, that's on. So, welcome everyone. We got George D and Pal from Vogoni and they will be talking about Dainci which is the new the newest uh voting protocol. We walking through their mission, why they think uh digital voting uh in secure voting is important, some of the success stories, the use cases and how the the protocol works. So, I'll hand it off to Jordan and Pal to get started. Okay. Yeah. Thank you so much. Thank you everyone for joining us. Uh yeah, let me share the screen so we can uh have some slides. Let me check. I can do it.

Okay. And now let me Yeah, it's already pinned, right? Okay. Okay. Can you see the screen? Yeah, I cannot hear you. Yeah, you you can see the screen, right? I'm sharing. Oh, yes. Yes. Okay, perfect. Sorry about that. Sure. Perfect. No, no problem. Thank you so much. Okay, let's go. Uh, so yeah, uh, I'm Jordi. I'm working at BDON since some years ago.

And yeah uh today in this uh learn and share u uh video from PSA uh I would like to introduce uh Dainci which is like the latest protocol we have been working on at Vogdoni. I will do a brief introduction uh and of what is Vogdoni some use cases that we had and we'll uh pass the the micro to explain more technical details of the of the Vinci. So yeah let's start. Okay. So what is Vogdoni? Uh Vogdoni is written in Espiranto and it means uh to give voice and it's an open-source uh digital voting project that leverages distributed technologies and cryptography uh to deliver secure

and transparent decision- making processes. So our vision is to improve uh democratic health and promote participatory governance using the centralized and open source technology. uh uh from that vision we end up with a mission to build a censorship resistant, secure and transparent voting protocol that facilitate decision- making for communities and organization. And uh we are uh organized around the values of digital sovereignty, open source, public goods and for using the tech for for goods.

So I would like also to give you some uh insights of our mindset of the foundations of the mindset that define us. So our end goal is to provide a voting system with all the guarantees that a democratic voting process must have. Uh we also focus on practicality. We cannot expect that people understand web 3 or technology at all. So all technical aspects must be transpar transparent for the end user. And yeah, we also are privacy first. We think that uh voting system should be censorship resistant, should be end to end verifiable, accessible by anyone uh uh anywhere at any time. And yeah, we

also would like to provide target solutions. So you have the protocol, you have the AP an API and SDK for interacting with the protocol and on top of that you have a UI that will be what the end user will will have. So uh when I talk about all the guarantees that the uh democratic voting process must have um there are uh certain um attributes that should that must be accomplished by any digital voting system that can be considered uh secure and transparent. Uh before uh talking about these properties let me also uh give a bit of the background that we we have and where we

came from. So uh Vogdoni as a project was born in 2018. It was led by a multi-disiplinary group of uh pro-democracy activists uh and it was in a context of state repression against the Catalan civil society for running a democratic referendum about self-determination. And at that point we realized that current usable voting solutions are opaque are costly and are centralized and that the world needs an unstoppable voting system because nowadays voting is an exclusive asset controlled by national states. If you try to imagine how to create a voting at your home, at your municipality, at your country, uh first you don't have the census then

it's an exclusive asset because you need a lot of money to organize it and we want to change this paradigm with BDON. So going back to what a voting a proper voting a proper democratic voting system should have. We have uh some properties that are kind of agreed between uh the community that is working in this in this field. So we have three groups. Uh we have security properties, integrity properties and verifiability properties. Going a bit more in depth of each one. In the security properties we have the valid privacy. So no uh outside observer can determine the contents of a specific vote. Then we have the

recipess. So after an election a voter cannot prove how they voted. And we have corrosion resistance. So meaning that during an election a voter cannot prove uh their vote to a cursor. Then if we go to integrity properties we have censorship resistant meaning that no party even the administrator of an election can censor a valid vote. We have nonreposition meaning that no party can modify or erase a vote that has already been cast with the exception of a valid voter nullifying their past vote and willing to cast a new vote. So it would be like a boat overwrite. Then we have also the correct exe execution. So no party can forge a false tally of the the

casted boats. And finally in the third group we have the verifiability properties. So we have uh it's all of them together it's what we call end to end verifiability. So uh having like individual verifiability meaning that a voter can verify that their ballot was correctly uh contained in a set of published results. We have the universal verifiability meaning that anyone can verify that the published uh results correspond with a set of published votes. And we have the eligibility verifiability. So anyone can verify that each vote included in the results was cast by an eligible voter. So it was in the census and that each voter casted no more than one vote. So if we put

together these three properties, the individual verifiability, the universal verifiability and the legibility verifiability, we have what we call the end toend verifiability on a on a voting process. So having that in mind uh during the past years we have been uh providing uh organizations institutions and any uh human group uh with uh uh voting technology that can be used and it's easy to use and I wanted to highlight some use cases that we have. So these use cases uh will be um done uh will be grouped by the verticals that we we identified on the market. But uh before uh before uh going uh a bit deeper on

the on the use cases, I want to also highlight uh the tech evolution that we have, we have uh been always trying to to innovate and to use the best solutions that we had in that moment for solving like real need use cases, real world use cases, sorry. So uh when we started in 2018, it was Q1 Q, uh two of 2018, uh we forked Zcash uh to u try to create an MVP to show the feasibility of uh blockchain voting and uh by using uh cryptography and distributed technologies. So we had a real use case with uh 28,000 votes and people uh did not realize that they were

using blockchain technology and this was in 2018 some some years ago. The problem with that solution is that it was limited and it lacks uh it lacked of programmability. Then in another iteration in the uh second part of 2018, we tried to build an Ethereum a custom Ethereum pro authority network but at that point Ethereum was missing the cryptographic primitives for building an private anonymous voting system and we also had an scalability problem and because of that on 2019 we decided to build a custom L1 blockchain based on ter on tendermin uh BFT uh nowadays it's uh called comet at BFD and we were using sircom on the client side for for

generating all the zero knowledge proof uh that uh our anonymity and privacy are are based on uh this custom blockchain is still running this is the blockchain that we are uh using right now while we are uh developing the the new protocol I mean implementing the new protocol and it's being used by more than 200 uh organizations and we also have uh more than 200,000 votes process it and then we end up in 2024 uh where we thought that the technology was ready for trying to implement what we think is kind of the holy grail for uh digital voting and it's uh the the project or the code name was uh Dainci

and we leverage uh full uh as you can voting state machine why we are doing this uh it's because uh the custom tendering blockchain uh from our point of uh it was it is not like the centralized enough for for heling national state voting and we don't uh solve the problem of uh collusion. Okay. So going back to the case studies I was mentioning uh some I would like to highlight that we have a proven track record of delivering secure and decentralized voting solution across uh both the web two and web three markets. So I'm going to go uh for each vertical. So for example uh using uh

this unstoppable voting technology we were able to provide developer Russian opposition uh that were were in the need of anonymous censorship resistant and tamperproof voting technology for their citizen council elections. So in a in an environment of um censorship, political pressure, people in fear, uh they decided to integrate uh the Voni protocol via the SDK that we provide to their own app. And it was super nice because uh more than 6,000 uh people casted their vote under a represent repres scenario, sorry. And we had also international observation mission that verify that all the process had the the

democratic guarantees that they they need to have. Uh we provide also uh a voting solution to political parties. For example, we have the success story of Scar Republicana, which is one of the largest political parties in Spain. And it was super nice because the vote was decisive uh for uh uh electing the Catalan presidency and also for the formation of the Spanish government. uh they had a really high turnouts and uh as you will see like in the different uh use cases that we had uh the voters authentication is a super u flexible mechanism. So it's up to the organizer of the election to choose their

preferred authentication mechanism. In this case, SC Republicana were using an email with a unique access code that were recite as a a two factor identification and we are very happy because they're still using it for their high stake uh internal voting processes. Okay. Then we also uh provided some solutions to governments. We have the success story of the Barcelona city hall. uh in this case the Barcelona city hall is using desim which is one of the biggest uh governance solution open source governance solution the is used in the um Barcelona city hall but also in the city hall of paris uh New York it's being u uh being tried to be used in the by the Brazilian

government and we are very happy that they decided to to use Bdoni and to integrate Bdoni in their in their governance solutions and also we have the the municipality of Belputs that it was the first uh full digital referendum that was held under under the Spanish law uh and under COVID restrictions. So people had uh the chance to vote uh digitally from their home. But we also uh provide like a physical space a secure physical space for people that doesn't understand that much about technology to go there and to vote uh in with a QR code and some other credentials that you can see here in the in the photo.

Then we also provide solutions to global organizations. In this case it was the football club Barcelona. Uh it was the for the uh advisory council of the football club Barcelona and given that their members are spread around the world. We provide this this digital voting uh solution where the members could be identified using uh member ID and also two factor identification. In that uh use case, we were very happy because most of the members were uh over the age of 60. So, it's super cool to see like I'm not going to say all people, but I mean people that maybe is not uh that much into technology to use flawlessly uh the the solutions and the and the and the yeah and the and the

voting uh project that we implemented for them. Um yeah we also in terms of scalability we also provide um uh our voting technology to cultural which is the largest uh cultural organization in Europe. Uh it was also under uh repression um environment. So Omnium is a let's say a pro-independence uh Catalan organization. So they needed uh the censorship resistant properties and the and the the to be really sure that no any of the votes or the tally were were altered uh afterwards the election. Uh yeah we also had a nice polling during the the Catalan

parliamentary elections. The cool uh thing or the thing to highlight about this case is that uh we decided to authenticate people using stateisssued digital certificates. In that case was something called IDCAT. This is a digital certificate that any uh person in in Catalonia can have and yeah it was uh super nice. We had a lot of media coverage, more than 1 million views in in national TV and it was a really nice experiment that uh highlighted that the voting technology is is ready for being used and it's convenient. It's cheaper and it's more uh gives you more pleasure to use than spend all the day like outside your home

uh voting and going to the polling station and so on. And yeah, one of the use cases that we cover the most is for uh professional bodies. uh in this case it was for the official college of nurses of Barcelona and yeah they had more than 40,000 members and yeah uh again we used their own credentials to authenticate and then we enabled that two factor authentification via SMS and and email for having this this extra layer of security and yeah we are very happy that these professional bodies are among the most interested uh user groups uh on using uh digital voting because there's something they need to do they they are forced to do it uh each each

year and finally we also provide uh the technology uh to Dows and we uh onchain decisions uh this was uh an endeavor we we end up having in in uh forecaster uh I don't know if you're familiar with sorry I don't know if you are familiar with uh this thing about the frames and the mini apps and so on so basically what we did were was to integrate uh a a to create uh voting processes from the application and to make people be able to vote from their social feeds and it was super nice. We had uh good uh good feedback on them and yeah and for example the DJ DAO which is one of the I

would say most one of the biggest uh Dows in the in the forecaster space uh is using uh this solution for for the voting needs. So yeah, as you can see, we have uh yeah, we had like a lot of um different use cases and this uh validates the need of of uh of the market and of the people to to use the this kind of technology. It's just better to use this technology. We are uh working online all the day. All the financial u structure is online, but we still voting like 200 years ago. So I think it's time to to change this. And now we think that the technology is ready. So yeah, this was a bit of a background about Bogdoni uh where we

came from, who we are, uh some use cases and now uh if you don't mind, I will uh pass the the micro to P so he can introduce you to Dainci and uh the the new protocol we are building. I'm going to stop sharing the screen so P can share his screen and meanwhile I will be listening and preparing the live demo with the the wallets you are sharing in the chat. Thank you so much. Thank you Jordan. Uh so hey uh I'm Pao I am um current tech lead at Pogdoni. I have been also a founder of Pogdoni together with more people in 2018. So I have been some time already on this on this field and yeah now I would like to

introduce uh the technical side and the details of the new protocol we're working on which is the Davinci protocol. Uh I hope I'm going to be a bit technical here. I hope I'm not getting people bored. Um yeah, let's let's try to to make it uh quick, fast, and and clear for everyone. So uh and yeah, a last disclaimer uh I'm not a cryptographer. I am a computer engineer with some uh crypto cryptography knowledge. But um yeah, we have a cryptographer in our team. So if there are very specific questions on

cryptography, I think I would like to to forward to to her. Um so Davinci Davinci is an acronym that means the centraliz the centralized autonomous vault integrity network with cryptographic inference. Uh here you have the white paper URL. Uh so if some of you want to open it, you can also have some extra details on this on this document. It's white paper.b So let's start explaining why the acronym why the name because it means a lot actually. So first is the centralized autonomous meaning that the protocol can run autonom autonomously same as uh DAO right so this is because

we're using as you may know Ethereum smart contracts and uh a specific purpose z rollup network uh so at some point we can disappear and the protocol should uh keep running uh it's a vote integrity network so it's this is the main objective of the protocol and it's a network made out of sequencers that accumulate, verify and aggregate votes and send the final proof to Ethereum and it uses cryptographic inference. So meaning that uh in order to uh get conclusions so to get the tally the result at the end we are only

using cryptographic premises. So we try to avoid uh a single point of failure and and trust to any authority here. Yeah, these are the designs princip uh properties. Um so when we started to design Dainci, this was the list of things that we wanted to accomplish. Uh and this comes from our experience um uh implementing voting solutions. So for instance, I'm not going to go through all of them, but uh for instance, the Ethereum signers compatibility and hardware wallets is a requirement that we have and it's quite

hard to achieve in a voting protocol like this because as you may know Ethereum signature scheme is not very ZK friendly. Also there is a issue with deterministic signatures that um makes it makes very hard to create nullifiers for a voting process and also if we want to support hardware wallet it means that we don't have access to private keys. So we only have yeah some signature uh that uh it's not the perfect tool for voting I would say like this. Um we also wanted to support other uh identity systems like ROS or

ADDCA. Uh so we created the the protocol flexible to be able to block different identity systems. uh everything should should be based on should should be based on ZKS snarks that's also very important from the beginning to the end and lastly I would just say that uh the technology and the design uh is done to be implemented now. So we are not uh basing our solution on not ready cryptography or technology. We want to use the tools that we already have in order to have the system ready

yesterday. Let's see a quick overview on the architecture. Uh we have mainly three components here. We have the voters that send the vote. Then we have the network of sequencers that work offchain let's say and they are accumulating votes from the voters. They are accumulating votes aggregating them adding them in a share state and then committing this state to Ethereum. So the only information that is stored on Ethereum is the the root hash of this of this state. This is how the state looks. It's uh more or less it's a sparse Merkel tree. It's very

common in blockchains to use a Merkel tree as as a state because it's a deterministic construction. Uh so and also in in ZKS NARS it's it's very common. So we using the Iden 3 implementation the one that is available on circum if you have been using circum or snarks then you probably are using the the SMT processor. Uh so we use exactly the same tree and we have implemented this in other languages. So we have in circum and go in generic and so on and and this is how it looks. This is the state for a single voting process. So on every voting process there is a new state in order to start a voting process

um the organizer needs let's say to build the initial state and from this initial state new votes are being uh accumulated and added and the state is is uh evolving to a new state. Uh the state contains the configuration of the voting process. This is the the left side. So these are um static um paths where some static information is stored like the process identifier, the sensor route, the valid mode and we will talk about that later, encryption key and so on. So these are like yeah uh things that the results are

changing but the rest are not changing. So they uh resume uh the the voting process itself. describe the voting process and in the right side we have the nullifiers the valid the addresses and the vote ids. So on it on every new batch of boats new of these um Merkel tree uh leaves and paths are being added to the to the state and this state is constructed by several sequencers. So it's it's a it's a matter of collaborating let's say using Ethereum as as a coordination platform. Let's go step by step how it

works. Uh so the first one is the orchestration. It means that the organizer or someone needs to create the voting process on Ethereum. We have a smart contract where you can send a transaction uh with some data like the census root hash the duration and the valid configuration. uh and then on this transa this transaction will trigger uh the sequencer network to start to process votes that voters eligible voters are sending to the sequencers. Yeah, of course the census needs to be built in advance. That's something which is not part of the protocol. Uh you can build the census in many ways. So you can have a list of

addresses or uh you can use an NFT or ESC20 token to build also census. We have some tooling around it which facilitates the creation of a census. Uh it's also possible to create a ZKS snark uh verifying that a census out of some data on Ethereum is is is correct. That's something we still have uh not started to implement but that's something that we we want to do also in the future. But for now you need to build your sensors. That's organizer responsibility.

Um yeah then in the step one we have the sequencers uh generating the encryption key. This is a threshold encryption key uhomorphic you using amomorphic encryption Elgamal on electric core. Um so uh we have designed or elaborate a distributed key generation protocol that the sequencers must follow in order to create together this threshold encryption key. Threshold means that in order to decrypt the results at the end you don't need the full set of sequencers. You don't need the 100%. You need maybe a 60 70%. It depends on the threshold.

Um so they will use Ethereum the our Ethereum smart contract to coordinate and to go through the steps in order to create this encryption key. This is around two transactions per sequencer more or less to Ethereum in order to exchange the information required for for doing this this MPC. Then uh once the key is generated the the voters can start sending ballots and in this case the voter needs to build a valid envelope uh that follows a list of constraints and this is verified by a zik snark

which is executed or generated on the on the browser of the of the user. Uh the constraints are that the voter is illegible. So there is a a census Merkel proof that proves that the voter is part of the census and the valot is correctly encrypted with the encryption public key uh and Elgal and so on. So all of this is also verified inside the smart circuit and the encrypted valot or let's say the plain text valot follows the voting rules. So if you have four candidates, you cannot vote to the five candidates candidate right. So uh

we enforce all these rules uh on this ZKSN which is generated on the on the client's device. And regarding the valid um rules, this is also important. Um we have designed something that we call the valid protocol. It's a very simple um mechanism uh to to define several different kind of voting types. With this system you can you can do range voting, rank voting, quadratic voting, uh budgeting, um even multi- choice and so on. uh and yeah I'm not going to go deep in into this but you have all the

documentation also in the vogon developer portal uh about this valid protocol and also in the white paper but mainly as to to summarize it h a a valid is an array of numbers and then you have a set of rules that decides how this valid must be format and these are the valid variables so max count for instance indicate how what's um how many fields of the right needs to be sent to the to the voting process. Yeah. Then step three, votes are batch and here is where the sequencers get into work and committed to Ethereum. So the sequencers will

fetch votes and we'll aggregate them. Currently our our batch is uh of 60 volts. Uh we we want to to increase this uh to 100 or maybe even thousand. We believe it's it's possible. Uh as bigger the the bats, bigger also the circuit. Um so this is a bit like the block size on Ethereum, right? You if you want to to have um compatibility with with device with commodity hardware then you cannot like uh increase a lot this the size because then only uh people that can afford very big machines

can participate in the sequential network and this goes against the centralization. Um so the votes are homorphically add to the existing encrypted results and also this is very important they are re-encrypted uh by the sequencer. So reenryption when we're talking about amomorphic amomorphic encryption means to add to zoom zero. So uh if you zoom zero to something which is encrypted you're having the same result but you're changing some um say some parameters of the of the encryption payload that will remove any receipt uh that the user might use

afterwards in order to to um to prove uh how they vote. Sorry, I'm going to disable notifications. Okay. Um Okay. Uh so the votes are r encrypted and then the batch of votes of re encrypted votes which is everything it's verified on inside zark. So all of these must be uh safe and sequencers must always follow all the rules. Uh so once the batch is uh aggregated then the se sequencer creates the state transition.

So he proves that from one route to the next one there is only uh the batch of boats added to the state the results are correctly uh added uh to the new votes and everything works as expected. So then we have the new state route and this state route is sent to Ethereum which verifies the ZKS smart proof and if it's correct it will update the state route on Ethereum. This is how any chicken roll up works to be honest but uh in this case we are doing it for boats. Um the sequencer network can work in parallel. This is also a nice property from our zig rollup system. Not

all of the zig rollups allows this property to to have a par. Oops. Hey, you're muted but you went down for some seconds. Yeah. Yeah, I know. Sorry. Let's keep going. So, um yeah, I would I was saying that uh we allow working in parallel for the sequencers and that's something that I would say most of the Zika rollup uh networks around do not allow.

uh it's that uh everyone can be also actually a sequencer. Everyone can prove a state transition and everyone can send it to a finger. So they can work in parallel. Parallel doesn't mean that they this is still the problem with the data races, right? So it's there is a sequencer working from on a state transition and another in the same time window they might collide at some point. that can happen. But then it's is it's like any blockchain like the first one will will be the one um having succeed on the on the on the state transition.

Um then voters can override their vote privately also. This is a very important uh property for for for um for coercion, resistance and and so on. uh we allow the the voter to in in any time during the voting process to send again the vote and in order to hide the overrides from votes we are performing random re encryptions on every uh state transition. So on every state transition a sequencer must re-encrypt randomly a number of ports uh and so an external observer or other

sequencers do not know for sure if if it's the user a voter that sends an override to the network or if it's a random encryption from the sequencer. So this is how we are mitigating delivery and and corion. Um at the end votes are decrypted and results are published. So the sequencers will need to also to change some information. This can be done this time can be done offchain. Um in order to decrypt the results uh it's important that in the this process of decryting results the the key of the for decryting the results cannot be used for decryting individual ballots

only the results. uh and then one of the sequencers or a coordinator of sequencers or whatever will create a ZKS snark proof proving that the results are correctly decrypted and we'll send this a new transaction to Ethereum. Uh in this transaction we mainly have the last state route the results in plain text uh as a public inputs and and that's it. And then uh as a private input we have some uh miracle proofs and so on to prove uh that we are correctly decryting the results. Uh so the the decryption of results matches with the encrypted

results that is um available inside the state tree with that root. So with this proof we already have the results and we have the last state. And now let's talk a bit more about how did we organize the circuits. Uh there is a lot of zkos code in in our uh implementation and circuits is the is is the main the main thing here. And so this is some decisions that we take um for implementing the the circuits.

First, we're using G 16 for now uh because uh it's uh cheap and easy to verify on Ethereum, but in the future we might also go for Plunk or or other variants. We're using circoms on the client side and in our experience for zk snarks this is the best on browser and especially on mobile phone browsers which are very limited. So we have if we have this real world let's say non-technological users around uh we need to provide a solution that works for all of them and to be honest snarks

is the only thing that in our experience uh work everywhere uh and that's thanks to Jordi Bina and all the work that he did with programming in web assembly directly and optim amazing everything. So it's a it's a it's amazing imaging work and and this is something that we we we we know we we we want to use in the in the client side and in the back end at the end we started trying uh SP1 and some ZKVMs but it was heavy it was maybe too heavy and then it we had the issue with the centralization what was I was telling before so if we want something that can be running let's say almost commodity

commodity hardware ware then we need a solution with uh do not require like a GPU or a cluster of GPUs and and uh one terabyte of memory. Uh so we end up uh using Garch by consensus. It's a very fast and highly optimized pro prover and especially and this is why we decided to use generic for now is that it supports many cures but especially these two cures uh that allow native recursion. So as we are aggregating votes then we need to have a good recursion um framework and um this this these

cures available on generic uh work pretty pretty pretty good on this on this sense and then yes it's also not as high uh level as a zika VM but still the generic syntax is easy to to use to understand and to implement. So, uh that's also one of the points of of Garch. And regarding the circuits, uh we don't have a single circuit that makes everything. We have split the working for actually five. There is the results circuit which is not here. But in the in the process of validating and aggregating votes, we have four circuits. the valot which is the one in

the browser then the authenticate that's and also transforms the proof so we have a BN2 two uh 54 proof uh from circom in the browser then we change to the BLS curve here on genark on the on the on the sequencer side and then we aggregate with the native recursion uh recursion 60 of them and finally we create the state transition This design I think is nice because um the second circuit the authenticate can be parallelized. So you can have a cluster of hard of of of devices uh doing the the proving of the of this of

the c of this zks. uh so you can scale horizontally. Then you have the aggregate with it which is a heavy task but it's okay and the state transition is also heavy is is the is the bigger circuit uh but it's reduced to the minimum scope that that we need for proving the state transition. So in case you have a collision with some other sequencer you only need to repeat the last circuit the state transition. This is the time and the number of constraints that everyone needs. Uh they are not yet optimized. Uh I think we just implemented them.

Actually we achieve a complete flow uh two weeks ago or something like that. Uh but we are still in in heavy development. Uh so we believe that these numbers of constraints and so on will will be reduced uh in the future for sure. And at the end I have added some estimation about what's the cost of a vote because this is also a very important question to understand the sustainability of the of the whole system. Um and these are the numbers. So we're using right now this kind of server to create the proofs which is an AMD Ryzen 9 that you can find it for $150 month in some providers on the

internet. And then as the votes are being queued added to the queue and they are being processed one after the other uh we can process a number of uh approximately um 14,000 votes per day. So the whole calculation also taking into into account the the gas cost of the transactions to update the state route on Ethereum uh gives a number that's an approximation of course of uh 0.0013 0013 per volt which is okay I would say. Uh yeah and finally let's talk

about the risks that we have detected. I mean nothing is perfect. Uh Dainci is not perfect and there are some risk and some things that we need to improve probably in the future and there are probably some new risk that we still don't know that will appear because voting it's very hard. It's a very hard problem to solve to be honest. Um so yeah, sequencers can call you to decrypt individual votes. Good thing here is that they cannot manipulate results since everything is CK snark um proven uh but they can break privacy.

So the mitigation here is that if you need something that is very uh for for high stake election that requires that the voter is anonymous forever let's say uh then you can use another cryptographic scheme on the identity of the voter instead of using uh Ethereum addresses let's say you must use uh ADSA addresses uh and then you can anonymize anonymize also the identity on the first circuit generated on the browser because you can generate a valid nullifier.

Um yeah, availability or censorship. So uh that can also happen like sequencer go down for some reason or they uh decide not to process a vote. The good thing here is that anyone can send a valid state transition. So if sequencer is not available anymore, you can even run your own sequencer. uh sequencers might also uh collute to in order to not decrypt the results. Uh the mitigation that we have for that is to require a collateral and slice them. So um yeah, if you want to to be a sequencer that holds an encryption key, then you need to provide some

collateral. And then also compromised voting devices means that for instance the mobile phone you're using for voting is compromised and it manipulates the vote at the last time before you voting. Uh this is a very hard complex to to solve. Uh but what we can say is to use verified UI front ends or devices. But of course we consider that the the web application or or the mobile application that the user is is using for voting is is is secure. Uh yeah and finally just saying that the test net is almost here. I hope uh at the end of June we will have

something already public uh on on Sepia so people can start to play to to test the system to to participate as sequencer or keyeper or something like this. Uh so yeah we are very open to to to to create new collaborations and and to have uh early adopters for for our test net. So yeah in you have the link here to a to a form uh you want to stay up to date about this upcoming event and you also can you can also scan the QR code and that's it.

Thank you so much P. Uh yeah, so while P was uh explaining like the technical part of uh Dainci, uh thanks for putting your your addresses here. I created a test voting process. Uh so the idea is that every every anyone can uh test what we have been building. So right now uh I will share here in the chat a link to the voting process. This is the UI we're using right now under the hood. It runs uh on the tendermin uh custom layer one network. But the idea is that you can get an idea of how uh the vter or what the voter feels when it's using the the application. I I can go uh uh bit later if we have time on the process of of the

creation of the election. But here you will experience the same the same uh experience that say a real world user will will have. And uh yeah uh just a disclaimer uh this voting is anonymous uh using zik snags and the results will be published uh uh at the end of the so if you're using a mobile phone for voting uh the computation on the client side is quite heavy. We try to maintain it as the minimum as possible but if you're using like a mid lowend mobile phone uh take your time. Maybe it takes like 50 or 40 seconds to to generate your your uh vote envelope. So yeah, uh let me share the screen so I can also uh show uh the

voting from my site. Uh let me check if I can do that. Okay. Yeah, I think it's already pinned. Yeah, it's been perfect. So yeah, the idea is to vote on the our favorite topic which is pizza. So the idea is that we we create an approval voting process to help the PSC group uh to collaborate collaboratively sorry uh decide on the ideal combination of ingredients for our pizza. So here you have a list of uh toppings that we we that you can choose. So you can choose

uh one or even more of them. And yeah uh the idea is that also your role remains anonymous and with all the things that we explained and you can also override your vote. So this is what the the user will will see at the end. So first this is like my organization. I already have added my address and yours of course and first thing you need to do is to sign up. So first you sign here. I'm already signed in. So in that case for example if you want a two factor two factor authentication when you sign up you need to put like your credentials and then there's a second step where where you recite the two factor identification and then you can vote. Uh the cool thing about this is that this is created with

Ethereum addresses but it can be um extrapolated also to private database that organizations can have and so on. So that's why we need I mean we want to maintain the census creation very open because when you face like real world or organizations they have uh different ways of of u managing their member base. So yeah in that case for example my toppings would be tomato sauce, mozzarella, onions, bacon and arugula for example. Okay, now I just need to select press on bolt and now my my vote is being created on the client side because it's anonymous. It takes a bit for creating everything but I think in

some seconds we will see that the vault is is already processed and then what we give is a link to an explorer that we have which is an explorer for the L1 network and someone that doesn't know about technology can just click on a verify your vote button and he or she can see uh all the the information about their vote while remaining uh anonymous. So let's see the presentation and the live presentation got help us and hopefully this will not break uh let's see okay maybe meanwhile I can go uh um yeah okay now my vote is submitted so

you can see like the okay this I can go sorry I can go here to verify my vote so I can press here and it this redirects me to the uh voting explorer. So I can see that my vote has been registered correctly and here uh the from I mean this is the election I voted on. Here are the details of my vote. So for example, I didn't override my my vote. These are some encryption the encryption key index that was used and yeah and some cryptographic information. And here we can see the vote package which was um encrypted and it contains all the relevant information. So yeah, uh a user that wants to verify their vote, they can just use the uh the code that you

can see uh on the top um on the bottom uh left side of the screen which is the your identifier or this one and then you can just go here verify your vote and you add your vote ID and this is uh process your vote and says if your vote was tampered or and it was or not and it was correctly put it there. So yeah, uh now I for example I can resubmit my vote if I change my mind of I being cursed because someone is pointing me with a gun saying that tomato sauce is not like the right option and we should put pineapple and then I can uh change this vote in front of him or her and then I can uh just resubmit my vote. And this

was like uh the the the UI that the voter will will see when voting. Okay. And yeah, just for not extend it like a bit here I have my organization and when creating a new vote I can just go to a new voting. Here I put a title, description, the start time and end time uh for example tomorrow at uh 700 p.m. And here I can put for example I want the results to be encrypted until the end. I want to allow vote override. I want the vote uh to be casted anonymously using the zk technology. Uh and for example if I click next here I can choose the voting

type. So we have s single choice approval voting I can put my question here options add more options then click next and here's oh sorry uh and here we have the cool part which is the census. So we support uh custom data, Gitcoin, passport, Ethereum wallets, token based here. For example, you can select your network and import the token you want and then we have for example integrations via phone number, email, CRM, database, digital certificates. So cool thing about the custom data is that you can download a CSV template and then you can put all the fields here that are recognized uh by the the UI but also on the pro at a protocol level for

authenticating the user and yeah you just uh put your census here for example when I created this election I was putting the addresses that you shared with me here and why I was adding the the addresses one by one or I can just upload a CSV and then when I click next the election basically it's created and you get exactly the link that I shared with you here in the in the in the chat. So that would be like the voting experience and as I said this for now is like production environment and is being used by by organizations and by the people and the idea is that once we have uh Dainci uh production ready and everything is is properly audited and so on we should we

just will do a like a swap and we'll use like the the new back end and also the UI is uh the organization management and so on is being revamped a bit taking into that. Yeah, that was uh the the demo. Uh I think I think we might end the voting part. I think I think I can because there are seven out of eight votes. Okay, nice. There's someone that has not cast a vote for some reason, but uh yeah, maybe yeah, I can end the vote in

here. Okay, so now when I end the process, uh the back end will have a signal and then the the encryption keys will be published and the votes could be decrypted and we'll have the the results. So I click on end process. So a transaction has been okay. So the voting has ended and hopefully you will see the results in a way. Let me refresh screen.

Okay. So yeah, we have the results here. So if you go to explorer also I can go to processes. We created the collective pizza voting which ended. We have the publish it uh uh encryption keys and here we can see the results on the explorer to here and also on the on the application. So, our perfect pizza would be a pizza with tomato sauce, with mozzarella cheese, some onions, some pineapple also. No.

Uh, and yeah, that will be like our perfect pizza for for the VSC lure team today. So, yeah, I hope pineapple cannot. Well, it's just a matter of preferences. Uh, okay. So I hope that you enjoyed like the the live uh session that you enjoyed the voting and you had a great experience and yeah hopefully uh with the new uh system we can optimize a bit more uh on the client side so you don't need like to wait that uh many seconds but we will see.

Uh so yeah that's it. uh any questions that you might have uh please feel free to write it and we'll be super happy to to answer them. Thank you so much. Great. Thank you so much guys. Uh I think I'll start with a question if you don't mind. Um so I wasn't sure I wasn't sure about the the state transition. So you mentioned that can be done by anyone, right? So you don't need to be a sequencer or you do like I think you mentioned about the stake being needed but yeah um and also I wasn't really

sure about the sort of race condition because if you can like like in parallel like provides straight transition and if someone does it before me then technically mine would be outdated because I will be starting from an old state route. So how does that work? Uh so uh we actually are splitting the work of keyepers with the sequencers. So uh in the beginning we had everything together like uh sequencer will hold a key and so on as as a slice of the key. Um but uh in the last months we have decided to split. So

because this is more censorship resistant as anyone can send a state transition. So there is no actual point for not allowing anyone to send a state transition. Uh so in one side you have we will have the keyepers. You can run a sequencer which is also a keyeper or you can just run a keyeper or you can just run a sequencer and um for running a keyeper uh it will require very low profile hardware. So uh you can use maybe a raspberry API whatever you only need to to hold the key. So we also expect to have more um more distribution on the key if if we do this way. So and and the keyeper is the one that requires to to provide some collateral and so on

not the sequencer. The sequencer will get paid because of the work they they they doing. So depending on the number of votes that you have sequenced then you will have a share of the the budget for the voting process. Um but it's not uh he's not going to be sliced and um what about the race condition part? Uh so when you submit the state update like is there some sort of like start and stop where um only one can do it at a time or how would that work? Yeah, we still don't have this problem. So I I like to see like a lot of sequencers and and boats going on then we can think

about that. My first take would be to try to build something offchain some communication channel maybe through IPFS uh using gossip poop or whatever kind of protocol uh in order to let the good behavior sequencers at least to change information about hey I'm doing this um um transition so others can can just uh try to coordinate a bit but yeah let's say that we will allow some competence here too. So, uh if you want if you have a data race, you need to rebuild your state transition and send it again.

Yeah. And another thing that we thought about it was uh to provide like um a time frame uh for the sequencers to be able to to upload uh the state transition. So let's say the sequential public t ends in an odd or even number for example uh you will have like this time frame for for that you are allowed to submit an state transition but we still need to to figure this out like uh with a real case scenario and doing some simulations. Nice. And what about the census like where is that store? So like is my understanding that the user that never actually talks to Ethereum, right? They

just like send the proof and everything to you um to to the sequencer, right? Um and yeah, like how would someone verify the census and um Yeah. Yeah. Yeah. The census it's out of the scope of the protocol. It's more in the application level. Um so it's another layer. Um and yeah we we we want to provide tools in order to build censuses and to verify censuses on chain. Um but yeah in our experience most of of our experience is on web two.

Uh so usually the organizations have a census some way you can audit the census. So at some point you can see uh you can verify that uh if you have a member base of 10 people you have 10 keys on the census for instance and you can also randomly ask to the people this is your key. No that's something that can be done and and in the other side if you want to build some sensors out of Ethereum information then the the the way would be to either to use some optimistic approach. So you we have this tool with this service that we call census 3 which scans the Ethereum network and will

build a miracle tree of the census out of any token that you you want but then you need to post the census route somewhere and to wait for someone to challenge it or whatever. So that's an optimistic approach and the other is the ZK approach which means that uh you can build the sensors and then you can create a ZKS snark proving that the sensors is correctly built using the storage proofs and this is feasible at least with the technologies that we have been exploring to up to thousand or maybe 10,000 10,000 um addresses on the sensors then maybe with commodity hardware you need like few hours in order to create this snark to

verify the census which is uh feasible. Great. Thank you. I think we got a few in the Q&A as well. Can we see somehow? Yeah, if you go next to the chat, we'll have this this square made of points. Uh you can go to uh questions and answer. Oh, great. And if you go view, I think Vivian was the Okay. the first if I wrong. Okay. Uh so the first one is why SMT and not IMT. I think IMT means

indexed tree. Uh so we go for a sparse because um I mean proving a state transition is not easy because you need to prove a lot of things. Then you need to prove that you have changed some value some some path or some leaf and then you must also prove that you have not modified any other leaf on the tree. That's hard to achieve. Um it's a hard problem to achieve. So with indexed Merkel trees yeah they are smaller and so on they are more efficient but uh we didn't find any existing implementation that uh work for us with all the requirement that we have and for

the sparse Merkel tree we have the ident 3 implementation from circum that we have port to genark and it contains exactly what we needed. So this sparse miracle tree and the processor implemented with circum is exactly to prove this kind of state transitions. So for now we're using an S SMT but yeah maybe in the future we change to even to vertical trees or whatever else. Okay. Um next one is have you compared your solution with other similar projects othering the same problem?

Yes, we have uh I mean I don't want to go into details. Every solution is a valid solution and it covers probably different uh needs. Uh we have been we have learned a lot from Macy for instance. Um also from from conversations about how how to improve Macy. Uh I think our solution and ZK Macy are quite similar in some aspects but uh yeah I think we maybe are more more focused to scalability um and Macy or CKS is more focused to on chain voting uh but that's just a take I don't know

in deep the all the details then there are yeah other solutions similar we have helios and and valios and so on which are also systems that achieve similar properties without using zikas narks but they are not decentralized as far as I understand and there is always a kind of authority or single point of failure yeah and in terms of the centralized voting and open source I think Davinci and Macy are probably the only ones at least the ones that I can can find. You take the next one, Charlie.

Yeah. Uh so how are sequences incentivized to behave honestly? This is via token. Uh yeah. Uh sequences needs to stake uh some tokens uh in order to to be able to uh get sliced uh if they behave uh if they don't behave properly. And then the organizer of the elections need to uh pay up front those tokens and the the the cost of the election is calculated via formula that we have described on the on the paper and then uh depending on the number of uh rewrites the votes processed and so on.

Uh the final cost of the election is is is calculated and the sequencers keep uh the the the economic incentive for the votes that they processed and so on. And then the organizer will will get back like uh the the difference. Uh and the other part of the question is what is the economic security slashing conditions required to keep the sequencers uh behaving honestly. So right now uh we didn't had a lot of time to make uh proper um calculations on that. We don't had a lot of time to make uh uh let's say um some prospections on on the cars that we have. But the cool thing about this is that how the way that we uh envision this is that uh the

organizers will have uh the free will to choose how many sequencers uh they want to use. Uh so they can tweak a bit like the security level. So for example, if you want to use all the sequences of the network, you should be paying to all the sequencers of the network and then the election will be uh will be uh more more expensive. Uh but yeah, this is something that we need to finally figure out. Uh we have like the basis uh and yeah, we need some more time to to work on the on the on the details of this.

Yeah. Well, the next one is a clarification and AMT means incremental merry and I think the same the same answer applies. Uh actually an indexed Merkel tree is also incremental. Um, so yeah, nothing else to comment here. And and Dennis O'Neal is asking about a way to connect to for a user for a voter to know on which proposals can he participate. Yes, this is out of the DNC protocol scope but this is in the the application level and as we are working on this new uh application actually that the the one that Jordi showed is let's say the old

one but we have we are cooking a new one which will be very nice and much powerful I would say and on this new web application we will support things like that. Yeah. uh because that's also a need that we detected uh uh from some other use cases. Yeah. So I think we are done with the with the questions. Yeah. I just wanted to point out like some things uh is that I think there's like not a lot of people in the world uh working on on digital voting and I'm always trying to push to for collaboration and to to try

to build uh something together. I don't know if this should be like the world voting dow or something like that but I think it would be nice like to exchange uh information about what we are building the way we are uh trying to solve these problems and so on. So two weeks ago we had the call with with ship.org voting and I had the pleasure to to exchange some information with with the founder and it was super nice because I mean we kind of ended up trying to solve like the the same problem from the from the UI perspectives and and so on and given that we are like not that much people and yeah and this thing is difficult and especially at a social layer also for

politicians to adopt technology and so on. I think we should be pulling together and trying to to upgrade the way we are voting because yeah proper paper voting is is not that that much nice uh nowadays. So yeah uh we are open also to contributions on the code. Uh if you have some feedback on the paper please uh reach to us. If you need further clarifications reach reach us. Uh I think we can share here our contacts in the chat. Um also if you need the slides please uh feel free I don't know Alex they will be updated like on uh uploaded sorry on the on the YouTube channel but if you need uh so we can send a copy so yeah people can

follow the the slides too and yeah just wanted to say thank you to the PSC team for having us here today and to give us the the opportunity to present uh the things that we have been cooking over the the past years and Yeah, hopefully we'll end up having like a proper solution that solves uh the needs. Thank you. Yeah, thank you so much guys. This was awesome. Um yeah, you know, there's a bright future with all the stuff that you guys are building, S is building, uh Macy Enclave as well. like it's good that people target it in different ways and you know I want to be

optimistic and you know I really like your energy and everything. I think you you guys are doing great work and uh yeah it was a pleasure to have you. Um yeah, if no one else has got any questions, you know, uh sorry, go on, Paul you think you wanted to say something, Paul? No sorry. No worries. Thank you everyone. Yeah, cool. Thanks. Yeah, I know. Yeah, I wanted to say that thank you for organizing this this this event. I think it's amazing what you're doing here. Cool. Thank you for coming.

Yeah. Awesome. I'll stop the recording.