El equipo del proyecto Stellar presentó Project Thruput, un modelo experimental de ejecución de transacciones diseñado para permitir el procesamiento paralelo incluso cuando las operaciones modifican el mismo estado de la cadena de bloques. En pruebas iniciales, la ejecución de pagos aumentó de 1,18 millones por segundo en una máquina a 7,02 millones por segundo en ocho máquinas.

Project Thruput está disponible en la red de pruebas FutureNet, con código de fuente abierta, documentación técnica y pruebas comparativas reproducibles.

El equipo del proyecto Stellar presentó Project Thruput, un modelo experimental de ejecución de transacciones destinado a permitir el procesamiento paralelo incluso cuando las operaciones modifican el mismo estado de la cadena de bloques. El modelo es relevante porque los desarrolladores afirman que puede ampliar la capacidad de cómputo al añadir hardware sin fragmentar la cadena de bloques.

En pruebas iniciales, la ejecución de pagos en un solo validador aumentó de 1,18 millones por segundo con una máquina a 7,02 millones por segundo con ocho máquinas. Project Thruput ya está disponible en FutureNet, junto con su código de fuente abierta, documentación técnica y pruebas comparativas reproducibles.

Cómo funciona Project Thruput

Stellar dijo que muchas cadenas de bloques ejecutan transacciones en un único orden o las procesan en paralelo solo cuando no existen conflictos de acceso a datos. Por ello, las operaciones que intentan modificar el mismo saldo o fondo de liquidez pueden tener que esperar unas a otras.

Con Project Thruput, las transacciones dentro de un bloque comienzan desde la misma instantánea del libro mayor y pueden ejecutarse en paralelo incluso si modifican el mismo estado. El sistema combina cambios compatibles cuando confirma el bloque.

Por ejemplo, en vez de escribir un nuevo valor de saldo, una transacción puede especificar una operación que reste una cantidad determinada. El sistema puede combinar esos cambios en distintos órdenes siempre que cumplan con las restricciones definidas, al tiempo que evita que dos pagos gasten los mismos fondos simultáneamente.

Los desarrolladores también pueden definir reglas para grupos de transacciones, incluido un límite sobre el importe total retirado durante un bloque. Los tipos de almacenamiento determinan qué cambios pueden combinarse y qué límites debe aplicar el sistema.

Las pruebas con alta contención de datos, con transferencias limitadas a 100 cuentas, mostraron que el rendimiento aumentaba a medida que crecía el número de núcleos de procesador y máquinas. El mejor resultado reportado fue de 7,02 millones de pagos por segundo en ocho máquinas, casi seis veces los 1,18 millones registrados en una máquina.

Las pruebas comparativas cubrieron transferencias RV32 ERC-20, ejecución de transacciones, verificación de firmas y el proceso completo desde la apertura de un bloque hasta su finalización en el motor central de Project Thruput. No midieron el rendimiento de red de extremo a extremo.

Comisiones de transacción y límites de capacidad

Project Thruput no cobra comisiones por transacciones individuales, un diseño destinado a respaldar micropagos gratuitos y cálculos complejos, como los cálculos de riesgo de carteras.

El modelo no permite cómputo ilimitado. El gas sigue midiendo y limitando la ejecución de cada transacción. Cuando la demanda supera la capacidad disponible, la participación de una cuenta en la cola de programación depende de su saldo desbloqueado de tokens nativos.

Los tokens no se gastan durante la programación, y las transacciones no pueden obtener prioridad pagando comisiones más altas. Un mecanismo similar se aplica al almacenamiento de datos: parte del saldo de una cuenta queda bloqueado mientras los datos permanecen almacenados y se libera tras su eliminación.

Bermudas dijo anteriormente que trasladaría los pagos gubernamentales a la cadena de bloques utilizando Stellar.

Fuente: HODL Press