- Tema
34k Popularidad
12k Popularidad
6k Popularidad
16k Popularidad
61k Popularidad
31k Popularidad
2k Popularidad
95k Popularidad
27k Popularidad
27k Popularidad
- Anclado
34k Popularidad
12k Popularidad
6k Popularidad
16k Popularidad
61k Popularidad
31k Popularidad
2k Popularidad
95k Popularidad
27k Popularidad
27k Popularidad
Interpretación de la importancia de la descentralización de Rollup desde múltiples ángulos
Autor original: Shivanshu Madan
Recopilación original: Luffy, Foresight News
Gran parte de la discusión sobre Crypto Twitter últimamente gira en torno a la descentralización L2. ¿Está lo suficientemente descentralizado el paquete acumulativo que estamos construyendo? ¿Están ya en el camino de la descentralización? ¿Importa?
Exploraré estos temas en este artículo. Antes de profundizar, si aún no sabe cómo funcionan realmente los paquetes acumulativos, le sugiero que lea este artículo rápidamente: Paquetes acumulativos para principiantes.
La idea de Rollup es bastante simple: quiere que los participantes fuera de la cadena realicen transacciones que luego se pueden verificar fácilmente en la cadena. Con Rollup, la "confianza" de la capa base se extiende a actividades fuera de su cadena de bloques. A cambio, Rollup paga una pequeña tarifa (alquiler) para usar este fideicomiso.
Entonces, ¿necesitamos Rollup descentralizado?
La respuesta intuitiva es: ¡definitivamente necesito hacerlo! Este es el espíritu de blockchain.
Sin embargo, también creo que la respuesta a esta pregunta no es un simple sí o no. Más bien, abarca múltiples aspectos, que deben ser analizados individualmente. En lo que sigue, exploraré este tema desde tres perspectivas: filosofía, tecnología y economía.
Perspectiva filosófica
Comencemos por llevar la conversación a un nivel superior: ¿por qué nos importa la descentralización?
Porque queremos un futuro sin permisos que promueva la innovación abierta. Queremos que los usuarios puedan construir cosas nuevas sin restricciones y sin necesidad de confiar en ninguna entidad única.
En la breve historia de blockchain, muchos desarrolladores anónimos han creado cosas increíbles. De hecho, Bitcoin en sí mismo fue creado por una entidad anónima, y pronto puede convertirse en la moneda de pago global utilizada por la mayor parte del mundo. ¡Ese es el poder de la innovación sin permiso!
Blockchain nos permite trabajar con personas que no tienen nada en común y sabemos que no hay forma de que rompan esa confianza.
—— Preston Evans
La base descentralizada de redes sin confianza como Bitcoin y Ethereum nos permite construir ese futuro. ¡Obviamente, cualquier cadena que tenga una relación de confianza con estas cadenas de bloques, como Rollup, también debe descentralizarse!
De hecho, plantea una pregunta interesante e importante:
Si Rollup no está descentralizado, ¿eso significa que Ethereum no está descentralizado?
Una forma un poco optimista de ver esto es que, en un mundo sin permisos, se debe permitir que los Rollups construyan lo que quieran, incluidas (entre otras) cadenas autorizadas, y los usuarios de ese Rollup aún podrían aprovechar la seguridad de la capa subyacente. . Siempre que la capa base esté descentralizada y el paquete acumulativo esté "totalmente implementado" (hablaremos más sobre la "implementación completa" en la sección técnica), incluso las cadenas autorizadas deberían ser seguras de usar.
Pero la realidad es que la mayoría de los paquetes acumulativos actuales no han llegado a la etapa de implementación completa y no brindan a los usuarios el nivel de seguridad y confianza que necesitan.
Entonces, ¿cuál es la implementación correcta de Rollup? vamos a ver:
Perspectiva técnica
Para comprender verdaderamente las preocupaciones de seguridad y descentralización de Rollup, debemos analizarlo desde los primeros principios. Pocas personas pueden explicar los primeros principios de blockchain mejor que Sreeram Kannan.
Blockchain es un libro mayor distribuido, y diferentes nodos en la red siguen reglas de protocolo predeterminadas para obtener un consenso sobre el estado del libro mayor. Dependiendo de cómo estos nodos vean la red, pueden tener diferentes reglas para confirmar el estado correcto de su propia red de contabilidad.
Especialmente en Rollup, los nodos completos y los clientes ligeros tienen diferentes reglas de confirmación. En el Smart Contract Rollup tradicional (SCR), el contrato inteligente (puente de verificación) tiene sus propias reglas de confirmación. Si no hay eventos adversos, estas reglas de confirmación eventualmente coinciden en las llamadas "regiones de consistencia". Como su nombre lo indica, en una zona de consenso, todos los participantes tienen la misma vista de la red (y el mismo historial en el libro mayor).
Si todas las reglas de confirmación son seguras, no sucederán cosas malas. Como compartió Sreeram en la publicación anterior, 5 propiedades definen principalmente la seguridad de estas reglas de confirmación.
Las primeras 2 propiedades definen la condición "viva" del sistema, mientras que las últimas 3 propiedades definen la condición "segura".
Examinemos estos problemas desde la perspectiva de diferentes participantes de Rollup y veamos cuáles se pueden mitigar sin descentralización.
Diferentes actores confían en diferentes mecanismos para la seguridad y la vida.
Nodo completo:
Si ejecuta un nodo completo, tiene acceso a los datos publicados y puede verificarlos directamente. Luego puede usar esos datos para ejecutar transacciones usted mismo y determinar la validez de las transacciones y el estado final del Resumen después de esas transacciones.
Las restantes condiciones de seguridad son, por tanto, la actividad y la resistencia a la recombinación. Para la resistencia a la reorganización, los nodos completos se basan en los validadores de la cadena base y el protocolo de consenso que utiliza, mientras que para la vitalidad, los nodos completos se basan en la implementación de Sequencer y Rollup.
Cliente ligero:
La mayoría de los usuarios interactúan con la cadena de bloques utilizando clientes ligeros para obtener datos de la cadena de bloques. Hay varios tipos de nodos de luz:
Si ejecuta un cliente ligero de validación completo, puede verificar si los datos están disponibles a través del muestreo de disponibilidad de datos, verificar la validez de las transiciones de estado a través de pruebas de validez o pruebas de fraude, y verificar si el estado sigue el consenso de la capa base (en Ethereum arriba , se puede hacer siguiendo el comité de sincronización).
Luego, la condición de seguridad restante es viva, y el cliente ligero depende de la implementación del secuenciador y del resumen.
Contrato inteligente integrado (puente de verificación):
En el SCR tradicional, la "regla de confirmación" de un contrato inteligente es hacer cumplir las 5 propiedades de seguridad:
Los nodos completos de SCR se basan en contratos inteligentes para hacer cumplir las propiedades de vida. Obtienen su resistencia a la reorganización de la capa base.
Los nodos de luz se basan en contratos inteligentes para mejorar las propiedades de vida y absorber DA y resistencia a la reorganización de la capa base. Pueden verificar las pruebas de validez por sí mismos o mediante contratos inteligentes.
El consenso de SCR es seguir la cadena canónica definida por el contrato inteligente.
¿Qué pasa con los paquetes acumulativos soberanos?
Los Sovereign Rollups no tienen contratos inteligentes (puentes de validación) para hacer cumplir las condiciones de validez o vida. En su lugar, demostrarán que se "desplazan hacia abajo" a los nodos acumulativos posteriores. Estos nodos aún dependen de la disponibilidad de datos y la resistencia a la reorganización de la capa base.
Al igual que en SCR, en Sovereign Rollup los nodos necesitan algún mecanismo para hacer cumplir la propiedad de vida. Para definir la cadena canónica, optaron por mecanismos independientes como la transmisión de pruebas p2p.
¿Qué tiene que ver todo esto con la descentralización?
Ya sea un Rollup de contrato inteligente o un Rollup soberano, la propiedad de vida proviene de la implementación correcta del Rollup. Como hemos visto anteriormente, una correcta implementación de Rollup debe incluir dos componentes importantes:
Los mecanismos de inclusión obligatoria ayudan a aumentar la resistencia a la censura. Este mecanismo permite a los usuarios "forzar la inclusión" de sus transacciones directamente en la capa base. Cualquier usuario en el Rollup puede forzar el retiro de sus fondos a la capa base. Por lo tanto, incluso si solo hay un nodo recopilador centralizado, no puede censurar a los usuarios siempre que exista un mecanismo de inclusión obligatorio maduro.
¿Pero es eso suficiente?
Incluso si los usuarios son libres de salir, esto podría significar que L2 no tiene muchos incentivos para continuar operando si la mayoría de los usuarios regresan a L1. Además, el mecanismo de inclusión obligatoria suele tener un largo tiempo de espera y puede resultar bastante caro de implementar para el usuario medio. La resistencia a la censura que proporciona este mecanismo no es del todo práctica (ni en tiempo real), podemos llamarla “censura débil”.
Luego tenemos el atributo de actividad final: el crecimiento del libro mayor.
Si el ordenante centralizado hace algo malo, puede detener el crecimiento de la cadena Rollup simplemente deteniendo la producción de bloques. Si esto sucede, no hay nada que el usuario pueda hacer para que el resumen vuelva a estar "activo".
Para resolver este problema, necesitamos un protocolo de reemplazo del clasificador.
La idea del Protocolo de reemplazo de secuenciador es que si un Secuenciador se comporta de manera maliciosa, Rollup puede iniciar un nuevo Secuenciador a través de la gobernanza. Una de las formas de lograr esto es reemplazar los nodos de pedidos centralizados con protocolos de pedidos descentralizados. Si el ordenante está descentralizado y no monopoliza la construcción de bloques de Rollup, será casi imposible bloquear la cadena de Rollup.
Por lo tanto, si bien los fondos de los usuarios siempre están seguros en los paquetes acumulativos a través del mecanismo de inclusión obligatorio, la creación de un protocolo sólido de reemplazo de pedidos ayuda a mantener vivos los paquetes acumulativos y proporciona una resistencia práctica a la censura en tiempo real.
¿esto es todo?
no completamente. Desde un punto de vista técnico, hay un aspecto más a considerar:
¿Qué pasaría si los propios contratos inteligentes pudieran ser actualizados por el comité central de Rollup? Digamos que Rollup actualmente se implementa correctamente, pero mañana el comité acuerda que ya no necesitamos contratos inteligentes, sino que transmitimos pruebas del estado de Rollup a la red p2p.
Si, como usuario de Rollup, no está de acuerdo con dicha actualización, debería poder salir de Rollup antes de que se implemente la actualización (aunque esta no es una buena experiencia de usuario y puede no ser buena para el negocio). Esto se puede lograr a través de "actualizaciones de gobernanza retrasadas", como un "período de notificación", después del cual se implementarán las actualizaciones. Los usuarios que no estén de acuerdo con las actualizaciones pueden retirarse dentro del período de notificación.
El extremo de la descentralización es tener contratos inteligentes completamente inmutables. Estos contratos no se rigen por ninguna billetera de firmas múltiples u otro comité, y una vez implementados, nunca se pueden actualizar.
Por supuesto, esto tiene sus propios problemas. Si hay algún error en el código, o algún evento importante requiere actualizar el contrato inteligente, la única opción para Rollup es bifurcarse con el nuevo contrato inteligente, mientras que los fondos de los usuarios están atrapados en el contrato anterior.
Desafortunadamente, el estado actual de Rollup está lejos de la implementación completa que discutimos anteriormente. La mayoría de los Rollups todavía están en la fase de "exploración", tratando de implementarlos correctamente.
Según L2 BEAT, Fuel v1 y DeGate son los dos únicos Rollup que han madurado para alcanzar todas las condiciones de actividad y seguridad.
Perspectiva Económica
Finalmente, echemos un vistazo a la economía de Rollup desde la perspectiva de los usuarios y operadores de Rollup:
La experiencia del usuario se optimiza cuando los usuarios reciben servicios de transacción rápidos y económicos.
La velocidad a la que se finalizan las transacciones depende de la velocidad a la que se finaliza la capa base. Las transacciones pueden considerarse definitivas siempre que se finalicen los datos en L1. Sin embargo, los usuarios que ejecutan nodos completos también pueden lograr una finalidad instantánea simplemente ejecutando transacciones y determinando el estado final.
Pero no es práctico para todos ejecutar un nodo completo. Por lo tanto, un clasificador centralizado es útil porque puede proporcionar a los usuarios una "confirmación suave" de que su transacción está incluida en un bloque y se finalizará. Esto es suficiente para la mayoría de los casos de uso. Sin embargo, depende de instituciones centralizadas que pueden tomar medidas adversas.
Si bien algunas soluciones de protocolos alternativos al pedido renuncian a esta propiedad (como una desventaja para los usuarios), otras soluciones, como el esquema de consenso de PoS externo Espresso, pueden proporcionar garantías de confirmación previa similares sin el riesgo de un pedido centralizado.
¿Qué pasa con los costos de usuario?
El costo explícito de una transacción de resumen suele ser:
Costo de gas L2 = Costo de gas L1 + Tarifa de secuenciador. Los clasificadores centralizados racionales siempre quieren maximizar sus ganancias, incluso si eso significa pasar costos más altos a los usuarios. Sin embargo, vale la pena señalar que esto tampoco puede resolverse necesariamente mediante un mecanismo de clasificación descentralizado. Incluso los nodos PoS en un ordenante descentralizado quieren maximizar sus propias ganancias.
De hecho, esto crea un problema de desajuste, donde Rollup puede no querer entregar las ganancias a los secuenciadores externos.
Beneficio acumulado: además de las tarifas del secuenciador, Rollup también puede obtener ganancias extrayendo MEV de las transacciones de los usuarios. Este MEV a menudo es difícil de atribuir porque es difícil averiguar si el ordenante incluye algunas de sus propias transacciones iniciales en el paquete de transacciones.
Si se reemplaza el Rollup por un consenso de PoS externo, entregarán este MEV a un operador externo.
Vale la pena señalar que estos dos problemas de Rollup que entrega ingresos a mecanismos externos pueden resolverse a través de "acuerdos de transacción" entre Rollup y mecanismos externos.
Sin embargo, como se explicó en la charla de Jon Charbonneau durante la Cumbre Modular y la publicación posterior, una mejor idea podría ser hacer que la gobernanza de Rollup delegue los pedidos a un conjunto de nodos validados. Estos nodos se pueden elegir estratégicamente para que estén dispersos geográficamente, y la gobernanza puede simplemente expulsar a los malos actores.
Esta podría ser una solución que mate dos pájaros de un tiro, ya que permite a Rollup mantener las ganancias internamente, al mismo tiempo que mitiga la desventaja de los clasificadores centralizados.
Pero, por el contrario, en el caso de una rotación limitada del secuenciador, el secuenciador puede tener un comportamiento miope, lo que puede conducir a precios de monopolio/aumento de precios, perjudicando aún más los intereses de los usuarios sacrificados de Rollup.
De cualquier manera, para que Rollup sea rentable para los usuarios, es necesario algún protocolo de reemplazo del clasificador.
en conclusión
Independientemente del camino que tome el paquete acumulativo, es crucial que apunte a una implementación completa con un protocolo de reemplazo de secuenciador maduro, inclusión obligatoria y mecanismos de actualización de gobernanza de retrasos. Si existe un mecanismo para la inclusión obligatoria y las actualizaciones retrasadas, los fondos de los usuarios estarán seguros, ya sea que el clasificador esté centralizado o no.
Sin embargo, un protocolo robusto de reemplazo de secuenciador puede mejorar las garantías de vida y potencialmente mejorar la economía para los usuarios de Rollup.