Descentralización, al doble

Este blog es parte de una serie continua sobre el progreso realizado en el mapa de ruta 2025 de SDF y las iniciativas clave que estamos impulsando para mejorar la usabilidad, expandir la adopción y fortalecer el ecosistema de Stellar.

Hay un hito en el Q4 en el mapa de ruta 2025 de Stellar Development Foundation (SDF) que puede parecer un poco oscuro, pero que tiene grandes implicaciones para la salud y descentralización de la red de Stellar:

Resiliencia de Nivel 1 2x

Actualmente tenemos 7 organizaciones de nivel 1 que permiten que la red siga operativa con 2 fallos. Para fortalecer la gobernanza abierta y la resiliencia, planeamos agregar 6 más a través de mejoras en la superposición y el consenso, alcanzando 13 para finales de 2025.

Ahora mismo, Stellar puede sostener el fallo operacional de 2 organizaciones; para fin de año, el objetivo es duplicar eso. ¿Qué significa eso? ¿Por qué ahora? ¿Por qué debería importarte? Sigue leyendo para descubrirlo.

Las organizaciones de Nivel 1 son equipos que construyen en Stellar y ejecutan validadores que, parafraseando los documentos para desarrolladores, soportan la seguridad y la vitalidad de la red de Stellar debido a que la mayoría de las otras organizaciones requieren su acuerdo. Para entender qué significa eso, es útil entender cómo funcionan los validadores en blockchain en general, y cómo funcionan específicamente en Stellar.

Validadores son servidores conectados que se comunican entre sí, mantienen un libro mayor común y trabajan sincronizados para aplicar transacciones y actualizar ese libro mayor. Sus interacciones son recurrentes y programáticas, y por lo tanto, el software que ejecutan implementa reglas diseñadas para prevenir el robo, el engaño y el doble gasto, así como protocolos destinados a hacer cumplir esas reglas. En algún cadencia periódica — que varía de blockchain a blockchain — un protocolo selecciona un validador para ensamblar un bloque de transacciones, que luego propone a otros validadores. Ellos verifican su validez, lo ratifican y lo aplican para actualizar el estado del libro mayor.

En la prueba de trabajo — el protocolo que utiliza Bitcoin — el derecho a agregar bloques va al primer validador que completa un problema matemático de fuerza bruta, junto con una recompensa de token de red. Demuestras que hiciste el trabajo para resolver el problema, propones un bloque de transacciones que sigue las reglas, es aceptado por otros validadores, obtienes un bitcoin. En la prueba de participación — el protocolo que la mayoría de las blockchains utiliza en este punto — el protocolo selecciona a un validador al azar para agregar un bloque, pero para ser elegible cada validador tiene que bloquear tokens del protocolo en reserva. Cuando un validador es seleccionado y propone un bloque que es aceptado por otros validadores, es recompensado con tokens del protocolo. Si falla en proponer un bloque válido, el protocolo recorta tokens apostados como penalización. Tanto la prueba de trabajo como la prueba de participación se basan en incentivos financieros para fomentar un buen comportamiento: asumen que la combinación de recompensas y penalizaciones hace que valga más la pena seguir las reglas al producir un bloque que romperlas.

Stellar es diferente. En el Protocolo de Consenso de Stellar — que es un protocolo de prueba de acuerdo — cada validador mantiene una lista de los otros validadores en los que confía, y solo interactúa con los validadores en esa lista para proponer y aceptar bloques. Para crear un nuevo bloque, los validadores intercambian mensajes con los otros validadores en su lista para compartir transacciones candidatas, seleccionar un líder para ensamblar un bloque con esas transacciones, y pasar ese bloque a través de una serie de votaciones antes de ratificarlo y aceptarlo. Cuanto más aparece un validador en las listas de otros validadores, más se considera cuando propone y acepta bloques, más influencia tiene sobre la red.

Crucialmente, la prueba de acuerdo requiere que los humanos configuren sus validadores para confiar en otros validadores, lo cual hacen porque confían en los humanos que ejecutan esos validadores. Para hacer eso posible, los operadores de validadores de Stellar se identifican públicamente. La reputación en el mundo real del operador, que suele ser una organización que hace negocios en Stellar, es lo que está en juego: si no siguen las reglas, todos lo saben. Por eso hablamos de organizaciones de nivel 1 organizaciones: en Stellar, un validador manifiesta la identidad de una organización.

