Transacciones privadas: información sobre los principios de diseño en ZCash y Aleo

Referencias Zcash - Especificación del protocolo Zcash Aleo - Especificación del protocolo Zexe

Zcash

1. Acerca de Zcash?

Un video corto para aprender sobre Zcash.

Características:

• Versión anónima de BTC, modelo similar a UTXO
• Solo se puede usar para escenarios de pago sin programabilidad

2. Conceptos principales

Nota: Zcash se ha sometido a varias actualizaciones de protocolo y solo nos centramos en la última versión. Este artículo presenta principalmente los conceptos básicos de Zcash.

2.1 Componentes clave

• sk : clave de gasto, generada uniformemente
• preguntar: gastar clave de autorización
• ak: gasta la clave de validación
• nk: clave de derivación del anulador
• rivk: aleatoriedad
• dk: clave diversificadora
• ivk: clave privada / clave de visualización entrante
• ovk: tecla de visualización saliente
• pkd: clave de transmisión
• Clave de gasto: clave secreta
• Clave de visualización completa: descifrar el contexto de la transacción
• Clave de visualización entrante
• Tecla de visualización saliente
• Dirección de pago blindada: debe ser diferente cada vez

Puede conocer los métodos de cálculo de estas claves en la especificación del protocolo Zcash: sección 4.2.3, página 36.

2.2 Notas

Note es la unidad básica del protocolo Zcash, similar al UTXO de BTC; en Zcash, las entradas y salidas de todas las transacciones son notas. Por supuesto, Zcash también admite transacciones no anónimas, idénticas al modelo de transacciones de Bitcoin. Por lo tanto, para comprender mejor Zcash, primero debe conocer la estructura de datos de la nota:

• {d,pk_d}: información de la dirección del propietario de la nota
• v : el monto correspondiente de la nota
• {ρ,ψ}: calcular el número aleatorio del anulador
• rcm : se utiliza para calcular el número aleatorio del compromiso de la nota

En el protocolo Zcash, la nota no se puede hacer pública debido al requisito de privacidad. Por lo tanto, se debe calcular el compromiso correspondiente para representar la nota. El método de cálculo es el siguiente:

2.3 Transferencia de acciones

Una transacción puede contener múltiples transferencias de acción, y cada transferencia de acción gastará el billete anterior y generará un nuevo billete. La estructura de datos es la siguiente:

• cv^{net}: se utiliza para la verificación de saldo para la transferencia de acciones en forma de firma vinculante sin incluirse en la prueba zk
• rt^{Orchard}: el estado de árbol del bloque anterior, que se utiliza para verificar la validez de la nota gastada
• nf: el logotipo del billete gastado, que se utiliza para evitar el doble gasto
• rk: se utiliza para verificar que el gastador tiene derecho a gastar el billete en forma de verificación de firma de gastoAuthSig
• cm_x: compromiso de generar una nueva nota
• clave pública temporal epkepk, que se utiliza para descifrar la información de la nota del nuevo billete
• C^{enc},C^{out}: el texto cifrado cifrado de la nueva nota
• enbaleSpends, enableOutputs: indicando el tipo de transferencia de la acción actual
• π: prueba de zk

2.4 Declaración de acción

Las entradas públicas son:
Las entradas de privacidad son:
Las afirmaciones para probar:

• La integridad de la nota gastada está vinculada de forma única a la reclamación de la nota
• Validez de la nota gastada, prueba de existencia del árbol de cm.
• La integridad del compromiso de valor está vinculada únicamente a rcv , el valor anterior y el valor nuevo
• La integridad del anulador evita el doble gasto y mantiene un conjunto de billetes gastados
• Legitimidad del billete gastado
• Integridad de la dirección
• Integridad de la nueva nota
• Bandera de legitimidad

2.5 Construcciones y ejemplos de transacciones

2.5.1 Construcción de transacciones

Toda la estructura de la transacción consta de cuatro partes:

• Información pública (1 - 5)
• Información de transacciones transparentes (6 - 9)
• Información de transacciones de árboles jóvenes (10 - 16)
• Información de transacción de huerto (17 - 25)

2.5.2 De transparente a escudo

El protocolo Orchard incluye dos tipos de direcciones, dirección transparente (TA) y dirección de protección (SA). Generalmente, para ejecutar una transacción privada, primero es necesario transferir de TA a SA. La estructura de transacción correspondiente debe ser:

• Información pública (1 - 5)
• Información de transacciones transparentes (6 - 9)
  • tx_in _* : valor real
  • tx_out _* : valor por defecto
• Información de transacciones de árboles jóvenes (10 - 16)
  • Todos: valor por defecto
• Información de transacción de huerto (17 - 25)
  • Todo: valor real

2.5.3 De escudo en escudo

