Recuperación social integral: ¿Cómo logra zk-SNARKs la separación de la lógica de las transacciones de billetera y los activos?

Autor original: @Toni Wahrstätter

Fecha de lanzamiento: 12 de septiembre de 2023

Traducción: Instituto de Investigación DeBox

Prefacio

Vitalik recomienda utilizar zk-SNARK para separar las cuentas de lógica comercial de las cuentas que contienen activos. Esto mejora la privacidad, la experiencia del usuario y la recuperación social con un solo clic. El investigador de Ethereum, Toni Wahrstätter, proporciona un análisis detallado de este prototipo de billetera, que cubre el flujo de trabajo y las ventajas.

Muchas gracias a Matt por las excelentes discusiones sobre este tema y por desarrollar esta herramienta para analizar cada contrato y colocarlo en un árbol Merkle disperso que simplifica la creación de prototipos al eliminar la necesidad de pruebas zk en el árbol de patricia. Además, gracias a Vitalik por su gran aporte.

Administrar varias cuentas puede resultar un desafío por diversos motivos, incluidos problemas de recuperación social, privacidad, L2 y experiencia general del usuario. El uso de una dirección oculta complica las cosas porque cada interacción requiere una nueva cuenta. Vitalik recomienda utilizar zk-SNARK para separar las cuentas de lógica comercial de las cuentas que contienen activos. Esto mejora la privacidad, la experiencia del usuario y la recuperación social con un solo clic.

Para lo siguiente, recomiendo primero consultar la publicación “Tres transformaciones” de Vitalik para conocer algunos antecedentes.

En pocas palabras, lo que intentamos lograr es:

**Recuperación social integral sin comprometer la privacidad. **

1. Método tradicional

Una implementación simple pero que compromete la privacidad se ve así:

1. El usuario proporciona una firma y alguna intención/comando a la cuenta de haberes de activos.
2. La cuenta de haberes de activos envía la firma a la cuenta de haberes lógica.
3. La cuenta de haberes lógica deriva la clave pública de la firma y la compara con su clave pública almacenada.
4. Si se pasa la verificación, la cuenta lógica notificará a la cuenta de haberes de activos para continuar la operación.
5. La cuenta de haberes de activos ejecuta las órdenes del usuario.

La desventaja es que esto vincula públicamente cuentas lógicas y cuentas de tenencia de activos, comprometiendo así la privacidad.

2. Utilice ZK-SNARK

Al utilizar zk-SNARK, los usuarios pueden demostrar que están autorizados a gastar sin revelar la conexión entre la cuenta de haberes lógica y la cuenta de haberes de activos.

El flujo de trabajo es el siguiente:

1. El usuario construye un árbol Merkle localmente e identifica las hojas que contienen su contrato.

1.1. Un árbol Merkle básicamente contiene los valores de slot0 y slot1 de cada contrato existente ordenados por fecha o nombre.

1.2 Cada usuario puede crear un árbol Merkle localmente según el estado más reciente.

2. El usuario construye una prueba zk para demostrar que conoce el secreto en la cuenta de haberes lógica. Prueba en detalle más adelante.

3. El usuario envía zk-proof a la cuenta de haberes de activos.

4. Certificado de verificación de cuenta de tenencia de activos, que acredite lo siguiente:

4.1 Los usuarios saben dónde está la lógica.

4.2 El usuario conoce un valor secreto que se codifica y se asigna al valor almacenado en la cuenta de haberes lógica.

4.3 Los usuarios pueden reconstruir el estado de la cuenta, la raíz del árbol Merkle mantenida en la cadena canónica (por ejemplo, precompilada)

4.4 Utilice números aleatorios correctos (utilizados para cambiar claves en cuentas de haberes lógicas).

Básicamente, un usuario puede decir: “Tengo permiso demostrable de la cuenta lógica para realizar esta acción y conozco la ubicación de esa cuenta lógica”.

ventaja

• Experiencia de usuario: una clave privada o una configuración de firma múltiple pueden controlar varias cuentas, incluso si están en diferentes L2.
• Restaurar: las cuentas se pueden restaurar más fácilmente con una única actualización del contrato.
• Privacidad: No hay enlaces públicos entre cuentas.
• Compatibilidad: esto ayuda a popularizar las carteras de abstracción de cuentas (AA) y otras funciones.

Además, al agregar otro contrato (agregador) entre la lógica y el contrato de tenencia de activos, se pueden proporcionar múltiples pruebas de diferentes cuentas de tenencia de activos en una sola transacción, lo que permite que la cuenta se trate casi como una UTXO. Los agregadores podrán obtener múltiples certificados zk y enviarlos a sus respectivas cuentas de activos para su verificación. Por supuesto, un agregador de este tipo podría crear vínculos (incluida la privacidad) entre cuentas de activos individuales.

Vale la pena señalar que no es necesariamente una elección entre usar SNARK (y, por lo tanto, confiar en su seguridad) y no usar SNARK en absoluto (y, por lo tanto, perderse buenas propiedades de privacidad). Un compromiso podría ser utilizar una prueba SNARK para abrir una ventana de tiempo en el contrato de tenencia lógico, seguido de un breve retraso, después del cual el propietario del contrato de tenencia lógico puede cambiar el valor de slot0, en lugar de requerir una prueba SNARK para gastar y cambiar así la lógica del consumo. El propietario actual del contrato puede utilizar un retraso antes de que se abra la ventana de tiempo para evitar actualizaciones de credenciales.

detalles técnicos

La configuración de zk-SNARK incluye elementos privados:

