Fase uno y listo: Eth2 como motor de disponibilidad de datos.

Nota del editor: el título original de este artículo era "Fase uno y listo: eth2 como motor de disponibilidad de datos". En el momento de la publicación (abril de 2019), el autor tenía la intención de proponer una hoja de ruta para que Eth2.0 reemplazara a la Fase 2. es decir, si solo se utiliza la fragmentación para garantizar la disponibilidad de los datos, es útil dicho sistema y qué partes deben agregarse para que sea útil. Sorprendentemente, hace un año y medio, el autor se dio cuenta de que para un sistema como zk-rollup, la capa inferior debe garantizar que "la ejecución de las transiciones de estado y la disponibilidad de datos deben estar atómicamente unidas", por lo que la capa inferior debe tener la capacidad de ejecución, incluso si se trata de una ejecución sin estado muy simple; además, (el autor también señaló a través de capas de razonamiento) para garantizar la experiencia del usuario, la parte principal que aún falta es el procedimiento de cómo fragmentar los datos Tarifa acuerdo de pago (estos dos puntos de entendimiento, incluso hoy en día, todavía pueden llamarse de vanguardia, incluso avanzados). El protocolo de tarifas aún falta en la especificación de la Fase 2. Por cierto, el autor de este artículo es Casey Detrio, quien es miembro del equipo de Ewasm y ha brindado muchas ideas para la Fase 2 anteriormente; también cree que Eth2 debe diseñarse con el núcleo de "garantizar que los contratos de Eth1 puedan ser ejecutado como de costumbre cuando llega Eth2" .0. Es un desarrollador subestimado. Actualmente, el cuello de botella que limita el rendimiento de Eth1 es el crecimiento estatal. Entonces, si queremos escalar Ethereum, lógicamente, 1000 fragmentos con estado independiente pueden aumentar el rendimiento 1000 veces. Sin embargo, desde la ruta Eth1.x, Eth1.x quiere hacer ajustes importantes en el costo de dos tipos de recursos: almacenamiento (storage) y datos de transacción (tx data). Actualmente, el almacenamiento está subvaluado y los datos transaccionales están sobrevaluados. Esto incentivará a los desarrolladores de dApp a utilizar más almacenamiento que datos de transacciones al redactar contratos, lo que provocará que el almacenamiento se convierta en un cuello de botella en el rendimiento. La solución propuesta a este problema es aumentar el precio del almacenamiento y reducir el precio de los datos de transacción. Con estos ajustes de costos, se incentivará a los desarrolladores a utilizar los datos de transacciones más que el almacenamiento (es decir, escribirán más contratos sin estado en lugar de contratos con estado). Por lo tanto, en un futuro cercano (si la hoja de ruta de Eth1.x logra una adopción generalizada), esperamos que el rendimiento de Eth1 esté limitado por los datos de transacción, no por el almacenamiento. Si asumimos que el rendimiento está limitado por los datos de transacción, entonces los fragmentos de Serenity no necesitan tener estado para escalar Ethereum. Si el rendimiento está limitado por los datos de transacción de los contratos sin estado, entonces 1000 fragmentos sin estado aumentarán el rendimiento en 1000 veces. Esto suena bien, pero debe implementarse mediante fragmentación, que está previsto que espere hasta la Fase 2. Al mismo tiempo, podemos utilizar la Fase 1 como motor de disponibilidad de datos. El término motor de disponibilidad de datos parece estar ganando popularidad. Pensemos en cómo funciona. Tome zk-rollup como ejemplo, zk-rollup está limitado por la disponibilidad de datos. ¿Puede un contrato zk-rollup en Eth1 usar efectivamente Eth2 como proveedor de garantía de disponibilidad de puente? Si no se puede garantizar la disponibilidad de los datos durante la ejecución (es decir, verificar la prueba de SNARK y actualizar la raíz del estado), termina con un sistema zk-rollback similar al plasma. Aunque este sistema puede mejorar en gran medida el TPS, introducirá compensaciones complejas y tendrá que lidiar con los desafíos del operador y los mecanismos de salida como el plasma. En un desafío de disponibilidad, cualquiera puede proporcionar datos para probar la disponibilidad, por lo que no está claro si poner datos en un fragmento Eth2 con puente facilitaría las cosas. Mawson Infrastructure lanzó un ETF centrado en la minería de criptomonedas en Australia: Jinse Finance informó que Mawson Infrastructure Group lanzó un ETF centrado en la minería de criptomonedas en Australia, incluidas empresas como Galaxy Digital y Hut8 Mining. El ETF será el primer producto ofrecido por su división Cosmos Asset Management bajo el símbolo "DIGA.CXA". Según un comunicado, el ETF seguirá el desempeño del Índice Global de Minería Digital administrado por S&P. El comunicado de prensa no especificó cuándo comenzaría a cotizar el ETF. [2021/11/2 6:26:11] Ahora con otra versión de zk-rollup, a saber, 500 TPS zk-rollup, todo es mucho más simple. Ya no es necesario un operador designado, cualquiera puede actuar como retransmisor en cualquier momento y generar pruebas SNARK para actualizar el estado. De hecho, las garantías de disponibilidad de datos siempre van acompañadas de actualizaciones de estado, lo que significa que no hay necesidad de lidiar con desafíos del operador y mecanismos de salida como el plasma. Pero esto requiere garantías tanto de ejecución como de disponibilidad de datos en la misma transacción, lo que desafortunadamente no podemos hacer con un motor de disponibilidad puenteado. En otras palabras, el puente es suficiente para un sistema a prueba de fraude como zk-rollback, pero no lo suficiente para un sistema a prueba de validez como zk-rollup. La conclusión es que, para simplificar la prueba de validez en la Capa 2, una función importante que debe tener el motor de disponibilidad en la Capa 1 es garantizar que la disponibilidad de los datos y la ejecución de las transiciones de estado ocurran atómicamente juntas. Tal vez no debería sorprendernos esta realización. Si la disponibilidad de datos por sí sola (sin ejecución) fuera útil, nadie argumentaría que la Fase 1 comenzó solo para garantizar la disponibilidad de un montón de blobs distintos de cero (objetos binarios grandes), y nadie se quejaría de tener que esperar a que llegue Eth2. en La próxima etapa realmente entrará en juego (además de PoS). Estamos trabajando en la Fase 1 como motor de disponibilidad de datos, pero aún no hace nada, por lo que es decepcionante. (¡Vaya, podemos construir Mastercoin 2.0!) Entonces, ¿por qué la Fase 1 entraría en conflicto con la implementación? Bueno, suponiendo una ejecución con estado, cada fragmento mantiene algún estado local. Si los validadores necesitan mantener una gran cantidad de estado local, entonces la reproducción aleatoria del validador es mucho más complicada. Por el contrario, si no hay implementación, no se preocupe por el estado local. La reproducción aleatoria del validador sería mucho más simple, podríamos centrarnos en crear fragmentos con blobs de datos e iniciar fragmentos más rápido. Sin embargo, no supongamos que la ejecución es con estado. ¿Qué pasa si intentamos hacerlo con una máquina virtual sin estado muy simple? Supongamos que hay 3 nuevos campos de validación en el estado de la cadena de balizas: código, stateRoot y deploymentShardId. También hay una función process_deploy (justo debajo de process_transfer). Una vez que se implementa el código, el verificador debe asegurarse de que el saldo de la cuenta no sea inferior a un cierto umbral [al menos 1 ETH está bloqueado. Si no hay un programa de autodestrucción (SELFDESTRUCT) en el código, entonces esta parte de ETH equivale a ser destruida y el código se implementará permanentemente]. Ahora, supongamos que ya existen algunas cuentas con códigos en el estado global. A continuación, intentamos empaquetar blobs de datos específicos en fragmentos, pero ¿cómo? Hasta donde yo sé, sigue siendo una pregunta abierta para los validadores de fragmentos de fase 1 decidir qué blobs de datos empaquetar en bloques de fragmentos. Suponga que esto no se detalla en la especificación de la fase 1. Entonces, para los usuarios, si quieren empaquetar sus propios blobs de datos en fragmentos, solo hay dos formas: (1) Contactar al verificador y enviarlo a Su pago; (2) Conviértase en un validador usted mismo y podrá (cuando se seleccionan aleatoriamente como el proponente del bloque del fragmento) empaquetan el blob de datos en el fragmento. Ambos métodos son malas ideas. Una mejor manera es poner las cosas sobre la mesa y permitir que el verificador pague al proponente del bloque actual a través de un acuerdo de transacción. A cambio, el proponente del bloque empaqueta el blob de datos del validador en la cadena de fragmentos. Sin embargo, este enfoque no funciona si las operaciones de bloqueo de la cadena de balizas (como las transferencias de validadores) tienen requisitos mínimos de capacidad. El caso de uso de la "fase 1 como motor de disponibilidad de datos" no sería posible sin un protocolo transaccional que permitiera a los validadores priorizar el empaquetado de blobs de datos (ya sea un contrato eth1 conectado a través de un puente a la cadena de balizas, o un Truebit, Mastercoin 2.0, u otros casos de uso de disponibilidad de datos de los que he oído hablar antes). De todos modos, supongamos que no importa cómo el proponente del fragmento empaquete blobs de datos en el modo "Motor de disponibilidad de datos sin ejecución", puede estar igualmente disponible en el modo "Motor de disponibilidad de datos con ejecución simple sin estado". Muy bien, digamos que ciertos blobs de datos se pueden empaquetar en bloques. Cada bloque limita la ejecución a una transacción (por ejemplo, todo el blob de datos debe incluirse como una sola transacción). Todavía no hemos aclarado si la transacción se firmará con una clave (hay un acuerdo de transacción) o no será necesario firmar (no hay un acuerdo de transacción). Suponga lo último, y el código implementa su propia verificación de firma (similar a la abstracción de cuenta; hay un límite de gas de bloque, pero no hay un mecanismo de transferencia de tarifas, por lo que no hay precio de gas ni código de operación GASPAY). Si el blob se puede decodificar correctamente como una transacción, el código de cuenta de destino se ejecuta con los datos y la raíz del estado actual como entrada. Si la ejecución tiene éxito, los datos devueltos son la raíz del nuevo estado. ¿Cómo actualizamos el stateRoot de la cuenta del validador? No podemos actualizar la raíz del estado en BeaconState (estado de la cadena de balizas) de cada bloque de fragmentos (porque la cantidad de operaciones de la cadena de balizas está estrictamente limitada). Sin embargo, el campo de fragmentación en el estado de la cadena de balizas se actualizará con el enlace cruzado. Tome las raíces de estado actualizadas de todas las cuentas en el mismo fragmento, asumiendo que se les aplica un algoritmo hash para obtener shard_state_root (raíz de estado de fragmento). shard_state_root parece similar a crosslink_data_root ya en el diseño de la fase 1 (ambos dependen del hash del contenido del bloque de fragmento anterior). Es innegable que no cada vez que se extrae un bloque de cadena de balizas, todas las raíces de estado de fragmento se actualizan, por lo que hay algún estado local. Sin embargo, si la cuenta es global, los datos de la raíz del estado se minimizan. Esto es similar a la necesidad de transferir algunos datos de bloques de fragmentos entre validadores durante una reproducción aleatoria. Por supuesto, aquí se omiten muchos detalles. Lo que intento transmitir es que la mayoría de los requisitos para la ejecución sin estado parecen cumplirse en la fase 1. En mi opinión, el mayor problema es que aún no está claro cómo los usuarios pueden empaquetar sus blobs en la cadena (si no se soluciona este problema, la fase 1 no puede ser un motor de usabilidad puente). Tal vez este es solo el primer problema, y ​​hay otros problemas serios que he pasado por alto. ¿Qué me estoy perdiendo? ¿Cuál es la parte más difícil de permitir que los usuarios empaqueten blobs en cadena en la fase 1 (o fase 1.1, si lo prefiere)? Este modo de ejecución es más simple que la propuesta de la fase 2. Una de las razones es que la cuenta del contrato es global, al igual que la cuenta del validador. Esto significa que la cantidad de cuentas de contrato debe tener un tope, y el costo de implementar el código es tan alto (y posiblemente más bajo) que el costo de convertirse en un validador. Sin embargo, si esto nos permite llevar la ejecución a Eth2 más rápido, ¿es una compensación que podemos aceptar? Una vez que se implementa el código, el almacenamiento de contratos no se puede cambiar, por lo que también se puede decir que estamos tratando de proporcionar funciones de ejecución para la Fase 1 sin expandir el almacenamiento de contratos. Aquí hay otro caso de uso importante: rendimiento ultra alto con disponibilidad de datos (aumento de 1000 veces en el rendimiento de transacciones). Incluso con la ejecución sin estado básica, los usuarios pueden implementar llamadas de contrato entre fragmentos enviando la prueba de estado de un contrato como datos de transacción a otro contrato. Los contratos también pueden implementar su propia funcionalidad similar a un recibo (los recibos en la raíz del estado del contrato son tan verificables como los campos de recibo en los encabezados de los bloques). La experiencia del desarrollador no es muy buena, porque el acuerdo no proporcionará ninguna ayuda. Pero las propuestas existentes de la fase 2 parecen carecer de características prácticas para facilitar la interacción de contratos entre fragmentos (estos problemas se dejan a los desarrolladores de dApp, quienes deben implementar la lógica de obtener recibos de diferentes fragmentos, asegurando que los recibos no se gasten dos veces, etc.) . Por lo tanto, la ejecución sin estado básica de la fase 1 no suena mucho peor que una idea "simple" de la fase 2 en términos de experiencia del desarrollador. La ejecución sin estado subyacente también es suficiente para una vinculación bidireccional entre BETH en la cadena de balizas y ETH en la cadena principal. La mayor diferencia entre la propuesta de la Fase 2 y nuestra propuesta aquí es que el objetivo de la Fase 2 es expandir el almacenamiento del contrato. Pero el almacenamiento, y la correspondiente ejecución con estado, también parece ser la fuente de la mayor parte de la complejidad, y es lo que hace que no podamos introducir la ejecución en la Fase 1.

Tags：

TUSD