Levamos moito tempo interesados no tema do anonimato nas criptomoedas e intentamos seguir o desenvolvemento das tecnoloxías nesta área. Nos nosos artigos xa comentamos en detalle os principios de funcionamento en Monero, e tamén realizada tecnoloxías existentes neste campo. Non obstante, todas as criptomoedas anónimas hoxe están construídas sobre o modelo de datos proposto por Bitcoin - Unspent Transaction Output (en diante UTXO). Para cadeas de bloques baseadas en contas como Ethereum, solucións existentes para implementar o anonimato e a confidencialidade (por exemplo, ou ) intentou replicar o modelo UTXO en contratos intelixentes.
En febreiro de 2019, un grupo de investigadores da Universidade de Stanford e Visa Research liberado "Zether: cara á privacidade no mundo dos contratos intelixentes". Os autores foron os primeiros en propoñer un enfoque para garantir o anonimato nas cadeas de bloques baseadas en contas e presentaron dúas versións dun contrato intelixente: para transaccións confidenciais (ocultar saldos e importes de transferencia) e anónimas (ocultar o destinatario e o remitente). Parécenos interesante a tecnoloxía proposta e gustaríanos compartir o seu deseño, así como falar sobre por que se considera moi difícil o problema do anonimato nas cadeas de bloques baseadas en contas e se os autores lograron resolvelo por completo.
Sobre a estrutura destes modelos de datos
No modelo UTXO, unha transacción consta de "entradas" e "saídas". Un análogo directo de "saídas" son as facturas da túa carteira: cada "saída" ten algunha denominación. Cando pagas a alguén (forma unha transacción) gastas unha ou máis "saídas", nese caso convértense en "entradas" da transacción e a cadea de bloques márcaas como gastadas. Neste caso, o destinatario do teu pago (ou ti mesmo, se precisas cambio) recibe as "saídas" recentemente xeradas. Isto pódese representar esquemáticamente así:
As cadeas de bloques baseadas en contas estrutúranse como a túa conta bancaria. Só tratan o importe da túa conta e o importe da transferencia. Cando transfire algunha cantidade da súa conta, non queima ningunha "saída", a rede non precisa lembrar que moedas se gastaron e cales non. No caso máis sinxelo, a verificación da transacción pasa por comprobar a sinatura do remitente e o importe do seu saldo:
Análise da tecnoloxía
A continuación, falaremos de como Zether oculta o importe da transacción, o destinatario e o remitente. A medida que describimos os principios do seu funcionamento, observaremos as diferenzas nas versións confidencial e anónima. Dado que é moito máis fácil garantir a confidencialidade nas cadeas de bloques baseadas en contas, algunhas das restricións impostas pola anonimización non serán relevantes para a versión confidencial da tecnoloxía.
Ocultar saldos e importes de transferencia
Utilízase un esquema de cifrado para cifrar saldos e transferir cantidades en Zether . Funciona do seguinte xeito. Cando Alicia quere enviar a Bob b moedas por enderezo (a súa clave pública) Y, ela escolle un número aleatorio r e cifra a cantidade:
onde C - cantidade cifrada, D - valor auxiliar necesario para descifrar esta cantidade, G - un punto fixo na curva elíptica, cando se multiplica pola clave secreta, obtense a clave pública.
Cando Bob recibe estes valores, simplemente engádeos ao seu saldo cifrado do mesmo xeito, polo que este esquema é conveniente.
Do mesmo xeito, Alicia resta os mesmos valores do seu saldo, só como Y usa a túa chave pública.
Ocultar o destinatario e o remitente
A mestura de "saídas" en UTXO remóntase aos primeiros días das criptomoedas e axuda a ocultar o remitente. Para iso, o propio remitente, ao realizar unha transferencia, recolle "saídas" aleatorias na cadea de bloques e mestúraas coas súas propias. A continuación, asina as "saídas" cunha sinatura de anel, un mecanismo criptográfico que lle permite convencer ao verificador de que as moedas do remitente están presentes entre as "saídas" implicadas. As moedas mixtas en si, por suposto, non se gastan.
Non obstante, non poderemos xerar saídas falsas para ocultar o destinatario. Polo tanto, en UTXO, cada "saída" ten o seu propio enderezo único, e está ligado criptograficamente ao enderezo do destinatario destas moedas. Polo momento, non hai forma de identificar a relación entre o enderezo de saída único e o enderezo do destinatario sen coñecer as súas claves secretas.
No modelo baseado en contas, non podemos usar enderezos únicos (se non, xa será un modelo de "saídas"). Polo tanto, o destinatario e o remitente deben mesturarse entre outras contas na cadea de bloques. Neste caso, as moedas 0 cifradas cárganse das contas mixtas (ou engádense 0 se o destinatario é mixto), sen que realmente cambie o seu saldo real.
Dado que tanto o remitente como o destinatario sempre teñen un enderezo permanente, faise necesario utilizar os mesmos grupos para mesturar cando se transfiren aos mesmos enderezos. É máis fácil mirar isto cun exemplo.
Digamos que Alice decide facer unha contribución á organización benéfica de Bob, pero prefire que a transferencia permaneza anónima para un observador externo. Entón, para disfrazarse no campo do remitente, tamén entra nas contas de Adam e Adele. E para ocultar a Bob, engade as contas de Ben e Bill no campo do destinatario. Facendo a seguinte contribución, Alice decidiu escribir a Alex e Amanda xunto a ela, e Bruce e Benjen xunto a Bob. Neste caso, ao analizar a cadea de bloques, nestas dúas transaccións só hai un par de participantes que se cruzan: Alice e Bob, que desanonimiza estas transaccións.
Carreiras de transaccións
Como xa mencionamos, para ocultar o seu saldo en sistemas baseados en contas, o usuario cifra o seu saldo e o importe da transferencia. Ao mesmo tempo, deberá demostrar que o saldo da súa conta segue sendo non negativo. O problema é que ao crear unha transacción, o usuario constrúe unha proba sobre o estado da súa conta actual. Que pasa se Bob envía unha transacción a Alice e acéptase antes que a enviada por Alice? Entón, a transacción de Alice considerarase non válida, xa que a proba de saldo foi construída antes de que a transacción de Bob fose aceptada.
A primeira decisión que se produce nesta situación é conxelar a conta ata que se realice a transacción. Pero este enfoque non é axeitado, porque ademais da complexidade de resolver un problema deste tipo nun sistema distribuído, nun esquema anónimo non estará claro quen debe bloquear a conta.
Para solucionar este problema, a tecnoloxía separa as transaccións entrantes e saíntes: o gasto ten un efecto inmediato no balance, mentres que os recibos teñen un efecto atrasado. Para iso, introdúcese o concepto de "época": un grupo de bloques de tamaño fixo. A "época" actual determínase dividindo a altura do bloque polo tamaño do grupo. Ao procesar unha transacción, a rede actualiza inmediatamente o saldo do remitente e almacena os fondos do destinatario nun tanque de almacenamento. Os fondos acumulados póñense a disposición do beneficiario só cando comeza unha nova "era".
Como resultado, o usuario pode enviar transaccións independentemente da frecuencia con que se reciban os fondos (sempre que o permita o seu saldo, claro). O tamaño da época determínase en función da rapidez coa que se propagan os bloques pola rede e a rapidez coa que unha transacción entra nun bloque.
Esta solución funciona ben para transferencias confidenciais, pero con transaccións anónimas, como veremos máis adiante, xera serios problemas.
Protección contra ataques de repetición
Nas cadeas de bloques baseadas en contas, cada transacción está asinada pola clave privada do remitente, o que convence ao verificador de que a transacción non foi modificada e que foi creada polo propietario desta clave. Pero e se un atacante que estaba escoitando a canle de transmisión intercepta esta mensaxe e envía exactamente a mesma segunda? O verificador verificará a sinatura da transacción e convencerá da súa autoría e a rede cancelará de novo a mesma cantidade do saldo do remitente.
Este ataque chámase ataque de repetición. No modelo UTXO, este tipo de ataques non son relevantes, xa que o atacante tentará utilizar saídas gastadas, que en si mesmas non son válidas e son rexeitadas pola rede.
Para evitar que isto ocorra, incorpórase na transacción un campo con datos aleatorios, que se chama nonce ou simplemente "sal". Ao volver a enviar unha transacción cun sal, o verificador mira se o nonce se utilizou antes e, se non, considera a transacción válida. Para non almacenar todo o historial de nonces do usuario na cadea de bloques, normalmente na primeira transacción establécese igual a cero e, a continuación, increméntase nun. A rede só pode comprobar que o nonce da nova transacción difire da anterior por un.
No esquema de transferencias anónimas, xorde o problema de validar nonces de transacción. Non podemos vincular explícitamente o nonce ao enderezo do remitente, xa que, obviamente, isto desanonimiza a transferencia. Tampouco podemos engadir un aos nomes de todas as contas participantes, xa que isto pode entrar en conflito con outras transferencias que se están procesando.
Os autores de Zether propoñen xerar o nonce criptograficamente, dependendo da "época". Por exemplo:
Aquí x é a clave secreta do remitente e Xepoca — un xerador adicional para a época, obtido por hash dunha cadea da forma "Zether + ". Agora o problema parece estar resolto: non revelamos o nonce do remitente e non interferimos cos nonce dos participantes non implicados. Pero este enfoque impón unha limitación seria: unha conta non pode enviar máis que unha transacción por "época". Este problema, por desgraza, segue sen resolverse, e actualmente fai que a versión anónima de Zether, na nosa opinión, sexa pouco apta para o seu uso.
A complexidade das probas de coñecemento cero
En UTXO, o remitente debe demostrar á rede que non está gastando unha cantidade negativa, se non, é posible xerar novas moedas da nada (por que isto é posible, escribimos nun dos anteriores ). E tamén asina as "entradas" cunha sinatura de anel para demostrar que entre as moedas que se mesturan hai fondos que lle pertencen.
Na versión anónima da cadea de bloques baseada en contas, as expresións de proba son moito máis complexas. O remitente demostra que:
- A cantidade enviada é positiva;
- O saldo segue sendo non negativo;
- O remitente encriptou correctamente os importes da transferencia (incluído cero);
- O saldo do saldo cambia só para o remitente e o destinatario;
- O remitente posúe a clave privada da súa conta e en realidade está na lista de remitentes (entre os implicados);
- O Nonce usado na transacción está composto correctamente.
Para unha proba tan complexa, os autores usan unha mestura (un dos autores, por certo, participou na súa creación) e , que se chaman balas Sigma. A proba formal de tal afirmación é unha tarefa bastante difícil e limita moito o número de persoas dispostas a implementar a tecnoloxía.
O resultado?
Na nosa opinión, a parte de Zether que brinda privacidade ás cadeas de bloques baseadas na conta pódese usar agora mesmo. Pero polo momento, a versión anónima da tecnoloxía impón serias restricións ao seu uso e a súa complexidade á súa implementación. Non obstante, non hai que descontar que os autores o publicaron hai só uns meses, e quizais alguén máis atope unha solución aos problemas que existen na actualidade. Despois de todo, así se fai a ciencia.
Fonte: www.habr.com