Sobre la minimización de la confianza y el escalamiento horizontal

Ethereum es una computadora mundial sin permisos que posee (posiblemente) la mayor cantidad de seguridad económica en el momento de escribir este artículo, actuando como libro de liquidación para una gran cantidad de activos, aplicaciones y servicios. Ethereum tiene sus limitaciones: el espacio de bloques es un recurso escaso y costoso en la capa uno (L1) de Ethereum. El escalamiento de capa dos (L2) se ha considerado la solución a este problema, y en los últimos años han llegado al mercado numerosos proyectos, principalmente en forma de paquetes acumulativos. Sin embargo, los rollups, en el sentido estricto del término (lo que significa que los datos acumulativos están en Ethereum L1), no permiten que Ethereum escale indefinidamente, solo permiten hasta unos pocos miles de transacciones por segundo.

Confianza minimizada: (una característica de) un sistema L2 tiene confianza minimizada si funciona sin requerir confianza externa a la base L1.

Escalado horizontal: un sistema es escalable horizontalmente si se pueden agregar instancias sin imponer cuellos de botella globales.

En este artículo, sostenemos que los sistemas de confianza minimizada y escalables horizontalmente son la forma más prometedora de escalar las aplicaciones blockchain, aunque actualmente están poco explorados. Presentamos el argumento explorando tres preguntas:

1. ¿Por qué se debe minimizar la confianza en las aplicaciones?
2. ¿Por qué construir sistemas que sean escalables horizontalmente?
3. ¿Cómo podemos maximizar tanto la minimización de la confianza como la escalabilidad horizontal?

(Descargo de responsabilidad: aunque nos centraremos en Ethereum como base L1 en este artículo, la mayor parte de lo que analizamos aquí se aplica a capas de liquidación descentralizadas más allá de Ethereum).

¿Por qué se debe minimizar la confianza en las aplicaciones?

Las aplicaciones se pueden conectar a Ethereum de manera confiable: pueden escribir y leer desde la cadena de bloques Ethereum, pero se confía en los operadores para ejecutar la lógica empresarial correctamente. Los intercambios centralizados como Binance y Coinbase son excelentes ejemplos de aplicaciones confiables. Estar conectado a Ethereum significa que las aplicaciones pueden acceder a una red de liquidación global con un conjunto diverso de activos.

Existen riesgos importantes asociados con los servicios confiables fuera de la cadena. El colapso de los principales intercambios y servicios en 2022, como FTX y Celsius, es una gran advertencia sobre lo que sucede cuando los servicios confiables se comportan mal y fallan.

Por otro lado, las aplicaciones de confianza minimizada pueden escribir y leer desde Ethereum de manera verificable. Los ejemplos incluyen aplicaciones de contratos inteligentes como Uniswap, paquetes acumulativos como Arbitrum o zkSync y coprocesadores como Lagrange y Axiom. En términos generales, la confianza se elimina a medida que las aplicaciones quedan protegidas por la red Ethereum, a medida que se subcontratan más funcionalidades (ver más abajo) a L1. Como resultado, se pueden ofrecer servicios financieros con confianza minimizada sin riesgos de contraparte o custodio.

Hay tres propiedades clave que pueden tener las aplicaciones y servicios, que se pueden subcontratar a L1:

1. Vida (y ordenación): las transacciones enviadas por los usuarios deben incluirse (ejecutarse y liquidarse) de manera oportuna.
2. Validez: las transacciones se procesan según reglas preestablecidas.
3. Disponibilidad de datos (y estado): los datos históricos, así como el estado actual de la aplicación, se ponen a disposición del usuario.

Para cada una de las propiedades anteriores, podemos pensar en cuál es el supuesto de confianza requerido; en particular, ¿Eth L1 proporciona la propiedad o se requiere confianza externa? La siguiente tabla clasifica esto para diferentes paradigmas de arquitectura.

¿Por qué construir sistemas que sean escalables horizontalmente?

El escalado horizontal se refiere al escalamiento mediante la adición de instancias independientes o paralelas de un sistema, por ejemplo aplicación o resumen. Esto no requiere que exista ningún cuello de botella global. El escalado horizontal permite y facilita el crecimiento exponencial.

