Fragmentación: otra posibilidad de escalabilidad 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 pospuso 6 veces. Debido al desarrollo a largo plazo y la amplia atención, muchas personas asumieron erróneamente que la fusión traería naturalmente una mayor escalabilidad, seguridad y sostenibilidad, pero en realidad no es así. La transición de Prueba de trabajo (PoW) a Prueba de participación (PoS) solo cambia "las vías y las ruedas", y no traerá directamente una mayor velocidad, mayor capacidad o menores tarifas. 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 la escalabilidad. Al dividir los nodos de la red en grupos más pequeños, se pueden procesar diferentes conjuntos de transacciones y lograr el procesamiento en paralelo. Es como en Walmart, donde al abrir varias cajas de pago se puede reducir visualmente el tiempo de espera y aumentar la eficiencia en el proceso de 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 no son incorrectos, pero siempre se encuentran muchos problemas en la implementación. Este artículo pretende aclarar la dirección y los dilemas en el camino de la "fragmentación", dibujando un mapa de explorador de fragmentación que mira las estrellas y está enraizado en la realidad. Al mismo tiempo, a través de la comparación de las soluciones de fragmentación existentes, se encuentran algunos problemas comunes y se propone una dirección de exploración viable: Shardeum y 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 las dos ideas de "vertical" y "horizontal", clasificamos los métodos de escalabilidad actuales de la cadena de bloques en dos grandes categorías:

Escalado vertical (: se logra mejorando el rendimiento del hardware existente del sistema. Establecer una red descentralizada donde cada nodo en la red tenga 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 otras aplicaciones que son sensibles a la latencia. Sin embargo, este método de escalado limita el nivel de descentralización de la red, ya que el costo de operar nodos de validación o nodos completos ha aumentado. Mantener el nivel de descentralización está limitado por la velocidad aproximada de crecimiento del rendimiento del hardware de cálculo ) lo que se conoce como "Ley de Moore": el número de transistores en un chip se duplicará cada dos años, y el costo de cálculo se reducirá a la mitad (.

Escalamiento Horizontal ): El escalamiento horizontal generalmente tiene varias ideas. Una de ellas es, en el contexto de la cadena de bloques, dispersar la carga de cálculo de transacciones en un ecosistema a múltiples cadenas de bloques independientes, donde cada cadena tiene sus propios productores de bloques y capacidad de ejecución. Este enfoque permite personalizar completamente la capa de ejecución de cada cadena, como los requisitos de hardware de los nodos, funciones de privacidad, tarifas de gas, máquinas virtuales y configuraciones de permisos. Otra solución de escalamiento horizontal es la cadena de bloques modular, que divide la infraestructura de la cadena de bloques en capas de ejecución, capas de disponibilidad de datos (DA) y capas de consenso. El mecanismo modular de cadena de bloques más común es rollup. También hay otra forma de dividir una cadena de bloques en muchos fragmentos, ejecutándose en paralelo. Cada fragmento puede considerarse como una cadena de bloques, lo que significa que muchas cadenas de bloques pueden ejecutarse en paralelo. Además, suele haber una cadena principal, cuya única tarea es mantener todas las fragmentaciones sincronizadas.

Es importante señalar que las ideas de escalabilidad mencionadas anteriormente no existen de manera aislada; cada solución representa un punto de equilibrio encontrado dentro del triángulo imposible, combinada con el diseño de mecanismos de incentivos creados por las fuerzas económicas en el sistema, logrando un equilibrio efectivo a nivel macro y micro.

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

Aún suponiendo un escenario así, en el checkout de Walmart, para mejorar la eficiencia de pago y reducir el tiempo de espera del cliente, hemos pasado de un único canal de pago a 10 ventanillas de pago. Para evitar errores en la contabilidad, en este 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 debe ir cada cliente a pagar?

Tercero, ¿cómo se debe realizar la consolidación de estos 10 libros de contabilidad individuales correspondientes a las 10 ventanas?

Cuarto, ¿cómo se puede prevenir que los cajeros cometan errores para evitar que ocurran desajustes en las cuentas?

Estas preguntas corresponden en realidad 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 determinar a qué fragmento 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 del estado (State Sharding);

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

( 01 Fragmentación de red ) Network Sharding ###

Si entendemos la cadena de bloques como un libro de contabilidad descentralizado, ya sea el mecanismo de consenso PoS o PoW, ambos son para permitir que los nodos compitan por el derecho de llevar la contabilidad según ciertas reglas establecidas, garantizando la corrección del libro de contabilidad en este proceso. La fragmentación de la red se refiere a la necesidad de otra regla establecida para fragmentar la red de cadena de bloques, donde cada fragmento maneja las transacciones en la cadena, compitiendo por el derecho de llevar la contabilidad, es decir, la regla de agrupación de nodos.

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

