Autor: ChiHaoLu (chihaolu.eth) Fuente: medium Traducción: Shanoba, Golden Finance

Este artículo se centra en el desarrollo de la abstracción de cuentas (AA) en la solución Aztec Layer 2 y contenidos relacionados. Cito una serie de recursos oficiales de Aztec, incluyendo documentación oficial, blogs y tutoriales. ¡Encuentre estos excelentes recursos en la sección de referencias al final del artículo!

Antecedentes

Debido a la mayor complejidad de Aztec en comparación con otras implementaciones nativas de AA en ZK-Rollups, los lectores pueden beneficiarse de tener algo de contexto para comprender mejor este artículo.

• Familiaridad con las billeteras de contratos inteligentes y sus características
• Familiaridad con EIP-4337
• Familiaridad con la abstracción de cuentas nativas en ZK-Rollups
• Conceptos básicos de UTXO
• El concepto básico de ZK-Rollups
• Conceptos básicos de los programas de prueba de conocimiento cero

Introducción

Echa un vistazo rápido a Aztec

Aztec es una red de capa 2 de código abierto diseñada para proporcionar escalabilidad y protección de la privacidad de Ethereum. Aztec aprovecha las pruebas de zkSNARK para proporcionar protección de la privacidad y escalabilidad a través del servicio ZK-Rollup. Los usuarios de Aztec no necesitan terceros de confianza ni mecanismos de consenso adicionales para acceder a transacciones privadas.

Todos sabemos que en los ZK-Rollups tradicionales, “ZK” no significa necesariamente privacidad; Significa utilizar pruebas de conocimiento cero (ZKP) para demostrar que ciertos cálculos se han realizado correctamente fuera de la cadena. Sin embargo, en Aztec, la privacidad se implementa en ZK-Rollup además de la escalabilidad. Profundizando, en el pasado, los detalles de cada transacción eran visibles públicamente en la cadena, pero en Aztec, la entrada y la salida de cada transacción están encriptadas. Estas transacciones son verificadas por ZKP para demostrar que la información cifrada es precisa y se originó en texto sin formato. Solo el usuario que construye estas transacciones privadas conoce la información real de texto sin formato.

Incluso los caracteres importantes de ZK-Rollup, como Sequencer y Prover, no pueden determinar cuál es el texto sin formato. Toda la información sobre la transacción, incluido el remitente, el destinatario, los datos de la transacción y el valor de la transferencia, está oculta. Aunque solo los propios usuarios conocen los detalles de la transacción, aún pueden confiar en la corrección de la transacción. Esta confianza se deriva del hecho de que solo las transacciones legítimas pueden generar pruebas válidas de conocimiento cero para demostrar su exactitud.

Cómo implementar transacciones privadas y cómo verificar sus fundamentos es un gran tema que está más allá del alcance de este artículo. En términos simples, lo que necesitamos es una “capa adicional para la verificación de prueba de conocimiento cero” para validar las listas ZKP, cada una de las cuales valida una transacción privada. Por eso se llaman “ZK-ZK-Rollups”.

¿Qué es el Noir?

En Aztec, se utiliza una abstracción de cuenta nativa, lo que significa que no hay diferencia entre una cuenta de propiedad externa (EOA) y una cuenta de contrato. Todas las cuentas son contratos inteligentes. Por lo tanto, daremos una breve descripción general del ecosistema de desarrollo de contratos de Aztec, ya que es crucial para comprender el desarrollo de contratos. Sin embargo, si no planea desarrollar el contrato de cuenta usted mismo, la lectura y comprensión de este artículo no requiere que encienda su computadora y escriba el contrato. Solo necesita comprender la lógica en el código del contrato de la cuenta. ¡Puedes explorar la profundidad del tema a tu propia discreción!

Noir es un lenguaje para escribir programas SNARK, similar a Circcom y ZoKrates. No solo le permite generar automáticamente contratos de Solidity Verifier después de crear el circuito, sino que también se puede usar para escribir sus propios protocolos o incluso cadenas de bloques. Dado que Noir no se basa completamente en Aztec (no compila en un sistema de prueba específico), puede lograr sus objetivos implementando un servidor backend y una interfaz de contrato inteligente para el sistema de prueba.

