Fragmentación técnica: Exploración de vanguardia para la expansión de la Cadena de bloques

El 15 de septiembre de 2022, Ethereum completó la fusión (Merge). Este es un momento histórico, Ethereum se preparó para esto durante 5 años y se pospuso 6 veces. Debido a la depuración repetida y al desarrollo a largo plazo, así como al efecto de gran atención pública, muchas personas asumieron erróneamente que la fusión traería naturalmente mayor escalabilidad, seguridad y sostenibilidad, pero en realidad no es así. La transición de PoW( prueba de trabajo) a PoS( prueba de participación) solo cambió "los rieles y las ruedas", y no traerá directamente una mayor velocidad, mayor capacidad o tarifas más bajas. Lo que realmente puede lograr estos objetivos es un conjunto completo de soluciones: una red principal con capacidad de fragmentación combinada con soluciones Layer2 que mejoran la escalabilidad.

Como señaló el fundador de Ethereum, Vitalik Buterin, la fragmentación es una solución de escalabilidad en el dilema de escalabilidad. Al dividir los nodos de la red en grupos más pequeños, se procesan diferentes conjuntos de transacciones y se logra un procesamiento en paralelo. Es como en el supermercado, donde al abrir múltiples cajas de pago se puede reducir el tiempo de espera y mejorar la eficiencia en el pago.

Esta es la lógica de la fragmentación, directa y simple. Sin embargo, el diablo está en los detalles: el principio y la dirección son correctos, pero siempre se encuentran muchos problemas en la implementación. Este artículo tiene como objetivo ordenar la dirección y los dilemas en el camino de la "fragmentación", dibujando un mapa de exploradores de fragmentación que mira hacia las estrellas y se mantiene con los pies en la tierra. Al mismo tiempo, al comparar las soluciones de fragmentación existentes, se busca encontrar algunos problemas comunes y se propone una dirección de exploración viable: Shardeum y la fragmentación dinámica.

Uno, sobre "Fragmentación"

En términos simples, considerando las restricciones del triángulo imposible, partiendo de Ethereum como el origen del sistema de coordenadas (0,0), según dos enfoques: "vertical" y "horizontal", clasificamos los métodos de escalabilidad actuales de la cadena de bloques en dos grandes categorías:

Escalado vertical (Vertical Scaling): Se logra mejorando el rendimiento del hardware existente del sistema. Se establece una red descentralizada en la que cada nodo de la red tiene capacidad de supercomputación, es decir, cada nodo necesita un hardware "mejor". Este método es simple y efectivo, y puede lograr una mejora inicial en el rendimiento, especialmente adecuado para el comercio de alta frecuencia, juegos y otros escenarios de aplicación que son sensibles a la latencia. Sin embargo, este método de escalado limitará el nivel de descentralización de la red, ya que el costo de ejecutar nodos de validación o nodos completos aumenta. Mantener el nivel de descentralización está limitado por la velocidad de crecimiento aproximada del rendimiento del hardware de cálculo ( esto es lo que se conoce como "Ley de Moore": el número de transistores en un chip se duplica cada dos años, y el costo de cálculo se reduce a la mitad ).

Escalado Horizontal(Horizontal Scaling): El escalado horizontal generalmente tiene varias ideas. Una es, en el contexto de la Cadena de bloques, dispersar la carga de cálculo de transacciones de un ecosistema en varias cadenas de bloques independientes, cada una con su propio productor de bloques y capacidad de ejecución. Este método permite personalizar completamente la capa de ejecución de cada cadena, como los requisitos de hardware de los nodos, funciones de privacidad, costos de gas, máquinas virtuales y configuraciones de permisos, entre otros. Otra solución de escalado horizontal es la Cadena de bloques modular, que divide la infraestructura de la Cadena de bloques en capas de ejecución, capa de disponibilidad de datos (DA) y capa de consenso. El mecanismo modular más popular de Cadena de bloques es el rollup. También hay otra forma de dividir una Cadena de bloques en muchas fragmentaciones que se ejecutan en paralelo. Cada fragmentación puede considerarse como una Cadena de bloques, lo que significa que muchas Cadenas de bloques pueden ejecutarse en paralelo. Además, generalmente hay una cadena principal cuya única tarea es mantener la sincronización de todas las fragmentaciones.

Es necesario señalar que las ideas de escalabilidad anteriores no existen de forma aislada; cada una de las soluciones representa un punto de equilibrio dentro del triángulo imposible, combinado con el diseño de mecanismos de incentivos creados por las fuerzas económicas en el sistema, para lograr un equilibrio efectivo en los niveles macro y micro.

Para discutir "Fragmentación", necesitamos empezar desde el principio.

Aún supongamos una situación así, en el checkout de un supermercado, para mejorar la eficiencia del checkout y reducir el tiempo de espera de los clientes, ampliamos de un único canal de checkout a 10 ventanillas de checkout. Para evitar errores en los libros, en ese momento necesitamos establecer reglas uniformes:

Primero, si tenemos 10 cajeros, ¿cómo los asignamos a qué ventanilla trabajar?

