Starlight: Un Protocolo de Canal de Pago de Capa 2 para Stellar

CAP-21 añade un conjunto de nuevas precondiciones que pueden ser añadidas a las transacciones. Las precondiciones son condiciones que deben ser satisfechas para que una transacción sea válida. Un ejemplo de una precondición bien conocida son los límites de tiempo de transacción: una transacción necesita ser enviada durante sus límites de tiempo. CAP-21 añade límites de ledger, número de secuencia mínimo, firmantes extra, así como la capacidad de crear bloqueos de tiempo relativos.

Starlight utiliza la precondición de número de secuencia mínimo para que grupos de transacciones puedan saltar números de secuencia en cuentas. Esto significa que los clientes de Starlight solo necesitan mantener el último acuerdo. No hay necesidad de almacenar o revocar acuerdos antiguos ya que son invalidados implícitamente por nuevos acuerdos.

Starlight utiliza el bloqueo de tiempo relativo (añadiendo tiempo relativo y retrasos de ledger entre transacciones) para que cuando un canal de pago se está cerrando, se pueda insertar un retraso entre el inicio del proceso de cierre y su finalización. Este retraso da al otro participante la oportunidad de actualizar el cierre al estado más reciente si el participante accidentalmente o intencionalmente inició el proceso de cierre usando un acuerdo antiguo.

La precondición de firmantes extra puede ser usada como una manera de adjuntar un componente hash sin estado de un HTLC (contrato de tiempo de bloqueo hash) a una transacción fuera de la red. Esperamos que Starlight pueda usar esto en el futuro para facilitar pagos que abarquen múltiples canales de pago.

CAP-40 extiende CAP-21 y añade un nuevo tipo de firmante a la red de Stellar – la firma de otra transacción. Starlight utiliza esto para autorizar de manera atómica múltiples transacciones revelando la firma de una transacción dentro de otra.

Esto hace seguro para un protocolo de contrato de múltiples participantes y múltiples transacciones (como Starlight) pasar múltiples transacciones en un solo mensaje en lugar de necesitar usar un protocolo de saludo de múltiples partes. Esto reduce el número de mensajes que los usuarios de canal de pago necesitan pasar de ida y vuelta, reduce el número de estados de canal potenciales, y aumenta el número de acuerdos que Starlight puede procesar por segundo.

El prototipo con el que hemos estado experimentando se basa en el protocolo Starlight e implementa buffering. Buffering no está definido en el protocolo Starlight, pero es un patrón que está bien adaptado para ser usado encima del protocolo. Los canales de pago seriales, como Starlight, usualmente están limitados por la latencia de la red en la que operan. Por ejemplo, si la latencia de la red es de 20 milisegundos, el máximo rendimiento posible sería de 50 transacciones por segundo. Buffering hace uso del ancho de banda de red disponible recopilando pagos durante esos 20 milisegundos y enviándolos juntos en un solo acuerdo. El límite se transforma en 50 acuerdos por segundo, y cada acuerdo puede contener muchos pagos. En lugar de obtener la confirmación de un pago cada 20 milisegundos, el canal puede entregar la confirmación de muchos pagos en un solo acuerdo en milisegundos.

Buffering es similar al procesamiento por lotes en sistemas de pagos tradicionales lentos, excepto que porque Starlight es rápido, los buffers son pequeños y transmiten rápidamente, por lo que mantiene rápida finalización.

Hemos medido Starlight produciendo 38 pagos por segundo sin buffer y 1.19 millones de pagos por segundo con buffer en 12 acuerdos por segundo. Esto fue observado entre dos participantes conectados a través de internet usando hardware de consumo y servicios de internet residenciales, cuando esos pagos fluyen consistentemente en una dirección.

Esta medición supera bien las necesidades de empresas que construyen en blockchain y empresas que están haciendo la transición de cargas de alto volumen existentes a blockchain. Estos hallazgos son interesantes para los usuarios de Stellar que transaccionan frecuentemente entre sí, donde los canales de pago son aplicables.

Todavía hay más trabajo por hacer y más para explorar en hacer Starlight listo para su uso. Starlight hoy especifica los mecanismos que dos usuarios pueden usar para construir y realizar pagos para un solo activo dentro de un canal de pago bidireccional half-duplex entre solo esos dos participantes. Muchas de las capas alrededor de esos mecanismos aún necesitan ser bien definidas, como cómo los participantes coordinan quién puede hacer el siguiente pago, formatos de mensajes, apretones de manos de conexión, etc.

Reconocemos las emocionantes posibilidades que un protocolo de Capa 2 como Starlight puede traer a Stellar, y queremos colaborar con el ecosistema más amplio para asegurar que esta tecnología proporcionará utilidad para los usuarios en el futuro. Si tienes alguna idea sobre qué casos de uso podría aplicar Starlight o comentarios en general, por favor comunícate aquí.

Para saber más sobre cómo funciona Starlight:

• Mira una demostración de Starlight y pagos con buffer en esta charla en Meridian donde entramos en detalle sobre cómo funcionan CAP-21, y CAP-40, y pagos con buffer.
• Lee la especificación del mecanismo Starlight.
  

Puedes experimentar con Starlight hoy con el prototipo Starlight Go SDK en devnet. El SDK proporciona una máquina de estados que implementa los mecanismos así como mensajería rudimentaria, gestión de conexiones y persistencia de estado que son adecuados para experimentación y pruebas. Nuestro repositorio de GitHub tiene todos los detalles y rastrea problemas a resolver y futuros desarrollos. Si eres un desarrollador, marca el repo y ¡participa!