Shardeum y la fragmentación de estado dinámico: otra posibilidad en la exploración de fragmentación
El 15 de septiembre de 2022, Ethereum completó la tan esperada fusión (Merge). Este momento histórico marca la transición de Ethereum del Proof of Work (PoW) al Proof of Stake (PoS), para lo cual el equipo de Ethereum se preparó durante 5 años y retrasó 6 veces. Sin embargo, muchas personas creen erróneamente que la fusión traerá de forma natural una mayor escalabilidad, seguridad y sostenibilidad, pero en realidad no es así. La fusión simplemente cambió "las vías y las ruedas", y no traerá directamente una velocidad más rápida, mayor capacidad ni 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 Layer 2 que mejoren la escalabilidad.
Como señaló el fundador de Ethereum, Vitalik Buterin, la fragmentación es una solución de escalabilidad para el dilema de la escalabilidad. Divide los nodos en la red en grupos más pequeños, procesando diferentes conjuntos de transacciones y logrando procesamiento en paralelo. Al compartir la carga de manejar la gran cantidad de datos necesarios para resumir en toda la red, al igual que cuando hacemos la compra en el supermercado y abrimos múltiples cajas de pago, se puede reducir visualmente el tiempo de espera y mejorar la eficiencia del pago.
Esta es la lógica básica de la Fragmentación, simple y directa. Sin embargo, el diablo está en los detalles: el principio y la dirección son correctos, pero siempre hay muchos problemas en la implementación. Este artículo tiene como objetivo aclarar la dirección y los dilemas en el camino de la "Fragmentación", dibujando un mapa para los exploradores de la Fragmentación. Al mismo tiempo, al comparar las soluciones de fragmentación existentes, encontramos algunos problemas comunes y proponemos una dirección de exploración viable: Shardeum y la fragmentación dinámica.
Uno, sobre "Fragmentación"
En términos simples, considerando las limitaciones 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 blockchain en dos grandes categorías:
Escalado Vertical ( Vertical Scaling ): Se logra mejorando el rendimiento del hardware existente del sistema. Se establece una red descentralizada, donde cada nodo en la red tiene una capacidad de computación superior, 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 transacciones de alta frecuencia, juegos y otras aplicaciones sensibles a la latencia. Sin embargo, este enfoque de escalado limita el nivel de descentralización de la red, ya que el costo de operar nodos de validación o nodos completos aumenta. Mantener el nivel de descentralización está limitado por la tasa de crecimiento aproximada del rendimiento del hardware de computación ( 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 computación se reduce a la mitad ).
Escalabilidad Horizontal(Horizontal Scaling): La escalabilidad horizontal generalmente tiene varias ideas. Una es, en el contexto de blockchain, distribuir la carga de cálculo de transacciones de un ecosistema en múltiples blockchains independientes, cada una con su propio productor 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, entre otros. Otra solución de escalabilidad horizontal es la blockchain modular, que divide la infraestructura de blockchain en capa de ejecución, capa de disponibilidad de datos(DA) y capa de consenso. El mecanismo modular de blockchain más común es el rollup. También hay otra opción que consiste en dividir una blockchain en muchas fragmentaciones, ejecutándose en paralelo. Cada fragmentación puede verse como una blockchain, es decir, muchas blockchains pueden ejecutarse en paralelo. Además, generalmente habrá una cadena principal, cuya única tarea es mantener sincronizados todos los fragmentos.
Es importante señalar que las ideas de escalabilidad anteriores no existen de forma aislada; cada solución encuentra un punto de equilibrio dentro del triángulo de imposibilidad, combinando el diseño de mecanismos de incentivos creados por las fuerzas económicas en el sistema para lograr un equilibrio efectivo a niveles macro y micro.
Para discutir la "Fragmentación", necesitamos empezar desde el principio.
Sigamos suponiendo este escenario: en el supermercado, al realizar el pago, para mejorar la eficiencia en el proceso de pago y reducir el tiempo de espera de los clientes, hemos pasado de un solo canal de pago a 10 ventanillas de pago. Para evitar errores en los libros contables, 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 va cada cliente para pagar?
Tercero, ¿cómo se deben resumir estos 10 libros de cuentas individuales correspondientes a las 10 ventanas?
Cuarto, ¿cómo se puede evitar que los cajeros cometan errores para prevenir la discrepancia en las cuentas?
Estas preguntas corresponden en realidad a varias cuestiones 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é 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 blockchain en diferentes Fragmentación? Es decir: ¿cómo se lleva a cabo el estado de fragmentación (State Sharding);
La complejidad implica riesgo, sobre la base de todo lo anterior, ¿cómo evitar la fragmentación de la seguridad del sistema en su totalidad?
01 Fragmentación(Network Sharding)
Si entendemos la blockchain como un libro de contabilidad descentralizado, tanto el mecanismo de consenso PoS como PoW están diseñados para que los nodos compitan por el derecho a llevar la contabilidad según ciertas reglas establecidas, garantizando la precisión del libro en este proceso. La fragmentación de la red se refiere a la necesidad de otra regla establecida, que fragmenta la red blockchain, permitiendo que cada fragmento maneje las transacciones en cadena y compita por el derecho a llevar la contabilidad, es decir, la regla de agrupación de nodos.
Y el problema que encontramos en este proceso es que, a medida que los nodos internos de la blockchain se dividen en diferentes fragmentos, la dificultad y el costo para los atacantes disminuyen drásticamente. Podemos inferir que, suponiendo que las reglas y los resultados de este proceso de agrupamiento son fijos y predecibles, un atacante que desee controlar toda la red de blockchain solo necesita controlar de manera dirigida uno de los fragmentos, comprando 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 dividir a los X validadores en 10 fragmentos, cada fragmento ahora solo tiene X/10 validadores, destruir un fragmento solo requiere destruir el 5.1% del total de validadores ( 51% / 10). Esto lleva a un segundo punto: ¿quién elige a los validadores para cada fragmento? Solo cuando todos estos validadores del 5.1% 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 drásticamente su capacidad para dañar 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 minimizar la probabilidad de éxito de un atacante. Por ejemplo, en 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 cambia a los validadores.
Dicho de manera simple, consiste en agrupar aleatoriamente los nodos y luego asignar el trabajo para que cada grupo de nodos lo verifique de manera independiente.
Sin embargo, es necesario señalar que la aleatoriedad en la blockchain es un tema muy desafiante. Lógicamente, el proceso de generación de este número aleatorio no debería depender del cálculo de ningún fragmento específico. Para este cálculo, muchas de las ideas de diseño existentes son desarrollar una blockchain separada para mantener 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 asignarse a qué fragmentos", lo que no solo permite alcanzar el objetivo de procesamiento en paralelo, sino que también evita la aparición del problema del doble gasto. La diferencia en el modelo de libro mayor de la cadena de bloques puede afectar el desarrollo de la fragmentación de transacciones.
Actualmente, existen dos tipos de métodos de contabilidad en la red blockchain, que son el modelo de Salidas de Transacción No Gastadas (UTXO) ) y el modelo de cuenta/saldo. El representante típico del primero es BTC, mientras que el segundo incluye 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 en la cadena de bloques que no han sido gastadas y que pueden ser utilizadas como entradas para nuevas transacciones, mientras que las salidas de transacciones que ya han sido gastadas no pueden ser utilizadas nuevamente. Es similar a la situación de pago y cambio con billetes en efectivo: un 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 posible forma de hacerlo es: colocar el valor de alguna entrada de la transacción en una función hash para procesarlo y convertirlo en un valor hash discreto que determine a qué fragmento debe ir la información.
Para asegurar que las entradas se coloquen de manera consistente en la fragmentación correcta, los valores ingresados en la función hash deben provenir de la misma columna. Esta columna se llama Clave de Fragmentación. A continuación, las transacciones que generan un valor de 1 se agrupan en la fragmentación 1, mientras que las transacciones que generan un valor de 2 se agrupan en la fragmentación 2. Sin embargo, la desventaja de este método es que las fragmentaciones deben comunicarse entre sí para evitar ataques de doble gasto. Si se limita el comercio entre fragmentaciones, se restringirá la disponibilidad de la plataforma, y si se permiten transacciones entre fragmentaciones, se deberá sopesar el costo de la comunicación entre fragmentaciones con los beneficios de las mejoras en el rendimiento.
Modelo de cuentas/saldos: 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 bancaria; solo se puede realizar la transacción si el saldo de la cuenta es mayor que el monto de transferencia requerido. En el modelo de cuentas/saldos, dado que una transacción tiene solo una entrada, se puede garantizar que múltiples transacciones de la misma cuenta se procesen en la misma fragmentación al fragmentar las transacciones según la dirección del remitente, previniendo efectivamente el doble gasto. Por lo tanto, la mayoría de las blockchains que utilizan tecnología de fragmentación son sistemas de libro mayor de cuentas, como Ethereum.
( 03 Estado Fragmentación)State Sharding###
La fragmentación de estado 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 ventana tiene su propia cuenta, ¿cómo se registran sus libros contables? Si: un cliente se coloca en una cola, se registra en esa cuenta, por ejemplo, si el cliente A fue a la ventana A, y al día siguiente el mismo cliente fue a otra ventana de pago, como la ventana B, pero la ventana B no tiene la información de cuenta previa del cliente (, por ejemplo, si se trata 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 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 asignan a diferentes fragmentos según la dirección, es decir, el estado solo se almacenará en el fragmento correspondiente a su dirección. En este caso, uno de los problemas a enfrentar es que las transacciones no solo se realizarán en un fragmento, a menudo involucrando la fragmentación cruzada (Cross-Sharding).
Considera un escenario 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 fondos a B, se formará una transacción de fragmentación cruzada, y la fragmentación 2 llamará al historial de transacciones de la fragmentación 1 para confirmar la validez de la transacción. Si A envía monedas a B con frecuencia, la fragmentación 2 tendrá que interactuar constantemente con la fragmentación 1, lo que reducirá la eficiencia del procesamiento de las transacciones. Sin embargo, si no
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
7 me gusta
Recompensa
7
4
Republicar
Compartir
Comentar
0/400
ThreeHornBlasts
· 08-09 22:54
Otra vez se está poniendo alcista.
Ver originalesResponder0
CrossChainBreather
· 08-09 22:52
¿Eso es todo después de la fusión? ¿No puede correr o no puede correr?
Ver originalesResponder0
DecentralizeMe
· 08-09 22:39
¿Qué cosa estás preparando durante cinco años? ¿Está fuera de control, verdad?
Shardeum: Exploración de la fragmentación de estado dinámico como nueva dirección para la expansión de la Cadena de bloques
Shardeum y la fragmentación de estado dinámico: otra posibilidad en la exploración de fragmentación
El 15 de septiembre de 2022, Ethereum completó la tan esperada fusión (Merge). Este momento histórico marca la transición de Ethereum del Proof of Work (PoW) al Proof of Stake (PoS), para lo cual el equipo de Ethereum se preparó durante 5 años y retrasó 6 veces. Sin embargo, muchas personas creen erróneamente que la fusión traerá de forma natural una mayor escalabilidad, seguridad y sostenibilidad, pero en realidad no es así. La fusión simplemente cambió "las vías y las ruedas", y no traerá directamente una velocidad más rápida, mayor capacidad ni 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 Layer 2 que mejoren la escalabilidad.
Como señaló el fundador de Ethereum, Vitalik Buterin, la fragmentación es una solución de escalabilidad para el dilema de la escalabilidad. Divide los nodos en la red en grupos más pequeños, procesando diferentes conjuntos de transacciones y logrando procesamiento en paralelo. Al compartir la carga de manejar la gran cantidad de datos necesarios para resumir en toda la red, al igual que cuando hacemos la compra en el supermercado y abrimos múltiples cajas de pago, se puede reducir visualmente el tiempo de espera y mejorar la eficiencia del pago.
Esta es la lógica básica de la Fragmentación, simple y directa. Sin embargo, el diablo está en los detalles: el principio y la dirección son correctos, pero siempre hay muchos problemas en la implementación. Este artículo tiene como objetivo aclarar la dirección y los dilemas en el camino de la "Fragmentación", dibujando un mapa para los exploradores de la Fragmentación. Al mismo tiempo, al comparar las soluciones de fragmentación existentes, encontramos algunos problemas comunes y proponemos una dirección de exploración viable: Shardeum y la fragmentación dinámica.
Uno, sobre "Fragmentación"
En términos simples, considerando las limitaciones 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 blockchain en dos grandes categorías:
Escalado Vertical ( Vertical Scaling ): Se logra mejorando el rendimiento del hardware existente del sistema. Se establece una red descentralizada, donde cada nodo en la red tiene una capacidad de computación superior, 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 transacciones de alta frecuencia, juegos y otras aplicaciones sensibles a la latencia. Sin embargo, este enfoque de escalado limita el nivel de descentralización de la red, ya que el costo de operar nodos de validación o nodos completos aumenta. Mantener el nivel de descentralización está limitado por la tasa de crecimiento aproximada del rendimiento del hardware de computación ( 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 computación se reduce a la mitad ).
Escalabilidad Horizontal(Horizontal Scaling): La escalabilidad horizontal generalmente tiene varias ideas. Una es, en el contexto de blockchain, distribuir la carga de cálculo de transacciones de un ecosistema en múltiples blockchains independientes, cada una con su propio productor 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, entre otros. Otra solución de escalabilidad horizontal es la blockchain modular, que divide la infraestructura de blockchain en capa de ejecución, capa de disponibilidad de datos(DA) y capa de consenso. El mecanismo modular de blockchain más común es el rollup. También hay otra opción que consiste en dividir una blockchain en muchas fragmentaciones, ejecutándose en paralelo. Cada fragmentación puede verse como una blockchain, es decir, muchas blockchains pueden ejecutarse en paralelo. Además, generalmente habrá una cadena principal, cuya única tarea es mantener sincronizados todos los fragmentos.
Es importante señalar que las ideas de escalabilidad anteriores no existen de forma aislada; cada solución encuentra un punto de equilibrio dentro del triángulo de imposibilidad, combinando el diseño de mecanismos de incentivos creados por las fuerzas económicas en el sistema para lograr un equilibrio efectivo a niveles macro y micro.
Para discutir la "Fragmentación", necesitamos empezar desde el principio.
Sigamos suponiendo este escenario: en el supermercado, al realizar el pago, para mejorar la eficiencia en el proceso de pago y reducir el tiempo de espera de los clientes, hemos pasado de un solo canal de pago a 10 ventanillas de pago. Para evitar errores en los libros contables, 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 va cada cliente para pagar?
Tercero, ¿cómo se deben resumir estos 10 libros de cuentas individuales correspondientes a las 10 ventanas?
Cuarto, ¿cómo se puede evitar que los cajeros cometan errores para prevenir la discrepancia en las cuentas?
Estas preguntas corresponden en realidad a varias cuestiones 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é 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 blockchain en diferentes Fragmentación? Es decir: ¿cómo se lleva a cabo el estado de fragmentación (State Sharding);
La complejidad implica riesgo, sobre la base de todo lo anterior, ¿cómo evitar la fragmentación de la seguridad del sistema en su totalidad?
01 Fragmentación(Network Sharding)
Si entendemos la blockchain como un libro de contabilidad descentralizado, tanto el mecanismo de consenso PoS como PoW están diseñados para que los nodos compitan por el derecho a llevar la contabilidad según ciertas reglas establecidas, garantizando la precisión del libro en este proceso. La fragmentación de la red se refiere a la necesidad de otra regla establecida, que fragmenta la red blockchain, permitiendo que cada fragmento maneje las transacciones en cadena y compita por el derecho a llevar la contabilidad, es decir, la regla de agrupación de nodos.
Y el problema que encontramos en este proceso es que, a medida que los nodos internos de la blockchain se dividen en diferentes fragmentos, la dificultad y el costo para los atacantes disminuyen drásticamente. Podemos inferir que, suponiendo que las reglas y los resultados de este proceso de agrupamiento son fijos y predecibles, un atacante que desee controlar toda la red de blockchain solo necesita controlar de manera dirigida uno de los fragmentos, comprando 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 dividir a los X validadores en 10 fragmentos, cada fragmento ahora solo tiene X/10 validadores, destruir un fragmento solo requiere destruir el 5.1% del total de validadores ( 51% / 10). Esto lleva a un segundo punto: ¿quién elige a los validadores para cada fragmento? Solo cuando todos estos validadores del 5.1% 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 drásticamente su capacidad para dañar 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 minimizar la probabilidad de éxito de un atacante. Por ejemplo, en 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 cambia a los validadores.
Dicho de manera simple, consiste en agrupar aleatoriamente los nodos y luego asignar el trabajo para que cada grupo de nodos lo verifique de manera independiente.
Sin embargo, es necesario señalar que la aleatoriedad en la blockchain es un tema muy desafiante. Lógicamente, el proceso de generación de este número aleatorio no debería depender del cálculo de ningún fragmento específico. Para este cálculo, muchas de las ideas de diseño existentes son desarrollar una blockchain separada para mantener 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 asignarse a qué fragmentos", lo que no solo permite alcanzar el objetivo de procesamiento en paralelo, sino que también evita la aparición del problema del doble gasto. La diferencia en el modelo de libro mayor de la cadena de bloques puede afectar el desarrollo de la fragmentación de transacciones.
Actualmente, existen dos tipos de métodos de contabilidad en la red blockchain, que son el modelo de Salidas de Transacción No Gastadas (UTXO) ) y el modelo de cuenta/saldo. El representante típico del primero es BTC, mientras que el segundo incluye 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 en la cadena de bloques que no han sido gastadas y que pueden ser utilizadas como entradas para nuevas transacciones, mientras que las salidas de transacciones que ya han sido gastadas no pueden ser utilizadas nuevamente. Es similar a la situación de pago y cambio con billetes en efectivo: un 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 posible forma de hacerlo es: colocar el valor de alguna entrada de la transacción en una función hash para procesarlo y convertirlo en un valor hash discreto que determine a qué fragmento debe ir la información.
Para asegurar que las entradas se coloquen de manera consistente en la fragmentación correcta, los valores ingresados en la función hash deben provenir de la misma columna. Esta columna se llama Clave de Fragmentación. A continuación, las transacciones que generan un valor de 1 se agrupan en la fragmentación 1, mientras que las transacciones que generan un valor de 2 se agrupan en la fragmentación 2. Sin embargo, la desventaja de este método es que las fragmentaciones deben comunicarse entre sí para evitar ataques de doble gasto. Si se limita el comercio entre fragmentaciones, se restringirá la disponibilidad de la plataforma, y si se permiten transacciones entre fragmentaciones, se deberá sopesar el costo de la comunicación entre fragmentaciones con los beneficios de las mejoras en el rendimiento.
Modelo de cuentas/saldos: 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 bancaria; solo se puede realizar la transacción si el saldo de la cuenta es mayor que el monto de transferencia requerido. En el modelo de cuentas/saldos, dado que una transacción tiene solo una entrada, se puede garantizar que múltiples transacciones de la misma cuenta se procesen en la misma fragmentación al fragmentar las transacciones según la dirección del remitente, previniendo efectivamente el doble gasto. Por lo tanto, la mayoría de las blockchains que utilizan tecnología de fragmentación son sistemas de libro mayor de cuentas, como Ethereum.
( 03 Estado Fragmentación)State Sharding###
La fragmentación de estado 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 ventana tiene su propia cuenta, ¿cómo se registran sus libros contables? Si: un cliente se coloca en una cola, se registra en esa cuenta, por ejemplo, si el cliente A fue a la ventana A, y al día siguiente el mismo cliente fue a otra ventana de pago, como la ventana B, pero la ventana B no tiene la información de cuenta previa del cliente (, por ejemplo, si se trata 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 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 asignan a diferentes fragmentos según la dirección, es decir, el estado solo se almacenará en el fragmento correspondiente a su dirección. En este caso, uno de los problemas a enfrentar es que las transacciones no solo se realizarán en un fragmento, a menudo involucrando la fragmentación cruzada (Cross-Sharding).
Considera un escenario 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 fondos a B, se formará una transacción de fragmentación cruzada, y la fragmentación 2 llamará al historial de transacciones de la fragmentación 1 para confirmar la validez de la transacción. Si A envía monedas a B con frecuencia, la fragmentación 2 tendrá que interactuar constantemente con la fragmentación 1, lo que reducirá la eficiencia del procesamiento de las transacciones. Sin embargo, si no