La misión de Strike es incorporar a todo el mundo a una forma de dinero mejor. Los servicios que hemos creado están diseñados para ofrecer pagos rápidos, económicos y fluidos a través de la red de bitcoin. Una de las técnicas fundamentales que utilizamos para lograrlo es agrupar los pagos de bitcoin on-chain. 

En este artículo, exploraremos cómo funciona nuestro sistema de agrupación on-chain, los matices que lo hacen eficaz y algunos de los desafíos técnicos que hemos superado para garantizar que nuestros usuarios reciban un servicio de primer nivel.

Servicios de pago en cadena por niveles

En Strike ofrecemos un servicio por niveles para enviar pagos en cadena:

  • Nivel flexible (gratuito): para quienes están dispuestos a esperar entre 12 y 48 horas

  • Nivel estándar: para envíos más rápidos y asequibles

  • Nivel prioritario: para transacciones que no pueden esperar, con confirmación prevista en el siguiente bloque

Este enfoque por niveles nos permite atender las distintas necesidades y preferencias de nuestros usuarios, equilibrando eficazmente el coste y la velocidad. Ofrecer a todos nuestros usuarios envíos en cadena gratuitos e ilimitados y transacciones en el siguiente bloque plantea numerosos desafíos técnicos. Necesitamos un sistema que pueda escalar para atender a un número muy elevado de usuarios, procesar pagos en cadena a volúmenes empresariales, mantener unos costes de comisión asequibles y aprovechar inteligentemente la liquidez de nuestras carteras activas.

La eficiencia de la agrupación

Agrupar varios pagos en una sola transacción grande reduce significativamente nuestra huella en cadena y mitiga algunos de nuestros desafíos de escalabilidad. Este enfoque beneficia no solo a nuestros usuarios, sino también a la comunidad de bitcoin, ya que minimiza el uso de datos de nuestras transacciones y, por tanto, reduce la congestión de la red y las comisiones. También significa que uno de nuestros UTXO (salidas de transacciones no gastadas, a veces denominadas “monedas”) puede utilizarse para facilitar varios pagos en cadena para nuestros usuarios, algo crucial para escalar nuestras operaciones.

Ahorro de costes mediante la agrupación

Al agrupar los pagos, podemos ofrecer envíos en cadena a un coste inferior al que pagarían los usuarios si enviaran las transacciones individualmente. En la red de bitcoin, pagas por el tamaño de los datos de tu transacción, no por su valor económico. El ahorro de la agrupación se debe al menor tamaño en bytes de las transacciones agrupadas en comparación con la publicación de varias transacciones individuales. Todas las transacciones en cadena contienen datos fijos y variables. Los datos fijos incluyen información estándar para todas las transacciones, mientras que los datos variables incluyen las entradas de la transacción (las monedas que se gastarán en la transacción) y las salidas (los destinos de las monedas), cuyo número y tamaño pueden variar. Al combinar varias transacciones individuales en una única transacción grande agrupada, todas las salidas pueden compartir los mismos datos fijos y las mismas monedas de entrada, amortizando así sus costes.

Mejora de nuestro sistema de agrupación

Strike lleva bastante tiempo agrupando pagos en cadena en nombre de nuestros usuarios, lo que nos ha permitido ofrecer envíos en cadena a precios muy competitivos (¡incluido un nivel gratuito!). Sin embargo, recientemente hemos realizado una gran mejora en nuestro sistema de agrupación que, creemos, reforzará nuestra posición de liderazgo en bitcoin. Al compartir contigo nuestra estrategia de agrupación más reciente, queremos dejar claro qué puedes esperar cuando uses Strike para realizar un pago en cadena y ayudar también a otros desarrolladores compartiendo algunas lecciones que hemos aprendido mientras iterábamos sobre nuestro servicio de pagos en cadena.

Añadir salidas a transacciones no confirmadas

La actualización más reciente de nuestro sistema de agrupación permite añadir más salidas (receptores o destinos) a transacciones agrupadas existentes y no confirmadas cuando es posible. Esto se consigue aprovechando una función propia de bitcoin llamada Replace-By-Fee (RBF). RBF nos permite “reemplazar” transacciones no confirmadas aumentando la comisión que pagan. Es importante señalar que las salidas no tienen que ser las mismas que las de la transacción original, lo que nos permite añadir más salidas a transacciones existentes y no confirmadas cuando sea necesario.