El escalado vertical se refiere al escalamiento mediante el aumento del rendimiento de un sistema monolítico, como Eth L1 o una capa de disponibilidad de datos. Cuando el escalamiento horizontal se topa con cuellos de botella en un recurso compartido de este tipo, a menudo se requiere el escalamiento vertical.

Afirmación 1: Los paquetes acumulativos (de datos de transacciones) no pueden escalarse horizontalmente porque pueden verse obstaculizados por la disponibilidad de datos (DA). Escalar verticalmente las soluciones DA requiere hacer concesiones en materia de descentralización.

La disponibilidad de datos (DA) sigue siendo el cuello de botella para los rollups. Actualmente, cada bloque L1 tiene un tamaño máximo objetivo de ~1 MB (85 KB/s). Con EIP-4844, habrá ~2 MB adicionales (171 KB/s) disponibles (a largo plazo). Con Danksharding, Eth L1 puede llegar a admitir hasta 1,3 MB/s de ancho de banda DA. Eth L1 DA es un recurso compartido por el que compiten muchas aplicaciones y servicios. Por lo tanto, aunque el uso de L1 para DA proporciona la mejor seguridad, obstaculiza la escalabilidad potencial de dichos sistemas. Los sistemas que utilizan L1 para DA (normalmente) no podrán escalar horizontalmente y tendrán deseconomías de escala. Las capas DA alternativas, como Celestia o EigenDA, también tienen límites de ancho de banda (aunque mayores, 6,67 MB/s y 15 MB/s, respectivamente). Pero se produce a expensas de trasladar el supuesto de confianza de Ethereum a otra red (a menudo menos descentralizada), comprometiendo la seguridad (económica).

Afirmación 2: La única forma de escalar horizontalmente servicios con confianza minimizada es obtener (casi) cero datos marginales L1 por transacción. Los dos enfoques conocidos son los paquetes acumulativos de diferencias de estado (SDR) y los validiums.

Los paquetes acumulativos de diferencias de estado (SDR) son paquetes acumulativos que publican diferencias de estado en un lote agregado de transacciones en Ethereum L1. Para EVM, a medida que los lotes de transacciones crecen, los datos por transacción publicados en L1 disminuyen a una constante que es mucho más pequeña que la de los resúmenes de datos de transacciones.

Por ejemplo, durante el evento de prueba de estrés de gran avalancha de inscripciones, zkSync vio una reducción de los datos de llamadas por transacción hasta tan solo 10 bytes por transacción. Por el contrario, los paquetes acumulativos de datos de transacciones como Arbitrum, Optimism y Polygon zkEVM suelen ver alrededor de 100 bytes por transacción para el tráfico normal.

Un validium es un sistema que publica pruebas de validez de las transiciones de estado a Ethereum, sin datos de transacciones ni estados asociados. Los validiums son altamente escalables horizontalmente, incluso en condiciones de poco tráfico. Esto es especialmente cierto porque se puede agregar la liquidación de diferentes validiums.

Además de la escalabilidad horizontal, un validium también puede proporcionar privacidad en cadena (de los observadores públicos). Un validium con DA privado tiene datos centralizados y controlados y disponibilidad estatal, lo que significa que los usuarios deben autenticarse antes de acceder a los datos y que el operador puede aplicar buenas medidas de privacidad. Esto permite un nivel de experiencia de usuario similar al de los servicios web o financieros tradicionales: las actividades de los usuarios están ocultas del escrutinio público, pero existe un custodio confiable de los datos del usuario, en este caso el operador validium.

¿Qué pasa con los secuenciadores centralizados y descentralizados? Para mantener los sistemas escalables horizontalmente, es crucial crear instancias de secuenciadores independientes, ya sean centralizados o descentralizados. En particular, aunque los sistemas que utilizan secuenciadores compartidos disfrutan de una <a href="https://hackmd.io/@EspressoSystems/SharedSequencing"> composability atómica , no pueden escalar horizontalmente, ya que el secuenciador puede convertirse en un cuello de botella a medida que se agregan más sistemas.

