Visualizar el futuro de Ethereum debería ser una elección

El siguiente contenido es una adaptación del discurso del autor del 9 de abril (viernes). Muchas gracias a Danny Ryan y Sacha Saint-Leger por sus sugerencias. Este artículo trata sobre el camino hacia el futuro de Ethereum. El Ethereum de hoy es lo que los desarrolladores de eth2 llaman "eth1", que es la cadena de PoW actual que conocemos y amamos; el Ethereum de mañana no es ni eth1 ni eth2, pero... Ethereum: integrado en la actualidad Una serie de trabajos de eth2 para implementar PoS y sharding en parte superior de la capa de ejecución (eth1). Repasemos el Ethereum de hoy (eth1): la forma en que funciona la cadena eth1 hoy En el Ethereum de hoy, cuando los usuarios quieren hacer algo (es decir, "transacciones"), envían transacciones (transacciones) a los mineros, quienes luego empaquetan las transacciones en bloques y agregue esos bloques a una cadena de bloques en crecimiento (eth1). Los mineros ejecutan el mecanismo de consenso PoW para decidir quién agregará el siguiente bloque, y los mineros también ejecutan las transacciones contenidas en el bloque para garantizar que estas transacciones sean válidas. PoS reemplaza a PoW: los verificadores reemplazan a los mineros y los servidores pequeños reemplazan una gran cantidad de equipos de minería. PoW requiere una gran cantidad de dispositivos de hardware para ejecutar cálculos intensivos, lo que resulta en un consumo de energía excesivo. Aquí, no discutiremos el desperdicio de energía como la mayoría de los críticos de las criptomonedas (como "¿por qué usaríamos un sistema de pago que consume la energía de ?"), pero si pudiéramos consumir absolutamente más Si hay menos kWh (kilovatios hora) para hacer algo, entonces esto (PoW) es de hecho un desperdicio de energía, y debemos reducir el consumo de energía. Esto nos lleva a PoS, que utiliza servidores pequeños en lugar de muchos equipos de minería y validadores en lugar de mineros. En PoS, si el verificador no realiza el trabajo de verificación (paso 2 en el diagrama), el depósito se perderá apropiadamente Entonces, ¿qué es el paso 2 (es decir, verificación) en el diagrama anterior? ¿Qué es exactamente lo que el verificador está tratando de verificar? Podemos dividir las actividades de Ethereum en dos partes: Capa de consenso → "¿Cuál es el dato correcto?"; Capa de ejecución → "¿Qué significan los datos?" La capa de consenso asegura que todos estén de acuerdo con el consenso. La capa de ejecución en realidad "interpreta" los datos para darles sentido. "Datos" se refiere a cualquier interacción con la cadena de bloques, como implementar un contrato inteligente, realizar una transacción en un intercambio, enviar un pago, etc. El núcleo de la cadena de bloques es la introducción de nuevos bloques en la cadena. Cuando se agrega un nuevo bloque, habrá una transición de estado entre el estado anterior al ingreso del nuevo bloque y el estado posterior al ingreso. El estado actual de la cadena de bloques resume los datos de todos los bloques anteriores. Por ejemplo, si el estado actual mantiene un libro mayor que registra los saldos de las cuentas de Alice y Bob, y un nuevo bloque contiene una transacción en la que Bob le paga a Alice 10 monedas, entonces el nuevo bloque se agrega a la cadena de bloques. , el estado registrará el nuevo información de saldo. Después de agregar un nuevo bloque, cambiará el estado actual (por ejemplo, actualizará el saldo de Alice y Bob) o creará un nuevo estado (como implementar un contrato inteligente o agregar a Carol al libro mayor...) . BTC superó la marca de los $17 600 y cayó un 1,52 % en el día: los datos de Huobi Global muestran que BTC ha subido a corto plazo, superando la marca de los $17 600, y ahora cotiza a $17 600,26, con una caída intradiaria del 1,52 %. fluctúa mucho, así que por favor haga un buen trabajo en el control de riesgos. [2020/11/19 21:17:27] De acuerdo con el plan de Ethereum, el primer paso es desvincular el consenso de la ejecución; el segundo paso es reemplazar el consenso de PoW con el consenso de PoS. De acuerdo con nuestro plan, el trabajo general de Rollups y eth2 El punto principal es tratar con el primer paso en la figura anterior, es decir, desacoplar el consenso y la ejecución (descorrelacionar el consenso y la ejecución). Entonces, ¿cómo va esto? ¡El paso 1 está hecho! Desde diciembre de 2020, hemos tenido dos cadenas de bloques ejecutándose en paralelo (ver arriba): la superior es la cadena de consenso PoS (es decir, la cadena de baliza) y la inferior es la cadena confiable de ejecución de consenso PoW (es decir, la cadena eth1). Estos dos las cadenas se ejecutan en paralelo, pero se "comunicarán" entre sí, por supuesto, actualmente unidireccional... ¿Cómo convertirse en un validador? Para convertirse en un verificador de la cadena de consenso PoS (es decir, la cadena de baliza), los usuarios deben bloquear 32 ETH en el contrato de depósito implementado en la cadena de ejecución + consenso PoW (es decir, eth1), y el depósito se transferirá automáticamente al Cadena de consenso PoS. Una vez que se activa el validador, puede comenzar a validar (en la cadena de consenso PoS) y ganar recompensas. Después de la fusión, la cadena de balizas (púrpura) es la cadena de consenso, y la cadena eth1 (roja) cambiada al consenso de PoS servirá como cadena de ejecución. ¿Cuándo se logrará la fusión? Posiblemente en 2021... no espere que esta "comunicación" unidireccional dure mucho. La fusión de estas dos cadenas cerrará de forma permanente la brecha entre la cadena de consenso de PoS (cadena de baliza) y la cadena de ejecución de consenso de PoW (eth1), lo que permitirá que el verificador sea la capa de ejecución (es decir, cambiar a la cadena eth1 del PoS). consenso después de la fusión) Generar bloques. Por lo tanto, después de la fusión, tendremos dos cadenas: la misma cadena de consenso de PoS (es decir, la cadena de baliza) y la cadena de ejecución basada en PoS (es decir, la cadena eth1 cambió a consenso de PoS). Cadena de consenso de PoS (cadena de balizas) Los validadores finalmente podrán canjear y retirar sus recompensas y depósitos, y enviarlos de regreso a la cadena de ejecución de PoS (eth1). ¡Todo esto nos lleva de un entorno PoW a un entorno PoS completamente calificado! Pero debe tenerse en cuenta que en este momento, el ancho de banda de esta cadena no aumenta; este es el objetivo de la fragmentación. Antes de eso, cuando todavía tenemos solo una cadena de ejecución (es decir, la cadena eth1), analicemos cómo expandir la ejecución de otras formas. Plan de expansión: 1. Transferir la ejecución fuera de la cadena 2. Enviar datos a la cadena. Los paquetes acumulativos son una de las muchas soluciones de escala disponibles, pero desde el punto de vista del diseño del protocolo, probablemente proporcione el mejor compromiso. El concepto de Rollups es simple: al enviar los datos necesarios para reconstruir la ejecución de la transición de estado en la cadena, la transición de estado se procesa integralmente y la ejecución se transfiere fuera de la cadena. Si alguien no está de acuerdo con los resultados de la ejecución, o si alguien se olvida de ejecutarla en primer lugar, los datos están ahí para que todos los procesen. ¡Los paquetes acumulativos no requieren licencia! Más precisamente, en Rollups, los datos necesarios para la ejecución (entrada de transacción) se separan de su portador (transacción) y estos datos se "agrupan" de manera eficiente en el espacio. Al mismo tiempo, los Rollups se ejecutan fuera de la cadena de ejecución (es decir, la cadena eth1), envían datos y los ejecutan. Vea la imagen a continuación: ahora se está produciendo la expansión de la cadena eth1, se han implementado paquetes acumulativos y también se están desarrollando otras soluciones de expansión. Los usuarios que desean "usar una cadena de resumen" deben almacenar algunos activos en el contrato de resumen en la cadena de ejecución (eth1), y luego el usuario puede hacer algunas cosas en el resumen, como usar sus propios activos con el resumen Otros activos en la cadena Rollup se negocian. Una vez que el usuario ha hecho lo que quiere hacer, el activo puede retirarse del Rollup a la cadena de ejecución. ¡Eso es! ¿Qué otras alternativas existen a los Rollups? ¿Qué pasaría si en lugar de estas cadenas de Rollps ejecutándose en paralelo (cadenas amarillas en el diagrama anterior), tuviéramos muchas cadenas de ejecución ejecutándose en paralelo (cadenas rojas en el diagrama anterior)? Por ejemplo, ¿qué sucede si la cadena eth1 se "replicó" y se ejecutó en paralelo con varias otras cadenas replicadas? El problema aquí es cómo tratamos con varias cadenas de ejecución que se ejecutan en paralelo. ¿Qué sucede si una cadena de ejecución quiere saber qué sucedió en otra cadena de ejecución? Este es exactamente el problema complicado que encuentra la fragmentación (nota: también el llamado problema de comunicación entre fragmentos). Podrías decir, "¡Los paquetes acumulativos casi tienen el mismo problema!", y lo tienen. Cuando desee interactuar con otra cadena de resumen en una cadena de resumen, también surgirá el mismo problema espinoso (es decir, un problema de comunicación de resumen cruzado). Pero el punto es que actualmente existen varios diseños de resumen, y el espacio de solución para este problema es grande y en gran parte inexplorado. Entonces, ¿por qué no comenzar a experimentar con Rollups antes de incorporar algo en la capa de protocolo? Esto nos lleva a la hoja de ruta de Ethereum centrada en Rollup. Eth2 centrado en rollup: uso de fragmentos para guardar datos publicados por rollups Ha oído hablar de la escasez de espacio en bloques, ¿verdad? ¡Los rollups necesitan publicar datos y el espacio del bloque eth1 es escaso! Y como se mencionó anteriormente, la fragmentación cruzada es difícil. Entonces, ¿por qué no usar fragmentos para almacenar los datos que los informes acumulativos necesitan publicar? Con 64 cadenas de fragmentos, esto puede brindar 64 veces más ancho de banda que el disponible actualmente, y posiblemente más, porque un bloque de fragmentos probablemente contenga más datos que el bloque eth1 actual. Debe enfatizarse que esto no significa que las funciones de ejecución en la capa de fragmentos estén permanentemente excluidas. La hoja de ruta actual de Ethereum centrada en Rollup es una forma de avanzar a corto y mediano plazo hasta que (por ejemplo) se encuentren mejores primitivas criptográficas para garantizar que la ejecución se divida correctamente en varias cadenas (nota: es decir, implementar la fragmentación ejecutable). Todo es muy encantador y debería mantener a muchas personas ocupadas durante mucho tiempo. Mientras tanto, los Rollups son el camino a seguir. Cada cadena de Rollup es su propio "entorno de ejecución": ¿cómo moverse fácilmente hacia/desde Rollups? ¿Podemos realizar operaciones de Cross-Rollup? ¿Cómo deben manejar los paquetes acumulativos la congestión? ¡Todavía hay mucho trabajo por hacer en esta área! Primero, no olvidemos que fusionar y fragmentar son trabajos complejos, con varios equipos trabajando actualmente en uno o ambos. E incluso con Rollups, todavía hay algunas preguntas muy interesantes para explorar, y estas son solo algunas de ellas: Cómo migrar usuarios hacia y desde Rollups en cadena a escala es un concepto genial. Si tiene suficiente transporte público para llegar entre la Capa 1 (eth1) y la Capa 2 (Rollps), ¿por qué tiene que conducir de un lado a otro? ¿Cuál es el mecanismo económico en él? ¿Qué haces si quieres hacer algo en una cadena de resumen adyacente porque ese resumen tiene algunas cosas geniales que no están en el resumen en el que estás? ¿Tiene que retirarse del Resumen actual a la Capa 1 y luego transferir de la Capa 1 al Resumen adyacente? Esto parece bastante antieconómico. Los rollups son un gran impulso de ancho de banda para las operaciones en cadena actuales, no hay duda al respecto. Sin embargo, Rollups no es la autopista infinita que esperan los usuarios. En Rollups, todavía habrá mucha gente queriendo hacer muchas cosas, ¡a veces al mismo tiempo! Por lo tanto, los Rollups lidiarán inherentemente con la congestión, pero a diferencia del mercado de congestión protegido por los protocolos de Capa 1 (EIP-1559 se implementará pronto), los Rollups tienen un espacio de diseño más grande para explorar. Hablando de problemas de congestión, esto es más específico del protocolo, pero también veremos que EIP-1559 actúa como policía de tránsito para regular la cantidad de datos publicados en cada fragmento para garantizar que los validadores puedan manejar esta cantidad. Si cree que el mecanismo EIP-1559 es genial en una cadena (eth1), será aún más genial cuando haya 64 cadenas de fragmentos que ejecuten el mecanismo simultáneamente. Entonces, ¿dónde deberían los Rollups publicar sus datos? ¿Los datos solo se publican en un solo fragmento, de modo que los datos solo se pueden obtener en este fragmento? ¿O se publica en varios fragmentos para beneficiarse del intercalado de fragmentos planificado? Entre ellos, el escalonamiento de shards es una idea propuesta recientemente por Vitalik, es decir, todos los shards se turnan para generar bloques, de modo que cuando los proyectos de Capa 2 (como los Rollups) publican datos, el intervalo de tiempo de un nuevo bloque no excederá varios cientos. Milisegundos, que es ideal para aplicaciones que requieren una finalización rápida, consulta ?.

Tags：

OKB