¿Ethereum Wallet podría recibir una actualización importante pronto? Leer EIP-3074

Es posible que la billetera Ethereum pronto obtenga una actualización importante. Una vez que se completa la actualización, las cuentas ordinarias (EOA) pueden enviar transacciones por lotes, transacciones de fecha límite, transacciones fuera de servicio, etc.

Dos de mis colegas @_SamWilsn_ y @adietrichs y yo estamos investigando cómo mejorar la experiencia de interacción con Ethereum. Después de muchas iteraciones, se nos ocurrió EIP 3074: Opcodes AUTH y AUTHCALL.

Para usar estos dos códigos de operación, la cuenta externa debe firmar un mensaje fuera de la cadena y enviar el mensaje al repetidor, quien luego envía la firma y los datos de la llamada a un contrato en la cadena (llamado "llamada por"). El contrato de la persona que llama primero usará el código de operación AUTH para verificar la firma y luego usará el código de operación AUTHCALL para retransmitir la llamada desde la cuenta externa.

AUTHCALL se diferencia de una llamada normal en una sola forma: AUTHCALL establece la persona que llama (por ejemplo, el remitente del mensaje) en una dirección externa restaurada con el código de operación AUTH. De esta forma, los usuarios pueden interactuar con Ethereum sin utilizar Ethereum. En otras palabras, sus transacciones son "patrocinadas" por repetidores.

Puede sentir que este mecanismo le resulta familiar. De hecho, así es como funcionan las metatransacciones. Pero aquí quiero enfatizar que el remitente del mensaje no puede establecerse arbitrariamente en la metatransacción. Por lo tanto, los contratos deben respaldar explícitamente las metatransacciones. EIP 3074 tiene como objetivo eliminar las metatransacciones y reducir la complejidad del contrato.

Antes de profundizar en cómo funciona, primero presentemos lo que queremos construir. Queremos construir un mecanismo que permita a los usuarios comunes enviar transacciones sin confianza y sin usar ether. La palabra clave aquí es "sin confianza", es decir, el usuario no otorga ningún privilegio al repetidor que pueda ser explotado.

EIP 3074 crea un sistema sin confianza al elegir cuidadosamente los parámetros incluidos en las firmas de cuentas comunes. El usuario firma keccak (0x03++invoker_address++commit_hash).

"byte de tipo" es un byte constante de EIP 2718 con un valor de 0x03. El propósito de este byte es evitar conflictos con otros mecanismos de firma, por ejemplo, transacciones de lista de acceso de EIP 2930, transacciones de mercado de tarifas de EIP 1559, mensajes firmados 0x19 de EIP 191, etc.

La dirección de la persona que llama vincula la llamada del usuario a un contrato específico. La firma del usuario sólo es válida para el contrato del llamante. Por lo tanto, los usuarios pueden elegir la persona que llama en la que confían, al igual que elegir una billetera de contrato inteligente para almacenar activos.

Esperamos que solo exista una pequeña cantidad de personas que llaman, ya que los usuarios corren el riesgo de perder dinero si la implementación del contrato de la persona que llama sale mal (tenga en cuenta que las personas que llaman están habilitadas). Desarrollar un contrato de llamada seguro puede ser costoso y requiere múltiples auditorías y pruebas estáticas.

Pero eso no es muy diferente de la práctica actual. Las billeteras de contrato inteligente también deben auditarse y certificarse por completo antes de depositar grandes cantidades de fondos. Lo mismo ocurre con muchos proyectos grandes de DeFi.

El último parámetro de firma es commit_hash (o commit). Esto brinda más flexibilidad al diseñador de llamadas, lo que le permite desarrollar muchas soluciones diferentes.

Este compromiso restringe a las personas que llaman a acciones específicas y crea requisitos de validación específicos (requisitos de validez) para manejar las llamadas. Los usuarios pueden confiar en que las personas que llaman seguirán este proceso, ya que pueden verificar el código en la cadena. Esta es la belleza de la cadena de bloques.

