Autor: Vitalik Buterin Compilación: Vernacular Blockchain

En mi artículo anterior sobre los tres turnos, describí algunas de las razones clave por las que es valioso comenzar a pensar explícitamente en el soporte L1 + cross-L2, la seguridad de la billetera y la privacidad como características fundamentales necesarias de la pila del ecosistema. Las cosas se construyen como complementos. que puede ser diseñado individualmente por una sola billetera.

Esta publicación se centrará más directamente en los aspectos técnicos de un subproblema en particular, como: cómo leer más fácilmente L1 de L2, L2 de L1 o L2 de otro L2. Abordar este problema es fundamental para habilitar las arquitecturas de separación de activos/almacén de claves, pero también tiene casos de uso valiosos en otras áreas, sobre todo optimizando cadenas de llamadas confiables entre L2, incluidos casos de uso como mover activos entre L1 y L2. Este catálogo de artículos ¿Cuál es el objetivo? ¿Cómo es la prueba de cadena cruzada? ¿Qué tipo de esquema de prueba podemos usar? Prueba de Merkle ZK SNARK Certificado KZG dedicado Prueba de árbol Verkle polimerización lectura directa de estado ¿Cómo aprende L2 la raíz de estado de Ethereum más reciente? Carteras en cadenas que no sean L2s protección de la privacidad Resumir

1. ¿Cuál es el objetivo?

Una vez que L2 se convierta en la corriente principal, los usuarios tendrán activos en múltiples L2 y posiblemente también en L1. Una vez que las billeteras de contrato inteligente (multigrado, recuperación social u otras) se vuelvan comunes, las claves necesarias para acceder a ciertas cuentas cambiarán con el tiempo y las claves más antiguas ya no necesitarán ser válidas. Una vez que sucedan esas dos cosas, los usuarios necesitarán una forma de cambiar las claves que tienen acceso a muchas cuentas ubicadas en muchos lugares diferentes sin realizar una gran cantidad de transacciones. En particular, necesitamos una forma de lidiar con direcciones contrafactuales: direcciones que no han sido "registradas" en la cadena de ninguna manera, pero que aún necesitan recibir y mantener fondos de forma segura. Todos confiamos en direcciones contrafácticas: cuando usa Ethereum por primera vez, puede generar una dirección ETH que alguien puede usar para pagarle sin "registrar" la dirección en la cadena (esto requiere pagar una tarifa de tx, así que ya tenga algo de ETH). Para EOA, todas las direcciones comienzan con una dirección hipotética. Con las billeteras de contratos inteligentes, las direcciones contrafactuales aún son posibles gracias en gran parte a CREATE2, que le permite tener una dirección ETH que solo puede completarse mediante un contrato inteligente con un código que coincida con un hash específico.

EIP-1014 (CREATE2) Algoritmo de cálculo de direcciones

Sin embargo, las billeteras de contrato inteligente presentan un nuevo desafío: la posibilidad de cambios en la clave de acceso. Esta dirección es un hash del código de inicio y solo puede contener la clave de verificación inicial de la billetera. La clave de verificación actual se almacenará en el almacenamiento de la billetera, pero ese registro de almacenamiento no se propagará mágicamente a otras L2. Si un usuario tiene muchas direcciones en muchas L2, incluidas direcciones desconocidas para la L2 en la que se encuentran (porque son contrafactuales), entonces parece haber una sola forma de permitir que los usuarios cambien sus claves: una arquitectura de separación de activos/almacén de claves. Cada usuario tiene (i) un "contrato de almacén de claves" (ya sea en L1 o en un L2 específico) que almacena claves de verificación para todas las billeteras y reglas para cambiar claves, y (ii) "contratos de billetera" que leen cadenas para claves de verificación.

Hay dos maneras de lograr esto:

Versión ligera (solo verifica las claves actualizadas): cada billetera almacena la clave de verificación localmente y contiene una función que se puede llamar para verificar la prueba de cadena cruzada del estado actual del almacén de claves y actualizar su clave de clave de verificación almacenada localmente para que coincida. Cuando la billetera se usa por primera vez en un L2 en particular, se debe llamar a esta función para obtener la clave de autenticación actual del almacén de claves. -Ventajas: las pruebas de cadenas cruzadas se usan con moderación, por lo que no importa si las pruebas de cadenas cruzadas son caras. Todos los fondos solo se pueden usar con la clave actual, por lo que permanece seguro.