El protocolo Orchard incluye dos tipos de direcciones, dirección transparente (TA) y dirección de protección (SA). Generalmente, para ejecutar una transacción privada, primero es necesario transferir de TA a SA. La estructura de transacción correspondiente debe ser:

• Información pública (1 - 5)
• Información de transacciones transparentes (6 - 9)
  • Todos: valor por defecto
• Información de transacciones de árboles jóvenes (10 - 16)
  • Todos: valor por defecto
• Información de transacción de huerto (17 - 25)
  • Todo: valor real

2.5.4 De escudo a transparente

El protocolo Orchard incluye dos tipos de direcciones, dirección transparente (TA) y dirección de escudo (SA). Generalmente, para ejecutar una transacción privada, primero es necesario transferir de TA a SA. La estructura de transacción correspondiente debe ser:

• Información pública (1 - 5)
• Información de transacciones transparentes (6 - 9)
  • tx_in _* : valor por defecto
  • tx_out _* : valor real
• Información de transacciones de árboles jóvenes (10 - 16)
  • Todos: valor por defecto
• Información de transacción de huerto (17 - 25)
  • Todo: valor real

2.6 ¿Cómo se logra la privacidad?

• Desvinculable
  El billete generado está representado por cm, y el billete gastado está representado por nf. No hay conexión entre nf y cm. Por lo tanto, nadie puede saber en qué transacción se gastó cualquier billete generado.
• Privado
  • Dirección del remitente:
    La información de la transacción no contiene la dirección del remitente y el gastoAuthSig es una firma única (es diferente cada vez, por lo que la clave pública es diferente, rk)
• Dirección del receptor:
  La transacción no contiene la dirección del destinatario y la nueva nota está encriptada por la clave pública del destinatario (la dirección privada del destinatario también es única)
• Valor:
  Oculte la nota en forma de compromiso de pedersen y asegure el atributo de saldo de la transacción mediante bindsig

Aléo

1. Las similitudes y diferencias con Zcash

Zcash solo puede ejecutar transacciones privadas basadas en el modelo OUTX y no tiene programabilidad; por lo tanto, la principal diferencia entre Aleo y Zcash es la programabilidad de privacidad; y la similitud es que ambos admiten atributos de privacidad (la privacidad de las transacciones no se limita solo a los activos).

2. Aleo contra Zcash

2.1 Unidad

A diferencia del billete de Zcash, la unidad básica de operación de Aleo es el registro (UTXO en BTC). Encuentre las principales diferencias entre los dos a continuación:

Aunque los nombres de los parámetros específicos son diferentes, existe una relación correspondiente entre los dos desde el punto de vista funcional: correspondiente a la información de dirección del propietario de la nota, información relacionada con el compromiso, información relacionada con nf/sn y valor- información relacionada, respectivamente.
Por lo tanto, las estructuras de los dos son bastante similares; las principales diferencias existen en el predicado de nacimiento y predicado de muerte del registro, que son dos funciones de tipo booleano, que representan las condiciones que deben cumplirse cuando un registro se encuentra en las etapas de nacimiento (generación) y muerte (gasto). Esta parte es compatible con la definida por el usuario, por lo que es programable.

2.2 Construcción de transacciones

Todavía hay algunas similitudes en comparación con la construcción principal de la transacción de Zcash (2.5.1):

• El número de serie correspondiente sn del registro gastado, que está representado por nf en Zcash, es único
• El compromiso del nuevo disco
• La denuncia del nuevo registro, incluyendo los datos del titular, correspondiente nacimiento/defunción predicado, etc.

2.3 Declaración del probador

Necesitas probar:

• La vigencia del antiguo registro
• La legitimidad del registro anterior (tiene derecho a gastar el registro)
• La vigencia del nuevo récord
• La validez del predicado de nacimiento/muerte (similar a la verificación de saldo en Zcash)

3 más

3.1 Tecnologías no mencionadas

Desde la perspectiva del documento, el diseño de privacidad del diseño de privacidad programable de Aleo es más similar al documento técnico anterior de Zcash ( zerocash ), la estructura de clave similar, la estructura de nota similar y el nombre similar (nf se llama sn en zerocash , número de serie). Este artículo hace una comparación basada en el último artículo de Zcash y el ZEXE de Aleo. Aunque existen diferencias en detalles específicos, como la estructura de la clave y los métodos criptográficos específicos utilizados, el diseño de alto nivel es generalmente el mismo.
Además de los detalles técnicos descritos anteriormente, todavía hay algunos otros detalles técnicos que aún no se han mencionado, como el esquema de prueba delegado, el algoritmo de prueba de conocimiento cero, el esquema de recursividad/agregación, etc. Las personas interesadas en ellos pueden estudiar más.

3.2 ¿Por qué todos están basados en UTXO, no en cuentas?

Observación 2.3 (Especificación del protocolo Zexe: sección 2.3, página 11)