Importante plan de expansión de Ethereum: Informe de estado de resumen optimista (Parte 1)

Si no fuera por el hecho de que MolochDAO encargó este informe de investigación, no creo que DAOSquare traduzca artículos académicos tan "técnicos" (al menos no en esta etapa). Sin embargo, la escalabilidad de Ethereum es de hecho un tema importante y candente. Las soluciones existentes incluyen Optimistic Rollup, Zk Rollup y Optimistic Rollup es una solución emergente que no se ha propuesto durante mucho tiempo. Se considera el plan de expansión más prometedor. Entonces, ¿cómo le ha ido hasta ahora? ¿Qué pasa con las perspectivas? El autor de este artículo, Daniel Goldman, completó este informe a través de mucha investigación, ¡y ahora, DAOSquare compartirá este resultado con todos! Sin embargo, debido a que la extensión del artículo es demasiado "grande", lo presentaremos en tres entregas, y este artículo es la primera parte. Autor: Daniel Goldman (Daniel Goldman) Ingeniero de software independiente, consultor técnico, escritor Traductores: Emma, ​​​​Snow Lu Corrección de pruebas: Samuel Descripción técnica general del ecosistema de rollup optimista emergente de Ethereum ;Roller optimista (original de Daniel Goldman, 2020) El siguiente informe fue autorizado por  MolochDAO, y John Adler proporcionó comentarios/reseñas relevantes; sin embargo, todas las opiniones en este artículo representan las mías. Además, la evaluación del programa es solo una instantánea del estado en el momento de la publicación de este informe (febrero de 2020). Todo está cambiando, no prometas demasiado. La neblina que se cierne sobre la comunidad de expansión de Ethereum: Optimistic Rollup En la segunda mitad de 2019, Optimistic Rollups (ORU u Optiroll) como protocolo de expansión de Ethereum Layer 2 rápidamente se hizo popular. Este artículo tiene como objetivo proporcionar una descripción general del ecosistema de desarrollo ORU emergente a partir del momento de la publicación (febrero de 2020). Primero colocamos las propiedades teóricas de ORU en el contexto del espacio de diseño de la Capa 2 y luego comparamos los métodos y las decisiones de diseño técnico de diferentes proyectos y las diversas compensaciones. Los 9 proyectos incluyen:   Fuel Labs ANON Whitehat, Cellani, Lim (en adelante, "WCL") Pinkiebell Offchain Labs Interstate Network Optimism IDEX Celer Haga clic aquí para revisar sus diferencias. Finalmente, profundizaremos en algunas preguntas cualitativas sobre cómo los proyectos anteriores desempeñarán su papel en el espacio. Antecedentes y teoría A pesar de su reputación, las cadenas de bloques abiertas y sin permisos tienen muchos problemas: todos los nodos completos de la red deben ser visibles y verificar cada transacción procesada por el sistema; la eficiencia ultrabaja (en comparación con el sistema de pago digital centralizado) es fundamental del tan debatido desafío de escalamiento de las criptomonedas. Los protocolos de capa 2 son una clase de formas de aliviar esta carga. En lugar de que todos los nodos validen todas las transacciones localmente, solo un subconjunto de transacciones es validado localmente por las partes interesadas (como aquellas que desean asegurar sus propios fondos) para que (de alguna manera, forma) cambien esta carga. Es importante destacar que conservan el modelo de seguridad sin confianza de la capa base, sin depender de otros recursos que no sean el software que el usuario ejecuta. La PHA del proyecto Polkadot en la plataforma BiKi ha aumentado un 221 % en 24 horas: según los datos del mercado de BiKi, a las 16:47 de hoy (GMT+8), la moneda de la plataforma PHA del proyecto Polkadot ha aumentado un 221 % en 24 horas, y el precio actual es 1.11USDT. El mercado fluctúa mucho, preste atención al control de riesgos. [2021/2/25 17:52:04] Disponibilidad de datos: solución En las primeras etapas del desarrollo de Ethereum Layer 2, los desarrolladores planearon operar bajo el supuesto implícito de que la capa base "reduce la carga de verificación" para integrar completamente ( Ciertos) los datos de transacciones están aislados de la cadena de bloques. (Consulte el artículo de principios de 2018 de Josh Stark Cómo dar sentido a la capa 2 de Ethereum para obtener una descripción general del pensamiento en ese momento).  El protocolo de moneda de encriptación tiene sus propiedades económicas inherentes, que pueden motivar a los productores de bloques a compartir bloques de manera oportuna y extensa (a menos que se trate de casos extremos de minería egoísta como la minería egoísta); la capa base de la cadena de bloques a veces se denomina como la "Motor de disponibilidad de datos". Garantizar que los datos sean (totalmente) públicos garantiza que se puedan verificar y que las transacciones no válidas sean prácticamente imposibles de pasar. Por lo tanto, en el escenario de la Capa 2, si los datos deben estar completamente aislados fuera de la cadena, ya no podremos garantizar que tengamos este tipo de disponibilidad de datos, porque aquellos que se preocupan por la validez de los datos pueden ocultar la datos. Por lo tanto, tenemos que averiguar cómo garantizar de alguna manera que las actualizaciones de estado no válidas no ocurran en este caso de esquina. Para los sistemas de Capa 2, el problema de la ocultación de datos es siempre el más difícil y el peor de los casos, porque lo peor es buscar hechos sin información. Si nuestra definición es lo suficientemente flexible, todas las soluciones a este problema de ocultación de datos se pueden dividir en dos categorías: canales de estado y Plasma (canales y Plasma). Si las dos partes están en el mismo canal, la actualización de los datos fuera de la cadena será realmente efectiva después de que ambas partes estén de acuerdo. Por lo tanto, si Alice elige mantener los datos de Bob, Alice estará actualizada; mantener los datos no le hace ningún bien. En cambio, Plasma no tiene este requisito de mutuo acuerdo. Esto lleva directamente al hecho de que en Plasma, pueden ocurrir actualizaciones no válidas si el usuario no tiene ninguna evidencia directa. Incluso en este caso, Plasma aún puede garantizar que los usuarios tengan los datos fuera de la cadena necesarios para probar y garantizar la propiedad de sus activos durante el período de desafío interactivo. En términos de resultados prácticos, los canales de estado se han convertido en la primera construcción de Capa 2. Es fácil de entender para las personas, y los canales estatales (probablemente) resuelven algunos desafíos de investigación fundamentales, y vemos canales estatales utilizados en Bitcoin y Ethereum. Los canales estatales tienen algunas propiedades prácticas, como transacciones instantáneas, que son muy adecuadas para las necesidades de algunas aplicaciones específicas. Aunque es un esquema de expansión más general, todavía está limitado hasta cierto punto. Los canales son inherentemente independientes entre sí, y las conexiones sin confianza serían ineficientes desde el punto de vista del capital y/o estarían restringidas por las rutas de flujo disponibles. (Previamente publiqué limitaciones y soluciones relacionadas en Lightning Network de Bitcoin). Se espera que Plasma proporcione una solución de expansión de cadena lateral más versátil que facilite a los participantes el intercambio de información, pero su camino de desarrollo sea más difícil. Los detalles sobre los desafíos técnicos de Plasma están más allá del alcance de este artículo. Sin embargo, en términos (muy) simples, la incapacidad de garantizar la disponibilidad de los datos dificulta la conservación inmediata de muchas características, como: admitir pagos con denominaciones arbitrarias, minimizar los requisitos de autenticación/almacenamiento para los usuarios, evitar esquemas de salida masiva y admitir una lógica de contrato inteligente. . Si bien estos problemas pueden aliviarse, el precio de abordar una barrera suele ser la exacerbación de otra. En resumen, es difícil hacerlo exactamente bien, e incluso cuando estas construcciones son lo suficientemente factibles, su complejidad hace que su práctica sea difícil y lenta. (He publicado aquí y aquí analizando el progreso plausible de Plasma Cash y sus variantes y los desafíos que plantean. Los problemas de Plasma hacen que algunos incluso piensen que desaparecerá (declarar su desaparición). Incluso si algunas personas piensan que esto es demasiado pronto para saberlo. (como yo), pero no hay duda de que Plasma es más difícil y complejo de lo previsto, y la velocidad espacial a la que se transmiten los resultados es más lenta de lo que inicialmente se esperaba. Con Plasma estancado, la comunidad Ethereum está ansiosa por algo similar. Bajo supervisión, cosas con características de cadena lateral. En este momento, en términos de estado de investigación e implementación, ha aparecido Optimistic Rollup.   Disponibilidad de datos: Concesiones Podemos encontrar rastros de la construcción actual de Optimistic Rollup en varias propuestas anteriores, como Shadowchains,  ;Coinwitness, validación masiva con ZK-SNARKS (ahora llamado ZK-Rollup), y un discurso estudiantil sobre Arbitrum a principios de 2015. En lo que respecta a la comprensión actual, John Adler y Mikerah Quintyne-Collins (también conocido como " Bad Crypto Bitch") llamó a la base del protocolo "Merged Consensus". El equipo anterior de Plasma Group (ahora Optimism, descrito a continuación) describió un principio similar en una publicación de blog, y lo enmarcó en el análisis semántico del juego Optimistic Layer 2, llamado Optimistic Rollup (por el motivo que sea) y lo finalizó. Optimistic Rollup toma el marco descrito en el párrafo anterior y lo voltea; ORU En lugar de tener la intención de permanecer sin custodia frente a la ocultación de datos, adopta un enfoque más directo de requiriendo directamente que los datos de transacciones se publiquen en la cadena, y más específicamente, requiriendo que se publiquen suficientes datos en la cadena, para que cualquier persona que ejecute un nodo Ethereum pueda reconstruir el estado de la ORU. La ventaja de escalar es que la Capa 1 solo necesita para descubrir los datos y convertir su árbol de Merkle en la raíz del bloque, sin hacer nada, ejecución de capa 2. Por lo tanto, los datos de transacciones se publican en la cadena como datos de llamadas y no se almacenan en el estado, debido al crecimiento de la capacidad del estado y los costos de computación (probablemente) son los cuellos de botella centrales de la expansión de Ethereum, esto tiene mucho espacio para crecer. Al igual que Plasma, la incapacidad de la capa base para verificar directamente las transacciones significa que habrá algunas transacciones no válidas. Bajo ORU, cualquier parte será testigo de la actualización de transacciones no válidas, y luego informar a la base a través de evidencia de fraude La capa muestra la prueba de fraude, que restaurará el bloque fraudulento y las actualizaciones posteriores del bloque. Una vez que ha pasado suficiente tiempo sin presentar una prueba de fraude, se pueden determinar y agregar bloques, y se pueden completar los retiros iniciados de esos bloques. Para frenar el daño malicioso a la comunidad mediante la publicación intencional de bloques no válidos, el remitente del bloque emitirá un depósito y, si el fraude resulta ser válido, el depósito se reducirá drásticamente. La manera precisa en que se maneja esta prevención de fraude es el núcleo de cualquier estructura de ORU en particular. En comparación con Plasma, ORU tiene una desventaja fundamental inevitable, es decir, su escalabilidad relativamente baja. Asumiendo que los datos en la cadena son proporcionales a los datos en el bloque ORU, la construcción de ORU estará limitada por la cantidad máxima de datos en la capa base. Sin embargo, ORU también tiene muchos beneficios en otros aspectos, que incluyen: Soporte más fácil/amplio para contratos inteligentes Soporte más fácil para denominaciones de pago arbitrarias Producción de bloques sin permiso Mecanismo de salida del juego más simple Operación relativamente simple Como esperábamos, incluso los factores anteriores también deben ser pesados ​​entre sí en diferentes estructuras ORU. (Para obtener más información sobre ORU, consulte "Los porqués de Optimistic Rollup" de John Adler). de los cuales ha optado por permanecer seudoanónimo al publicar (en lo sucesivo, "ANON"). Considere solo los proyectos en el alcance de Optimistic Rollup, es decir, todos deben ser "Optimistas", incluir algún tipo de suposición de que "la suposición es válida a menos que se presente una prueba de fraude" (es decir, no ZK-rollup) e incluir "Resumen", es decir, se publican suficientes datos en la cadena para que cualquier observador pueda reconstruir el estado y detectar la invalidez (es decir, no Plasma). La mayoría de los proyectos analizados se ajustan estrictamente a estos parámetros, con la única excepción de IDEX 2.0, cuyos detalles se analizan a continuación. Varios otros proyectos que trabajan en Plasma o construcciones adyacentes a Plasma se encuentran en las primeras etapas de investigación de ORU, incluidos Matic, LeapDAO y Cryptoeconomics Lab. Compatibilidad con contratos inteligentes y pruebas de fraude La principal diferencia entre los proyectos ORU interactivos es la medida en que admiten scripts de contratos inteligentes y la naturaleza de la verificación y la prueba de fraude que requieren. Entre los 9 proyectos encuestados en esta encuesta, 5 proyectos han implementado funciones completas de máquina virtual Ethereum en su Rollup, y la cadena lateral rollup tiene soporte de contrato inteligente de Solidity, y su nivel de soporte es (aproximadamente) comparable al de la capa base de Ethereum. El soporte de contratos inteligentes es comparable, mientras que los proyectos restantes están más inclinados a soportar funciones más limitadas y restringidas. En términos generales, además de la funcionalidad del contrato inteligente en sí, admitir un EVM completo garantiza la coherencia técnica entre el resumen y la cadena principal, promete una integración más sencilla con las herramientas de infraestructura y facilita la transición para los desarrolladores que están acostumbrados a los contratos inteligentes compilados con Solidity en Layer1. . Por el contrario, los proyectos que favorecen una funcionalidad más limitada y restringida tienen las siguientes ventajas: pruebas de fraude más baratas (más o menos), verificación más sencilla, optimizaciones sencillas para usuarios específicos y simplificación general.

Tags：

Precio de Etéreo