Hay grandes ventajas en la prueba de acuerdo — no consume energía como la prueba de trabajo o requiere fondos por adelantado como la prueba de participación; no permite la participación anónima, por lo que es resistente a ataques Sybil; no se basa en incentivos financieros, por lo que evita situaciones donde hacer trampas es más lucrativo que jugar según las reglas — y puedes leer todo sobre eso en la reciente publicación La Ventaja de Seguridad de Stellar. Pero por ahora, veamos cómo son realmente esas configuraciones de confianza para poder entender qué necesita cambiar para alcanzar el objetivo 2x.

Las configuraciones de confianza de los validadores son públicas, y puedes verlas — así como un gráfico de las conexiones entre validadores — en exploradores de red como Raar o Stellarbeat. Aquí, por ejemplo, está la configuración de confianza para los nodos validadores de SDF:

• Conjunto de quórum con umbral 5
  • Blockdaemon Inc. con umbral 2
  • Stellar Development Foundation con umbral 2
  • SatoshiPay con umbral 2
  • Franklin Templeton con umbral 2
  • LOBSTR con umbral 2
  • Creit Technologies LLP con umbral 2
  • Public Node con umbral 2

Actualmente, SDF incluye 7 organizaciones en nuestro conjunto de quórum (incluyéndonos), y nuestros validadores están configurados para aceptar un bloque si cualquier combinación de 5 de esas orgs también lo acepta. Nota: cada una de esas organizaciones ejecuta 3 validadores para redundancia; cualquier 2 son suficientes para representar su acuerdo. Por otro lado, eso significa que los validadores de SDF no podrán aceptar un bloque si 3 de esas orgs no están disponibles o no están de acuerdo, en cuyo punto se detienen. En otras palabras, como está configurado, SDF tiene una tolerancia a fallos de 2 organizaciones. ¿Qué pasa con la red en su conjunto?

La red de Stellar en su conjunto es un clúster de validadores individuales — cada uno de los cuales tiene una configuración como la de arriba — que cohesiona porque esas configuraciones tienen validadores en común. Uno de los conceptos clave detrás del Protocolo de Consenso de Stellar, que el Papel de Investigación SCP llama "la hipótesis de Internet," es que la coherencia de la red emerge naturalmente porque los participantes de la red se conectan para interoperar y hacer negocios. Como Internet "que todos entienden que significa la red IP conectada transitivamente más grande" se deriva de un deseo común de transmitir información, así Stellar se deriva de un deseo común de transmitir valor. Para usar la red, los participantes encuentran una manera de conectarse a otros participantes; al encontrar una manera de conectarse, crean la red.

Actualmente, la red cohesiona alrededor de las mismas 7 organizaciones que SDF tiene en nuestro conjunto de quórum. De una forma u otra, esas son las organizaciones que aparecen en cada configuración de validador individual, lo que significa que cada validador individual requiere un acuerdo suficiente de esas organizaciones al agregar bloques. Son los puntos de intersección de los cuales se deriva la red. Soportan la seguridad y la vitalidad de la red de Stellar debido a que la mayoría de las otras organizaciones requieren su acuerdo. Son las organizaciones de nivel 1.

Y ahora mismo, las organizaciones de nivel 1 limitan sus conjuntos de quórum a una a otra, lo que significa que no requieren entrada o acuerdo de orgs adicionales para agregar un bloque. Como resultado, la red en su conjunto tiene la misma tolerancia a fallos que los validadores de SDF: si 3 de las orgs de nivel 1 se caen, la red se detiene. El objetivo del mapa de ruta es duplicar esa tolerancia a fallos, y entraremos en cómo hacer que eso suceda, pero primero, es útil entender cómo llegamos a donde estamos.

