Importante plan de expansión de Ethereum: informe de estado acumulativo optimista (medio)

Este artículo es la segunda parte de "Plan de expansión importante de Ethereum: informe de estado de resumen optimista". Haga clic en "Plan de expansión importante de Ethereum: informe de estado de resumen optimista (Parte 1)" para la primera parte. EVM completo: máquina virtual de capa 2 Para que los cálculos de contratos inteligentes de la capa 2 sigan siendo confiables, debe haber una alternativa para realizar tales cálculos en la capa 1 de alguna forma. Se puede ver que ORU soporta un EVM completo, y la Capa 2 necesita su propia máquina virtual, la cual puede ejecutarse en la capa básica de EVM, por lo que no es fácil crear e implementar alto rendimiento. En resumen, el EVM no fue diseñado para ejecutarse por sí solo. Puede leer sobre algunos de estos desafíos en EIP, que también analiza la posibilidad de modificar el EVM para incorporar directamente esta funcionalidad, y la descripción general del problema de Plamsa de Kelvin Fitcher. Por lo tanto, los cinco proyectos completos de EVM crean sus propias versiones modificadas de EVM para la ejecución de la Capa 2. Para garantizar pruebas de fraude fiables y predecibles, la ejecución de las máquinas virtuales debe ser determinista, es decir, en el momento de la prueba debe ser capaz de reproducir con precisión las circunstancias en las que se descubrió originalmente el fraude. Por lo tanto, las operaciones no deterministas deben modificarse o eliminarse por completo, por ejemplo, verificar la altura del bloque, la dificultad y la marca de tiempo. Del mismo modo, los códigos de operación para la creación o destrucción de contratos también deben eliminarse, ya que esta lógica es especial. Por lo tanto, el contrato de Capa 1 en ORU puede requerir algunas modificaciones menores al código de Solidity antes de implementarse en la cadena ORU. Pruebas de fraude   Todas las ORU EVM completas comparten algunos puntos en común básicos en la forma en que facilitan las pruebas de fraude: el estado de la cadena ORU se ordena y confirma periódicamente, al igual que el hash de las operaciones de cómputo, incluida la realización de transiciones de estado. (En todas las prácticas, la responsabilidad de generar y validar el estado raíz recae en el operador, no en el usuario). Las pruebas de fraude usan estos datos en parte para mostrar que los pasos presentados en realidad no transformaron correctamente el estado inicial en el estado final.  La principal diferencia en la práctica completa de EVM es la forma interactiva en que manejan estas pruebas de fraude. ORU debe contener suficientes datos de llamadas en esencia, para que el comportamiento fraudulento se pueda encontrar de inmediato y, finalmente, obtener el consenso de la cadena principal. Sin embargo, el procedimiento para realizar esta prueba de fraude varía de una construcción a otra. En un esquema de prueba de fraude de ronda única (a veces, llamado confusamente "no interactivo"), el fraude siempre se puede probar en una sola transacción o en múltiples transacciones por una sola parte. La ventaja de esto es que la disputa se puede "resolver" instantáneamente, no hay problemas con el transportista, por lo que no se requiere fianza para un probador fraudulento y es simple de operar. En múltiples rondas de pruebas de fraude, el fraude es obvio, pero se requieren varios pasos de interacción entre el probador de fraude y el productor del bloque. La ventaja de esto es que el costo del gas es menor (en algunos casos menor), y el costo de datos en la cadena también puede ser menor. ◎ Ronda única de prueba de fraude Nutberry, Optimism y Celer's ORU admiten una ronda única de prueba de fraude. Esto requiere que cada transacción se comprometa con una raíz posterior al estado serializada. En el modelo de Optimism, Celer también se ve directamente afectado y, si se detecta un fraude, el probador de fraude publicará el estado inicial de la transacción y el tiempo (ranura) del estado final, y permitirá que la cadena principal ejecute la transacción por completo. (Este flujo es muy similar al modelo de  cliente sin estado  utilizado para validar bloques de Ethereum). Idealmente, una transacción requeriría solo una cantidad mínima de tiempo de estado (ranura) para demostrar ser fraudulenta. Pero, en principio, es posible que las transacciones necesiten leer grandes cantidades de datos de estado. Si la prueba de fraude requiere una gran cantidad de datos y/o cálculos, lo que dificulta colocarla en el bloque de la cadena principal, entonces Optimism puede dividir la prueba en múltiples transacciones (tenga en cuenta que el probador de fraude aún envía estas transacciones. Por lo tanto, from En cierto sentido, este paso adicional no califica como una "interacción".) El enfoque de Nutberry es similar, pero utiliza un modelo de "computación cerrada" para ejecutar contratos. Los contratos inteligentes están parcheados para incluir puntos de control. En este modelo, las transacciones se comprometen con múltiples raíces de estado intermedio más granulares, lo que potencialmente requiere más datos, pero realiza pruebas de fraude en partes más pequeñas. ◎ Múltiples rondas de prueba de fraude  El probador debe interactuar con el probador de fraude en varios pasos para decidir si la prueba de fraude de varias rondas es verdadera. La clave, como se define ORU, es publicar suficientes datos para que cualquier participante u observador honesto pueda determinar desde el principio qué lado está diciendo la verdad, prediciendo así el resultado del período de desafío. En el caso de Interstate One, la transacción contiene una raíz de estado y la raíz de Merkle se envía al paso de ejecución correspondiente al publicar, en lugar del paso en sí. En cierto sentido, esta sumisión es una suposición "optimista" secundaria. Solo cuando el verificador hace una pregunta, el operador publica la pila de mensajes EVM en los datos de la llamada, que el verificador puede usar para probar brevemente el fraude. En el peor de los casos, este proceso toma un total de 3 rondas y requiere datos de llamadas lineales en el número de pasos en las transacciones involucradas (en comparación con una prueba de fraude de una sola ronda que requiere datos lineales en todos los casos). Lo último en mejorar la interactividad es Arbitrum Rollup de Offchain Labs, que minimiza la huella en la cadena. Con Arbitrum, solo los bloques, no las transacciones, deben comprometerse con la raíz del estado. Al igual que Interstate, estos también incluyen el cálculo de hashes de confirmación. Si dos partes hacen afirmaciones contradictorias, entran en una disputa en la que descubren interactivamente un solo paso computacional que se realizó de manera inválida (en caso de fraude, en principio debe existir al menos un paso inválido). Hacen esto haciendo una búsqueda binaria eficiente en la pila hasta que se aísla el fraude: es decir, el probador de fraude recorre la pila, solicita un hash de estado en un punto a la mitad, luego divide la pila y repite la mitad que se sabe que no es válida. Este proceso se repite hasta que solo queda una operación no válida, que luego se ejecuta en la cadena. Por lo tanto, en el peor de los casos, este proceso requiere (n) pasos de registro (donde n es el número de operandos) y requiere un cálculo mínimo de Capa 1. Una propiedad sorprendente de este enfoque es que no hay necesidad de suspender el resto del sistema mientras la disputa está en curso. Los usuarios y los productores de bloques pueden continuar realizando transacciones como de costumbre. La "controversia" puede considerarse como una rama en un árbol de posibilidades. Los usuarios honestos pueden verificar y determinar qué parte es honesta y basarse en eso para ver cómo se resolverá finalmente la disputa. Por lo tanto, la duración de la disputa no retrasa el resto del sistema. Consulte Cómo funciona Arbitrum Rollup para obtener más información. Los proyectos RollupsORU específicos de la aplicación admiten una funcionalidad más restringida mientras buscan optimizar en torno a casos de uso más específicos: pagos tokenizados, intercambios descentralizados, pagos privados y migraciones masivas. Cada uno de los cuatro protocolos es distinto y se explorará por separado. ◎ Fuel ("Bitcoin en la cadena de bloques") Fuel está implementando una cadena lateral ORU basada en UTXO y centrada en pagos con un modelo de datos similar a Bitcoin. Este diseño necesita equilibrar algunas funciones de los contratos inteligentes a favor de la simplicidad y una verificación más barata y prueba de fraude. De hecho, muchos de los pensamientos sobre las compensaciones de Fuel vs. EVM ORU completo son similares a las compensaciones de Bitcoin vs. Ethereum. Al igual que Bitcoin, el estado de la cadena de combustible se define implícitamente como la recopilación de todas las salidas de transacciones no gastadas; no se requiere serialización de la raíz del estado. El modelo que admite pruebas de fraude sucintas es similar al propuesto originalmente para Bitcoin por Greg Maxwell en 2014 (y redescubierto de forma independiente y redescubierto de forma independiente por John Adler en 2019); las transacciones y las transacciones de Bitcoin son muy similares, pero contienen un campo de datos adicional que especifica donde se procesa cada entrada. Con esta área de datos, se pueden usar una o dos pruebas de inclusión para probar todos los casos de fraude (ataques de doble gasto, entradas falsas, etc.) en una sola ronda. Además de las pruebas de fraude de bajo costo, el modelo UTXO promete una verificación de mayor rendimiento: mejores patrones de acceso de estado y paralelismo (en comparación con la ejecución de EVM de verificación realizada sincrónicamente). Fuel admitirá transferencias ERC20 y ERC721 utilizando un modelo que refleja la propuesta de monedas de colores para Bitcoin. También admite ciertos tipos de transacciones especiales, incluidos intercambios atómicos para HTLC. El plan es admitir eventualmente un lenguaje de secuencias de comandos predicado sin estado más potente, similar en funcionalidad a Bitcoin Script. (Vea aqui para mas informacion). ◎ ZK-Optistic-Rollup de ANON ("ZCash en la cadena de bloques") Otro proyecto único de ORU es ZK-Optistic-Rollup de ANON, que admite transacciones de pago E RC-20 y ERC-721, y tiene la misma garantía de privacidad que ZCash privado dirección. El diseño tiene mucho en común con el propio ZCash (consulte aquí el manual básico de ZCash); las solicitudes de fondos toman la forma de "emisiones" al estilo UTXO; los pagos dan como resultado nuevas emisiones y crean "anuladores" que registran la emisión. para evitar futuros gastos dobles. Las transacciones también incluyen ZK-SNARK que se puede demostrar que satisfacen todas las condiciones de validez sin revelar ningún detalle al observador. Para mantener pruebas de fraude sucintas, ZK-ORU tiene una función que no se encuentra en ZCash: los avisos de revocación se almacenan en un árbol Sparse Merkle y se actualizan con cada nuevo bloque ORU. Esto facilita probar la membresía (comprometida) y la no membresía (no comprometida). Al igual que con todas las demás ORU, los cálculos se retrasan de manera optimista, incluida la verificación del propio SNARKS. Todos los casos de fraude, incluidos los SNARK no válidos, se pueden probar en un solo paso. Tenga en cuenta que la gran carga de generar SNARK recae en el usuario; ANON espera que un cliente pase de 10 a 30 segundos generando un SNARK. (También tenga en cuenta que, a pesar de los nombres y componentes similares, ZK-Optimistic-Rollup es en realidad distinto de ZK-Rollup en que no proporciona necesariamente protección de la privacidad, no utiliza pruebas de fraude y utiliza SNARK generados por operadores para demostrar su validez. Bienvenido. a criptomoneda.) ◎ Centro ORU de WCL La operación ORU está diseñada para convertirse en un estándar de transacción por lotes entre cadenas acumuladas, y es un medio para que los usuarios migren voluntariamente sus fondos para actualizar contratos. La operación en sí es una cadena simple basada en pagos solo de cuentas que, como Fuel, proporciona pruebas de fraude baratas y verificación de datos. El objetivo principal de esta construcción es establecer una arquitectura estándar para poder transferir directamente entre diferentes cadenas, es decir, sin tener que retirar fondos de una cadena y volver a depositarlos en otra cadena. Esto se puede lograr apoyando depósitos por lotes y estableciendo conexiones cruzadas unidireccionales entre cadenas. Siempre que un validador en la cadena de destino detecte un comportamiento fraudulento en la cadena de origen, el pago puede considerarse definitivo sin demora adicional. Esto es similar a la lógica de comunicación entre fragmentos ETH 2.0 de investigación en torno a la comunicación entre fragmentos ETH 2.0. Si bien el principal caso de uso planificado es la capacidad de actualización, otro posible caso de uso para este mecanismo es la migración entre cadenas de rollup en vivo separadas y distintas, y necesitamos investigar más sobre esto. Aún no se han hecho públicos más detalles sobre el protocolo preciso para la migración entre cadenas acumuladas y las cadenas canónicas que deben confirmarse, y se vincularán aquí en el futuro. ◎ IDEX 2.0 La característica única de IDEX es que utilizan ORU como la mejor versión de expansión del proyecto que se ha puesto en producción. El contrato de IDEX se está ejecutando actualmente en la red principal. El módulo de estado (estado) utilizado por el El contrato de IDEX es más que cualquier otro Ethereum. Hay muchas aplicaciones. La cadena acumulativa de IDEX 2.0 admite la función comercial descentralizada de órdenes de registro y se basa en este caso de uso específico. La cadena es responsable de ejecutar órdenes, mantener los saldos de los usuarios y permitir la configuración de otras funciones, como tipos de órdenes más avanzadas, motores de negociación automatizados, etc. Los validadores en la ORU de IDEX deben tener tokens IDEX. Los validadores envían recibos que prueban los bloques publicados y son recompensados ​​y/o penalizados (si eligen aceptar la validación completa de "riesgo") por sus firmas en bloques válidos y la emisión de pruebas de fraude válidas. Las recompensas se pagan utilizando una parte de las tarifas de transacción y tokens propios (el análisis de los modelos criptoeconómicos está fuera del alcance de este artículo; para obtener más información, consulte el documento técnico de IDEX 2.0). En el protocolo, el productor del bloque solo carga la raíz de Merkle del bloque como entrada inicial y solo publica el contenido del bloque en los datos de la llamada cuando se le solicita

Tags：

XRP