Fa temps que ens interessa el tema de l'anonimat a les criptomonedes i intentem seguir el desenvolupament de les tecnologies en aquest àmbit. En els nostres articles ja hem comentat amb detall els principis de funcionament a Monero, i també realitzat tecnologies existents en aquest camp. Tanmateix, totes les criptomonedes anònimes actuals es basen en el model de dades proposat per Bitcoin - Unspent Transaction Output (d'ara endavant UTXO). Per a cadenes de blocs basades en comptes com Ethereum, solucions existents per implementar l'anonimat i la confidencialitat (per exemple, o ) va intentar replicar el model UTXO en contractes intel·ligents.
El febrer de 2019, un grup d'investigadors de la Universitat de Stanford i Visa Research alliberat "Zether: cap a la privadesa al món dels contractes intel·ligents". Els autors van ser els primers a proposar un enfocament per garantir l'anonimat a les cadenes de blocs basades en comptes i van presentar dues versions d'un contracte intel·ligent: per a transaccions confidencials (amagar saldos i imports de transferència) i anònimes (amagar el destinatari i el remitent). Trobem interessant la tecnologia proposada i ens agradaria compartir-ne el disseny, així com parlar de per què el problema de l'anonimat a les cadenes de blocs basades en comptes es considera molt difícil i si els autors van aconseguir resoldre'l completament.
Sobre l'estructura d'aquests models de dades
En el model UTXO, una transacció consta de "entrades" i "sortides". Un anàleg directe de "sortides" són els bitllets de la cartera: cada "sortida" té alguna denominació. Quan pagues a algú (forma una transacció) gastes una o més "sortides", en aquest cas es converteixen en "entrades" de la transacció i la cadena de blocs les marca com a gastades. En aquest cas, el destinatari del teu pagament (o tu mateix, si necessites canvi) rep les "sortides" recentment generades. Això es pot representar esquemàticament així:
Les cadenes de blocs basades en comptes s'estructuren com el vostre compte bancari. Només tracten l'import del vostre compte i l'import de la transferència. Quan transfereixes una quantitat del teu compte, no cremes cap "sortida", la xarxa no necessita recordar quines monedes s'han gastat i quines no. En el cas més senzill, la verificació de la transacció es redueix a comprovar la signatura del remitent i l'import del seu saldo:
Anàlisi de la tecnologia
A continuació, parlarem de com Zether amaga l'import de la transacció, el destinatari i el remitent. A mesura que descriurem els principis del seu funcionament, observarem les diferències entre les versions confidencial i anònima. Com que és molt més fàcil garantir la confidencialitat a les cadenes de blocs basades en comptes, algunes de les restriccions imposades per l'anonimat no seran rellevants per a la versió confidencial de la tecnologia.
Ocultar saldos i imports de transferència
S'utilitza un esquema de xifratge per xifrar saldos i transferir quantitats a Zether . Funciona de la següent manera. Quan l'Alice vol enviar en Bob b monedes per adreça (la seva clau pública) Y, tria un nombre aleatori r i xifra la quantitat:
on C - quantitat xifrada, D - valor auxiliar necessari per desxifrar aquesta quantitat, G - un punt fix de la corba el·líptica, quan es multiplica per la clau secreta, s'obté la clau pública.
Quan Bob rep aquests valors, simplement els afegeix al seu saldo xifrat de la mateixa manera, per això aquest esquema és convenient.
De la mateixa manera, Alícia resta els mateixos valors del seu saldo, només com Y utilitza la teva clau pública.
Amaga el destinatari i l'emissor
La barreja de "sortides" a UTXO es remunta als primers dies de les criptomonedes i ajuda a amagar el remitent. Per fer-ho, el mateix remitent, quan fa una transferència, recull "sortides" aleatòries a la cadena de blocs i les barreja amb les seves. A continuació, signa les "sortides" amb una signatura d'anell: un mecanisme criptogràfic que li permet convèncer el verificador que les monedes del remitent estan presents entre les "sortides" implicades. Les monedes mixtes, per descomptat, no es gasten.
Tanmateix, no podrem generar sortides falses per amagar el destinatari. Per tant, a UTXO, cada "sortida" té la seva pròpia adreça única i està vinculada criptogràficament a l'adreça del destinatari d'aquestes monedes. De moment, no hi ha manera d'identificar la relació entre l'adreça de sortida única i l'adreça del destinatari sense conèixer les seves claus secretes.
En el model basat en comptes, no podem utilitzar adreces puntuals (en cas contrari, ja serà un model de "sortides"). Per tant, el destinatari i el remitent s'han de barrejar entre altres comptes de la cadena de blocs. En aquest cas, es debiten monedes 0 xifrades dels comptes mixts (o s'afegeixen 0 si el destinatari és mixt), sense que en realitat es modifiqui el seu saldo real.
Com que tant l'emissor com el destinatari tenen sempre una adreça permanent, es fa necessari utilitzar els mateixos grups per a la barreja quan es transfereix a les mateixes adreces. És més fàcil mirar-ho amb un exemple.
Suposem que l'Alice decideix fer una contribució a la caritat de Bob, però prefereix que la transferència es mantingui anònima per a un observador extern. Aleshores, per disfressar-se en el camp del remitent, també entra als comptes d'Adam i Adele. I per amagar en Bob, afegiu els comptes de Ben i Bill al camp del destinatari. Fent la següent contribució, l'Alice va decidir escriure Alex i Amanda al seu costat, i Bruce i Benjen al costat de Bob. En aquest cas, quan s'analitza la cadena de blocs, en aquestes dues transaccions només hi ha un parell de participants que s'entrecreuen: Alice i Bob, que desanonimitza aquestes transaccions.
Carreres de transaccions
Com ja hem comentat, per ocultar el vostre saldo en sistemes basats en comptes, l'usuari xifra el seu saldo i l'import de la transferència. Al mateix temps, ha de demostrar que el saldo del seu compte continua no negatiu. El problema és que en crear una transacció, l'usuari crea una prova sobre l'estat actual del seu compte. Què passa si en Bob envia una transacció a l'Alice i s'accepta abans que l'envia l'Alice? Aleshores, la transacció de l'Alice es considerarà no vàlida, ja que la prova del saldo es va crear abans que la transacció d'en Bob fos acceptada.
La primera decisió que es produeix en aquesta situació és congelar el compte fins que es realitzi la transacció. Però aquest enfocament no és adequat, perquè a més de la complexitat de resoldre aquest problema en un sistema distribuït, en un esquema anònim no estarà clar el compte de qui bloquejar.
Per solucionar aquest problema, la tecnologia separa les transaccions entrants i sortides: la despesa té un efecte immediat en el balanç, mentre que els rebuts tenen un efecte retardat. Per fer-ho, s'introdueix el concepte "època": un grup de blocs de mida fixa. La "època" actual es determina dividint l'alçada del bloc per la mida del grup. Quan es processa una transacció, la xarxa actualitza immediatament el saldo del remitent i emmagatzema els fons del destinatari en un dipòsit d'emmagatzematge. Els fons acumulats només es posen a disposició del beneficiari quan comença una nova "era".
Com a resultat, l'usuari pot enviar transaccions independentment de la freqüència amb què es rebin els fons (sempre que el seu saldo ho permeti, és clar). La mida de l'època es determina en funció de la rapidesa amb què es propaguen els blocs per la xarxa i la rapidesa amb què una transacció entra en un bloc.
Aquesta solució funciona bé per a transferències confidencials, però amb transaccions anònimes, com veurem més endavant, genera problemes greus.
Protecció contra atacs de repetició
En les cadenes de blocs basades en comptes, cada transacció està signada per la clau privada del remitent, la qual cosa convenç el verificador que la transacció no s'ha modificat i que l'ha creat el propietari d'aquesta clau. Però, què passa si un atacant que escoltava el canal de transmissió intercepta aquest missatge i envia exactament el segon? El verificador verificarà la signatura de la transacció i estarà convençut de la seva autoria, i la xarxa tornarà a cancel·lar la mateixa quantitat del saldo del remitent.
Aquest atac s'anomena atac de repetició. En el model UTXO, aquests atacs no són rellevants, ja que l'atacant intentarà utilitzar sortides gastades, que en si mateixes no són vàlides i són rebutjades per la xarxa.
Per evitar que això passi, s'incorpora un camp amb dades aleatòries a la transacció, que s'anomena nonce o simplement "sal". Quan torna a enviar una transacció amb una sal, el verificador mira si el nonce s'ha utilitzat abans i, si no, considera la transacció vàlida. Per no emmagatzemar tot l'historial de noces d'usuari a la cadena de blocs, normalment en la primera transacció es defineix igual a zero i després s'incrementa en un. La xarxa només pot comprovar que el noce de la nova transacció difereix d'un en un de l'anterior.
En l'esquema de transferència anònima, sorgeix el problema de validar les noces de transacció. No podem vincular explícitament el nonce a l'adreça del remitent, ja que, òbviament, això desanonimitza la transferència. Tampoc no podem afegir-ne un a les noces de tots els comptes participants, ja que això pot entrar en conflicte amb altres transferències que s'estan processant.
Els autors de Zether proposen generar el nonce criptogràficament, en funció de l'"època". Per exemple:
Aquí x és la clau secreta del remitent, i Gepoch — un generador addicional per a l'època, que s'obté fent hash una cadena de la forma "Zether +". Ara el problema sembla que s'ha solucionat: no revelem el nonce de l'emissor i no interferim amb els noces dels participants no implicats. Però aquest enfocament imposa una limitació greu: un compte no pot enviar més d'una transacció per "època". Aquest problema, malauradament, continua sense resoldre, i actualment fa que la versió anònima de Zether, segons la nostra opinió, sigui poc adequada per al seu ús.
La complexitat de les proves de coneixement zero
A UTXO, l'emissor ha de demostrar a la xarxa que no està gastant una quantitat negativa, en cas contrari serà possible generar noves monedes de la nada (per què això és possible, vam escriure en un dels anteriors). ). I també signar les "entrades" amb una signatura d'anell per demostrar que entre les monedes que es barregen hi ha fons que li pertanyen.
A la versió anònima de la cadena de blocs basada en comptes, les expressions de prova són molt més complexes. El remitent demostra que:
- L'import enviat és positiu;
- El balanç es manté no negatiu;
- El remitent ha xifrat correctament els imports de la transferència (incloent zero);
- El saldo del saldo només canvia per a l'emissor i el destinatari;
- El remitent és propietari de la clau privada del seu compte i, de fet, figura a la llista de remitents (entre els implicats);
- El Nonce utilitzat en la transacció està compost correctament.
Per a una prova tan complexa, els autors utilitzen una barreja (un dels autors, per cert, va participar en la seva creació) i , que s'anomenen bales Sigma. La prova formal d'aquesta afirmació és una tasca força difícil i limita molt el nombre de persones disposades a implementar la tecnologia.
El resultat?
Segons la nostra opinió, la part de Zether que aporta privadesa a les cadenes de blocs basades en comptes es pot utilitzar ara mateix. Però de moment, la versió anònima de la tecnologia imposa greus restriccions al seu ús i la seva complexitat a la seva implementació. No obstant això, no s'ha de descartar que els autors el van publicar fa només uns mesos, i potser algú més trobarà una solució als problemes que hi ha avui dia. Després de tot, així es fa la ciència.
Font: www.habr.com