Aquí tienes algunos enlaces para quienes quieran obtener más información sobre RBF:

Esta actualización nos permite gestionar un aumento de las solicitudes de “envío prioritario” (nuestro nivel con objetivo en el siguiente bloque, descrito anteriormente) sin crear constantemente nuevas transacciones agrupadas. En su lugar, añadimos más salidas a nuestras transacciones agrupadas existentes que ya se han difundido, pero aún no se han confirmado. Esta es la razón por la que supone un cambio radical:

  1. Menor huella en cadena: Al minimizar el número de nuevas transacciones creadas, reducimos aún más la congestión de la red de bitcoin.

  2. Ahorro en costes de comisiones: Un menor número de transacciones agrupadas para el mismo número de pagos generalmente se traduce en un ahorro aún mayor en las comisiones en cadena de bitcoin; normalmente observamos un ahorro de entre el 30 % y el 50 % por transacción.

  3. Mejora de la calidad del servicio (QoS): Como parte de la operación RBF, se incrementa la comisión de las agrupaciones existentes y no confirmadas hasta ajustarla a la tasa de mercado actual. Esto garantiza que nuestros usuarios disfruten de una mejor calidad del servicio, ya que sus transacciones tienen más probabilidades de incluirse en el siguiente bloque, independientemente de los picos de comisiones en la red.

Ejemplo de una agrupación en cadena que utiliza RBF para añadir salidas adicionales hasta que se confirma

Desafíos técnicos y soluciones

La implementación de este sofisticado sistema de agrupación requirió superar varios obstáculos técnicos:

¡Evitar el doble envío!

Utilizar RBF para añadir salidas adicionales requiere gestionarlo con cuidado para evitar problemas de doble envío y garantizar que todas las salidas adicionales añadidas se contabilicen correctamente. Hay varios motivos por los que los dobles envíos podrían convertirse en un problema al empezar a añadir salidas a las transacciones mediante RBF. Esto no se debe a ningún problema del protocolo de bitcoin, sino a que pueden surgir ciertos escollos conceptuales. Uno de los puntos principales es que debes gestionar el caso en que los mineros confirmen una versión que no sea la más reciente de tu transacción agrupada. Cualquier candidato que hayas añadido después de esa versión debe transferirse a una nueva agrupación. Pero si te equivocas aquí, ¡podrías acabar enviando el pago dos veces!

Garantizar el seguimiento de las transacciones

Para garantizar que no enviemos un pago dos veces, debemos llevar un registro meticuloso de qué transacciones se han publicado y supervisar qué versión de una transacción agrupada se confirma. Este seguimiento minucioso nos permite transferir correctamente los candidatos de las versiones no confirmadas a nuevas agrupaciones. 

Pero ¿qué ocurre si el software de tu cartera se bloquea justo cuando se publica una nueva transacción RBF en la red de bitcoin? ¿Cómo sabrás si se ha publicado la transacción? 

Algunos programas de cartera te proporcionan el nuevo TxId como respuesta cuando una nueva transacción se publica correctamente. Este enfoque no es suficientemente fiable en este caso, ya que podría hacer que nunca conociéramos el TxId de una transacción que se hubiera publicado y confirmado en cadena. Podríamos no recibir la respuesta que contiene el nuevo TxId debido, por ejemplo, a errores de red, bloqueos del software, etc., aunque de hecho se hubiera difundido una nueva transacción. Dado que todas nuestras versiones de transacciones contienen un conjunto diferente de salidas, es fundamental saber qué versión se confirma para poder decidir si alguna salida añadida NO se confirmó y, por tanto, debe transferirse a una nueva agrupación.
Este problema general puede resolverse mediante un enfoque de 2 pasos:

  1. Crea tu transacción y guárdala en tu base de datos

  2. Si el paso 1 se ha completado correctamente, intenta difundir la transacción en la red de bitcoin

Con este enfoque, el paso 2 puede reintentarse de forma segura si encuentras algún problema. También podrás supervisar la red de bitcoin para buscar el TxId y ayudar a determinar si la transacción se ha publicado o no. La forma en que funcionan las transacciones de bitcoin implica que crear la transacción también significa crear el TxId. Este es un proceso completamente sin conexión que tu software puede realizar sin comunicarse con el resto de la red de bitcoin.