En Aztec, Noir se utiliza para escribir contratos inteligentes donde las variables (estados) y las funciones pueden protegerse mediante la privacidad.

¿Qué es el estado privado y las notas privadas?

De acuerdo con nuestra comprensión de las cadenas de bloques públicas, por lo general todos los estados son públicos. En azteca, es importante comprender el concepto de estado privado y cómo administrarlo (agregar, modificar, eliminar). El Estado privado está encriptado y es propiedad de su titular. Por ejemplo, si soy el propietario de un contrato, una variable específica de ese contrato puede cifrarse y ocultarse en estado privado. Solo yo, como propietario de este estado privado, puedo descifrar el texto cifrado para obtener el texto plano.

El estado privado se almacena adjuntando solo el árbol de la base de datos. Esto se hace porque cambiar el valor de estado directamente puede filtrar mucha información del diagrama de transacciones. Sin embargo, la base de datos no almacena directamente el valor del estado privado. En su lugar, las registra como notas privadas en forma encriptada (por ejemplo, x=0 -> x=1) addr=0x00 -> addr=0x01. Así que, en realidad, estas variables privadas, aunque parecen ser variables, en realidad están formadas por un montón de notas privadas inmutables. Es la abstracción de las variables. Si no está claro, sigamos adelante.

Cuando necesite eliminar un estado privado, puede agregar los caracteres no válidos relacionados con ese estado privado a otra base de datos no válida para invalidarla. Cuando necesite cambiar el estado privado, primero invalide y luego agréguele un nuevo comentario privado.

Hablaremos del concepto de anuladores en breve. Puedes pensar en ella como la clave que necesitas para vincular una nota privada a su carácter no válido. Solo el propietario de una clave no válida puede identificar y utilizar la nota privada asociada a ella.

Llegados a este punto, los lectores expertos pueden haber notado que esta estructura es muy similar a las UTXO (salidas de transacciones no gastadas), y podemos iterar sobre las UTXO para determinar el estado actual del estado privado (aunque es importante recordar que es el usuario quien firma la transacción, no el UTXO; Lo explicaremos más adelante).

