El espacio de las cadenas de bloques (blockchain) se esta moviendo progresivamente a un arquitectura de ejecucion modular para alcanzar verdadera escalabilidad. Incluso cadenas como Ethereum, las cuales previamente fueron totalmente monoliticas, estan transicionando a un diseno modular para superar los obstaculos de las cadenas de bloques monoliticas.
Uno de los componentes centrales de la pila de blockchain modular es la capa de ejecución. Fuel está construyendo la capa de ejecución más rápida para la pila de blockchain modular.
¿Qué es una capa de ejecución modular? ¿Y cómo permitiran sistemas blockchain más escalables?
Las capas de ejecucion modular ofrecen 2 principales beneficios sobre las monoliticas:
Las cadenas monolíticas combinan el cómputo y la verificación en la misma capa, lo que genera una seguridad inferior a la media y una escalabilidad limitada. Las capas de ejecución modulares evitan esto al desacoplar el cómputo y la verificación, lo que permite garantías de seguridad mucho más sólidas a escala.
Las cadenas monolíticas están atrapadas en tecnologías ineficientes cuando se trata de la velocidad y la variedad de computación que pueden soportar. Por otro lado, las capas de ejecución modular se pueden diseñar específicamente para optimizar el cálculo eficiente.
Esta publicación profundiza en el beneficio principal, y el segundo se explora en una próxima Parte 2.
Para comprender las innovaciones que provienen de las capas de ejecución modular (MEL en ingles), primero debemos comprender cómo las cadenas de bloques monolíticas manejan el cálculo y la verificación.
Las cadenas de bloques se basan en una red de entidades que ejecutan transacciones y las agrupan en un bloque; estos se conocen como productores de bloques. Sin controles y equilibrios, un productor de bloques malicioso podría incluir transacciones no válidas en un bloque (por ejemplo, crear tokens a su propia dirección). Para evitar esto, las cadenas de bloques se basan en una red de otros nodos para determinar la validez de un bloque antes de agregarlo a su versión de la cadena.
Esto nos conduce a dos funciones básicas necesarias para que funcione una cadena de bloques:
Producción de bloques (computación): ejecución de transacciones y aplicación de transiciones de estado individuales para construir un bloque.
Validación de bloque (verificación): confirmación de que las transiciones de estado son válidas.
NOTA: Para facilitar la comprensión, esta sección proporciona una explicación simplificada de cómo funcionan la producción y verificación de bloques en cadenas de bloques monolíticas. En realidad, el proceso es más complejo y puede diferir según el diseño de la cadena específica. Sin embargo, se aplican muchos de los mismos principios básicos.
En la mayoría de los diseños de cadenas de bloques monolíticas, el cálculo y la verificación los realizan las mismas entidades - validadores (es decir, nodos completos). Cuando un usuario envía una transacción, un validador ejecutará la transacción y luego incluirá la transición de estado correspondiente en un bloque. Una vez que se crea y propaga un bloque, otros nodos completos descargan el bloque y vuelven a ejecutar las transacciones en el bloque para confirmar que es válido. Si el bloque es válido, suponiendo que sean honestos, los nodos completos agregan ese bloque a su versión de la cadena, dando autenticando su validez.
Esto se llama la suposición de la mayoría honesta y es la razón por la que la mayoría de las cadenas de bloques monolíticas son vulnerables a los ataques del 51 %. Bajo el modelo monolítico, debido a que se requiere una mayoría honesta de nodos completos para verificar que la cadena de bloques es válida, los clientes ligeros se ven obligados a confiar en la mayoría. Si más de la mitad de los nodos completos son deshonestos, los clientes ligeros no tienen forma de saberlo, por lo que terminarán siguiendo una cadena no válida.
La escalabilidad de las cadenas monolíticas está severamente limitada por su confianza en esta suposición mayoritaria honesta. Esto se debe a que, para aumentar el rendimiento de las transacciones, se debe aumentar el tamaño y/o la frecuencia del bloque para permitir que se procesen más transacciones en la misma cantidad de tiempo. Esto aumenta los requisitos de recursos (y los costos asociados) para los nodos completos; bloques más grandes/más rápidos = más computación = costos más altos.
A medida que aumenta el costo de ejecutar un nodo completo, más entidades optarán por ejecutar un cliente ligero, confiando en una red cada vez más pequeña de nodos completos para verificar la validez de la cadena. Esta creciente centralización de la validación de bloques es una gran amenaza para la seguridad de las cadenas monolíticas, ya que un grupo de validadores más centralizado es más vulnerable a los ataques y también más fácil de coludir.
La buena noticia es que los sistemas de cadena de bloques pueden alejarse de los diseños que se basan en una suposición mayoritaria honesta. Para evitar este escollo del diseño monolítico, la pila de blockchain modular desacopla el computo de la verificación. Al mover la ejecución (es decir, el cálculo) fuera de la cadena base (a menudo denominada "cadena principal"), se puede lograr una mayor escala sin comprometer la descentralización.
Dentro de la pila de blockchain modular, la capa de ejecución es responsable del cálculo, en otras palabras, procesar transacciones y aplicar transiciones de estado individuales.
Fuel define una capa de ejecución modular como: un sistema de computación verificable diseñado para la pila de blockchain modular. Más concretamente, una cadena de bloques comprobable de fraude o validez (u otro sistema de computación) que aprovecha una cadena de bloques modular para la disponibilidad de datos.
Para aclarar aún más, los sistemas de computación no son capas de ejecución modulares si: 1) no son comprobables de fraude o validez, o 2) no descargan la disponibilidad de datos a otra capa.
Al igual que las cadenas de bloques monolíticas, las capas de ejecución modular emplean una red de productores de bloques dedicados. Estas entidades manejan el proceso intensivo en recursos de ejecutar transacciones y producir bloques. Sin embargo, a diferencia de los sistemas monolíticos, la verificación no se maneja en la capa de ejecución, sino en los niveles inferiores de la pila de blockchain modular.
La genialidad de la ejecución modular es que mientras la verificación (es decir, la validación de bloques) esté descentralizada, la computación (es decir, la producción de bloques) no necesita estar descentralizada. Los tamaños de los bloques se pueden aumentar, lo que lleva a la centralización de los nodos que producen los bloques, pero mientras la verificación esté desacoplada, los bloques no válidos no se agregarán a la cadena.
Pero, cómo funciona esto? Cómo podemos garantizar que se mantenga la seguridad si permitimos que la producción de bloques permanezca centralizada? Aquí es donde entra en juego la modularidad.
Las capas de ejecución modulares (MEL) abstraen la función intensiva de recursos de la ejecución a poderosos productores de bloques que agrupan y ejecutan lotes de transacciones, y los publican periódicamente como bloques en la cadena principal (capas de verificacion/consenso/disponibilidad de datos). Para mantener la honestidad de estos productores de bloques, hay nodos completos adicionales que no producen bloques (a menudo denominados "verificadores" o "probadores") que descargan y vuelven a ejecutar los bloques publicados en la cadena principal para garantizar que contengan solo transacciones válidas.
Los detalles de cómo estos nodos completos comunican la validez o invalidez de las transacciones difieren dependiendo de si la capa de ejecución modular emplea un modelo optimista o ZK (zero-knowledge). En el caso de las capas de ejecucion modulares (MEL) optimistas, los nodos completos solo actúan (a través de pruebas de fraude) cuando detectan una transacción no válida. Por el contrario, en el caso de MEL de ZK, los nodos completos atestiguan activamente la validez de las transacciones (a través de pruebas de validez). En cualquier caso, la validez o invalidez de todas las transacciones proporcionadas por el productor de bloques se certifica en la cadena principal, no en la capa de ejecución modular.
Para proporcionar una ilustración más profunda, exploremos el caso de MEL optimistas (bajo el cual se supone que todas las transacciones son válidas a menos que se demuestre lo contrario). Si incluso un solo nodo completo en la capa de ejecución modular detecta una transacción no válida dentro de un bloque publicado en la cadena principal, puede generar una prueba de fraude (dentro de una "ventana de resolución de disputas" predefinida) que prueba criptográficamente que la transacción no es válida.
Dependiendo de la estructura de la pila modular particular, esto se puede tratar de varias maneras, por ejemplo:
En pilas modulares con capa de verificaion:
El nodo completo envía la prueba de fraude a un contrato de resolución de disputas dedicado en la capa de verificacion, que vuelve a ejecutar la transacción directamente (tenga en cuenta que esto requiere que las transacciones de MEL estén estructuradas de una manera que las haga comprobables de fraude en la máquina virtual de la capa de verificacion). de manera determinista; por ejemplo, FuelVM está diseñado para que sea comprobable contra el fraude dentro de EVM(Maquina Virtual de Ethereum) para permitir la liquidación en Ethereum).
Si la transacción no es válida, el productor del bloque infractor es castigado mediante una penalidad (es decir, pierde fondos), el "denunciante" es recompensado con una parte de estos fondos y el estado de la cadena se revierte al estado anterior a la transacción no válida. Debido a que no hay garantía de que cualquier transacción posterior a la no válida corresponda a un estado válido, estas transacciones posteriores se vuelven a ejecutar.
El nodo completo se comunica sobre la prueba de fraude a través de una red peer-to-peer para advertir a los clientes ligeros que el bloque contiene una transacción no válida. Usando la prueba de fraude como evidencia del comportamiento deshonesto del productor del bloque, los nodos completos pueden proponer una transacción de penalización en la cadena principal, lo que reduce drásticamente los fondos del productor del bloque.
Debido a que no hay una capa de verificacion para dictar la versión "canónica" de la cadena, los nodos completos maliciosos teóricamente podrían optar por no rechazar el bloque; sin embargo, la prueba de fraude ya se ha comunicado a los clientes ligeros, por lo que saben que no deben seguir la versión de la cadena de un nodo completo malicioso. Como resultado, el consenso social garantiza que el bloque inválido será rechazado.
En cualquier caso, debido a que el proceso de verificación está consagrado en la cadena principal en lugar de la capa de ejecución, la seguridad se subcontrata a la cadena principal, lo que significa que la capa de ejecución por sí sola puede operar con garantías de seguridad más bajas. Incluso si el 99% de los nodos completos en la capa de ejecución son deshonestos, solo se necesita un nodo completo honesto para garantizar que la capa de ejecución solo incluya transacciones válidas.
Esto significa que, en lugar de depender de una mayoría honesta de nodos completos, las capas de ejecución modulares (y los clientes ligeros MEL) pueden operar con una sola suposición de minoría honesta.
Mientras que un bloque inválido solo puede ser revertido por la mayoría de los nodos completos en un sistema monolítico, un único nodo completo en un sistema modular puede forzar la reversión de una transacción inválida mediante el uso de pruebas de fraude/validez.
Permitir que el cálculo se realice fuera de la cadena principal permite aumentos masivos en el rendimiento de las transacciones. El tamaño del bloque se puede aumentar significativamente sin preocuparse por la centralización de la producción de bloques, ya que el proceso de validación de bloques por separado mantiene a los productores de bloques honestos.
Si bien los bloques más grandes imponen una mayor carga sobre los nodos completos que realizan la validación, la suposición de la minoría honesta significa que la centralización en esta área es una amenaza menor, ya que las vulnerabilidades basadas en la centralización que dependen de una mayoría deshonesta se vuelven imposibles.
Los clientes ligeros también pueden ejecutarse con garantías de seguridad significativamente más altas bajo una arquitectura modular, ya que las pruebas de fraude les permiten identificar transacciones no válidas basadas en una prueba de un único nodo completo honesto (a diferencia de los sistemas monolíticos, que requieren que los clientes ligeros confíen en que al menos la mitad de los nodos completos son honestos).
Además, los productores de bloques son conscientes de que se detectará cualquier actividad maliciosa y resultará en una reducción, por lo que es menos probable que incluso intenten comportarse de manera deshonesta. Como tal, la capa de ejecución se puede optimizar para computación (es decir, manejar una gran cantidad de transacciones) mientras se basa en niveles inferiores optimizados para la seguridad de la pila modular.
Esta arquitectura modular presenta algunos desafíos técnicos y de teoría de juegos adicionales.
Si bien las pruebas de fraude/validez permiten que los nodos completos honestos demuestren el fraude, existe un problema adicional: la disponibilidad de datos. Para generar pruebas, los nodos completos dependen de la disponibilidad del bloque, ya que necesitan descargar y volver a ejecutar todas las transacciones en un bloque para determinar su validez y generar una prueba.
En teoría, un productor de bloques malicioso podría publicar solo encabezados de bloque en la cadena principal, lo que podría retener algunos o todos los datos correspondientes. Esto evita que los nodos completos puedan generar pruebas de fraude/validez para alertar a los clientes ligeros sobre el problema.
Al intentar validar un bloque, es trivial que los nodos completos identifiquen cuándo un productor de bloques malicioso ha retenido los datos. En este caso, simplemente pueden asumir que la cadena no es válida y separarse de ella. Pero, ¿cómo pueden los clientes ligeros determinar si un productor de bloques ha retenido los datos sin descargar el bloque completo?
Una nueva tecnología llamada muestreo de disponibilidad de datos (DAS) permite a los clientes ligeros determinar de forma probabilística si se ha publicado la totalidad de un bloque. En resumen, los clientes ligeros solicitan pequeñas porciones aleatorias (o "muestras") del bloque de nodos completos.
Una nueva tecnología llamada muestreo de disponibilidad de datos (DAS) permite a los clientes ligeros determinar de forma probabilística si se ha publicado la totalidad de un bloque. En resumen, los clientes ligeros solicitan pequeñas porciones aleatorias (o "muestras") del bloque de nodos completos.
Si todas las muestras solicitadas están disponibles, suponiendo que haya suficientes clientes ligeros que realicen el muestreo de disponibilidad de datos, esto prueba probabilísticamente que todo el bloque está disponible. Si alguna parte del bloque no está disponible, los clientes ligeros saben que se han retenido los datos y, por lo tanto, pueden separarse de esa versión de la cadena.
Una explicación completa de esta tecnología está fuera del alcance de esta publicación, pero puede leer más al respecto aquí. En última instancia, la conclusión importante es que DAS permite a los clientes ligeros identificar bloques no válidos incluso cuando un productor de bloques malicioso retiene datos.
Otro problema potencial es el fenómeno denominado “dilema del verificador”. La versión simplificada es la siguiente:
Si los productores de bloques saben que los nodos completos identificarán actividades deshonestas, se comportarán con honestidad para evitar ser penalizados.
Con el tiempo, si los nodos completos asumen que los productores de bloques seguirán comportándose con honestidad, no tendrán ningún incentivo para seguir validando bloques, ya que nunca recibirán una recompensa por identificar una transacción no válida.
Si los nodos completos no reciben incentivos financieros para continuar validando bloques, es posible que dejen de hacerlo. En este punto, se vuelve viable que los productores de bloques se comporten de manera deshonesta. Incluso si todavía hay una cantidad distinta de cero de nodos completos, puede ser financieramente viable para el productor del bloque sobornar a los nodos completos restantes para que ignoren una transacción no válida suficientemente valiosa.
Esto termina en un acertijo circular por el cual cuanto más segura se vuelve una capa de ejecución modular (es decir, menos incentivo hay para que un productor de bloques se comporte de manera deshonesta), más tiende hacia una menor seguridad (es decir, los nodos completos ya no tienen incentivos para validar bloques) . Por otro lado, cuanto menos seguro es, más tiende hacia una mayor seguridad.
Este dilema se puede mitigar a través de una serie de vías (para un análisis de teoría de juegos de estos factores, consulte esta extensa publicación):
Altruismo: debido a que los MEL solo requieren un único validador honesto, siempre que haya al menos un nodo completo altruista en funcionamiento, el sistema permanece seguro. Sin embargo, si bien esto puede ser lo suficientemente seguro en la práctica, no es una garantía suficiente para un sistema que controla una gran cantidad de activos.
Interés económico: hay muchas entidades que tienen incentivos financieros para ejecutar nodos completos que van más allá de la recompensa potencial del denunciante. Por ejemplo, productos y servicios como exploradores de bloques, proveedores de liquidez o dapps necesitan acceder al estado completo de la MEL para administrar su negocio de manera efectiva. Sin embargo, estas entidades son (en teoría) susceptibles de ser sobornadas por un productor de bloques malicioso.
Ballenas: las entidades con una gran cantidad de activos en una MEL pueden optar por ejecutar un nodo completo para garantizar que sus intereses estén protegidos y que la cadena sea segura.
Retiros rápidos: debido a que las MEL optimistas se basan en una ventana de resolución de disputas antes de garantizar la finalidad en las capas inferiores de la pila modular, las extracciones de la MEL a la capa de liquidación no se finalizan hasta que haya transcurrido esta ventana. Como tal, existe un mercado para servicios de terceros que ofrecen retiros rápidos, aceptan tokens en la MEL y envían instantáneamente los mismos tokens (menos una tarifa) al usuario en la capa de liquidación. Para garantizar que el estado de MEL no se revierta después de haber enviado fondos en la capa de liquidación, se incentiva al proveedor de servicios a verificar la validez de la cadena antes de realizar dicha transacción.
Productores de bloques: es posible introducir una penalización para los productores de bloques que envían bloques que se construyen sobre bloques no válidos anteriores. Con tal mecanismo implementado, los productores de bloques estarían incentivados a verificar la validez de la cadena antes de enviar un bloque.
Si bien las estrategias de mitigación anteriores pueden no ser completamente efectivas por sí solas, cuando se combinan, existe un claro incentivo para que varias partes diferentes continúen ejecutando nodos completos en la capa de ejecucion modular (MEL) y validando el estado de la cadena.
Al adoptar un diseño que permite una alta seguridad bajo una sola suposición honesta de la minoría, la pila de cadenas de bloques modulares permite el desarrollo de cadenas de bloques de mucho mayor rendimiento de lo que ha sido posible anteriormente con diseños monolíticos.
Sin embargo, junto con los beneficios de escalabilidad que se derivan de separar el cálculo de la verificación, se pueden lograr avances adicionales en la escalabilidad centrándose específicamente en el diseño de la parte superior de la pila: la capa de ejecución modular. Hacer que la computación sea más escalable y eficiente en esta capa es el siguiente paso para construir mejores cadenas de bloques.
La mayoría de las capas de ejecución modulares actualmente en desarrollo utilizan Ethereum como su cadena principal, por lo que se utiliza de forma predeterminada EVM como entorno de ejecución. Este es el diseño equivalente a mejorar la eficiencia energética de un motor de combustión interna: una mejora incremental en una tecnología ya obsoleta.
En realidad, la pila modular abre un espacio de diseño mucho más amplio, eliminando la necesidad de que las capas de ejecución modulares dependan de la EVM ineficiente. Fuel está aprovechando este espacio de diseño recientemente ampliado para construir una capa de ejecución modular que va más allá de EVM, optimizando para un cómputo eficiente y escalable, una experiencia de desarrollador superior y máxima seguridad.
En la Parte 2, exploraremos las formas en que las capas de ejecución modular pueden trascender las limitaciones tecnológicas de la generación anterior de diseño de blockchain para lograr una verdadera escalabilidad.
Fuel es la capa de ejecución más rápida para la pila de blockchain modular. Potente y elegante, la tecnología permite la ejecución de transacciones en paralelo, lo que permite a los desarrolladores obtener el mayor rendimiento flexible y la máxima seguridad necesarios para escalar. Los desarrolladores eligen FuelVM por su experiencia de desarrollador superior y la capacidad de ir más allá de las limitaciones de EVM.
Este Articulo ha sido traducido por @Slowly_rich. Sigueme en Twitter!