División de cadena y reorganización

Otro caso al que debes prestar atención es cuando las versiones de tu transacción agrupada se ven involucradas en divisiones de la cadena de bitcoin (bifurcaciones temporales de la cadena de bloques) y en la posible reorganización posterior de la cadena de bloques. Sin entrar en detalles, esto podría significar que una versión de tu transacción agrupada se confirme inicialmente en cadena, pero poco después quede invalidada y sea sustituida por otra versión de tu transacción agrupada.

Dado que todas las versiones de nuestras transacciones agrupadas contienen un conjunto diferente de salidas y tomamos decisiones sobre qué salidas transferir a una nueva agrupación en función de la versión que se confirmó, este fenómeno también podría hacer que enviemos un pago dos veces. Las divisiones de cadena y las reorganizaciones son una parte importante del funcionamiento de la cadena de bloques para garantizar el consenso, por lo que nuestros sistemas deben poder gestionarlas. Una solución sencilla consiste en hacer lo mismo que se hace normalmente con las recepciones en cadena: esperar a que la transacción tenga X (¡más de una!) confirmaciones en cadena antes de considerarla definitiva. En bitcoin, ocasionalmente verás bifurcaciones de la cadena con una profundidad de un bloque, pero si tu transacción se confirmó hace 6 bloques, generalmente se considera seguro considerarla “final”.

Estimaciones de comisiones adecuadas

Usar estimaciones de comisiones basadas en el mempool en lugar de estimaciones basadas en la cadena de bloques es crucial para la QoS y la eficiencia de costes. Este enfoque garantiza que las transacciones puedan incluirse en el siguiente bloque sin pagar de más. Nuestro sistema supervisa continuamente nuestro mempool para elegir una tasa de comisión adecuada para cada transacción por lotes y cada RBF.

Escalar las operaciones en cadena

Nuestro sistema mejorado de procesamiento por lotes nos permite ampliar nuestras operaciones en cadena hasta alcanzar un nivel que nos permita convertirnos realmente en una empresa global con millones de usuarios activos. Ahora nuestro sistema nos permite gestionar enormes aumentos en el volumen generado por nuestros usuarios sin comprometer la velocidad, el coste ni la calidad del servicio.

UTXO: un recurso escaso

Uno de los mayores desafíos de escalar un servicio de envíos en cadena con custodia, manteniendo al mismo tiempo la opción de “envío prioritario”, es la necesidad de mantener una reserva de UTXO que puedan utilizarse como entradas en tus transacciones para facilitar los pagos en cadena. Imagina tener que atender una solicitud de “envío prioritario” de tus usuarios cada segundo, mientras que en la red de bitcoin transcurre un intervalo mayor —por ejemplo, 1 hora— entre la minería de cada bloque. Si necesitas publicar todas estas transacciones al instante, no sería posible agruparlas en lotes.

Sin embargo, supongamos que somos ingeniosos y añadimos un pequeño retraso de tan solo 5 segundos entre cada una de nuestras transacciones por lotes. Esto significa que podemos agrupar 5 solicitudes juntas cada 5 segundos. Por lo tanto, durante una hora en la que no se mine ningún bloque, tendríamos que publicar 720 transacciones para atender las solicitudes de nuestros usuarios en este ejemplo. Como ninguna de estas transacciones se confirmaría durante esa hora, las salidas de cambio de estas transacciones no estarían disponibles para reutilizarlas de forma segura, lo que exigiría una reserva de 720 UTXO de tamaños adecuados en nuestra billetera caliente. Sin esto, nuestro servicio simplemente se detendría hasta que se mine un nuevo bloque. Esta situación se vuelve aún más complicada durante los picos de comisiones, que podrían hacer que las transacciones permanecieran sin confirmar durante un periodo todavía más largo.

