Descentralización, al Doble

Este blog es parte de una serie continua sobre el progreso realizado en el mapa de ruta 2025 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 permanezca operativa con 2 fallos. Para fortalecer la gobernanza abierta y la resiliencia, planeamos añadir 6 más a través de mejoras en el overlay y el consenso, alcanzando 13 para finales de 2025.

Ahora mismo, Stellar puede sostener el fallo operativo 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 que ejecutan validadores que, parafraseando los documentos de desarrolladores, soportan la seguridad y la vitalidad de la red de Stellar debido al hecho de que la mayoría de las otras organizaciones requieren su acuerdo. Para entender lo que eso significa, es útil entender cómo funcionan los validadores en blockchain en general, y cómo funcionan en Stellar específicamente.

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 alguna 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 añadir 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 utilizan en este punto — el protocolo selecciona a un validador al azar para añadir 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 sea más valioso 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 a partir de esas transacciones y pasar ese bloque por una serie de votaciones antes de ratificarlo y aceptarlo. Cuanto más aparece un validador en las listas de otros validadores, más se le considera al proponer y aceptar 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: 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 depende de 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 entender qué necesita cambiar para alcanzar el objetivo de 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, configurado de esta manera, 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 conjunto 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 operar entre sí 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 con 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 individual de validador, lo que significa que cada validador individual requiere suficiente acuerdo de esas organizaciones al añadir 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 al hecho de 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 entre sí, lo que significa que no requieren la entrada o el acuerdo de orgs adicionales para añadir 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 administrador 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 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 operacionales 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 nuevamente — 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 en la que todos confían 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 para 2025 de 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 al 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 la capa de superposición. Es una red peer-to-peer que conecta validadores y propaga transacciones, bloques y votos de consenso. Las organizaciones de Tier-1 tienen mucho que comunicarse entre sí, por lo que golpean la capa de superposición mucho más duro que los validadores no tier-1. Hasta hace poco, la capa de superposición realmente no estaba preparada para el estrés adicional que duplicar Tier 1 crearía.

Pero debido a cambios en la capa de superposición introducidos en Stellar Core v22.1.0 y mejoras de rendimiento introducidas en Stellar Core v22.3.0, ¡ahora lo está!

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

¿Cómo sé que la capa de superposición está preparada para el estrés adicional que duplicar Tier 1 creará? Porque lo probamos. Antes de seguir adelante 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 cerrándose sin introducir demasiada latencia. Si quieres jugar con Supercluster tú mismo, está aquí.

En este punto, dado las mejoras a la capa de superposición y las pruebas exitosas, no hay bloqueadores técnicos. ¡Woohoo!

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

Hace un año, no había muchas organizaciones que se tomaran en serio la ejecución de validadores. Pero el advenimiento de contratos inteligentes en Stellar y el crecimiento subsiguiente 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á alentando la participación en la red, y trabajará con organizaciones interesadas en ejecutar validadores para ayudarles a embarcarse, alcanzar y mantener la grandeza. Pero hay suficientes candidatos ahora mismo 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, por lo que decidimos escribirlo y compartirlo con el resto del ecosistema. El objetivo de hacer eso es hacer claras nuestras motivaciones, y ofrecer un modelo a otras orgs que también necesitan 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 técnicamente estamos desbloqueados y tenemos un conducto 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í — es ayudar a mejorar la salud y descentralización de la red, lo cual es importante para proteger 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 alto. Este trabajo será siempre continuo. El objetivo de 2025 es solo el siguiente paso. ¿Listo para tomarlo? Aquí vamos...