! [TEg3TOpeZXF82AgjnmG7in3uwiZp3ZtIpGsNQvxc.png] (https://img.jinse.cn/7128680_watermarknone.png “7128680”)

¿Qué es una nota privada? Un UTXO se denomina Nota, y recorremos este Árbol de Notas para obtener información sobre el estado privado. Cuando queremos cambiar el estado privado, los pasos son los siguientes:

1. El usuario recupera todas las notas privadas relacionadas con ese estado privado de la base de datos de notas.
2. El usuario (que en realidad es el nodo azteca que ejecuta el usuario) atestigua localmente la existencia de cada anotación recuperada en este árbol de base de datos.
3. El usuario añade un carácter no válido para evitar que otros vuelvan a leer la misma hoja.
4. El usuario inserta una nueva hoja (un nuevo comentario) para actualizar el valor de este estado privado.

Mecanismo AA de Azteca

¿Qué es la capa de protocolo y qué es la capa de aplicación?

Como todos sabemos, EIP-4337 tiene como objetivo trasladar todo el proceso de transacción a la capa de aplicación, implementar un sistema de retransmisión abierto y abstraer la firma (mecanismo de verificación) y el modelo de pago a través de la naturaleza programable de los contratos inteligentes. Sin embargo, para la abstracción de cuentas nativas, ya sea en StarkNet, la era zkSync o Aztec, que es el enfoque de este artículo, ciertos elementos deben grabarse en el protocolo de la capa 2 para funcionar correctamente. Por ejemplo, en Aztec, las claves de cifrado y las claves no válidas deben implementarse a nivel de protocolo.

Comprender la abstracción de cuentas nativas requiere una comprensión más profunda de cómo funciona toda la cadena (suponiendo que se llame “nativa”, con la lógica de ejecución de AA naturalmente vinculada a un protocolo de capa 2 específico). Por ejemplo, en la era zkSync, existe la necesidad de comprender el contrato del sistema, en StarkNet, existe la necesidad de comprender cómo funciona el secuenciador, y en Aztec, es crucial comprender el papel de estas “claves y su estado privado subyacente”.

Puntos de entrada de la cuenta y fases de verificación

En Aztec, a diferencia de otras implementaciones de abstracción de cuentas, no hay un nombre de función estrictamente definido (firma de función) como punto de entrada al contrato de cuenta (por ejemplo, validateUserOp en EIP-4337, validateTransactionzkSync Era y __validate__StarkNet). El usuario es libre de elegir cualquier función del contrato de cuenta como punto de entrada y enviar una transacción con los parámetros relevantes.

La función elegida por el usuario (la llamamos entrypoint()) debe ser privada (ejecutada en el entorno de ejecución privado del usuario). Solo se puede llamar desde el cliente del propietario del contrato de la cuenta (la billetera del usuario). Cuando el entrypoint() de la billetera del usuario se ejecuta localmente, también genera una prueba de conocimiento cero. Esta certificación informa al protocolo Aztec de la fase de verificación de que la ejecución fuera de la cadena se ha producido y ha sido exitosa.

Limitaciones de la fase de validación

Esto también se extiende a la cuestión de si se deben imponer o no restricciones a lo que se puede hacer durante la fase de validación. Es bien sabido que, dado que no hay límite de costo para validar transacciones (esencialmente, validar transacciones es una vista de función), un atacante puede realizar un ataque de denegación de servicio (DOS) en el mempool para comprometer el empaquetador (EIP-4337) o el operador/secuenciador (AA nativo). EIP-4337 define qué códigos de operación están prohibidos y cómo se restringe el acceso al almacenamiento. zkSync Era relaja parte del uso de OpCode, mientras que StarkNet no permite llamadas de contrato externas en absoluto.

Debido a que el protocolo Aztec implica que el cliente valide una prueba de conocimiento cero adjunta, en lugar de llamar realmente a una función de validación para determinar que el resultado es o , trueAztecfalse, a diferencia de otros protocolos, no impone ninguna restricción durante la fase de validación. El punto de entrada del contrato en la cuenta puede llamar libremente a otros contratos, acceder a cualquier almacenamiento y realizar cualquier cálculo.

Flujo de interacción

Más detalladamente, en zkSync Era y StarkNet, solo el “contrato de cuenta” puede iniciar una transacción, porque el protocolo llama a una función específica como punto de entrada, imponiendo esta restricción. Sin embargo, en Aztec, “todos los contratos” pueden iniciar transacciones, ya que no hay límite para la función a la que llama el protocolo como punto de entrada. Esto significa que en Aztec, ya no es un flujo de interacción fijo en el que un usuario envía una transacción a un rol específico (como el contrato de EntryPoint en EIP-4337 o el secuenciador/operador en AA nativo) y luego invoca el contrato de destino. Los usuarios pueden enviar transacciones a través de la billetera y dejar que el contrato de destino complete directamente las interacciones relevantes, lo que mejora en gran medida la flexibilidad.

Si está familiarizado con EIP-2938, otra implementación de AA, encontrará que Aztec es más parecido al enfoque multiinquilino en él. Sin embargo, este es un tema más profundo que puedes explorar por tu cuenta.

Claves en tu cuenta Aztec

En Aztec, cada cuenta suele tener dos claves maestras: la clave de firma y la clave maestra de privacidad.

Clave de firma

La clave de firma se utiliza para representar la autorización del usuario para realizar una acción específica mediante la clave privada. Un ejemplo sencillo es cuando un usuario registra una clave pública derivada de la clave de firma en el contrato de cuenta. A continuación, la firma generada se puede restaurar dentro del contrato firmando la transacción o el mensaje utilizando esta clave de firma para comprobar que coincide con la clave pública registrada en el contrato (también conocida como clave controlada por el propietario, que se almacena en forma de clave). addressContrato de billetera de Solidity).