Segundo, si tenemos 1000 clientes en fila esperando, ¿cómo decidimos a qué ventanilla va cada cliente a pagar?

Tercero, ¿cómo se deben resumir los 10 libros contables individuales correspondientes a estas 10 ventanas?

Cuarto, ¿cómo se puede evitar que el cajero cometa errores para prevenir la discrepancia en las cuentas?

Estas preguntas corresponden a varios problemas clave en la Fragmentación, que son:

¿Cómo determinar a qué fragmentación pertenecen los nodos/validadores de toda la red? Es decir: ¿cómo realizar la Fragmentación de red (Network Sharding)?

¿Cómo se determina a qué fragmentación se asigna cada transacción? Es decir: ¿cómo realizar la fragmentación de transacciones (Transaction Sharding);

¿Cómo se almacenan los datos de la Cadena de bloques en diferentes Fragmentaciones? Es decir: ¿cómo se realiza la Fragmentación de estado (State Sharding);

La complejidad implica riesgos, sobre la base de todo lo anterior, ¿cómo evitar la fragmentación de la seguridad de todo el sistema?

01 Fragmentación de red ( Network Sharding )

Si entendemos la cadena de bloques simplemente como un libro de contabilidad descentralizado, tanto el mecanismo de consenso PoS como el PoW están destinados a permitir que cada nodo compita por el derecho a llevar la contabilidad según ciertas reglas establecidas, asegurando la corrección del libro en este proceso. La fragmentación de la red se refiere a la necesidad de otra regla establecida para fragmentar la red de la cadena de bloques, donde cada fragmento maneja las transacciones en cadena y compite por el derecho a llevar la contabilidad, es decir, las reglas de agrupamiento de nodos.

Y el problema que encontramos en este proceso es que, a medida que los nodos internos de la cadena de bloques se dividen en diferentes fragmentaciones, la dificultad y el costo para los atacantes disminuirán drásticamente. Podemos inferir que, asumiendo que las reglas y resultados de este proceso de agrupamiento son fijos y predecibles, un atacante que quiera controlar toda la red de cadena de bloques solo necesita controlar de manera dirigida uno de los fragmentos, sobornando a algunos nodos dentro del fragmento.

El sistema de fragmentación debe desarrollar un mecanismo para confiar en que la red no revertirá estas transacciones desde fragmentos externos. Hasta ahora, la mejor respuesta puede ser asegurar que el número de validadores dentro de un fragmento supere un umbral mínimo, de modo que la probabilidad de que validadores deshonestos dominen un único fragmento sea baja. La forma más común es construir un cierto grado de aleatoriedad imparcial, utilizando métodos matemáticos para minimizar la probabilidad de éxito de los atacantes. Por ejemplo, Ethereum, la solución de Ethereum es seleccionar aleatoriamente a los validadores de un fragmento entre todos los validadores, y cada 6.4 minutos ( la longitud de un epoch ) se cambian los validadores.

Dicho de manera más simple, consiste en agrupar aleatoriamente los nodos y luego asignar el trabajo a cada grupo de nodos para que validen de manera independiente.

Sin embargo, es necesario señalar que la aleatoriedad en la cadena de bloques es un tema muy desafiante. Lógicamente, el proceso de generación de este número aleatorio no debería depender de los cálculos de ningún fragmento específico. En cuanto a este cálculo, muchas de las ideas de diseño existentes consisten en desarrollar una cadena de bloques separada que mantenga toda la red. Tal cadena se llama cadena Beacon en Ethereum y Near, cadena Relay en PolkaDot, y Cosmos Hub en Cosmos.

