Anunciando el Protocolo 19

El Protocolo 19 implementa dos Propuestas de Avance Central.

CAP-21 introduce un nuevo conjunto de precondiciones de transacción, que son requisitos opcionales que puedes agregar para controlar la validez de la transacción. Los límites de tiempo, que han sido durante mucho tiempo una precondición de transacción de Stellar, te permiten crear transacciones que solo son válidas en una ventana específica basada en tiempo. Las nuevas precondiciones del Protocolo 19 te permiten crear transacciones que omiten números de secuencia, establecen límites de libro mayor, imponen retrasos de tiempo y libro mayor relativos (también conocidos como "bloqueos de tiempo relativos"), y requieren firmantes adicionales (por ejemplo, bloqueos de hash).

CAP-40 añade un nuevo tipo de firmante que permite a múltiples partes construir un conjunto de transacciones para firmar que garantiza si una transacción se firma, autoriza y envía, se revela información que permite autorizar todas las demás transacciones en el conjunto también.

Los cambios del Protocolo 19 fueron diseñados para facilitar la creación de canales de pago, que son protocolos de Capa 2 que soportan casos de uso de alto rendimiento. Los canales de pago permiten que dos partes que transaccionan frecuentemente entre sí muevan la mayor parte de su actividad fuera de la cadena, mientras aún registran los saldos iniciales y el asentamiento final en la cadena.

Generalmente, los canales de pago dependen de una secuencia estructurada de transacciones. Dos partes abren un canal con una transacción en cadena que da a ambas partes control sobre las cuentas de asentamiento. Luego, pasan transacciones de ida y vuelta, las validan y las firman fuera de la cadena. Cuando una de las partes está lista para liquidar, declara su intención de cerrar el canal, y hay un período de tiempo para que la otra parte objete. De esa manera, la parte notificada tiene recurso si hay una disputa, o la declaración de cierre es prematura, maliciosa o errónea. Si todo está bien, la transacción de liquidación se envía a la red, y la transferencia final de fondos ocurre en la cadena.

Crear una cuenta que ambas partes controlen siempre ha sido fácil usando las capacidades multi-firma integradas de Stellar, pero antes del Protocolo 19, era difícil manejar el resto de ese proceso. Una transacción solo podía ser válida si el número de secuencia de la cuenta fuente era exactamente 1 mayor que el número de secuencia utilizado para la transacción anterior, lo que significaba que dos partes intercambiando transacciones no podían incrementar el número de secuencia en un canal fuera de la cadena. Tampoco podías agregar un retraso de tiempo relativo a las transacciones, lo que significaba que no había forma de asegurar que hubiera una ventana para objetar o invalidar una transacción de liquidación. Finalmente, combinar firmas para autorizar una transacción requería un apretón de manos de varias partes que requería mensajes adicionales y ralentizaba las cosas. Al agregar nuevas precondiciones y un nuevo tipo de firmante, el Protocolo 19 resuelve todos esos problemas.

Me doy cuenta de que esa explicación es un poco abstracta. Afortunadamente, hay un prototipo concreto de un canal de pago del Protocolo 19 en el que puedes profundizar para ver cómo encaja todo.

Antes de implementar los cambios del Protocolo 19 en producción, los ingenieros de SDF utilizaron una devnet de pruebas para construir un prototipo funcional de canal de pago llamado Starlight. Al aplicar la precondición de número mínimo de secuencia para omitir números de secuencia, agregar retrasos de tiempo y libro mayor relativos para crear un bloqueo de tiempo relativo, y usar el nuevo tipo de firma para autorizar atómicamente múltiples transacciones, Starlight probó todos los cambios del Protocolo 19, y los resultados fueron bastante asombrosos…

En pruebas usando hardware de consumo y conexiones a internet residenciales, Starlight fue capaz de manejar 1.19 millones de pagos por segundo entre dos usuarios. ¡Que es mucho!

Starlight está bien documentado, es de código abierto y está disponible para cualquiera que quiera arremangarse y experimentar. Para más información, consulta:

• El post del blog de Starlight, que resume cómo los cambios del Protocolo 19 permitieron a los ingenieros de SDF construir el prototipo
• La charla técnica de Starlight Meridian, que incluye una demostración en vivo de canales de pago bidireccionales
• La especificación del mecanismo de Starlight, que proporciona detalles técnicos sobre cómo funciona Starlight
• El Repositorio Github de Starlight, que permite a cualquier interesado profundizar en el código y experimentar con canales de pago

Starlight sigue siendo un prototipo, y hay mucho trabajo por hacer antes de que esté listo para su uso en producción. Con la llegada del Protocolo 19, esperamos ver más experimentación y compromiso en el ecosistema, y escuchar más sugerencias sobre cómo mejorar y hacer uso de Starlight. ¿Tienes una idea que te gustaría compartir? Agrégala a la lista de casos de uso.

Aunque el Protocolo 19 fue diseñado para soportar canales de pago similares a Starlight, eso no es lo único que las nuevas precondiciones te permiten construir.

Kaladin, por ejemplo, está construyendo un sistema de concentradores y radios que conecta blockchains para permitir el intercambio barato y transparente de activos sin depender de un intermediario de confianza. Su solución se basa en canales de estado, que son un superset de canales de pago, y su integración con Stellar aprovecha las precondiciones del Protocolo 19 para agregar un retraso entre iniciar y finalizar el cierre de un canal, y para crear acuerdos de bloqueo de tiempo hash, que su protocolo utiliza para sincronizar intercambios.

La sección de Razonamiento de Diseño de CAP-21 también describe varios otros casos de uso, así que si estás interesado en explorar nuevas posibilidades, y quieres algo de inspiración completa con detalles técnicos, es un gran lugar para comenzar. Además de canales de pago bidireccionales, describe cómo crear:

• Canales de pago unidireccionales
• Contratos Bloqueados por Tiempo Hash (HTLCs)
• Nuevas soluciones de recuperación de claves
• Mecanismos de envío de transacciones paralelas
• Mecanismos para números de secuencia de cuenta determinísticos en la creación

¿Interesado en saber más? Consulta el canal #protocol-19 en el Discord de Desarrollo de Stellar. Hay una discusión activa y en curso mientras trabajamos para coordinar el desarrollo y la adopción del Protocolo 19.