Veamos un caso sencillo. El usuario quiere enviar una llamada a través de la persona que llama. Para evitar que sus llamadas se retransmitan infinitamente, deben proporcionar un nonce, entre otros valores inmutables. El usuario procesa estos valores para obtener una confirmación e incluye esa confirmación en el mensaje firmado para que el contrato verifique usando el código de operación AUTH.

La persona que llama utilizará el valor pasado para regenerar el hash de confirmación. De esta manera, si el patrocinador cambia uno de los valores, el hash de confirmación calculado por la persona que llama será completamente diferente al firmado por la cuenta externa, lo que hace que AUTH restaure una dirección basura, como se muestra en la siguiente figura:

Con suerte, ya está convencido de que la persona que llama es como una billetera de contrato inteligente que cualquier cuenta normal puede usar. Ahora veamos cómo usar commit para crear soluciones más interesantes.

En general, "una operación corresponde a una firma" se ha convertido en una regla general. Este es un entendimiento relativamente simple. La firma se crea en función del valor hash de una transacción, ¿por qué no combinamos varias transacciones para el cálculo hash? Resulta que EIP 3074 puede hacer precisamente eso.

Siempre que una cuenta pueda pasar la autenticación de AUTH, la persona que llama puede realizar cualquier número de AUTHCALL de acuerdo con los requisitos de la cuenta. Esto está bien porque confiamos en que la persona que llama ejecutará el código fielmente. Podemos diseñar un esquema que fusione y convierta múltiples llamadas en una confirmación.

En el esquema que se muestra en la figura anterior, la persona que llama combinará todos los valores (nonce1, nonce2, etc.) y los codificará para generar una confirmación. La persona que llama utilizará este compromiso y la firma del usuario para llamar a AUTH. AUTH verifica que el usuario realmente firmó estos parámetros.

Luego, la persona que llama itera a través de cada llamada y verifica el nonce y otros parámetros antes de enviar los datos de llamada autenticados (datos de llamada) a la dirección permitida.

Sobre esta base, podemos construir más soluciones. Por ejemplo, suponga que agrega un nuevo parámetro "vida útil". Este parámetro se codificará junto con otros parámetros para obtener la confirmación. Además, durante el proceso de verificación, la persona que llama verificará ese vencimiento < block.number. ¡Ahora, las transacciones por tiempo limitado están disponibles para cuentas externas!

EIP 3074 conducirá a una experiencia de usuario más fluida sin introducir suposiciones de confianza adicionales. Si desea leer el contenido completo de EIP 3074, haga clic en este enlace: https://eips.ethereum.org/EIPS/eip-3074

La implementación prototipo de go-ethereum se mantiene aquí:

https://github.com/quilt/go-ethereum/tree/eip-3074

Estamos trabajando con algunos equipos que están interesados ​​en la mecánica. Si encuentra útil este mecanismo, háganoslo saber, ¡trabajemos juntos! Se agradecen los comentarios sobre esta propuesta, ¡muchas gracias! Haga clic en este enlace para dejar sus comentarios: https://ethereum-magicians.org/t/eip-3074-auth-and-authcall-opcodes/4880/49.

Finalmente, si está interesado en nuestro trabajo, nuestro equipo está contratando. Estamos comprometidos a realizar mejoras a mediano y largo plazo en el protocolo central de Ethereum. Para obtener más información, envíeme un mensaje privado directamente a @lightclients.

(Fin)

Enlace del texto original: https://twitter.com/lightclients/status/1371911245561917441 Autor: lightclients Traducción y revisión: Min Min & A Jian

También te puede interesar:

Abstracción de cuenta (EIP-2938): por qué y cómo

Metatransacción de Ethereum

Límite de cuentas, transacciones, gas y gas de bloque en Ethereum

Tags：

DYDX