02 Transacción Fragmentación (

La fragmentación de transacciones se refiere a la formulación de reglas sobre "qué transacciones deben ser asignadas a qué fragmentos", lo que permite alcanzar el objetivo del procesamiento paralelo y evitar la aparición del problema del doble gasto. Las diferencias en el modelo de contabilidad de la cadena de bloques afectarán el desarrollo de la fragmentación de transacciones.

Actualmente existen dos tipos de mecanismos de contabilidad en la red de Cadena de bloques, que son UTXO)Unspent Transaction Outputs, el modelo de salidas de transacción no gastadas ( y el modelo de cuenta/saldo, siendo el primero un representante típico de BTC y el segundo como ETH.

Modelo UTXO: En las transacciones de BTC, cada transacción tiene una o más salidas. UTXO se refiere a las salidas de transacciones de cadena de bloques que no se han gastado y pueden ser utilizadas como entradas para nuevas transacciones, mientras que las salidas de transacciones ya gastadas no se pueden volver a gastar, similar a la situación de pago y cambio en una transacción con billetes de papel, donde el cliente entrega uno o más billetes al vendedor, y el vendedor devuelve uno o más billetes como cambio al cliente. Bajo el modelo UTXO, la fragmentación de transacciones requiere comunicación entre fragmentos. Una transacción puede incluir múltiples entradas y múltiples salidas, no existe el concepto de cuentas ni registros de saldo. Una posible forma es: procesar su valor de entrada de transacción a través de una función hash para convertirlo en un valor hash discreto que determine a qué fragmento deben ir los datos.

Para asegurar que las entradas se coloquen de manera consistente en las fragmentaciones correctas, los valores que se ingresan a la función hash deben provenir de la misma columna. Esta columna se llama Clave de Fragmentación. Luego, las transacciones que generen el valor 1 se asignan a la fragmentación 1, y las transacciones que generen el valor 2 se asignan a la fragmentación 2. Sin embargo, el inconveniente de este método es que las fragmentaciones deben comunicarse entre sí para evitar ataques de doble gasto. Limitar las transacciones entre fragmentaciones restringirá la disponibilidad de la plataforma, mientras que permitir transacciones entre fragmentaciones requerirá sopesar el costo de la comunicación entre fragmentaciones frente a las ganancias en el rendimiento que se obtienen.

Modelo de cuenta/saldo: El sistema registra el saldo de cada cuenta. Al realizar una transacción, el sistema verifica si la cuenta tiene suficiente saldo para el pago, similar a cuando un banco registra el saldo de cada cuenta durante una transferencia; solo se puede realizar la transacción si el saldo de la cuenta es mayor que el monto de la transferencia requerida. En el modelo de cuenta/saldo, dado que una transacción tiene solo una entrada, siempre que se fragmenten las transacciones según la dirección del remitente, se puede garantizar que múltiples transacciones de la misma cuenta se procesen en la misma fragmentación, lo que previene eficazmente el doble gasto. Por lo tanto, la mayoría de las cadenas de bloques que utilizan tecnología de fragmentación son sistemas de libro mayor de cuentas, como Ethereum.

![Explicación detallada de la nueva cadena de bloques Shardeum: otra posibilidad de fragmentación])https://img-cdn.gateio.im/webp-social/moments-4227a2e49f76cd01b23d7b5398e51a3c.webp(

) 03 estado de Fragmentación ###State Sharding (

El estado de fragmentación se refiere a cómo se distribuyen los datos en la cadena de bloques para almacenarse en diferentes fragmentos.

Siguiendo el ejemplo de la cola en nuestro supermercado, cada ventanilla tiene una cuenta, ¿cómo se registran sus libros de cuentas? Si: un cliente se coloca en una cola, se registra en esa cuenta, por ejemplo, si el cliente A fue a la ventanilla A, al día siguiente ese cliente fue a otra ventanilla de pago, como la ventanilla B, y la ventanilla B no tiene la información de la cuenta pasada del cliente ), como por ejemplo si se utilizó una tarjeta de valor almacenado u otros métodos de pago (, ¿qué se debe hacer? ¿Llamar a la ventanilla A para obtener la información de la cuenta de ese cliente?

El estado de la fragmentación es el mayor desafío de la fragmentación, más complicado que la fragmentación de red y la fragmentación de transacciones mencionadas anteriormente. Debido a que, bajo el mecanismo de fragmentación, las transacciones se procesan en diferentes fragmentos según la dirección asignada, es decir, el estado solo se almacenará en el fragmento correspondiente a su dirección, y un problema al que se enfrenta en este momento es que las transacciones no se realizan solo en un fragmento, a menudo involucran la fragmentación cruzada )Cross-Sharding(.

Considera un caso de transferencia, la cuenta A transfiere 10U a la cuenta B, y la dirección de A está asignada en la fragmentación 1, el registro de la transacción también se almacenará en la fragmentación 1. La dirección de B está asignada en la fragmentación 2, el registro de la transacción se almacenará en la fragmentación 2.

Una vez que A quiere transferir a B, se formará una transacción cruzada de fragmentación, y el fragmento 2 llamará a los registros de transacciones pasadas del fragmento 1 para confirmar la validez de la transacción. Si A transfiere monedas a B con frecuencia, el fragmento 2 deberá interactuar constantemente con el fragmento 1, lo que reducirá la eficiencia del procesamiento de transacciones. Sin embargo, si no se descargan y verifican la historia completa de un fragmento específico, los participantes no podrán determinar necesariamente que el estado de sus interacciones es el resultado de una cierta secuencia de bloques válidos, y que dicha secuencia de bloques es efectivamente la cadena normativa dentro del fragmento.

Por lo tanto, en comparación con una cadena única sin fragmentación, el sistema de fragmentación enfrenta el nuevo desafío de que los usuarios no pueden verificar directamente la validez y disponibilidad de ninguna cadena dada, debido a la gran cantidad de datos. Se debe proporcionar a los usuarios un método indirecto que minimice la necesidad de confianza y que sea práctico para verificar cuál cadena es completamente utilizable y válida, para que puedan determinar cuál cadena es la cadena normativa. En la práctica, los desarrolladores de cadenas de bloques pueden utilizar las siguientes técnicas para resolver algunos problemas de verificación: como comités, SNARKs/STARKs, mecanismos de pescador, así como pruebas de fraude y de disponibilidad de datos.

Hay dos enfoques para resolver este problema, uno es la sincronización entre fragmentaciones.