- Tema
4k Popularidad
93k Popularidad
15k Popularidad
5k Popularidad
30k Popularidad
16k Popularidad
23k Popularidad
14k Popularidad
3k Popularidad
13k Popularidad
- Anclado
4k Popularidad
93k Popularidad
15k Popularidad
5k Popularidad
30k Popularidad
16k Popularidad
23k Popularidad
14k Popularidad
3k Popularidad
13k Popularidad
V God Blog: Comprensión de billeteras y otros casos de aplicaciones Capa 2 Lectura de capas cruzadas
Autor: Vitalik Buterin; Compilador: Bulu dijo
En el artículo Las tres transiciones, Vitalik Buterin, el fundador de Ethereum, explicó claramente la "red principal (en adelante, L1) + cadena cruzada de capa 2 (en adelante, L2 cruzada) soporte"" "Seguridad de la billetera" y "privacidad" son valores importantes como las funciones necesarias de la pila del ecosistema. No deberían ser solo algunos componentes adicionales, y una billetera separada proporciona funciones relacionadas.
Y este artículo, señaló Vitalik Buterin, se centrará en un problema técnico clave: cómo leer más fácilmente los datos de L1 desde L2, o leer los datos de L2 desde L1, o cómo leer más fácilmente los datos de L2 desde un L2 Leer datos desde otro L2 . **
Vitalik Buterin señaló que la clave para resolver los problemas anteriores radica en cómo realizar la separación de activos y almacenes de claves. Esta tecnología también tiene casos de uso muy valiosos en áreas distintas al escalado, como la movilidad de activos entre L1 y L2.
** ¿Cuál es el objetivo de hacer esto? **
Una vez que L2 se generalice, los usuarios podrán poseer activos en múltiples L2 y posiblemente también en L1.
Una vez que las billeteras de contratos inteligentes se conviertan en la corriente principal, las "claves" ahora comunes ya no se utilizarán.
Una vez que estas dos cosas sucedan al mismo tiempo, los usuarios necesitarán un método que no requiera una gran cantidad de transacciones para cambiar las claves de diferentes cuentas.
En particular, necesitamos una forma de lidiar con las direcciones que son "contrafactuales" (también conocidas como "direcciones hipotéticas"): direcciones que aún no están "registradas" en la cadena de ninguna manera, pero que aún necesitan recibir y mantener activos de manera segura. .
De hecho, todos confiamos en esta "configuración contrafactual" de las direcciones: cuando un usuario usa Ethereum por primera vez, el usuario puede generar una dirección ETH y otros pueden pagar a esta cuenta sin tener que registrarse en la cadena de bloques. la dirección (pero deberá pagar tarifas de transacción, por lo que debe tener algo de ETH).
Para las cuentas externas (EOA), de hecho, todas las direcciones parten de la dirección del "ajuste contrafactual".
Las direcciones "establecidas de manera contrafactual" aún son posibles con las billeteras de contrato inteligente, gracias en gran parte a CREATE2, que le permite tener una dirección ETH que solo puede crearse mediante un código de contrato inteligente que coincida con un relleno de hash específico.
△ Algoritmo de cálculo de direcciones EIP-1014 (CREATE2).
Sin embargo, la introducción de billeteras de contrato inteligente también trae nuevos desafíos: **Las claves de acceso pueden cambiar. **Este cambio es que la dirección es el valor hash del código de inicio, que solo puede contener la clave de verificación inicial de la billetera, y la clave de verificación actual se almacenará en el almacenamiento de la billetera, pero el registro de almacenamiento no será transferido automáticamente a otra L2.
Si un usuario tiene direcciones en muchos L2, solo Separación de activos y arquitectura de almacenamiento de claves puede ayudar a los usuarios a cambiar sus claves.
La estructura de esta arquitectura dividida es que cada usuario tiene (i) un "contrato de almacenamiento de claves" (ya sea en L1 o en una cadena L2 específica) que almacena claves de verificación para todas las billeteras y reglas para cambiar claves, y (ii) "contratos de billetera " en L1 y muchas cadenas L2, que obtienen claves de verificación a través de lecturas entre cadenas.
Hay dos formas de implementar la arquitectura de separación de almacenamiento de activos y claves:
Versión liviana (es decir, solo busca claves actualizadas): cada billetera almacena la clave de verificación localmente y contiene una función activable para verificar la prueba de cadena cruzada del estado actual del almacén de claves y actualizar el almacenamiento local La autenticación clave para emparejar. Se requiere llamar a esta función para obtener la clave de autenticación actual del almacén de claves cuando se usa la billetera por primera vez en un L2.
Versión completa (es decir, se verifica cada transacción): cada transacción requiere una prueba de cadena cruzada que muestre la clave actual en el almacén de claves.
**¿Qué es la prueba de cadena cruzada? **
Para demostrar la complejidad de las pruebas de cadena cruzada, seleccionamos uno de los escenarios de aplicación más complejos para demostrar y explicar este principio técnico. Este escenario de aplicación complejo es el siguiente: la clave se almacena en un L2 y la billetera está en otra L2. Si el almacén de claves de la billetera está en L1, solo se necesita la mitad de este diseño.
Suponga que el almacén de claves está en Linea y la billetera está en Kakarot. El proceso completo de certificación de la clave de la billetera debe incluir:
Hay dos preguntas de implementación espinosas principales aquí: "¿Qué tipo de prueba se necesita usar? (¿Es una prueba de Merkle? ¿O algo más?)" y "¿Cómo aprende L2 la raíz de estado L1 más cercana?" O, "L1 ¿Cómo aprender la raíz del estado de L2?"
Entonces, en ambos casos, ¿cuánto tiempo transcurre entre el momento en que ocurre un evento de una parte y el momento en que la otra parte puede proporcionar pruebas?
**¿Qué esquemas de prueba están disponibles para nosotros? **
Hay cinco métodos principales para elegir:
En términos de trabajo de infraestructura requerido y costos de usuario, se pueden clasificar aproximadamente de la siguiente manera:
"Agregación" se refiere a agregar todas las pruebas proporcionadas por los usuarios en cada bloque en una gran meta-prueba, fusionándolas. Esto funciona para SNARK y KZG, pero no para las horquillas Merkle.
De hecho, la "agregación" solo es valiosa cuando la solución tiene una gran cantidad de usuarios.
**¿Cómo funcionan las pruebas de Merkle? **
Este problema es muy simple y puede ser seguido directamente por el diagrama de la sección anterior. Cada "prueba" (suponiendo que se demuestre que una L2 es otra L2, que es el escenario de aplicación más difícil) incluirá:
Una bifurcación de Merkle que atestigua contiene la raíz de estado del almacén de claves L2, la última raíz de estado de Ethereum conocida por L2. Las raíces de estado que contienen el almacén de claves L2 se almacenan en ranuras de almacenamiento conocidas en direcciones conocidas (contratos L1 que representan L2), por lo que las rutas se pueden codificar de forma rígida.
Una sucursal de Merkle que acredite la clave de verificación actual, de acuerdo con la raíz del estado que contiene el almacén de claves L2. Además, las claves de autenticación se almacenan en ranuras conocidas en direcciones conocidas, por lo que las rutas se pueden codificar.
Sin embargo, las pruebas de estado en Ethereum son complicadas, pero hay bibliotecas que se pueden usar para verificarlas, y si se usan estas bibliotecas, el mecanismo no es demasiado complicado.
Sin embargo, el mayor desafío es el costo. ** Merkle resultó ser muy largo y el árbol de Patricia fue 3,9 veces más largo de lo necesario, mucho más alto que el precio base actual de 21 000 Gas Fee por transacción.
Sin embargo, si la prueba se verifica en L2, la discrepancia empeora. La computación dentro de L2 es barata porque la computación se realiza fuera de la cadena y en un ecosistema con menos nodos que L1.
Podemos calcular lo que esto significa observando la comparación entre el costo de la tarifa de gas L1 y el costo de la tarifa de gas L2:
En la actualidad, si se trata de una operación de envío relativamente simple, el costo en la red L1 es aproximadamente 15 a 25 veces mayor que el de L2, y el costo del intercambio de tokens es aproximadamente 20 a 50 veces mayor que el de L2.
La operación de envío simple tiene una gran cantidad de datos y la operación de intercambio requiere una mayor potencia informática, por lo que la operación de intercambio es un mejor punto de referencia para aproximar el costo del cálculo L1 y el cálculo L2.
Juntando lo anterior, si asumimos una relación de costos de 30x entre el costo computacional L1 y el costo computacional L2, esto parece implicar que el costo de poner las pruebas de Merkle en L2 podría ser equivalente a unas cincuenta transacciones regulares.
Por supuesto, usar un árbol Merkle binario reduciría el costo por un factor de aproximadamente 4, pero incluso entonces el costo seguiría siendo prohibitivo en la mayoría de los casos, y si estuviéramos dispuestos a renunciar a la compatibilidad con el árbol de estado hexa actual de Ethereum, podría Buscará mejores opciones.
**¿Cómo funciona la prueba ZK-SNARK? **
El uso de ZK-SNARK también es conceptualmente fácil de entender: simplemente reemplaza las pruebas de Merkle en el diagrama anterior con ZK-SNARK que prueban la existencia de esas pruebas de Merkle. El monto de cálculo de un ZK-SNARK es de aproximadamente 400 000 Gas Fee, aproximadamente 400 bytes; una transacción básica requiere 21 000 Gas Fee y 100 bytes.
Por lo tanto, desde el punto de vista del cálculo, el costo de ZK-SNARK es 19 veces el costo de transacción básico actual; desde el punto de vista de los datos, el costo de ZK-SNARK es 4 veces el costo de transacción básico actual y 16 veces el futuro costo básico de transacción.
Estos números representan una gran mejora con respecto a las pruebas de Merkle, pero siguen siendo bastante caros. Hay dos formas de mejorar esta situación: (i) pruebas KZG de propósito especial, o (ii) agregación, similar a la agregación ERC-4337.
**¿Cómo funciona la prueba KZG de propósito especial? **
Primero, un resumen de cómo funcionan las promesas de KZG:
*[D_1 ...D_n] representa un conjunto de datos a través del cual se deriva la prueba polinomial KZG. *
*Específicamente, el polinomio P, donde P(w) = D_1, P(w²) = D_2 ... P(wⁿ) = D_n, donde es la "raíz uniforme", para algún campo de evaluación tamaño N, valor wN = 1 (todo esto se hace en campos finitos). *
G es el punto generador de la curva
Pi es el i-ésimo coeficiente del polinomio P
Si es el i-ésimo punto en la configuración de confianza
*Y para probar que P(z) = a, creamos un polinomio cociente Q = (P - a) / (X - z), y creamos un compromiso com(Q). Solo es posible crear tal polinomio si P(z) es realmente igual a a. *
Algunas propiedades clave que también debe conocer incluyen:
La prueba es solo el valor com(Q), que es de 48 bytes
com（P₁） + com（P₂） = com（P₁ + P₂）
*Esto también significa que puede "editar" el valor en un contrato existente. *
Supongamos que sabemos que D_i es actualmente a, queremos establecerlo en b, y el compromiso existente con D es com(P). prometemos "P, pero P(wⁱ) = b, y no hay otros cambios de evaluación", luego establecemos com(nuevo_P) = com(P) + (ba)*com(Li), donde Li es "lag langeriano polinomio", igual a 1 en wⁱ y 0 en otros puntos wj. *
Para realizar estas actualizaciones de manera eficiente, cada cliente puede precalcular y almacenar todos los N compromisos con el polinomio de Lagrangian (com(Li)). En un contrato en cadena, podría ser demasiado almacenar todos los N compromisos, por lo que puede hacer compromisos KZG con el conjunto de valores com(L_i), de modo que cada vez que alguien necesite actualizar el árbol en cadena, puede simplemente enviar a Proper com(L_i) proporciona prueba de su corrección. *
Por lo tanto, tenga una estructura que siga agregando valores al final de la lista creciente, pero con un límite de tamaño determinado. Luego, use esta estructura como estructura de datos para (i) compromisos con la lista de claves en cada L2, almacenados en ese L2 y reflejados en L1, y (ii) compromisos con la lista de compromisos con claves L2, almacenada en Ethereum en L1 y reflejado en cada L2.
Mantener los compromisos actualizados puede ser parte de la lógica central L2 o implementarse a través de un puente de depósito y retiro sin cambiar el protocolo central L2.
Una prueba completa requiere lo siguiente:
De hecho, las dos pruebas KZG anteriores se pueden combinar en una con un tamaño total de solo 100 bytes.
Tenga en cuenta un detalle: dado que una lista de claves es una lista, no un mapa clave/valor como lo es el estado, la lista de claves debe tener posiciones asignadas en orden. El contrato de promesa de clave contendrá su propio registro interno, asignando cada almacén de claves a una ID, y para cada clave, almacenará el hash (clave, la dirección del almacén de claves) en lugar de solo la clave, para informar explícitamente a otros L2 sobre qué almacén de claves al que se refiere una entrada en particular.
La ventaja de esta técnica es que funciona muy bien en L2. Aproximadamente 4 veces más corto que ZK-SNARK, mucho más corto que la prueba de Merkle. El coste de cálculo es de unos 119.000 Gas Fee.
En L1, la potencia informática es más importante que los datos, por lo que KZG es un poco más caro que la prueba de Merkle.
**¿Cómo funcionan los árboles de Verkle? **
Los árboles Verkle implican esencialmente apilar compromisos KZG: para almacenar valores 2⁴⁸, se puede hacer un compromiso KZG con una lista de valores 2²⁴, cada uno de los cuales es en sí mismo un compromiso KZG con valores 2²⁴.
Los árboles de Verkle se consideran para los árboles de estado de Ethereum porque los árboles de Verkle se pueden usar para contener mapas de clave-valor.
Las pruebas en los árboles de Verkle son más largas que las pruebas KZG, pueden tener cientos de bytes de longitud.
De hecho, los árboles Verkle deben considerarse como árboles Merkle, pero son más factibles sin SNARKing, pero se ha demostrado que SNARKing tiene un costo de prueba más bajo.
La gran ventaja de los árboles de Verkle es que pueden coordinar estructuras de datos: por lo que se pueden usar directamente para L1 o L2, no hay una estructura de superposición y se usa exactamente el mismo mecanismo para L1 y L2.
Una vez que las computadoras cuánticas se convierten en un problema, o una vez que las ramas de Merkle demuestran ser lo suficientemente eficientes, los árboles de Verkle tienen más usos.
polimerización
Si N usuarios realizan N transacciones y necesitan probar N reclamos de cadena cruzada, podemos ahorrar una gran cantidad de tarifas de gas agregando estas pruebas, lo que puede significar:
En los tres casos, cada prueba solo cuesta unos cientos de miles de tarifas de gas.
Los desarrolladores necesitan hacer una prueba de este tipo en cada L2 para los usuarios de esa L2; por lo tanto, para que esta prueba sea útil, todo el esquema debe tener suficiente uso para que haya al menos algunas transacciones.
Si se utilizan ZK-SNARK, es posible que cada usuario deba gastar miles de tarifas de gas L2. Si se utiliza la prueba múltiple KZG, el verificador debe agregar 48 tarifas de gas al L2 de cada almacén de claves utilizado en el bloque.
Aún así, estos costos son mucho más bajos que sin la agregación, lo que inevitablemente implica más de 10 000 tarifas de gas L1 y cientos de miles de tarifas de gas L2 por usuario.
Para el árbol Verkle, los usuarios pueden usar directamente Verkle multiprueba, cada usuario agrega alrededor de 100~200 bytes, o puede hacer un Verkle multiprueba ZK-SNARK, su costo es similar al ZK-SNARK de la rama Merkle, pero la prueba parece obviamente barata.
Desde el punto de vista de la implementación, podría ser mejor dejar que los empaquetadores agreguen pruebas entre cadenas a través del estándar de abstracción de cuentas ERC-4337. ERC-4337 ya tiene un mecanismo para que los constructores agreguen partes de las operaciones del usuario de forma personalizada. Incluso hay una implementación para la agregación de firmas BLS, que puede reducir la tarifa de gas L2 de 1,5x a 3x.
Leer estado directamente
Una última posibilidad, y que solo se aplica a L2 leyendo L1 (en lugar de L1 leyendo L2), es modificar L2 para que directamente hagan llamadas estáticas a los contratos de L1.
Esto se puede hacer con un código de operación o precompilación que permite llamadas a L1 donde proporciona la dirección de destino, el gas y los datos de llamada y devuelve la salida, aunque dado que estas llamadas son estáticas, en realidad no pueden cambiar ningún estado de L1. L2 tiene que saber qué sucede con L1 para poder procesar los depósitos, por lo que no hay nada fundamental que impida que esto sea posible; es principalmente un desafío de implementación técnica.
Tenga en cuenta que si el almacén de claves está en L1 y L2 incorpora la funcionalidad de llamada estática de L1, entonces no se requiere ninguna atestación.
Sin embargo, si L2 no incorpora llamadas estáticas L1, o si el almacén de claves está en L2, entonces se requiere prueba.
**¿Cómo aprende L2 la raíz del estado de Ethereum más reciente? **
Todos los esquemas anteriores requieren L2 para acceder a la raíz del estado L1 más cercano o al estado L1 completo más cercano.
De hecho, si L2 tiene una función de depósito, entonces puede usar ese L2 tal como está para mover la raíz del estado L1 a un contrato en L2: simplemente haga que el contrato en L1 llame al código de operación BLOCKHASH y deposítelo como un activo El mensaje se pasa a L2. El encabezado de bloque completo se puede recibir en el lado L2 y se puede extraer su raíz de estado.
Sin embargo, cada L2 tiene preferiblemente una forma explícita de acceder directamente al último estado completo de L1 oa la raíz de estado de L1 más cercana.
El principal desafío para optimizar la forma en que L2 recibe la raíz de estado L1 más reciente es lograr seguridad y baja latencia al mismo tiempo:
Además, en la dirección opuesta (L1 lee L2):
Algunos de ellos son inaceptablemente lentos para operaciones de cadena cruzada sin confianza para muchos casos de uso de DeFi. Sin embargo, para el caso de uso de actualización de claves de billetera, los retrasos más largos son más aceptables, porque en lugar de retrasar las transacciones, retrasa los cambios de clave.
Los usuarios solo necesitan conservar la clave anterior durante un período de tiempo más largo. Si el usuario cambia la clave porque la clave fue robada, entonces existe un largo período de vulnerabilidad, pero se puede mitigar, p. A través de una billetera con funcionalidad de congelación.
En última instancia, la mejor solución para minimizar la latencia es hacer que L2 implemente de manera óptima lecturas directas de la raíz de estado L1, donde cada bloque L2 (o registro de cálculo de raíz de estado) contiene un puntero al bloque L1 más reciente, por lo que si L1 se recupera y L2 puede recuperarse también. El contrato de almacén de claves debe colocarse en la red principal o en L2 de ZK-rollup para que pueda confirmarse rápidamente en L1.
**¿Cuánta conexión a Ethereum necesita la otra cadena para mantener el almacén de claves almacenado en la billetera Ethereum o L2? **
Sorprendentemente, no tantos. De hecho, ni siquiera necesita ser un Rollup.
Si es un L3 o un validium, está bien almacenar billeteras allí, siempre que los usuarios almacenen el almacenamiento de claves en L1 o ZK-rollup, realmente necesitan tener acceso directo a la raíz del estado de Ethereum y están dispuestos a almacenar sus billeteras en Ethereum Al refactorizar, hard fork cuando Ethereum se bifurca.
Los esquemas basados en puentes ZK tienen propiedades técnicas atractivas, pero tienen una debilidad clave en el sentido de que no son resistentes contra ataques del 51 % o bifurcaciones duras.
protección de privacidad
Idealmente, los usuarios también quieren privacidad. Si un usuario tiene muchas billeteras administradas por el mismo almacén de claves, querrá asegurarse de que:
Pero esto crea un problema:
Para los SNARK, la solución es conceptualmente simple: las pruebas ocultan información de manera predeterminada y los agregadores deben producir SNARK recursivos para probar los SNARK.
El principal desafío actual con este enfoque es que la agregación requiere que el agregador cree un SNARK recursivo, que es bastante lento.
Para KZG, podemos usar la no indexación para revelar el trabajo de la prueba KZG. Sin embargo, la agregación ciega es un problema abierto que requiere más atención.
Sin embargo, aunque leer L1 directamente desde L2 no protege la privacidad, la implementación de esta capacidad de lectura directa sería muy útil, no solo para minimizar la latencia, sino para muchos más casos de uso.