¿Qué pasa con la interoperabilidad? Los sistemas escalables horizontalmente pueden interoperar sin confianza adicional si todos se asientan en la misma L1, ya que los mensajes se pueden enviar de un sistema a otro a través de la capa de liquidación compartida. Existe una compensación entre el costo operativo y el retraso en la mensajería (que potencialmente puede resolverse en la capa de aplicación).

Minimización de la confianza para sistemas escalables horizontalmente

¿Podemos minimizar aún más los requisitos de confianza para la vida, los pedidos y la disponibilidad de datos en sistemas escalables horizontalmente?

Es de destacar que, a costa de la escalabilidad horizontal, sabemos cómo salvar la falta de confianza y la disponibilidad de datos. Por ejemplo, las transacciones L2 se pueden iniciar desde L1 para garantizar su inclusión. Volition puede ofrecer disponibilidad de estado L1 opcional para los usuarios.

Otra solución es simplemente descentralizar (pero no depender de la L1). En lugar de un único secuenciador, los sistemas podrían volverse más descentralizados utilizando secuenciadores descentralizados (como Espresso Systems o Astria), minimizando así la confianza necesaria para la vida, los pedidos y la disponibilidad de datos. Hacerlo impone limitaciones en comparación con las soluciones de un solo operador: (1) el rendimiento puede estar limitado por el rendimiento del sistema distribuido y (2) para validiums con DA privado, la garantía de privacidad predeterminada se pierde si la red del secuenciador descentralizado no tiene permisos.

¿Cuánta confianza podemos minimizar adicionalmente para validiums o DEG de un solo operador? Hay un par de direcciones abiertas aquí.

Dirección abierta 1: Disponibilidad de datos con confianza minimizada en validiums. Plasma resuelve el problema de disponibilidad del estado hasta cierto punto: resuelve el problema de retiros solo para ciertos modelos de estado (que incluye el modelo de estado UTXO) o requiere que los usuarios estén en línea periódicamente (Plasma Free).

Dirección abierta 2: Preconfirmaciones contables en DEG y validiums. El objetivo aquí es proporcionar a los usuarios una confirmación previa rápida de la inclusión de la transacción desde un secuenciador, y la confirmación debería permitir al usuario cuestionar y recortar el interés económico del secuenciador si no se cumple la promesa de inclusión. El desafío aquí es que demostrar la no inclusión (necesaria para la reducción) probablemente requiera datos adicionales para el usuario, que un secuenciador simplemente puede retener. Por lo tanto, es razonable suponer que al menos exigimos que el SDR o validium emplee un comité de disponibilidad de datos (potencialmente autorizado) para sus datos de llamadas completos o su historial de transacciones, lo que permite al mismo comité proporcionar pruebas de no inclusión (de pre-inclusión). transacciones confirmadas) a petición del usuario.

Dirección abierta 3: Recuperación rápida de fallas de vida. Los sistemas de un solo operador pueden sufrir fallas de vida (p. ej. Arbitrum se desconectó durante el evento de inscripción). ¿Podemos diseñar sistemas que proporcionen una interrupción mínima del servicio en este escenario? En cierto sentido, las L2 que permiten la autosecuencia y las propuestas estatales brindan garantías contra fallas prolongadas de vida. Actualmente, el diseño de sistemas de un solo operador que sean más resistentes contra fallas de vida más cortas está poco explorado. Una posible solución en este caso es responsabilizar las fallas de vida, proporcionando recortes contra las fallas de vida. Otra posible solución es simplemente acortar el período de demora (que actualmente está previsto en alrededor de una semana) antes de que pueda ocurrir una adquisición.

Conclusión

Ampliar un libro de contabilidad de liquidación global manteniendo al mismo tiempo la minimización de la confianza es un problema difícil. No ha habido una distinción clara entre el escalamiento vertical y el escalamiento horizontal en el mundo actual de disponibilidad de datos y resumen. Para realmente escalar sistemas de confianza minimizada para todos en la tierra, necesitamos construir sistemas de confianza minimizada y escalables horizontalmente.

Agradecimientos

Muchas gracias a Vitalik Buterin y Terry Chung por sus comentarios y debates, así como a Diana Biggs por sus comentarios editoriales.

声明:

Descargo de responsabilidad:

1. Este artículo está reimpreso de [Mirror]. Todos los derechos de autor pertenecen al autor original [1kx]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.