Además, mantener UTXO de un “tamaño adecuado” añade otra capa de complejidad. Por ejemplo, si todas las solicitudes de envío fueran de 1 BTC cada una, tendríamos que mantener 720 BTC en nuestra billetera caliente, divididos en UTXO de 1 BTC cada uno. Esto no solo resulta complejo de gestionar, sino también ineficiente desde el punto de vista operativo y difícil de escalar. Por supuesto, es imposible predecir con una precisión del 100 % qué harán tus usuarios, por lo que tu reserva de UTXO debe ser aún mayor para estar preparada ante picos imprevistos de demanda. El problema fundamental aquí es que terminamos teniendo muchas transacciones sin confirmar en el mempool al mismo tiempo, lo que bloquea muchos de nuestros UTXO.

¿Ejecutar el sistema con un solo UTXO?

En lugar de publicar nuevas transacciones por lotes cada 5 segundos, como en el ejemplo anterior, nuestro nuevo enfoque añade más salidas a nuestra transacción existente sin confirmar, si la hay. Esto proporciona una solución increíblemente eficiente al problema mencionado anteriormente. Añadir más salidas reutiliza el UTXO de entrada existente de la transacción sin confirmar, siempre que el UTXO sea suficientemente grande. Esto significa que, en teoría, todo nuestro sistema de procesamiento por lotes podría funcionar con un solo UTXO.

Cada vez que una de nuestras transacciones por lotes se confirma en la cadena, recibimos la salida de cambio como un nuevo UTXO, que puede utilizarse para financiar el siguiente lote. Este enfoque escala prácticamente de forma infinita —o, al menos, hasta alcanzar el límite de tamaño de los bloques de bitcoin—, lo que nos permite gestionar un volumen creciente de solicitudes de envío en cadena sin estar limitados por el número de UTXO en nuestra billetera caliente. También mitiga el riesgo asociado a los picos de comisiones, garantizando un funcionamiento continuo incluso durante la congestión de la red.

Con este sistema alcanzamos un nivel sin precedentes de escalabilidad y fiabilidad en nuestras operaciones en cadena. Esto permite que Strike crezca y atienda a una base de usuarios global con millones de usuarios activos, ofreciéndoles el mejor servicio posible en términos de velocidad, coste y fiabilidad.

QoS superior

Nuestro compromiso de ofrecer a nuestros usuarios el servicio de mayor calidad del sector es evidente en nuestro enfoque del procesamiento por lotes de pagos en cadena. Los usuarios pueden confiar en que sus pagos se gestionarán con el máximo cuidado, eficiencia y seguridad, tanto si eligen un envío flexible como estándar o prioritario.

Los picos de comisiones en la red de bitcoin son un problema habitual que perjudica la calidad del servicio de otros proveedores. Es habitual publicar transacciones con una comisión lo bastante alta como para intentar que se confirmen en el siguiente bloque, solo para ver después cómo el mercado general de comisiones experimenta un aumento significativo. En estos casos, es probable que las transacciones publicadas no se confirmen durante varias horas y que puedan acabar atascadas durante mucho más tiempo o ser eliminadas del mempool. El protocolo de bitcoin ofrece soluciones para que puedas “aumentar la comisión” de tu transacción y resolver este problema, pero no están disponibles en todas las aplicaciones y billeteras, y no es habitual que las billeteras aumenten automáticamente la comisión de tu transacción en estos casos sin cobrarte más por ello. Strike simplifica todo esto por ti y ofrece flexibilidad a los usuarios con distintas preferencias en cuanto al tiempo.

Conclusión

En Strike, nos esforzamos continuamente por innovar y mejorar nuestros servicios. Nuestro avanzado sistema de procesamiento por lotes para los envíos en cadena demuestra nuestra dedicación a la eficiencia y a un servicio de alta calidad. Nuestro objetivo es ser los mejores en bitcoin, lo que significa ofrecer a nuestros usuarios la mejor experiencia posible con los pagos de bitcoin. Creemos firmemente que nuestra experiencia de envíos en cadena está avanzando claramente hacia el modelo según el cual funcionarán —y deberían funcionar— los pagos en cadena en el futuro. Sin embargo, siempre seguiremos perfeccionando nuestras soluciones para mejorarlas aún más y mostrar al mundo todo lo que bitcoin puede ofrecer.

No dudes en ponerte en contacto con nosotros si tienes alguna pregunta o necesitas más información sobre nuestro sistema de procesamiento por lotes en cadena y sus ventajas. Siempre estamos aquí para ayudarte y ofrecerte el mejor servicio posible.