Ezagutu Vocdoniren boto anonimoaren zehaztapen teknikoak, eta jakin nola iritsi ginen diseinu honetara.
Ferran
· 12 min irakurtzeko
Zehaztapen teknikoetan murgildu aurretik, komeni da azaltzea nola definitzen dugun boto anonimoa, eta zergatik iritsi ginen diseinu honetara. Produktua iragartzeko artikuluan bi anonimotasun mota aurkeztu genituen: boto-txartelen lausotzea eta hauteslearen anonimotasuna.
Boto-txartelen lausotzea boto bakoitzaren edukia ezkutatzetik eratorritako anonimotasuna da; hauteslearen anonimotasunak, berriz, hautesle bakoitzaren eta haren botoaren arteko lotura eteten du, botoak berak ezkutatu gabe. Gure boto anonimoaren inplementazioak hauteslearen anonimotasuna erabiltzen du. Zergatik?
Lehenik eta behin, boto-txartelen lausotzeak kostu nabarmenak dakartza berekin. Bozketa-prozesu bat muturretik muturrera egiaztagarria izan dadin, hautesleek emandako boto-txartelen edukia jarraitu eta aztertu ahal izan behar dute. Anonimotasuna boto-txartelen lausotzearen bidez bermatzen badugu, egiaztagarritasuna galtzen dugu: ezinezkoa da zure botoa zenbatu dela egiaztatzea eta bozketaren osotasuna auditatzea, boto guztien edukia ezkutuan badago.
Boto-txartelen lausotzearen beste eragozpen bat da zaila dela bozketa-sistema digital batean inplementatzea. Lausotze-teknika horietako bat zifratze homomorfikoa da, ohiko bozketa-sistemei anonimotasun kriptografikoa emateko proposatu izan dena. Zifratze homomorfikoak balio zifratuekin kalkuluak egitea ahalbidetzen du; hau da, botoen zenbaketa egin daiteke boto-txartel bakar baten edukia ere aztertu gabe. Teorian sendoa bada ere, zifratze homomorfikoak eragozpen asko ditu, eta horiek erakargarritasuna kentzen diote bozketa-teknologiaren oinarri gisa.
Nabarmenena: metodo honek boto-txartel zifratuen oinarrizko kalkuluak baino ez ditu ahalbidetzen, eta, horren ondorioz, zailagoa da bozketa koadratikoa edo hurrenkerazko bozketa bezalako eskemak inplementatzea. Gainera, zifratze homomorfikoarekin emaitzen kalkulua bermatuta badago ere, hauteslearen boto-txartelaren muturretik muturrerako egiaztapena ez dago bermatuta. Eskema honek ez du froga kriptografikorik ematen hauteslearen boto-txartela emaitzen multzoan sartu dela eta zuzen islatu dela bermatzeko. Horrez gain, gure kalkuluen arabera, bozketa-prozesu baten froga homomorfikoa balidatzeak baliabide konputazional handiak eskatuko lituzke, eta eskakizun hori areagotu egiten da bozketa handiagoetan. Horrek unibertsalki egiaztagarria den sistema baten onurak ezerezean utz litzake, egiaztapena makina ahaltsu eta garestietan soilik kalkulatu ahal izango bailitzateke, gehiegizko epe luze batean.
Hauteslearen anonimotasunak hainbat abantaila ditu zifratze homomorfikoaren aldean. Lehenik, muturretik muturrerako egiaztagarritasun-maila askoz handiagoa lor daiteke. Hauteslearen eta haren boto-txartelaren arteko loturak opakua izan behar du kanpoko edozein hirugarrenentzat, baina hautesleek beraiek beren boto-txartela identifika dezakete. Boto-txartelak ikusgai daudenez, beraz, edozein erabiltzailek bere botoaren jarraipena egin dezake, eman zuen unetik emaitzetan sartu arte. Gainera, hirugarrenek egiazta dezakete boto-txartel bakoitza hautesle baliodun batena dela eta txartel horren edukia zuzen zenbatu dela.
Hauteslearen anonimotasunak, gainera, diseinu konputazionalki askoz eraginkorragoak ahalbidetu ohi ditu. Anonimotasun horretan oinarritutako sistemek behin bakarrik lausotzen dute hautesle bakoitzaren boto-froga, boto berri bat eman ahala emaitza multzo osoa lausotu beharrean. Ez da urrats konputazional handirik behar emaitzak denen eskura jartzeko. Bozketaren emaitzak bozketa-prozesuan zehar ere argitara daitezke, anonimotasuna arriskuan jarri gabe (betiere denbora-korrelazioko erasoak arinduta badaude).
Horregatik erabaki dugu hauteslearen anonimotasuna gure errolda-frogaren mekanismoan txertatzea.
Hautesle-erroldaren mekanismoaren abiapuntua erroldaren Merkle zuhaitza da: gako publiko hashatuen egitura bat, non gako bakoitzak erroldako hautesle baliodun bat ordezkatzen duen. Merkle zuhaitzari esker, edozein hautesle baliodunek froga dezake erroldako censusKey bat duela, gainerako hautesleen gakoak ezagutu gabe. Ondoren, hautesleak froga hori bere boto-txartelaren barruan bidaltzen du. Boto-gutunazal horri nullifier bat ere eransten zaio: erabiltzailearen censusKey-tik eta electionID-tik eratorritako datu bat, haren botoari modu bakarrean dagokiona.
Froga hori bakarrik erabiliko balitz, prozesuaren antolatzaileak boto-gutunazal bakoitza hautesle baten censusKey-arekin lotu ahal izango luke, nullifier-aren bidez, eta bozketa desanonimizatu. Hori eragozteko, Vocdonik zk-SNARKak erabiltzen ditu bozketaren anonimotasuna bermatzeko.
zk-SNARK siglak Zero-knowledge Succinct Non-interactive ARgument of Knowledge esan nahi du (ezagutza zeroko argumentu trinko eta ez-interaktiboa). zk-SNARK batek aukera ematen dio erabiltzaile bati hirugarren bati frogatzeko informazio jakin bat baduela, informazioa bera agerian utzi gabe.
Gure kasuan, zk-SNARKei esker, hautesleek froga dezakete erroldakoak direla, beren secretKey agerian utzi gabe. Zehazki, zk-Circuit baten bidez egiten da hori: ezagutza zeroko froga bat (ZKP, Zero-Knowledge Proof) sortzeko diseinatutako software-zirkuitu bat da.
Zirkuitu bat diseinatu dugu, erabiltzaileek erroldako kide direla frogatzen duen ZKP bat sor dezaten, beren secretKey agerian utzi gabe. Zirkuituak sarrera pribatuak eta publikoak jasotzen ditu, eta hauteslearen identitatea ager lezaketen datuak pribatu mantentzen dira. Sarrera publikoak boto-gutunazalaren barruan bidaltzen dira, balidatzaileek frogaren aurka egiazta ditzaten eta erabiltzaileak bi aldiz bozkatu ez duela ziurta dezaten.
Zirkuitua antzeko tamainako errolda duen edozein prozesutan erabil daiteke, eta tamaina bakoitzeko behin bakarrik sortu behar da. Zehatzago esanda, zirkuitu bat sortu eta berrerabil daiteke zuhaitz-altuera bera duen erroldaren Merkle zuhaitz ororentzat. Zuhaitz bitarra erabiltzen dugunez, horrek esan nahi du zirkuitu bat behar dela n balio bakoitzeko, non xede-erroldaren tamaina 2^n-ren barrutian dagoen (adib. 128, 256, ..., 8192, 16384, etab.).
Zirkuituaren sorkuntza konfiantzazko ezarpen-zeremonia batean oinarritzen da. Prozesu horretan zirkuituaren frogatzaile- eta egiaztatzaile-gakoak sortzen dira, eta «konfiantzazkoa» da, zeren, alderdi bakar batek gako horien sorkuntza osoa kontrolatuko balu, froga faltsuak sortu ahal izango bailituzke. Horregatik, «zeremonia» deszentralizatu bat behar da zirkuituaren fidagarritasuna bermatzeko. Zeremonia horretan, interes kontrajarriak dituzten eta toki desberdinetan dauden hainbat alderdik gako-sorkuntzaren urrats bana egiten dute. Alderdi horietako batek bakarrak ere osotasunari eusten badio, ezinezkoa izango da froga faltsurik sortzea.
franchise proof delakoa zk-SNARK zirkuitua exekutatuz sortzen da.
index, secretKey, census Merkle-proofcensus Merkle-root, nullifier, election ID, votefranchise proof
Zehaztapen teknikoetan murgildu aurretik, komeni da azaltzea nola definitzen dugun boto anonimoa, eta zergatik iritsi ginen diseinu honetara. Produktua iragartzeko artikuluan bi anonimotasun mota aurkeztu genituen: boto-txartelen lausotzea eta hauteslearen anonimotasuna.
Boto-txartelen lausotzea boto bakoitzaren edukia ezkutatzetik eratorritako anonimotasuna da; hauteslearen anonimotasunak, berriz, hautesle bakoitzaren eta haren botoaren arteko lotura eteten du, botoak berak ezkutatu gabe. Gure boto anonimoaren inplementazioak hauteslearen anonimotasuna erabiltzen du. Zergatik?
Lehenik eta behin, boto-txartelen lausotzeak kostu nabarmenak dakartza berekin. Bozketa-prozesu bat muturretik muturrera egiaztagarria izan dadin, hautesleek emandako boto-txartelen edukia jarraitu eta aztertu ahal izan behar dute. Anonimotasuna boto-txartelen lausotzearen bidez bermatzen badugu, egiaztagarritasuna galtzen dugu: ezinezkoa da zure botoa zenbatu dela egiaztatzea eta bozketaren osotasuna auditatzea, boto guztien edukia ezkutuan badago.
Boto-txartelen lausotzearen beste eragozpen bat da zaila dela bozketa-sistema digital batean inplementatzea. Lausotze-teknika horietako bat zifratze homomorfikoa da, ohiko bozketa-sistemei anonimotasun kriptografikoa emateko proposatu izan dena. Zifratze homomorfikoak balio zifratuekin kalkuluak egitea ahalbidetzen du; hau da, botoen zenbaketa egin daiteke boto-txartel bakar baten edukia ere aztertu gabe. Teorian sendoa bada ere, zifratze homomorfikoak eragozpen asko ditu, eta horiek erakargarritasuna kentzen diote bozketa-teknologiaren oinarri gisa.
Nabarmenena: metodo honek boto-txartel zifratuen oinarrizko kalkuluak baino ez ditu ahalbidetzen, eta, horren ondorioz, zailagoa da bozketa koadratikoa edo hurrenkerazko bozketa bezalako eskemak inplementatzea. Gainera, zifratze homomorfikoarekin emaitzen kalkulua bermatuta badago ere, hauteslearen boto-txartelaren muturretik muturrerako egiaztapena ez dago bermatuta. Eskema honek ez du froga kriptografikorik ematen hauteslearen boto-txartela emaitzen multzoan sartu dela eta zuzen islatu dela bermatzeko. Horrez gain, gure kalkuluen arabera, bozketa-prozesu baten froga homomorfikoa balidatzeak baliabide konputazional handiak eskatuko lituzke, eta eskakizun hori areagotu egiten da bozketa handiagoetan. Horrek unibertsalki egiaztagarria den sistema baten onurak ezerezean utz litzake, egiaztapena makina ahaltsu eta garestietan soilik kalkulatu ahal izango bailitzateke, gehiegizko epe luze batean.
Hauteslearen anonimotasunak hainbat abantaila ditu zifratze homomorfikoaren aldean. Lehenik, muturretik muturrerako egiaztagarritasun-maila askoz handiagoa lor daiteke. Hauteslearen eta haren boto-txartelaren arteko loturak opakua izan behar du kanpoko edozein hirugarrenentzat, baina hautesleek beraiek beren boto-txartela identifika dezakete. Boto-txartelak ikusgai daudenez, beraz, edozein erabiltzailek bere botoaren jarraipena egin dezake, eman zuen unetik emaitzetan sartu arte. Gainera, hirugarrenek egiazta dezakete boto-txartel bakoitza hautesle baliodun batena dela eta txartel horren edukia zuzen zenbatu dela.
Hauteslearen anonimotasunak, gainera, diseinu konputazionalki askoz eraginkorragoak ahalbidetu ohi ditu. Anonimotasun horretan oinarritutako sistemek behin bakarrik lausotzen dute hautesle bakoitzaren boto-froga, boto berri bat eman ahala emaitza multzo osoa lausotu beharrean. Ez da urrats konputazional handirik behar emaitzak denen eskura jartzeko. Bozketaren emaitzak bozketa-prozesuan zehar ere argitara daitezke, anonimotasuna arriskuan jarri gabe (betiere denbora-korrelazioko erasoak arinduta badaude).
Horregatik erabaki dugu hauteslearen anonimotasuna gure errolda-frogaren mekanismoan txertatzea.
Hautesle-erroldaren mekanismoaren abiapuntua erroldaren Merkle zuhaitza da: gako publiko hashatuen egitura bat, non gako bakoitzak erroldako hautesle baliodun bat ordezkatzen duen. Merkle zuhaitzari esker, edozein hautesle baliodunek froga dezake erroldako censusKey bat duela, gainerako hautesleen gakoak ezagutu gabe. Ondoren, hautesleak froga hori bere boto-txartelaren barruan bidaltzen du. Boto-gutunazal horri nullifier bat ere eransten zaio: erabiltzailearen censusKey-tik eta electionID-tik eratorritako datu bat, haren botoari modu bakarrean dagokiona.
Froga hori bakarrik erabiliko balitz, prozesuaren antolatzaileak boto-gutunazal bakoitza hautesle baten censusKey-arekin lotu ahal izango luke, nullifier-aren bidez, eta bozketa desanonimizatu. Hori eragozteko, Vocdonik zk-SNARKak erabiltzen ditu bozketaren anonimotasuna bermatzeko.
zk-SNARK siglak Zero-knowledge Succinct Non-interactive ARgument of Knowledge esan nahi du (ezagutza zeroko argumentu trinko eta ez-interaktiboa). zk-SNARK batek aukera ematen dio erabiltzaile bati hirugarren bati frogatzeko informazio jakin bat baduela, informazioa bera agerian utzi gabe.
Gure kasuan, zk-SNARKei esker, hautesleek froga dezakete erroldakoak direla, beren secretKey agerian utzi gabe. Zehazki, zk-Circuit baten bidez egiten da hori: ezagutza zeroko froga bat (ZKP, Zero-Knowledge Proof) sortzeko diseinatutako software-zirkuitu bat da.
Zirkuitu bat diseinatu dugu, erabiltzaileek erroldako kide direla frogatzen duen ZKP bat sor dezaten, beren secretKey agerian utzi gabe. Zirkuituak sarrera pribatuak eta publikoak jasotzen ditu, eta hauteslearen identitatea ager lezaketen datuak pribatu mantentzen dira. Sarrera publikoak boto-gutunazalaren barruan bidaltzen dira, balidatzaileek frogaren aurka egiazta ditzaten eta erabiltzaileak bi aldiz bozkatu ez duela ziurta dezaten.
Zirkuitua antzeko tamainako errolda duen edozein prozesutan erabil daiteke, eta tamaina bakoitzeko behin bakarrik sortu behar da. Zehatzago esanda, zirkuitu bat sortu eta berrerabil daiteke zuhaitz-altuera bera duen erroldaren Merkle zuhaitz ororentzat. Zuhaitz bitarra erabiltzen dugunez, horrek esan nahi du zirkuitu bat behar dela n balio bakoitzeko, non xede-erroldaren tamaina 2^n-ren barrutian dagoen (adib. 128, 256, ..., 8192, 16384, etab.).
Zirkuituaren sorkuntza konfiantzazko ezarpen-zeremonia batean oinarritzen da. Prozesu horretan zirkuituaren frogatzaile- eta egiaztatzaile-gakoak sortzen dira, eta «konfiantzazkoa» da, zeren, alderdi bakar batek gako horien sorkuntza osoa kontrolatuko balu, froga faltsuak sortu ahal izango bailituzke. Horregatik, «zeremonia» deszentralizatu bat behar da zirkuituaren fidagarritasuna bermatzeko. Zeremonia horretan, interes kontrajarriak dituzten eta toki desberdinetan dauden hainbat alderdik gako-sorkuntzaren urrats bana egiten dute. Alderdi horietako batek bakarrak ere osotasunari eusten badio, ezinezkoa izango da froga faltsurik sortzea.
franchise proof delakoa zk-SNARK zirkuitua exekutatuz sortzen da.
index, secretKey, census Merkle-proofcensus Merkle-root, nullifier, election ID, votefranchise proof
secretKey edo erroldaren Merkle froga agerian utzi gabe, zirkuitu hau gai da honako hau frogatzeko:
zkCensusKey jakin bati dagokion secretKey-aren jabea dela.zkCensusKey-a erroldaren Merkle zuhaitzean sartuta dagoela.nullifier-a modu bakarrean dagokiela haren secretKey-ari eta bozketa-prozesu jakin baten election ID-ari.Kalkulua PUZ eta memoria aldetik intentsiboa bada ere, ZKPak erabiltzailearen bezeroan sor daitezke, hardware apalean exekutatuta. Vocdoni protokoloan, froga Vochain nodoek, meatzariek eta prozesua behatzen duen edozein hirugarrenek balidatzen dute.
Zirkuitua bere gutxieneko eskakizunetaraino minimizatu eta optimizatu da, edozein bezero-hardwarerentzat eskuragarri izan dadin. Horregatik ez da sinadura-egiaztapenik erabiltzen, secretKey bidezko planteamendua baizik.
Errolda anonimoa eraikitzeko erabiltzen den Merkle zuhaitzak zk-SNARKekin bateragarria den inplementazio bat izan behar du. Gaur egun Circom konpilatzailea erabiltzen dugunez zk-SNARK zirkuituetarako, circomlib-en Merkle zuhaitzaren inplementazioarekin bateragarria den zuhaitz bat behar dugu. Merkle zuhaitz horren zehaztapena hemen aurki daiteke.
Vochain-ek arbo Merkle zuhaitza erabiltzen du, Circom diseinuarekin bateragarria den Go inplementazio bat. Merkle zuhaitzak Poseidon hash-a erabiltzen du: «SNARK-lagunkoa» den hash-funtzio bat, gero zirkuitu baten barruan froga daitekeena murrizketa gehiegi behar izan gabe. Hurrengo diagramak zk-census-proof eskeman erabiltzen den Merkle zuhaitzeko hostoen datu-egitura irudikatzen du.
index balioa errolda-zuhaitzaren eraikitzaileak zehazten du, eta errolda-zuhaitz bakoitzak bere index balioa du. Balio hori handitu egiten da hosto berri bakoitza gehitzean. Hostoak horrela egituratuta daude Merkle zuhaitzak modu eraginkorragoan erabiltzeko: erabiltzaile gehiagoren gakoak sartzen dira zuhaitz txikiago batean, eta, horrela, zk-Circuit-aren tamaina murrizten da. Izan ere, hosto bakoitzaren key-aren balioak (value) zehazten du hosto horrek zuhaitzean duen posizioa.
Hostoaren gakoa zkCensusKey-ak zehaztuko balu, index inkremental batek beharrean, hosto berri bakoitzak talka-probabilitate nabarmena izango luke, altuera jakin baterako hosto-toki guztiak bete baino lehen. Zuhaitzak, beraz, desorekatuagoak lirateke, eta zirkuitu handiagoak beharko lituzkete errolda-tamaina bererako, zuhaitz-espazioa modu ez-eraginkorrean erabiltzeagatik. Indize inkrementalaren planteamenduarekin, aldiz, hosto-toki guztiak bete daitezke talka bakar bat ere gabe. Horrek zirkuitu askoz txikiagoak dakartza erabiltzaile kopuru bererako.
{
"censusRoot": "51642541620950251760298704744678482162425252475654827255045491135352807540162",
"censusSiblings": ["0","0","0","0"],
"index": "30",
"secretKey": "6190793965647866647574058687473278714480561351424348391693421151024369116465",
"voteValue": ["100964581237483263846637432502620436451", "278307331411790712608582894981321409946"],
"electionId": "10",
"nullifier": "1938187656076799017313903315498318464349291455761501098436114043715056719301",
}
zk-Input parametro bakoitzaren jatorria:
Parametro guztiak string edo []string dira, eta bigInt edo []bigInt adierazten dute.
censusRoot: errolda-agintaritzak kalkulatzen du, errolda-zuhaitzetik.censusSiblings: errolda-agintaritzak kalkulatzen du; Merkle froga dacensusSiblings-en luzera zk-Circuit-aren araberakoa izango da:nLevels finkoa da; beraz, siblings.length ere finkoa izan behar da.siblings.length erabilitako zk-Circuit-aren araberakoa izango da, zehazki zirkuituaren nLevels parametroaren araberakoawhile (siblings.length < this.levels) siblings.push(BigInt(0));index: Vochain-ek zehazten du, erabiltzailearen zkCensusKey-a errolda-zuhaitzean gehitzeansecretKey: erabiltzaileak sortzen duvoteValue: erabiltzailearen botoaren hash balioa, bi osoko handiz osatua.sha256(vote_bytes). sha256 hash-aren irteera SNARKetan erabiltzen den eremua baino apur bat handiagoa da; beraz, hash-irteera (32 byte) 16 byteko 2 arraytan zatitzen dugu, osoko gisa hartzen ditugu (little-endian ordenan), eta zirkuituko sarrera gisa erabiltzen ditugu.sha256 hash-a erabiltzen da, etorkizunean beharrezkoa balitz zirkuituaren barruan egiaztatu ahal izateko. Erabilera horrek kontuan hartu beharreko bi ezaugarri ditu: sha256 keccak256 baino bi aldiz garestiagoa da EVMko gasari dagokionez, baina circom-en inplementatuta dago eta, beraz, zirkuitu baten barruan egiazta daiteke; sha256 circom zirkuitu batean egiaztatzea garestia da murrizketa kopuruari dagokionez (zehaztapen honen egungo bertsioan, ez da zirkuituaren barruan egiaztatzen).h := sha256.Sum256(voteBytes) // voteBytes can be the votes array converted to bytes, or the encrypted votes
b1 := new(big.Int).SetBytes(swapEndianness(h[:16])) // swap endianness, as golang big int package works in big-endian, and we use little-endian
b2 := new(big.Int).SetBytes(swapEndianness(h[16:]))
Eta zirkuiturako voteValue-ren json sarrera hau litzateke: "voteValue": [b1, b2]
electionID: erabiltzailea parte hartzen ari den bozketaren IDanullifier: erabiltzaileak kalkulatzen du: nullifier = poseidon.Hash(sk, electionID)«Nola erabil daiteke teknologia hau Ethereumeko DAOen bozketetarako?» galderari erantzuteko, testuinguru pixka bat gehitu behar dugu:
Vocdonik gaur egun urrats hauen bidez onar dezake DAOetan modu anonimoan bozkatzea:
secretKey berri bat sortzen dute eta transakzio bat bidaltzen dute Vocdoni blockchainera, hautesle baliodunak direla frogatuz (biltegiratze-froga erabiliz). Transakzio horrek secretKey hashatua barne hartzen du, eta hori rolling Census bati gehitzen zaio; errolda hori Vocdoni blockchainaren logikak kalkulatzen du barnean. Urrats horri gakoen aurre-erregistroa deitzen zaio.secretKey erabiliz
Vocdonik DKG protokolo berri bat garatu du: diseinuz ez-interaktiboa, praktikan asinkronoa eragiketetan, eta primitiba kriptografiko estandarrez eraikia.
Jordi Pinyana
5 min irakurtzeko
Azken urteotan, Vocdonik Vochain-en gainean egin ditu bozketak, bozketarako berariaz sortutako gure L1 blockchainean. Edozein blockchainek bezala, zerbait indartsua eman zigun:…
Pau Escrich
4 min irakurtzeko
Milioi bat dolarreko pre-seed erronda bildu dugu inbertitzaile aingeruen eskutik, DAVINCI garatzeko. DAVINCIk gaur egungo bozketa-sistemen mugak gainditzen ditu: zentsurarekiko erresistentea, gasik gabea, eroskeriaren aurkakoa, eskalagarria eta anonimoa den soluzioa eskaintzen du gobernantza digitalerako.
Pau Escrich
5 min irakurtzeko