En los primeros años de Stellar, no había muchos recursos o herramientas para los validadores. El descubrimiento no era óptimo — solo había una lista en Github donde la gente podía agregar sus validadores — y aunque había una guía de administración en los documentos para ayudarte a instalar Stellar Core y unirte a la red, no había mucha instrucción sobre cómo pensar en los quórum o cómo construir un conjunto de quórum razonable. Como resultado, los conjuntos de quórum de los validadores eran mejores conjeturas configuradas a ciegas, y realmente solo había una organización común a todos ellos: SDF. SDF era el único punto de intersección de quórum, lo que también significa que era un único punto de falla. Si SDF se desconectaba, la red se detendría.

Dado que una ventaja clave de la blockchain es que no tiene un único punto de falla, estaba bastante claro para cualquiera que estuviera prestando atención — que, concedido, era un grupo bastante pequeño en ese momento — que la excesiva dependencia de SDF no era ideal. En 2019 SDF comenzó a coordinarse con los validadores para mejorar la resiliencia de la red. Conectamos a participantes clave del ecosistema que estaban ejecutando validadores y los pusimos a hablar, y comenzaron a incluirse mutuamente en sus conjuntos de quórum. Para 2019, 4 organizaciones además de SDF surgieron como validadores capaces: Satoshipay, Lobstr, Coinqvest y Keybase. Comenzamos a socializar la recomendación de ajustar los conjuntos de quórum para incluir esas 4 orgs.

Las cosas tuvieron un comienzo difícil — el 15 de mayo de 2019, antes de que las nuevas configuraciones de quórum pudieran realmente asentarse, algunas de las orgs recién recomendadas apagaron sus validadores para mantenimiento al mismo tiempo, lo que causó que la red se detuviera por 67 minutos — pero con un poco de coordinación, colaboración y esfuerzo, logramos estabilizar las cosas. Actualizamos Stellar Core para automatizar partes de la configuración de quórum, lanzamos herramientas para el monitoreo de la red y la verificación de intersección de quórum, creamos un canal dedicado para comunicarnos con orgs en el conjunto de quórum de SDF, y definimos los requisitos operativos para Tier 1, incluyendo el requisito de que las orgs de tier-1 ejecuten 3 validadores para redundancia. Todos comenzaron a seguir un proceso común para identificar sus validadores, y Stellarbeat descentralizó el descubrimiento de validadores. Y como medida de precaución, las orgs de tier-1 recién ungidas acordaron limitar sus conjuntos de quórum entre sí.

Para enero de 2020, Tier 1 había aumentado a 7 orgs, y aunque ha habido algunas sustituciones a lo largo de los años a medida que las organizaciones iban y venían, ahí es donde ha estado desde entonces. La red no se ha detenido de nuevo — incluso cuando los validadores de SDF tuvieron problemas por un día — y los validadores han procesado con éxito decenas de millones de libros mayores, aplicado miles de millones de operaciones y actualizado el protocolo 11 veces.

A pesar de esa estabilidad, sin embargo, hay un sentimiento predominante en el ecosistema de que la red actual con 7 validadores de tier-1 y una tolerancia a fallos de 2 orgs no es lo suficientemente robusta. ¡SDF está de acuerdo! Debería haber más validadores de alta calidad y una mayor tolerancia a fallos.

Cuántos más y quiénes deberían ser, eso es lo que todavía necesitamos averiguar. Es difícil medir la descentralización en Stellar — está asegurada por reputación, y un montón de validadores sospechosos en los que nadie confía no benefician a la red en absoluto, mientras que una sola organización de confianza para todos sí lo hace — y aún no está claro cuya participación como validador será suficiente para asegurar los miles de millones o billones en valor que un ecosistema próspero requerirá. Pero ya es hora de pensar todo eso, y de comenzar a esbozar las posibilidades. Y mientras lo hacemos, también podemos tomar medidas en lo que seguramente es la dirección correcta. Podemos duplicar la tolerancia a fallos actual, y partir de ahí. De ahí el objetivo 2025 para duplicar la Resiliencia de Tier 1.

Para hacer eso, hay tareas que abordar, algunas de las cuales ya están completas, algunas de las cuales están en curso. Específicamente, necesitamos:

Hacer cambios técnicos en el software de validadores (¡completo!)

Los validadores intercambian un montón de mensajes para proponer y ratificar bloques, y para hacer eso, usan una pieza de Stellar Core llamada el overlay. Es una red peer-to-peer que conecta a los validadores y propaga transacciones, bloques y votos de consenso. Las organizaciones de Tier-1 tienen mucho que comunicarse entre sí, por lo que golpean el overlay mucho más duro que los validadores no tier-1. Hasta hace poco, el overlay realmente no estaba preparado para el estrés adicional que crearía duplicar Tier 1.

