Presentamos Stellar Project Thruput: cómputo blockchain, sin racionar

La mayoría de las blockchain procesan transacciones en un orden estricto y global. Algunas han encontrado formas de ejecutar en paralelo transacciones no relacionadas, pero en el momento en que dos transacciones tocan el mismo estado o requieren los mismos datos, vuelven a la fila. Agregar hardware no cambia eso — máquinas extra quedan inactivas mientras las transacciones esperan su turno.

Stellar Project Thruput es una vista previa tecnológica de un nuevo modelo de ejecución que elimina el cuello de botella. Las transacciones no necesitan un único orden global, incluso cuando compiten por los mismos datos, así que la capacidad crece al agregar máquinas. En benchmarks iniciales, la capacidad de ejecución dentro de un solo validador subió de 1,18 millones de pagos por segundo en una máquina a 7,02 millones de pagos por segundo en ocho máquinas — casi 6x la capacidad original.

Project Thruput ya está disponible hoy en FutureNet, con código open-source, white papers y benchmarks reproducibles. Apenas estamos empezando, y queremos que lo pruebes, lo lleves al límite y nos muestres qué crearías si el cómputo dejara de ser un límite.

La industria ha logrado un progreso notable en velocidad. Algunas redes dividen el trabajo en secuencias de transacciones separadas (shards). Algunas requieren que las transacciones declaren qué cuentas usarán, para que el trabajo independiente pueda ejecutarse en paralelo. Otras ejecutan transacciones en paralelo y rehacen el trabajo cuando aparecen conflictos.

Aun así, la contención sigue siendo el cuello de botella. Cuando miles de transacciones compiten por actualizar un solo saldo o un fondo de liquidez, a menudo se esperan entre sí porque la mayoría de los diseños tratan tocar el mismo estado como depender de él. Eso limita cuánto puede hacer la red, incluso con más hardware.

Así que los desarrolladores construyen alrededor de los límites del ordenamiento. Mantienen los contratos pequeños, dividen la lógica entre transacciones y mueven trabajo fuera de la cadena, a veces a servidores en los que los usuarios deben confiar. Los usuarios cargan con los costos también. Pagan por competir por capacidad escasa, y donde sea que se pueda comprar el orden de las transacciones, puede usarse en su contra.

Con Project Thruput, las transacciones en un bloque parten de la misma instantánea del libro mayor y pueden ejecutarse en paralelo, incluso cuando actualizan el mismo estado. Sus cambios compatibles se combinan cuando el bloque se confirma.

Para un saldo, una transacción puede registrar “restar 5” en lugar de “el saldo ahora es 95”. Esos cambios pueden combinarse en cualquier orden, siempre que respeten los límites del saldo. Muchos pagos pueden actualizar la misma cuenta en un bloque, pero dos pagos no pueden gastar ambos el mismo último dólar.

Los contratos también pueden hacer cumplir límites entre transacciones, como un tope al monto total retirado en un bloque. Los desarrolladores eligen tipos de almacenamiento que le indican a Project Thruput qué cambios pueden combinarse y qué límites deben mantenerse.

Una vez que las transacciones dejan de esperar unas a otras, el hardware extra realmente se utiliza. En Project Thruput, cada validador puede distribuir la ejecución entre muchas máquinas que funcionan como una sola, contra el mismo estado compartido.

Esto agrega capacidad de ejecución sin dividir la blockchain en shards, así que las aplicaciones no tienen que dividir su estado para usar más hardware. Actualizaciones compatibles a la misma cuenta pueden ejecutarse en diferentes máquinas y aterrizar en un solo bloque. El objetivo es hacer que el hardware se adapte a la carga de trabajo de la aplicación: más transacciones, más cómputo en esas transacciones, o ambos.

Bajo alta contención, con cada pago moviéndose entre solo 100 cuentas, la capacidad de ejecución creció a medida que agregamos núcleos y máquinas.

Estos benchmarks miden transferencias RV32 ERC-20 reales, incluyendo ejecución, verificaciones de firmas y trabajo de apertura a confirmación de bloque en el motor central de ejecución de Thruput. No miden el rendimiento de red de extremo a extremo. Cada cifra es la mediana de tres ejecuciones en instancias AWS r8a.16xl. Los resultados exactos se pueden encontrar aquí.

Cuando la capacidad puede crecer con la demanda, el cómputo no necesita racionarse mediante tarifas de transacción. Project Thruput no tiene tarifas por transacción. Un micropago y un cálculo complejo de riesgo de cartera se ejecutan ambos sin un cobro de gas.

Eso no significa cómputo ilimitado. El gas aún mide y limita la ejecución de cada transacción. Cuando la demanda excede la capacidad, la porción de capacidad de programación de una cuenta se determina por su saldo de token nativo desbloqueado. La programación no gasta esos tokens, y las transacciones no compiten mediante tarifas de prioridad. Almacenar datos funciona de manera similar: bloquea parte de ese saldo, que se libera cuando se eliminan los datos.

Nuestra misión es el acceso equitativo al sistema financiero global. No solo al que tenemos hoy, sino al que tendremos en cincuenta años. Atender a diez mil millones de personas, y a los miles de millones de agentes de IA que realizarán transacciones en su nombre, requerirá mucho más cómputo del que cualquier blockchain tiene hoy.

Nuestro objetivo es hacer que la ejecución gratuita de contratos inteligentes sea práctica a escala. Aún queda mucho por resolver, pero hacia allí apuntamos: una computadora mundial donde los desarrolladores puedan crear las apps que han imaginado y la gente pueda usarlas sin preocuparse por el costo de cada transacción.

Si tienes un contrato del que te dijeron que era demasiado caro de ejecutar, tráelo. Si tienes agentes que no necesitan tarifas por transacción, tráelos. Lo que encuentres nos ayudará a decidir adónde va Project Thruput a continuación.

Explora Project Thruput:

• Saber más
• Lee la documentación