Agrupación de Envíos On-chain
Calidad del servicio (QoS), eficiencia y seguridad
Tim Normark
Aug 01, 2024
Strike tiene la misión de integrar al mundo a un mejor sistema monetario. Los servicios que hemos creado están diseñados para pagos rápidos, de bajo costo y sin complicaciones a través de la red Bitcoin. Una de las técnicas principales que utilizamos para lograr esto es la agrupación de 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 efectivo y algunos de los desafíos técnicos que hemos superado para asegurar que nuestros usuarios reciban un servicio de primera calidad.
En Strike, ofrecemos un servicio por niveles para enviar pagos on-chain:
Este enfoque por niveles nos permite atender diferentes necesidades y preferencias de los usuarios, equilibrando efectivamente el costo y la velocidad. Ofrecer tanto envíos on-chain ilimitados y gratuitos como transacciones para el siguiente bloque a todos nuestros usuarios plantea una serie de desafíos técnicos. Necesitamos un sistema que pueda escalar a un número muy grande de usuarios, realizar pagos on-chain a volúmenes empresariales, mantener los costos de las comisiones asequibles y utilizar inteligentemente la liquidez en nuestras billeteras calientes.
Agrupar múltiples pagos en una sola transacción grande reduce significativamente nuestra huella on-chain y mitiga algunos de nuestros desafíos de escalado. Este enfoque beneficia no solo a nuestros usuarios, sino también a la comunidad de Bitcoin al minimizar el uso de datos de nuestras transacciones, reduciendo así la congestión de la red y las comisiones. También significa que uno de nuestros UTXOs (salidas de transacciones no gastadas, a veces denominadas "monedas") puede usarse para facilitar varios pagos on-chain para nuestros usuarios, lo cual es crucial para escalar nuestras operaciones.
Al agrupar pagos, podemos ofrecer envíos on-chain más baratos en comparación con lo que los usuarios pagarían si enviaran transacciones individualmente. En la red Bitcoin, se paga por el tamaño de datos de tu transacción, en lugar de su valor financiero. Los ahorros de la agrupación provienen del tamaño reducido en bytes de las transacciones agrupadas en comparación con la publicación de múltiples transacciones individuales. Todas las transacciones on-chain contienen tanto datos fijos como variables. Los datos fijos incluyen información estándar para todas las transacciones, mientras que los datos variables incluyen las entradas de transacción (monedas a gastar en la transacción) y salidas (destino de las monedas), que pueden variar en número y tamaño. Al combinar múltiples transacciones individuales en una sola transacción agrupada grande, todas las salidas pueden compartir los mismos datos fijos y monedas de entrada, amortizando así sus costos.
Strike ha estado agrupando pagos on-chain en nombre de nuestros usuarios durante bastante tiempo, y esto nos ha permitido ofrecer envíos on-chain a precios muy competitivos (¡incluyendo un nivel gratuito!). Sin embargo, recientemente hicimos una gran mejora en nuestro sistema de agrupación, que creemos reforzará nuestra posición como líder en Bitcoin. Al compartir nuestra nueva estrategia de agrupación contigo, queremos establecer las expectativas de lo que puedes esperar cuando usas Strike para realizar un pago on-chain, así como ayudar a otros desarrolladores compartiendo algunas lecciones que hemos aprendido mientras iteramos en nuestro servicio de pagos on-chain.
La actualización más reciente de nuestro sistema de agrupación proporciona la capacidad de añadir más salidas (receptores/destinos) a transacciones agrupadas no confirmadas existentes cuando sea posible. Esto se logra aprovechando una característica nativa de Bitcoin llamada Replace-By-Fee (RBF). RBF nos permite "reemplazar" transacciones no confirmadas aumentando la comisión que pagan. Lo importante es que las salidas no tienen que ser las mismas que en la transacción original, lo que nos permite agregar más salidas a transacciones no confirmadas existentes cuando sea necesario. Aquí hay algunos enlaces para aquellos interesados en aprender más sobre RBF:
Esta actualización nos permite manejar un aumento en las solicitudes de "Envío Prioritario" (nuestro nivel que apunta al próximo bloque descrito anteriormente) sin crear constantemente nuevas transacciones agrupadas. En su lugar, agregamos más salidas a nuestras transacciones agrupadas existentes que han sido transmitidas pero aún no confirmadas. Aquí está por qué esto es un cambio de juego:
Ejemplo de una transacción agrupada on-chain, usando RBF para añadir salidas adicionales hasta que sea confirmada:
Implementar este sofisticado sistema de agrupación requirió superar varios obstáculos técnicos:
Usar RBF para añadir salidas extra requiere un manejo cuidadoso para evitar problemas de envío doble y asegurarse de que todas las salidas añadidas se contabilicen correctamente. Hay varias razones por las cuales el envío doble podría convertirse en un problema cuando empiezas a añadir salidas a transacciones a través de RBF. Esto no se debe a problemas en el protocolo Bitcoin, sino a que hay algunas trampas conceptuales que pueden surgir. Uno de los puntos principales es que necesitas manejar el caso donde los mineros confirmen una versión no más reciente de tu transacción agrupada. Cualquier candidato que hayas añadido después de esa versión necesita ser transferido a un nuevo lote. Pero si cometes un error aquí, podrías terminar enviando doblemente.
Asegurarnos de que no enviamos doblemente implica llevar un seguimiento meticuloso de qué transacciones han sido publicadas y monitorear qué versión de una transacción agrupada es confirmada. Este seguimiento cuidadoso nos permite transferir candidatos de versiones no confirmadas a nuevos lotes con precisión.
Pero, ¿qué pasa si tu software de billetera falla exactamente en el momento de publicar una nueva transacción RBF en la red Bitcoin? ¿Cómo sabrás si la transacción fue publicada?
Algunos software de billetera te darán el nuevo TxId como respuesta tras publicar exitosamente una nueva transacción. Este enfoque no es suficiente aquí, ya que podría resultar en que nunca aprendamos el TxId de una transacción que podría haber sido publicada y confirmada on-chain. Podríamos no recibir la respuesta que contiene el nuevo TxId debido a errores a nivel de red, fallos de software, etc., incluso si de hecho se transmitió una nueva transacción. Dado que todas nuestras versiones de transacciones contienen un conjunto diferente de salidas, es crucial que sepamos qué versión es confirmada para que podamos decidir si alguna salida añadida NO fue confirmada y por lo tanto necesita ser transferida a un nuevo lote.
Este problema general puede resolverse mediante un enfoque de 2 pasos:
Con este enfoque, el paso 2 se puede intentar nuevamente si encuentras algún problema. También tendrás la capacidad de monitorear la red Bitcoin para el TxId, para ayudar a determinar si la transacción fue publicada o no. La forma en que funcionan las transacciones de Bitcoin es que construir la transacción también significa construir el TxId. Este es un proceso completamente offline que puede ser realizado por tu software sin comunicación con el resto de la red Bitcoin.
Otro caso a tener en cuenta es cuando las versiones de tu transacción agrupada están involucradas en Divisiones de Cadena de Bitcoin (bifurcaciones temporales de la blockchain) y potencialmente la posterior reorganización de la blockchain. Sin entrar en detalles, esto podría significar que una versión de tu transacción agrupada inicialmente sea confirmada on-chain, pero poco después sea anulada y superada 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 un nuevo lote en función de qué versión fue confirmada, este fenómeno también tiene el potencial de hacernos enviar doblemente. Las Divisiones de Cadena y Reorganizaciones son una parte importante del funcionamiento de la blockchain para garantizar el consenso, por lo que nuestros sistemas deben poder manejar esto. Una solución simple es hacer lo mismo que normalmente se hace para las recepciones on-chain; esperar hasta que la transacción tenga X (¡más de una!) confirmaciones on-chain antes de considerarla como final. En Bitcoin, ocasionalmente verás divisiones de cadena con una profundidad de un bloque, pero si tu transacción fue confirmada hace 6 bloques, generalmente se considera seguro contarla como "final".
Usar estimaciones de comisiones basadas en el mempool en lugar de estimaciones basadas en la blockchain es crucial para la QoS y la eficiencia de costos. Este enfoque asegura que las transacciones puedan entrar en el próximo bloque sin sobrepagar. Nuestro sistema monitorea continuamente nuestro mempool para elegir una comisión adecuada para cada transacción agrupada y cada RBF.
Nuestro sistema mejorado de agrupación nos posiciona para escalar nuestras operaciones on-chain a un nivel donde realmente podamos crecer para ser una empresa global con millones de usuarios activos. Nuestro sistema ahora nos permite manejar grandes aumentos en el volumen de nuestros usuarios sin comprometer la velocidad, el costo o la calidad del servicio.
Uno de los mayores desafíos con la escalabilidad de un servicio de envío custodial on-chain, mientras se sigue ofreciendo la opción de "Envío Prioritario", es la necesidad de mantener un stock de UTXOs que puedan usarse como entradas en tus transacciones para facilitar los pagos on-chain. Imagina tener que atender una solicitud de "Envío Prioritario" de tus usuarios cada segundo, mientras hay un mayor intervalo (por ejemplo, 1 hora) entre los bloques que se minan en la red Bitcoin. Si necesitas publicar instantáneamente todas estas transacciones, agruparlas no sería posible.
Sin embargo, supongamos que somos inteligentes y añadimos un ligero retraso de solo 5 segundos entre cada una de nuestras transacciones agrupadas. Esto significa que podemos agrupar 5 solicitudes juntas cada 5 segundos. Entonces, durante una hora en la que no se mina ningún bloque, necesitaríamos publicar 720 transacciones para facilitar las solicitudes de nuestros usuarios en este ejemplo. Dado que ninguna de estas transacciones se confirmaría durante esa hora, las salidas de cambio de estas transacciones no estarían disponibles para un uso seguro, lo que requeriría un stock de 720 UTXOs de tamaños apropiados 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 permanezcan no confirmadas por un período aún más largo.
Además, mantener UTXOs de un "tamaño apropiado" añade otra capa de complejidad. Por ejemplo, si todas las solicitudes de envío son de 1 BTC cada una, necesitaríamos mantener 720 BTC en nuestra billetera caliente, desglosados en UTXOs de 1 BTC cada uno. Esto no solo se vuelve complejo de gestionar, sino también ineficiente desde el punto de vista operativo y difícil de escalar. Por supuesto, es imposible predecir con 100% de precisión lo que harán tus usuarios, por lo que tu stock de UTXOs necesita ser aún más grande que esto para estar preparado para picos de demanda imprevistos. El problema fundamental aquí es que terminamos con muchas transacciones no confirmadas en el mempool simultáneamente, bloqueando numerosos de nuestros UTXOs.
En lugar de publicar nuevas transacciones agrupadas cada 5 segundos como en el ejemplo anterior, nuestro nuevo enfoque añade más salidas a nuestra transacción no confirmada existente, si es que hay alguna. Esto proporciona una solución increíblemente eficiente al problema mencionado anteriormente. Añadir más salidas reutiliza la entrada UTXO existente de la transacción no confirmada, siempre que el UTXO sea lo suficientemente grande. Esto significa que, en teoría, todo nuestro sistema de agrupación podría ejecutarse en un solo UTXO.
Cada vez que una de nuestras transacciones agrupadas se confirma on-chain, recibimos la salida de cambio de vuelta como un nuevo UTXO, que luego puede usarse para financiar el siguiente lote. Este enfoque esencialmente escala infinitamente (¡o al menos hasta el límite de tamaño de bloque de Bitcoin!), permitiéndonos manejar un creciente volumen de solicitudes de envío on-chain sin estar limitados por el número de UTXOs en nuestra billetera caliente. También mitiga el riesgo asociado con los picos de comisiones, asegurando una operación continua incluso durante la congestión de la red.
A través de este sistema, logramos un nivel sin precedentes de escalabilidad y fiabilidad en nuestras operaciones on-chain. Esto posiciona a Strike para crecer y servir a una base de usuarios global con millones de usuarios activos, ofreciéndoles el mejor servicio posible en términos de velocidad, costo y fiabilidad.
Nuestro compromiso de proporcionar a nuestros usuarios el servicio de mayor calidad en la industria es evidente en nuestro enfoque hacia la agrupación de pagos on-chain. Los usuarios pueden confiar en que sus pagos serán manejados con el mayor cuidado, eficiencia y seguridad, ya sea que opten por un envío Flexible, Estándar o Prioritario.
Los picos de comisiones en la red Bitcoin son un problema común que afecta la calidad de otros proveedores. Es común publicar transacciones con una comisión lo suficientemente alta como para apuntar a una confirmación en el próximo bloque solo para ver luego que el mercado general de comisiones sube significativamente. En estos casos, es probable que las transacciones publicadas no se confirmen durante varias horas y podrían potencialmente quedar atascadas mucho más tiempo o ser podadas. El protocolo Bitcoin tiene soluciones para permitirte "incrementar comisiones" en tu transacción para resolver esto, pero no es algo ubicuo para todas las aplicaciones y billeteras, y no es común que las billeteras aumenten automáticamente la comisión de tu transacción en tales casos sin cobrarte más por ello. ¡Strike simplifica todo esto para ti y proporciona flexibilidad para usuarios con diversas preferencias de tiempo!
En Strike, continuamente nos esforzamos por innovar y mejorar nuestros servicios. Nuestro sistema avanzado de agrupación para envíos on-chain es un testimonio de nuestra dedicación a la eficiencia y el servicio de alta calidad. Nuestro objetivo es ser los mejores en Bitcoin, y eso significa proporcionar a nuestros usuarios la mejor experiencia posible que los pagos de Bitcoin pueden ofrecer. Realmente creemos que nuestra experiencia de envío on-chain está bien encaminada hacia cómo los pagos on-chain funcionarán y deberían funcionar en el futuro. Sin embargo, siempre continuaremos iterando en nuestras soluciones para mejorarlas aún más y mostrarle al mundo todo lo que Bitcoin tiene para ofrecer.
No dudes en ponerte en contacto si tienes alguna pregunta o necesitas más detalles sobre nuestro sistema de agrupación on-chain y sus beneficios. Siempre estamos aquí para ayudar y proporcionar el mejor servicio posible a nuestros usuarios.
© 2024 Strike
De cero a bitcoin.
Legal