Pero debido a los cambios en el overlay introducidos en Stellar Core v22.1.0 y las mejoras de rendimiento introducidas en Stellar Core v22.3.0, ¡lo está!

Realizar pruebas para asegurarse de que el crecimiento de Tier 1 no introduzca latencia (¡completo!)

¿Cómo sé que el overlay está preparado para el estrés adicional que creará duplicar Tier 1? Porque lo probamos. Antes de avanzar con un plan para aumentar radicalmente la participación en la red, modelamos los efectos en un entorno de laboratorio. Usamos algo llamado Supercluster para simular los efectos de duplicar Tier 1, y los resultados mostraron que los libros mayores deberían continuar cerrando sin introducir demasiada latencia. Si quieres jugar con Supercluster tú mismo, está aquí.

En este punto, dado las mejoras al overlay y las pruebas exitosas, no hay bloqueadores técnicos. ¡Woohoo!

Construir un pipeline de candidatos calificados (completo, y siempre en curso)

Hace un año, no había muchas organizaciones que estuvieran seriamente interesadas en ejecutar validadores. Pero la llegada de los contratos inteligentes en Stellar y el subsiguiente crecimiento del ecosistema alentaron a un grupo de nuevos proyectos a poner en marcha validadores, y basándonos en la observación casual, al menos 10 de ellos cumplen con los requisitos operacionales de tier-1.

Sí: SDF continuará fomentando la participación en la red, y trabajará con organizaciones interesadas en ejecutar validadores para ayudarles a incorporarse, alcanzar y mantener la grandeza. Pero ya hay suficientes candidatos ahora para desbloquear el objetivo.

Explicar cómo SDF elige agregar organizaciones a su conjunto de quórum (en curso)

Dicho esto, cumplir con los requisitos operacionales no es suficiente para que SDF agregue una org a nuestro conjunto de quórum. Realmente necesitamos evaluarlos contra criterios comerciales para entender si confiamos en ellos. ¿Quién es la org? ¿Son legítimos? ¿Capaces? ¿Alineados con la misión? ¿Agregarlos mejora la salud y descentralización de la red?

A medida que comenzamos a pensar en esas preguntas, nos dimos cuenta de que aún no habíamos formalizado el proceso que usamos para agregar orgs a nuestro conjunto de quórum, así que decidimos escribirlo y compartirlo con el resto del ecosistema. El objetivo de hacer eso es dejar claras nuestras motivaciones, y ofrecer un modelo a otras orgs que también necesiten tomar decisiones de conjunto de quórum. Lee todo sobre ello aquí.

Agregar candidatos calificados al conjunto de quórum de SDF (próximo)

Ahora que estamos técnicamente desbloqueados y tenemos un pipeline de candidatos y un método para evaluarlos, podemos realizar una revisión y agregar cualquiera que califique al conjunto de quórum de SDF. Cuando lo hagamos, también nos pondremos en contacto con otros validadores, y específicamente con otras orgs de tier-1. En última instancia, cada uno necesitará decidir si agregar nuevas orgs a su conjunto de quórum, y no estamos seguros de cómo serán esas discusiones, o dónde encontraremos (fuera de línea) acuerdo. ¡Será emocionante participar! ¡Y te mantendremos informado a medida que lo hagamos!

Algunas palabras finales: el punto de todo esto — las mejoras técnicas, el proceso explícito para evaluar candidatos, el objetivo general de duplicar la resiliencia de tier-1, incluso esta publicación de blog en sí misma — es ayudar a mejorar la salud y descentralización de la red, lo cual es importante para preparar el futuro de la red para que pueda manejar el uso y crecimiento continuos. En SDF, queremos que la red asegure suficiente valor y procese suficientes transacciones para lograr nuestra misión de crear acceso equitativo al sistema financiero global, y eso es un pedido bastante grande. Este trabajo será siempre continuo. El objetivo de 2025 es solo el siguiente paso. ¿Listo para tomarlo? ¡Aquí vamos…