El fundador de Near, Alexander Skidanov, describió este problema de la siguiente manera: si una cadena única con X validadores decide bifurcarse en una cadena de fragmentación y divide los X validadores en 10 fragmentos, ahora cada fragmento tiene solo X/10 validadores, destruir un fragmento solo requiere destruir el 5.1%(51% / 10) del total de validadores. Esto plantea el segundo punto: ¿quién elige a los validadores para cada fragmento? Solo cuando todos estos 5.1% de validadores están en el mismo fragmento, controlar el 5.1% de los validadores es perjudicial. Si los validadores no pueden elegir en qué fragmento validar, es muy poco probable que los participantes que controlan el 5.1% de los validadores coloquen a todos los validadores en el mismo fragmento, lo que reduce significativamente su capacidad para destruir el sistema.

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 sea mayor que un umbral mínimo, de modo que la probabilidad de que validadores deshonestos abrumen un solo fragmento sea muy baja. La forma más común es construir un cierto grado de aleatoriedad imparcial, confiando en métodos matemáticos para reducir al mínimo la probabilidad de éxito de los atacantes. Por ejemplo, Ethereum, la solución de Ethereum es seleccionar aleatoriamente a los validadores de un fragmento de entre todos los validadores, y cada 6.4 minutos ( la longitud de un epoch ) se reemplazan los validadores.

En pocas palabras, se trata de agrupar nodos aleatoriamente y luego asignar el trabajo a cada grupo de nodos para que verifiquen de manera independiente.

Sin embargo, es importante 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. Para este cálculo, muchas de las ideas de diseño existentes son 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 se asignarán a qué fragmentos", lo que puede lograr el objetivo de procesamiento en paralelo y evitar la aparición del problema del doble gasto. Las diferentes modelos de libro mayor de la cadena de bloques afectarán el desarrollo de la fragmentación de transacciones.

Actualmente existen dos tipos de métodos de contabilidad en la red de cadena de bloques, que son el modelo de UTXO### (salidas de transacción no gastadas) y el modelo de cuenta/saldo. El primero es representado típicamente por BTC, mientras que el segundo es como ETH.

Modelo UTXO: En las transacciones de BTC, cada transacción tiene una o más salidas, UTXO se refiere a la salida de una transacción de cadena de bloques que no ha sido gastada y puede ser utilizada como entrada para nuevas transacciones, mientras que las salidas de transacción que ya han sido gastadas no pueden ser utilizadas nuevamente, similar a los pagos y el cambio en transacciones de billetes, donde el cliente entrega uno o más billetes al comerciante, y el comerciante le devuelve uno o más billetes como cambio. 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 se registran saldos. Una forma posible es: colocar su valor de entrada de transacción en una función hash para procesarlo y convertirlo en un valor hash discreto, con el fin de determinar a qué fragmento deberían ir los datos. A continuación:

Para asegurar que las entradas se coloquen de manera consistente en los fragmentos correctos, los valores que se ingresan en la función hash deben provenir de la misma columna. Esta columna se llama Clave de Fragmento. Después, las transacciones que generen un valor de 1 se asignan al fragmento 1, y las transacciones que generen un valor de 2 se asignan al fragmento 2. Sin embargo, la desventaja de este método es que los fragmentos deben comunicarse entre sí para evitar ataques de doble gasto. Si se limita el comercio entre fragmentos, se restringirá la disponibilidad de la plataforma, y si se permiten transacciones entre fragmentos, se debe sopesar el costo de la comunicación entre fragmentos frente a las ganancias de la mejora del rendimiento.

Modelo de cuenta/saldo: el sistema registra el saldo de cada cuenta y, 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 bancaria; solo cuando el saldo de la cuenta es mayor que el monto de transferencia requerido, la transacción puede llevarse a cabo. En el modelo de cuenta/saldo, dado que una transacción solo tiene una entrada, al fragmentar la transacción 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 la tecnología de fragmentación son sistemas de libros de cuentas como el de Ethereum.

( 03 Estado de Fragmentación )State Sharding (

La fragmentación de estado se refiere a cómo los datos en la cadena de bloques se distribuyen y almacenan en diferentes fragmentos.

Siguiendo con nuestro ejemplo de la cola de Walmart, cada ventana tiene una cuenta, ¿cómo se registran sus libros contables? Si: el cliente elige qué cola esperar, se registra en esa cuenta, por ejemplo, si el cliente A va a la ventana A, y al día siguiente el cliente va a otra ventana de pago, como la ventana B, y la ventana B no tiene la información de la cuenta anterior del cliente ), como en el caso de métodos de pago como tarjetas de valor almacenado ###, ¿qué se debe hacer? ¿Llamar a la ventana 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. Porque 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 uno de los problemas a enfrentar en este caso es que las transacciones no se realizarán solo en un fragmento, a menudo involucrando 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 a 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 a 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 entre fragmentos, el fragmento 2 llamará a los registros de transacciones anteriores del fragmento 1 para confirmar la validez de la transacción. Si A transfiere monedas a B con frecuencia, el fragmento 2 deberá interactuar continuamente con el fragmento 1, lo que reducirá la eficiencia del procesamiento de las transacciones. Sin embargo, si no se descarga y verifica toda la historia de un fragmento específico, los participantes no necesariamente.