• Clave utilizada para la verificación.
• La dirección lógica de la cuenta de haberes es la dirección a la que apunta la cuenta de haberes de activos.
• Rama Merkle para identificar valores estatales específicos.
• Un nonce que permite la rotación de claves al tiempo que invalida las claves antiguas. Los elementos privados, como la lógica de texto sin formato que contiene direcciones de contratos y secretos, no se hacen públicos, pero se utilizan para vincular de forma privada cuentas de haberes lógicas y cuentas de haberes de activos. Al generar pruebas de todo el estado, no es necesario que una autoridad central construya un árbol Merkle para presentar pruebas.

1. Cuenta de haberes lógica

Un prototipo de una cuenta de haberes lógica podría verse así:

solidez pragma >=0.7.0 <0.9.0;

el contrato LogicHoldingAccount es de propiedad { uint256 public slot0 = 0x1234; // secreto hash uint256 public nonce = 0; // realizar un seguimiento de los cambios clave dirección pública propietario;

función updateOwner(uint256 newValue) public onlyOwner { nonce += 1; ranura0 = nuevoValor;

• slot0: la variable pública que inicialmente contiene el valor hash. Sólo el propietario conoce la preimagen hash.
• nonce: un contador que rastrea la cantidad de actualizaciones de información del propietario. Esto garantiza que las claves antiguas dejen de ser válidas.
• updateOwner(uint256 newValue): Función que actualiza el valor y agrega un número aleatorio.

Este contrato rastrea la lógica de gasto actual del propietario (slot0) y permite actualizaciones a través de la función updateOwner.

2. Cuenta de haberes

solidez pragma >=0.7.0 <0.9.0;

contrato AssetHoldingAccount { uint256 public logicHoldingAccountHash = 1234…;

// Tamaño de campo escalar, tamaño de campo base, datos de clave de verificación, etc. // …

función verificarProof(uint [2] datos de llamada _pA, uint [2] [2] datos de llamada _pB, uint [2] datos de llamada _pC, uint [2] calldata _pubSignals) public view return (bool val) { // Código ensamblador de Snarkjs para verificación de prueba… // … }

// _pubSeñales [0] - la raíz del árbol contract-slot0||nonce Merkle // _pubSignals [1] - la función de dirección del titular lógico hased ute (dirección a pagar, monto uint256, uint [2] datos de llamada _pA, uint [2] [2] datos de llamada _pB, uint [2] datos de llamada _pC, uint [2] calldata _pubSignals) public { contractRootPrecompile.getRoot(block.number) uint256 especificadoLogicHolder = _pubSignals [1] ; require(specifiedLogicHolder == logicHoldingAccountHash, “No permitido”);

bool validProof = verificarProof(_pA, _pB, _pC, _pubSignals) == verdadero; if (validProof) { (bool éxito,) = to.call{valor:cantidad}(“”); requerir(éxito); } }

recibir() pago externo {

Las cuentas de tenencia de activos almacenan activos como ETH y permiten a los usuarios enviar pruebas de retiros. Al verificar que el LogicHolder especificado coincida con el logicHoldingAccountHash, el propietario puede garantizar que el contrato de tenencia de activos solo acepte pruebas del contrato de tenencia lógica autorizado, en lugar de cualquier contrato arbitrario.

El secreto proporcionado como señal privada al construir la prueba garantiza que sólo el propietario de la cuenta que contiene la lógica de gasto pueda acceder a los fondos de la cuenta de tenencia de activos.

3.Circuito

El siguiente circuito fue desarrollado usando circom, el código completo se puede encontrar aquí.

pragma circom 2.0.2;

incluir “./modules/merkleTree.circom”; incluir “./modules/commitmentHasher.circom”;

plantilla principal (niveles) { raíz de entrada de señal; lógica de entrada de señalHoldingAddressHash; lógica de entrada de señalHoldingAddress; secreto de entrada de señal; entrada de señal nonce; ruta de entrada de señalElementos [levels] ; ruta de entrada de señalÍndices [levels] ; componente secretHasher = SecretHasher(); secretHasher.secret <== secreto; hasher de componente = CommitmentHasher(); hasher.logicHoldingAddress <== logicHoldingAddress; hasher.secret <== secretHasher.hashedSecret; hasher.nonce <== nonce; hasher.logicHoldingAddressHash === logicHoldingAddressHash; árbol de componentes = MerkleTreeChecker(niveles); árbol.hoja <== hasher.commitment; árbol.raíz <== raíz; para ( i = 0; i < niveles; i++) { tree.pathElements [i] <== elementos de ruta [i] ; árbol.rutaíndices [i] <== índices de ruta [i] ;

componente principal {público [raíz,logicHoldingAddressHash]} = Principal(N);

El circuito tiene un total de 7 señales, 2 de las cuales son públicas, a saber, la raíz del árbol Merkle y la dirección hash de la cuenta de tenencia lógica (que debe ser codificada antes de codificarse en el contrato de tenencia de activos para evitar que los observadores agreguen la cuenta). clase) basado en la misma lógica que la cuenta del titular).

en conclusión

En un mundo donde los usuarios deben administrar varias cuentas, la necesidad de una funcionalidad única de recuperación social es cada vez más importante. Zk-SNARK se puede usar en billeteras que implementan lógica/separación de activos, lo que permite a los usuarios usar la “lógica” de la Cuenta A para gastar desde la Cuenta B sin crear un vínculo entre las dos. Como primer paso, las pruebas SNARK se pueden utilizar para acciones que sean menos riesgosas que los desembolsos de activos. Por ejemplo, un buen punto de partida podría ser permitir a los usuarios iniciar “solicitudes de retiro”. Si el propietario del contrato de tenencia lógica no presenta objeciones, el usuario puede finalizar la solicitud después de un período de tiempo.

De esta manera, el propietario del contrato de tenencia lógico aún puede intervenir, aunque rompiendo la privacidad, en caso de que suceda algo inesperado.