• Desventaja: para cambiar la clave de verificación, debe realizar un cambio de clave en cadena en el almacén de claves y en cada billetera inicializada (aunque no en una billetera contrafáctica). Esto puede costar mucha gasolina. Versión pesada (verifique cada tx): cada transacción requiere una prueba de cadena cruzada que muestre la clave actual en el almacén de claves.
• Pros: menor complejidad del sistema, actualizaciones económicas del almacén de claves.
• Contras: el tx único es costoso, por lo que se requiere más ingeniería para hacer que las pruebas de cadena cruzada sean mucho más económicas. Tampoco es fácilmente compatible con ERC-4337, que actualmente no admite la lectura de objetos mutables en contratos durante la verificación.

2. ¿Cómo es la prueba de cadena cruzada?

Para demostrar toda la complejidad, exploraremos el caso más difícil: almacén de claves en una L2, billetera en una L2 diferente. Solo se necesita la mitad de este diseño si el almacén de claves de la billetera está en L1.

Suponga que el almacén de claves está en Linea y la billetera está en Kakarot. Una prueba completa de la clave de la billetera incluye:

• Prueba de la raíz del estado actual de Linea, dada la raíz del estado actual de Ethereum conocida por Kakarotto
• Prueba de la clave actual en el almacén de claves, dada la raíz del estado actual de Linea Hay dos problemas principales de implementación complicados aquí:
• ¿Qué tipo de evidencia utilizamos? (¿Es una prueba de Merkel? ¿Algo más?
• ¿Cómo aprende L2 primero la raíz de estado L1 (Ethereum) más cercana (o, como veremos, posiblemente el estado L1 completo)? O, ¿cómo aprende L1 las raíces estatales de L2? En ambos casos, ¿cuánto tiempo transcurre entre lo que sucede en un lado y lo que es demostrable en el otro lado?

3. ¿Qué tipos de esquemas de prueba podemos usar?

Hay cinco opciones principales: -A prueba de Merkle -ZK-SNARK generales

• Prueba dedicada (por ejemplo, usando KZG) -Verkle demuestra que están entre KZG y ZK-SNARK en términos de carga de trabajo y costo de infraestructura.
• No se requiere prueba, se basa en la lectura directa del estado En términos de trabajo de infraestructura requerido y costo de usuario, los clasificaría aproximadamente de la siguiente manera:

"Agregación" se refiere a la agregación de todas las pruebas proporcionadas por los usuarios dentro de cada bloque en una gran meta-prueba que combina todas las pruebas. Esto es posible con SNARK y KZG, pero no con las bifurcaciones de Merkle (puede combinar un poco las bifurcaciones de Merkle, pero solo le ahorra registro (txs por bloque)/registro (número total de almacenes de claves), en la práctica es probablemente 15-30% en el medio, por lo que probablemente no valga la pena el precio). La agregación solo vale la pena cuando el escenario tiene una gran cantidad de usuarios, por lo que, en la práctica, una implementación de la versión 1 podría omitir la agregación e implementarla en la versión 2.

4. ¿Cómo funcionarán las pruebas de Merkle?

Este es fácil: simplemente siga el diagrama en la sección anterior. Más precisamente, cada "prueba" (asumiendo el caso de probar la máxima dificultad de una L2 a otra L2) contendrá: Una sucursal de Merkle que acredite la raíz estatal de L2 que contiene el almacén de claves, dada la última raíz estatal de Ethereum conocida por L2. El almacén de claves mantiene la raíz del estado de L2 almacenada en una ranura de almacenamiento conocida en una dirección conocida (el contrato en L1 representa L2), por lo que la ruta a través del árbol se puede codificar de forma rígida. Una rama de Merkle que certifica la clave de verificación actual, dada la raíz del estado de L2 que contiene el almacén de claves. Aquí nuevamente, la clave de autenticación se almacena en una ranura de almacenamiento conocida en una dirección conocida, por lo que la ruta se puede codificar. Desafortunadamente, las pruebas de estado de Ethereum son complejas, pero existen bibliotecas para validarlas, y si usa esas bibliotecas, este mecanismo no es demasiado complicado de implementar. ** El mayor problema es el costo. **Las pruebas de Merkle son muy largas, desafortunadamente el árbol de Patricia es ~3.9 veces más largo de lo necesario (para ser exactos: una prueba de Merkle ideal para un árbol que contiene N objetos tiene 32 * log2(N) bytes de largo, y porque los árboles de Patricia de Ethereum tienen 16 hojas por niño, y la prueba de estos árboles es de 32 * 15 * log16(N) ~= 125 * log2(N) bytes de largo). En un estado con aproximadamente 250 millones (~2²⁸) de cuentas, esto hace que cada prueba sea 125 * 28 = 3500 bytes, o aproximadamente 56 000 de gas, más el costo adicional de decodificación y verificación del hash. Juntas, las dos pruebas terminarían costando alrededor de 100 000 a 150 000 gasolina (si se usan por transacción, sin incluir la verificación de firma), mucho más que el precio base actual de 21 000 gasolina 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 muchos menos nodos que L1. Por otro lado, los datos deben publicarse en L1. Así que la comparación no es gas 21k vs gas 15k, es gas L2 21k vs gas L1 100k. Podemos calcular lo que esto significa observando la comparación entre el costo del gas L1 y el costo del gas L2:

Actualmente, L1 es de 15 a 25 veces más caro que L2 para el envío simple y de 20 a 50 veces más caro para los intercambios de tokens. El envío simple es una cantidad relativamente grande de datos, pero la cantidad de cálculo del intercambio es mucho mayor. Por lo tanto, el intercambio es un mejor punto de referencia para el costo aproximado del cómputo L1 versus el cómputo L2. Teniendo todo esto en cuenta, 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 una prueba de Merkle en L2 podría ser equivalente a 50 transacciones regulares. Por supuesto, el uso de árboles binarios de Merkle reduce el costo en un factor de ~4, pero aun así, en la mayoría de los casos, el costo es demasiado alto: si estamos dispuestos a sacrificar la compatibilidad con el árbol de estado hexagonal actual de Ethereum, buscamos mejores opciones

5. ¿Cómo funcionará 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. Un ZK-SNARK requiere ~400 000 GAS para el cálculo, lo que requiere alrededor de 400 bytes (en comparación con: una transacción básica requiere 21 000 gas y 100 bytes, que pueden reducirse a ~25 palabras después de la compresión en el futuro Festival). Por lo tanto, desde un punto de vista computacional, el costo de ZK-SNARK es 19 veces el costo de las transacciones básicas de hoy, y desde el punto de vista de los datos, el costo de ZK-SNARK es 4 veces el de las transacciones básicas de hoy y 16 veces el costo de las futuras transacciones básicas veces. Esos números son una gran mejora con respecto a la prueba de Merkel, pero siguen siendo bastante caros. Hay dos formas de mejorar esto: (i) pruebas KZG de propósito especial, o (ii) agregación, similar a la agregación ERC-4337 pero usando matemáticas más sofisticadas. Podemos estudiar los dos al mismo tiempo.

6. ¿Cómo funcionarán las pruebas KZG especiales?

Advertencia, esta sección es más matemática que las otras. Esto se debe a que nos estamos moviendo más allá de las herramientas de propósito general y construyendo algunas de propósito especial más baratas, por lo que tenemos que ir "bajo el capó" más. Si las matemáticas profundas no son lo tuyo, pasa directamente a la siguiente sección. Primero, un resumen de cómo funcionan los compromisos de KZG: Podemos representar un conjunto de datos [D_1...D_n] usando la prueba KZG de un polinomio derivado de los datos: específicamente, el polinomio P, donde P(w) = D_1, P(w²) = D _2 ... P(wⁿ) = D_n donde está la "raíz uniforme", el valor de wN = 1 para algún tamaño de dominio de evaluación N (todo esto se hace en campos finitos). Para "comprometernos" con P, creamos un punto de curva elíptica com(P) = P₀ * G + P₁ * S₁ + ... + Pk * Sk. aquí: -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 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. Para verificar la prueba, verificamos la ecuación Q * (X - z) = P - a realizando una verificación de curva elíptica en la prueba com(Q) y el polinomio de compromiso com(P): verificamos e(com(Q ), com( X - z)) ? = e(com(P) - com(a), com(1)) Algunas propiedades clave que 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 en el polinomio de Lagrange (com(Li)). En un contrato en cadena, podría ser demasiado almacenar todos los N compromisos, por lo que podría hacer un compromiso KZG con el conjunto de valores com(L_i) (o hash(com(L_i)), por lo que siempre que alguien necesita Al actualizar el árbol en cadena, simplemente puede proporcionar una prueba de su corrección al com (L \ _i) apropiado. Así que tenemos una estructura en la que podemos seguir agregando valores al final de la lista creciente, aunque con algún límite de tamaño (en realidad, cientos de millones podrían ser factibles). Luego usamos esto como nuestra estructura de datos para administrar (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 de claves L2, almacenada en Ethereum 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.

Por lo tanto, una prueba completa requiere:

• El almacén de claves contiene la última com (lista de claves) en L2 (48 bytes) -KZG demuestra que com(lista de claves) es com(valor en mirror_list), compromiso con todas las listas de envío de listas de claves (48 bytes) -KZG demuestra que su clave está en com (lista de claves) (48 bytes, más 4 bytes para el índice) De hecho, es posible combinar dos pruebas KZG en una, por lo que obtenemos un tamaño total de solo 100 bytes. Tenga en cuenta una sutileza: debido a 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 compromiso de clave contendrá su propio registro interno, mapeando cada almacén de claves a una ID, y para cada clave, almacenará el hash (dirección del almacén de claves) en lugar de solo la clave, para comunicarse explícitamente con otros L2 cuyo almacén de claves una entrada en particular está hablando. La ventaja de esta técnica es que funciona muy bien en L2. Los datos son 100 bytes, que es aproximadamente 4 veces más corto que ZK-SNARK y más corto que las pruebas de Merkle. El costo de cálculo es principalmente un par de cheques, o alrededor de 119,000 de gasolina. En L1, los datos son menos importantes que el cálculo, por lo que, lamentablemente, los KZG son un poco más caros que las pruebas de Merkle.

7. ¿Cómo funcionará el árbol Verkle?

Los árboles de Verkle implican esencialmente apilar compromisos KZG (o compromisos IPA, que pueden ser más eficientes y usar un cifrado más simple): para almacenar valores de 2⁴⁸, usted hace un compromiso de KZG con una lista de valores de 2²⁴, cada uno de los cuales es en sí mismo un compromiso de KZG para Valor 2²⁴. Los árboles de Verkle se consideran fuertemente para los árboles de estado de Ethereum, porque los árboles de Verkle se pueden usar para mantener asignaciones de clave-valor, no solo listas (básicamente, puede crear un árbol de tamaño 2²⁵⁶ pero comenzar vacío, solo si solo llena partes específicas del árbol cuando realmente necesita llenarlos).

Cómo se ve un árbol Vicker. De hecho, puede dar a cada nodo un ancho de 256 == 2⁸ para árboles basados en IPA y 2²⁴ para árboles basados en KZG. Las pruebas en los árboles de Verkle son algo más largas que en KZG; pueden tener cientos de bytes de largo. También son difíciles de verificar, especialmente si intenta agregar muchas pruebas en una sola. En realidad, los árboles Verkle deben considerarse como árboles Merkle, pero más factibles sin SNARKing (debido al menor costo de datos), y SNARKing es más barato (debido al menor costo de prueba). La mayor ventaja de los árboles de Verkle es que pueden coordinar estructuras de datos: las pruebas de Verkle se pueden usar directamente para los estados L1 o L2, no tienen estructura de superposición y usan exactamente el mismo mecanismo para L1 y L2. Una vez que las computadoras cuánticas se conviertan en un problema, o una vez que la ramificación de Merkle demuestre ser lo suficientemente eficiente, los árboles de Verkle pueden reemplazarse en el lugar por árboles hash binarios con funciones hash compatibles con SNARK.

8. Agregados

Si N usuarios que realizan N transacciones (o, de manera más realista, N ERC-4337 UserOperations) necesitan probar N afirmaciones entre cadenas, podemos ahorrar mucho dinero agregando estas pruebas: combinando estas transacciones en un bloque o El constructor del paquete que entra en el bloque puede crear una prueba que pruebe todas estas afirmaciones al mismo tiempo. Esto podría significar:

• Pruebas ZK-SNARK para sucursales N Merkle
• Una prueba múltiple KZG
• Una multiprueba Verkle (o multiprueba ZK-SNARK) En los tres casos, cada prueba requiere solo unos pocos cientos de miles de gas. El constructor necesita hacer uno de estos en cada L2 para los usuarios en esa L2; por lo tanto, para facilitar la construcción, todo el esquema debe usarse lo suficiente como para que haya al menos unas pocas transacciones en el mismo bloque en el comercio de múltiples L2 principales. . Si se utilizan ZK-SNARK, el principal costo marginal es solo la "lógica comercial" de pasar números entre contratos, por lo que cada usuario puede necesitar varios miles de gas L2. Si se utiliza la prueba múltiple KZG, el probador debe agregar 48 gas por cada almacén de claves que contenga L2 utilizado dentro del bloque, por lo que el costo marginal del esquema por usuario será por L2 (no por usuario) y luego se agregarán ~800 L1 de gas. . Pero estos costos son mucho más bajos que sin agregación, lo que inevitablemente involucra más de 10,000 L1 de gas y cientos de miles de L2 de gas por usuario. Para los árboles de Verkle, puede usar las pruebas múltiples de Verkle directamente, agregando alrededor de 100-200 bytes por usuario, o puede hacer ZK-SNARK de las pruebas múltiples de Verkle, que cuestan de manera similar a las ZK-SNARK bifurcadas de Merkle, pero la prueba cuesta Mucho más bajo. Desde el punto de vista de la implementación, es mejor 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 acciones de los usuarios de forma personalizada. Incluso hay una implementación para la agregación de firmas BLS, que puede reducir los costos de gas en L2 en un factor de 1,5 a 3, dependiendo de las otras formas de compresión incluidas.

Diagrama de la publicación de implementación de la billetera BLS que muestra el flujo de trabajo para las firmas agregadas de BLS en una versión anterior de ERC-4337. El flujo de trabajo para agregar pruebas de cadenas cruzadas puede parecer muy similar.

9. Lectura directa de estado

Una última posibilidad, también disponible solo para L2 leyendo L1 (y no L1 leyendo L2), es modificar L2 para que directamente hagan llamadas estáticas a contratos en L1. Esto se puede hacer con códigos de operación o precompilación, lo que permite llamadas a L1, donde proporciona la dirección de destino, el gas y los datos de la llamada, y devuelve la salida, pero dado que estas llamadas son estáticas, en realidad no pueden cambiar ningún estado de L1. L2 debe saber que L1 ya procesó el depósito, por lo que no hay nada que impida que se implemente tal cosa; esto es principalmente un desafío de implementación técnica (ver: esto de una RFP optimista para admitir llamadas estáticas a L1). Tenga en cuenta que si el almacén de claves está en L1 y L2 integra llamadas estáticas L1, ¡no se necesita ninguna prueba! Sin embargo, si L2 no integra las llamadas estáticas L1, o si el almacén de claves está en L2 (lo que eventualmente tendrá que hacerse una vez que L1 se vuelva demasiado costoso para que los usuarios lo usen aunque sea un poco), entonces se requerirá una prueba.

10. ¿Cómo aprende L2 la raíz de 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. Afortunadamente, todas las L2 ya tienen alguna funcionalidad para acceder al último estado de L1. Esto se debe a que necesitan dicha funcionalidad para manejar mensajes de L1 a L2, especialmente depósitos. 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 páselo a L2 como un mensaje de depósito . 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:

• Si L2 implementa la funcionalidad de "lectura directa de L1" de manera perezosa, solo leyendo la raíz del estado final de L1, entonces el retraso suele ser de 15 minutos, pero en casos extremos de fugas de inactividad (que debe tolerar), el retraso puede ser semanas.
• L2 definitivamente se puede diseñar para leer raíces de estado L1 actualizadas, pero dado que L1 puede recuperarse (lo que sucede durante fugas inactivas incluso con la finalidad de un solo socket), L2 también debe poder recuperarse. Desde el punto de vista de la ingeniería de software, esto es un desafío técnico, pero al menos Optimistic tiene la capacidad.
• Si usa un puente de depósito para llevar las raíces del estado L1 a L2, entonces la economía simple puede requerir mucho tiempo entre las actualizaciones del depósito: si el costo total de un depósito es 100,000 de gas, supongamos $ 1800 en ETH y una tarifa de 200 gwei, y las raíces L1 ingresan a L2 una vez al día, esto costaría $236 por L por día, o $13,148 por L2 por año para mantener el sistema. Una hora de retraso cuesta la friolera de $ 315,569 por L2 por año. En el mejor de los casos, hay un flujo constante de usuarios ricos e impacientes que pagan para actualizar y mantener el sistema actualizado para todos los demás. En el peor de los casos, algunos actores altruistas tendrán que pagar por ello ellos mismos.
• "Oracles" (al menos la tecnología que algunas personas de DeFi llaman "oracles") no son una solución aceptable aquí: la administración de claves de billetera es una función de bajo nivel muy crítica para la seguridad, por lo que debería depender como máximo de varias. infraestructura de bajo nivel que no requiere confianza criptográfica. Además, en la dirección opuesta (L1s se lee como L2):
• En Agregación optimista, las raíces estatales tardan una semana en llegar a L1 debido a retrasos a prueba de fraude. En los resúmenes de ZK, ahora lleva horas debido a una combinación de tiempo de verificación y restricciones económicas, aunque la tecnología futura reducirá esto.
• La preconfirmación (del secuenciador, certificador, etc.) no es una solución aceptable para que L1 lea L2. La administración de billeteras es una función de bajo nivel muy crítica para la seguridad, por lo que el nivel de seguridad de la comunicación L2 - L1 debe ser absoluto: ni siquiera es posible enviar una raíz de estado L1 incorrecta tomando el control del conjunto de validadores L2. La única raíz de estado en la que L1 debe confiar es aquella que ha sido aceptada como raíz de estado final por el contrato de tenencia de raíz de estado de L2 en L1. Para muchos casos de uso de DeFi, algunos de ellos son inaceptablemente lentos para operaciones de cadena cruzada sin confianza; para estos casos, realmente necesita puentes más rápidos con modelos de seguridad más imperfectos. Sin embargo, para el caso de uso de actualización de claves de billetera, los retrasos más largos son más aceptables: en lugar de retrasar las transacciones durante horas, retrasa los cambios de clave. Solo necesita mantener la llave vieja por más tiempo. Si cambia su clave porque se la robaron, tiene una vulnerabilidad durante mucho tiempo, pero se puede mitigar, por ejemplo. 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 último bloque L1, por lo que si L1 se recupera y L2 puede recuperarse también. Los contratos de almacén de claves deben colocarse en la red principal o en L2 de ZK Rollup para que puedan comprometerse rápidamente con L1.

Los bloques de la cadena L2 pueden depender no solo de los bloques L2 anteriores, sino también de los bloques L1. Si L1 se recupera a través de dicho enlace, L2 también se recuperará. Vale la pena señalar que así es como se concibió que funcionaran las versiones anteriores (anteriores a Dank) de sharding; vea aquí el código.

11. ¿Cuánta conexión a Ethereum necesita otra cadena para mantener un almacén de claves enraizado en Ethereum o billetera L2?

Sorprendentemente, no tantos. Ni siquiera necesita ser un resumen en realidad: si es L3 o validación, está bien mantener una billetera allí, siempre que mantenga el almacén de claves en L1 o ZK rollup. Lo que realmente necesita es la cadena para tener acceso directo a la raíz del estado de Ethereum, y un compromiso técnico y social de estar dispuesto a reorganizarse si Ethereum se reorganiza, y a una bifurcación dura si Ethereum se bifurca. Una pregunta de investigación interesante es determinar hasta qué punto una cadena puede tener esta forma de conexión con muchas otras cadenas (por ejemplo, Ethereum y Zcash). Hacer esto de manera ingenua es posible: si Ethereum o Zcash se reorganizan, su cadena puede aceptar reorganizarse (y una bifurcación dura si Ethereum o Zcash se bifurcan), pero sus operadores de nodos y su comunidad generalmente tienen dos veces dependencias tecnológicas y políticas. Por lo tanto, esta técnica se puede utilizar para conectarse a otras cadenas, pero a un costo mayor. Los esquemas basados en puentes ZK tienen propiedades técnicas atractivas, pero su principal debilidad es que no son resistentes a ataques del 51 % o bifurcaciones duras. Puede haber soluciones más inteligentes también.

12. Protección de la privacidad

Idealmente, también queremos preservar la privacidad. Si tiene muchas billeteras administradas por el mismo almacén de claves, entonces queremos asegurarnos de que:

• No está claro que estas billeteras estén todas conectadas entre sí.
• Los Guardianes de Rehabilitación Social no saben qué domicilio están protegiendo. Esto crea algunos problemas:
• No podemos usar las pruebas de Merkle directamente porque no protegen la privacidad.
• Si usamos KZG o SNARK, la prueba debe proporcionar una versión ciega de la clave de verificación sin revelar la ubicación de la clave de verificación.
• Si usamos la agregación, entonces el agregador no debe aprender las posiciones en el texto sin formato; en su lugar, el agregador debe recibir pruebas ciegas y tener una forma de agregar estas pruebas.
• No podemos usar una "versión ligera" (renovación de claves usando solo pruebas de cadena cruzada), porque crea una fuga de privacidad: si se actualizan muchas billeteras al mismo tiempo debido al proceso de actualización, el tiempo filtra información que puede ser relevante para estas carteras. Por lo tanto, tenemos que usar la "versión pesada" (prueba de cadena cruzada de cada transacción). Con SNARK, la solución es conceptualmente simple: de forma predeterminada, las pruebas tienen información oculta y los agregadores deben generar SNARK recursivos para probar SNARK.

El principal desafío con este enfoque actualmente es que la agregación requiere que el agregador cree un SNARK recursivo, que actualmente es muy lento. Con KZG, podemos usar este trabajo (ver también: una versión más formal de este trabajo en el artículo de Caulk) en pruebas KZG que no revelan índices como punto de partida. Sin embargo, la agregación de pruebas ciegas es un problema abierto que requiere más atención. Desafortunadamente, leer L1 directamente desde L2 no preserva la privacidad, aunque implementar la funcionalidad de lectura directa sigue siendo muy útil, tanto para minimizar la latencia como por su utilidad para otras aplicaciones.

13. Resumen

Para tener una billetera de recuperación social de cadena cruzada, el flujo de trabajo más realista es una billetera que mantiene un almacén de claves en una ubicación y una billetera que mantiene billeteras en muchas ubicaciones, donde la billetera lee el almacén de claves para (i) actualizar su clave de autenticación localmente vista, o (ii) en el proceso de validación de cada transacción. Un elemento clave que hace esto posible son las pruebas de cadena cruzada. Tenemos que trabajar en la optimización de estas pruebas. Las soluciones ZK-SNARK o KZG personalizadas que esperan la prueba de Verkle parecen ser las mejores opciones. A la larga, es necesario un protocolo de agregación (donde los empaquetadores generan pruebas agregadas como parte de la creación de un paquete de todas las acciones de los usuarios enviadas por los usuarios) para minimizar los costos. Esto probablemente debería integrarse en el ecosistema ERC-4337, aunque es posible que se requieran cambios en ERC-4337. L2 debe optimizarse para minimizar la latencia de leer el estado L1 (o al menos la raíz del estado) desde dentro de L2. Es ideal para L2 leer el estado L1 directamente, ahorrando espacio de prueba. Las billeteras no solo pueden estar en L2; también puede colocar billeteras en sistemas con niveles más bajos de conectividad a Ethereum (L3, o simplemente aceptar incluir la raíz del estado de Ethereum y la cadena independiente de bifurcaciones). Sin embargo, el almacén de claves debe estar en L1 o en el paquete acumulativo ZK de alta seguridad L2. El uso de L1 ahorra mucha complejidad, pero incluso eso puede ser demasiado costoso a largo plazo, por lo que se debe usar un almacén de claves en L2. Preservar la privacidad requerirá trabajo adicional y hará que ciertas elecciones sean más difíciles. Pero probablemente deberíamos recurrir a soluciones de preservación de la privacidad de todos modos, al menos asegurándonos de que todo lo que se nos ocurra sea compatible con la preservación de la privacidad.