La elección del algoritmo para la curva elíptica de las firmas digitales depende del usuario. Por ejemplo, Ethereum usa secp256k1, mientras que Aztec proporciona un ejemplo schnorr para usar. En el contrato de cuenta, la función entrypoint() actúa como un punto de entrada (el origen de la llamada) y es utilizada por la lógica de validación (is_valid_impl()) para comprobar si la firma Schnorr coincide con la clave pública del registro std::schnorr::verify_signature(…).

! [eWwFvxmMF7pNt0axLcucSvjcig6QHMXl2HKH3luz.png] (https://img.jinse.cn/7128683_watermarknone.png “7128683”)

La clave de firma es esencialmente la misma que la clave controlada por el propietario en la billetera de contrato inteligente con la que estamos familiarizados, por lo que debería ser relativamente fácil de entender. De hecho, las claves de firma no son absolutamente necesarias. Si el desarrollador de la cuenta ha implementado un mecanismo de verificación diferente, es posible que la cuenta no tenga una clave de firma.

Clave maestra de privacidad

La clave maestra de privacidad en su cuenta Aztec no es transferible; Cada cuenta Aztec está vinculada a una clave maestra privada. La clave maestra privada deriva la clave maestra pública, que luego se hash con el código de contrato para generar la dirección del contrato de cuenta.

! [9WujRrvfd8YccfQkh9kbCtz0O1GVAKvNVJI7kXtm.png] (https://img.jinse.cn/7128684_watermarknone.png “7128684”)

Nosotros public_master_key la account_address, partial_address y colectivamente del usuario como la dirección completa de la cuenta. Cuando se trata de un estado privado, el usuario debe proporcionar estos tres datos para que cualquiera pueda verificar que la clave pública corresponde a la dirección prevista.

Sin embargo, si se trata de una aplicación public_master_key que no tiene la intención de manejar el estado privado y falta (por ejemplo, DeFi), simplemente puede completar ese campo public_master_key 0 para indicar que no desea recibir notas privadas.

Entonces, mientras que Aztec nos permite implementar un mecanismo de verificación e incluso algún mecanismo de recuperación en el contrato de la cuenta para mejorar la seguridad de la cuenta, el mecanismo relacionado con la clave maestra de privacidad está impreso en el protocolo y vinculado a la dirección. Por lo tanto, no es intercambiable.

La implicación aquí es que esta clave es tan importante como la clave privada de una EOA (cuenta de propiedad externa) en Ethereum, lo que la convierte en un único punto de falla (SPoF) para una cuenta. Si un usuario pierde o le roban la clave maestra de privacidad de una cuenta, no hay duda de que la cuenta no será recuperable.

La clave maestra de privacidad también utiliza un proceso similar al BIP-32 para exportar claves de cifrado y claves no válidas. Los usuarios pueden usar diferentes claves de cifrado y claves no válidas en diferentes aplicaciones o acciones para garantizar la privacidad y la seguridad.

Clave de cifrado

La clave pública de la clave de cifrado se utiliza para cifrar la nota privada, mientras que la clave privada se utiliza para descifrarla. Por ejemplo, en un escenario de transferencia de tokens, si yo (el remitente del token) quiero transferir tokens a mi amigo (destinatario del token), necesito cifrar la nota privada (la transferencia de tokens implica cambiar variables, esencialmente el balance es cambiar la variable de estado privada UTXO usando la clave pública criptográfica de mi amigo) y enviarla.

Desde el punto de vista de un extraño, sin conocer la clave privada criptográfica del destinatario del token, no pueden descifrar esta nota privada ni saber quién es el destinatario del token.

Carácter nulo

Cada vez que se utiliza una nota privada, se genera un carácter no válido derivado de ese comentario privado (cifrado con una clave no válida). Este mecanismo se utiliza para evitar el doble gasto (para evitar que otros utilicen el mismo método para determinar la ubicación de un billete o para deducir fondos dos veces) porque el protocolo Aztec comprueba si los caracteres no válidos son únicos. Para hacer coincidir ese carácter no válido con una nota privada, se requiere una clave privada no válida para descifrarla, por lo que solo su propietario puede establecer una relación entre las dos.

Transacciones Aztecas

Describir el concepto de una transacción en Aztec puede ser un desafío porque se puede confundir fácilmente con un UTXO (Private Notes) y el modo de ejecución de una transacción en EVM y Aztec es completamente diferente.

En Aztec, cada transacción se transmite en forma de prueba de conocimiento cero (obviamente por razones de privacidad). Los usuarios deben realizar cálculos localmente en sus nodos (aplicaciones de billetera o clientes) para generar pruebas correspondientes a las transacciones, en lugar de simplemente enviar objetos de transacción al mempool del minero o a cualquier operador de capa 2 a través de la API RPC como solíamos hacer.

Hashes y nonces de transacción

Cuando un usuario crea una transacción localmente, hay dos elementos importantes:

1. Dirección del remitente: Representa la dirección del contrato de cuenta que procesa la transacción. En este contrato de cuenta, existe el punto de entrada que mencionamos anteriormente, que sirve como función de verificación para que las partes externas verifiquen si la acción (transacción) está autorizada por el propietario de la cuenta.
2. Datos de carga útil: Esto incluye información sobre la transacción, como la firma, la dirección del contrato de destino, el valor, los datos, etc.

! [xReWU4p6VrxP45q5EYNXZGAziaZhIG1DTrjeO4yD.png] (https://img.jinse.cn/7128688_watermarknone.png “7128688”)

A nivel de protocolo de Aztec, el hash de cada transacción válida se utiliza como un medio para evitar que la misma transacción se ejecute varias veces. El desarrollador del contrato de cuenta puede decidir si debe haber un nonce en el contrato de cuenta y la lógica asociada. Por ejemplo, pueden establecer requisitos como garantizar que el campo nonce de la transacción se incremente estrictamente o que la transacción se pueda procesar en cualquier orden.

Dado que no existe un requisito estricto de nonce a nivel de protocolo, Aztec no puede cancelar una transacción pendiente enviando una nueva transacción con las mismas tarifas de nonce y gas más altas.

Ejecutar la solicitud

Como se mencionó anteriormente, el usuario puede especificar cualquier función en el contrato de la cuenta como punto de entrada dependiendo de la situación, y la operación en Aztec no está controlada por un simple objeto comercial. De hecho, lo que le dice a la cuenta de contrato qué hacer es un objeto llamado “solicitud de ejecución”. El objeto representa el comportamiento del usuario, como “Llamar a la función de transferencia en el contrato con 0x1234 de los siguientes parámetros”.

El usuario inicia una transacción localmente en la billetera, donde el sender_address es la dirección del contrato de cuenta, que contiene los datos de codificación relevantes de la función en el contrato de destino de llamada de carga útil transfer() y la firma que puede ser verificada por el contrato de cuenta. La billetera convierte estos dos elementos en una solicitud de ejecución.

A continuación, la billetera introduce una nota privada, una clave de cifrado o un secreto no válido en una máquina virtual local para simular esta solicitud de ejecución. Durante el proceso de simulación, se generará un rastro de ejecución, que se entregará al probador para generar una prueba de conocimiento cero. Esta prueba muestra que estos cálculos (la ejecución de funciones privadas) son realizados localmente por el usuario.

A través de este proceso, obtenemos dos piezas de información: proof y private_data (la salida del circuito privado del kernel para esta transacción). Luego, la billetera envía el objeto de transacción que contiene estas dos piezas de información a la mempool del secuenciador de Aztec y completa la transacción.

Entorno de ejecución de tipo ZKP basado en cliente en lugar de EVM

En Aztec, no nos limitamos a introducir toda la información en una máquina de Turing como la EVM para generar el estado actualizado. En su lugar, se basa en los circuitos dentro de cada Dapp para determinar cómo debe funcionar la información de privacidad. Esto significa que los desarrolladores de Dapp deben tener una forma de probar el estado de las variables contractuales. Por ejemplo, consideremos el saldo del usuario en un contrato de token ERC-20. Si queremos transferir 10 tokens DAI, el contrato puede tener la siguiente lógica:

1. Compruebe si el saldo del remitente es superior a 10 DAI (es decir, > 10 DAI).
2. Si el remitente tiene saldo suficiente, se crea un carácter no válido para indicar la destrucción de la nota privada de 10 DAI del remitente (que puede compensar la posesión del remitente de la nota privada de 10 DAI).
3. Crea una nueva nota privada para el destinatario.
4. Transmita y cifre todos los mensajes transmitidos con 10 DAI.

Desde el punto de vista de un extraño, solo pueden ver aparecer nuevas nulidades y comentarios, y todos están encriptados. Por lo tanto, todo el mundo sabe que se ha producido un nuevo acuerdo, pero lo que está sucediendo exactamente en su interior sólo lo saben los participantes implicados.

! [B2NwqMIhntBOllrlchIWeaetEbkSSdoTARJiM27A.png] (https://img.jinse.cn/7128690_watermarknone.png “7128690”)

Más información sobre los contratos de cuentas aztecas

Billetera

Las billeteras en Aztec son una parte importante de la gestión de las interacciones de los usuarios con la cadena de bloques y sus datos privados. Aquí hay un resumen de las tareas que la billetera Aztec tiene que manejar:

1. Crear una cuenta: La billetera debe permitir a los usuarios crear nuevos contratos de cuenta, lo que esencialmente significa implementar nuevos contratos de cuenta en la cadena de bloques.
2. Gestión de claves privadas: El monedero se encarga de gestionar la frase semilla y la clave privada del usuario, incluyendo la clave maestra de privacidad y la clave de firma (dependiendo del diseño del contrato de la cuenta). Esta gestión también se puede extender a la integración de la billetera de hardware.
3. Ver cuentas: Los usuarios deben poder ver sus cuentas y estados relacionados, incluidos los saldos y otros estados privados. Esto significa que la billetera debe mantener una base de datos local de todas las notas privadas relacionadas con el usuario.
4. Interactúa con las Dapps: Las billeteras deben facilitar la interacción entre los usuarios y las Dapps. Cuando un usuario interactúa con una Dapp, la Dapp puede solicitar que se envíe una transacción desde la cuenta del usuario.
5. Consentimiento del usuario: Las Dapps pueden requerir el consentimiento del usuario para mostrar ciertos estados del contrato, como el saldo en el contrato de token. Para exponer estos estados, la billetera debe poder recibir solicitudes de usuario (ya que la exposición de saldos requiere el consentimiento de la clave de usuario).
6. Generar prueba: Para enviar una transacción en nombre de un usuario, la billetera debe poder generar una prueba localmente. Esto implica la creación y el procesamiento de pruebas de conocimiento cero de la validez de las transacciones.

Un punto clave a tener en cuenta es que la billetera debe escanear todos los bloques comenzando con el bloque génesis, usar la clave del usuario para descubrir y descifrar las notas privadas relevantes y luego almacenarlas en una base de datos local para su uso futuro. Esto es fundamental para facilitar la interacción del usuario y garantizar que los datos de estado privados se puedan administrar de manera efectiva.

Mencionaste otro aspecto importante de Aztec, que es la necesidad de que los usuarios transmitan el discurso completo. Cuando una billetera crea una nota criptográfica para el destinatario de una transacción de destino, también debe poder obtener la dirección completa del destinatario. Esto se puede lograr ingresando manualmente o manteniendo una base de datos local de la dirección del destinatario. Para obtener más detalles sobre esto, consulte la documentación oficial de Azteca.

Contrato de cuenta

En Aztec, las principales tareas de un contrato de cuenta son verificar las firmas (confirmar que las transacciones están autorizadas por el propietario de la cuenta y, por lo tanto, autorizadas de manera más amplia, en lugar de necesariamente “verificadas por un algoritmo de firma digital específico”), administrar el consumo de gas e invocar otros contratos.

Este es un ejemplo oficial de un contrato de cuenta azteca que utiliza el algoritmo de firma Schnorr. El punto de entrada para todas las transacciones es la función entrypoint() (puede elegir la función o el nombre como punto de partida, pero en este caso se usa entrypoint()).

! [LahY9kfNGKkYkSm5ULPlReKATiTA3K5bjFGIClh0.png] (https://img.jinse.cn/7128692_watermarknone.png “7128692”)

Cuando llamamos a la cuenta entrypoint() con la carga útil adjunta, el contrato de la cuenta entrypoint() llamará a la biblioteca de cuentas azteca AA entrypoint().

! [OskBKScb0LqWpcTMIuhBMjeSB151sFvSWbwXl.png] (https://img.jinse.cn/7128697_watermarknone.png “7128697”)

Aztec no requiere que nuestros contratos de cuenta se importen a las bibliotecas de cuentas EntrypointPayload y Aztec AA; Usted es libre de diseñar su propia lógica de contrato de cuenta.

! [HNskT1CkOOPiZZaAVvqlJNf7L5VxU39Fz9ir2Ica.png] (https://img.jinse.cn/7128698_watermarknone.png “7128698”)

es el contexto, un objeto que está disponible en todas las funciones de Aztec.nr. Contiene toda la información del kernel necesaria para la ejecución de la aplicación de contexto. Citado de la documentación oficial azteca. - ¿Cuál es el fondo?

Lo anterior es el código entrypoint() de la biblioteca de cuentas Aztec AA. Es responsable de determinar si la operación está autorizada por el propietario de la cuenta en función de la función de validación () definida en el contrato de _valid cuenta es _impl, y realiza las llamadas necesarias para implementar la operación _calls requerida para la transacción.

Esto significa que si desea hacer referencia a esta biblioteca Aztec AA y el contrato de su cuenta no tiene una implementación de is_valid_impl con la misma firma de función, este paso fallará.

! [QZuhkG4BTiKMQF4hFZKGw0gi9MBlU5VGcDjyQyU9.png] (https://img.jinse.cn/7128699_watermarknone.png “7128699”)

Otro detalle clave de la implementación es usar get_auth_witness() para recuperar firmas. Puede consultar las referencias a continuación para obtener más información sobre cómo trabajan los Testigos. En términos simples, un testigo es “una autorización para que el usuario haga lo que quiera hacer”.

Un testigo de autenticación es un esquema para verificar operaciones en Aztec, de modo que los usuarios puedan permitir que terceros, como protocolos u otros usuarios, realicen acciones en su nombre. Citado de la documentación oficial azteca. — Testigos certificados

La razón por la que se llama “testigo” en lugar de simplemente “firma” es porque la forma en que se verifica el contrato de la cuenta no implica necesariamente verificar la firma.

Por ejemplo, supongamos que hay una operación que transfiere 1000 tokens de la cuenta de Alice a una plataforma DeFi. En este caso, el contrato de token debe consultar el contrato de la cuenta de Alice para ver si aprueba la “acción”. Esta “acción” requiere que se genere un testigo de autenticación en la billetera de Alice (localmente), que luego se puede verificar a través del contrato de su cuenta. Si el contrato de la cuenta se verifica con éxito, el contrato del token sabrá que la “acción” ha sido autorizada.

! [WJkuu8NWicgcHvCyH08YpHhjYtTtYiP8GbRxwwKs.png] (https://img.jinse.cn/7128700_watermarknone.png “7128700”)

Conclusión

A partir de ahora, Aztec no ha implementado un mecanismo de tarifas, y su objetivo también es abstraer el pago de tarifas. Esto significa que para que una transacción se considere válida, debe demostrar que ha bloqueado fondos suficientes para cubrir sus propias tarifas. Sin embargo, no especifica de dónde deben provenir estos fondos, lo que hace que los pagos o pagos en especie sean fácilmente posibles a través del intercambio instantáneo.