Saltar al contenido principal

Actualizar la red

La red misma tiene configuraciones a nivel de red que pueden ser actualizadas.

Esto se realiza mediante validadores que votan y coinciden con nuevos valores de la misma manera en que se alcanza el consenso para los conjuntos de transacciones, etc.

Un nodo puede ser configurado para votar por actualizaciones usando el endpoint upgrades. Consulta Comandos para más información.

Las configuraciones de la red son:

  • la versión del protocolo utilizado para procesar transacciones;
  • el número máximo de transacciones que pueden ser incluidas en un cierre de ledger dado. Configuración separada para transacciones Soroban y clásicas;
  • el costo (tarifa) asociado con el procesamiento de operaciones;
  • la reserva base utilizada para calcular el saldo de lumen necesario para almacenar datos no Soroban en el ledger; y
  • configuraciones de red Soroban generalizadas almacenadas en ConfigSettingsEntries.

Cuando el tiempo de la red es posterior al upgradetime especificado en el comando upgrades, el validador votará para actualizar la red al valor especificado en ese comando upgrades. Si el tiempo de la red ha pasado el upgradetime por más de 12 horas, la actualización será ignorada.

Cuando un validador está listo para cambiar valores de la red, la salida de info contendrá información sobre la votación.

Para que un nuevo valor sea adoptado, se necesita alcanzar el mismo nivel de consenso entre nodos que para los conjuntos de transacciones.

Notas importantes sobre las configuraciones a nivel de red​

Los cambios en las configuraciones a nivel de red deben ser orquestados adecuadamente entre validadores así como nodos no validadores. El proceso general que los validadores han utilizado para proponer y votar sobre las configuraciones de la red es el siguiente:

  1. Un cambio es revisado entre operadores (los cambios pueden ser agrupados).
  2. Se elige una fecha efectiva en el futuro para que el cambio surta efecto (controlada por el parámetro upgradetime del comando upgrades).
  3. Si es aplicable, se envía comunicación a todos los usuarios de la red.

Esta cuidadosa orquestación juega un papel importante en el funcionamiento de la red Stellar. Este proceso de planificación se lleva a cabo para evitar comportamientos indebidos de nodos, dar a conocer nuevas características incluidas en una actualización del protocolo para que el ecosistema esté al tanto y pueda aprovecharlas, y también le da al ecosistema tiempo para prepararse para cambios disruptivos que pueden tener un efecto (ya sea directa o indirectamente) en sus integraciones con Stellar. Un plan inapropiado puede causar incidencias tales como:

  • nodos que no alcanzan consenso (también conocido como "quedarse atascados"), y teniendo que usar el historial para reintegrarse
  • la reconfiguración de la red que toma efecto en un tiempo no determinístico (causando que las tarifas cambien antes de lo programado, por ejemplo)

Para más información, consulta cómo el versionado tiene en cuenta las actualizaciones de red en el documento versioning.md en el repositorio de GitHub de stellar-core.

Actualización de configuraciones Soroban​

El mecanismo para actualizar configuraciones Soroban es más complejo que actualizar algo como la baseReserve. El endpoint upgrades en stellar-core requerirá que los validadores voten sobre un ConfigUpgradeSetKey serializado, que contiene un contractID y el hash SHA-256 del ConfigUpgradeSet que se aplicará a las configuraciones existentes. El ConfigUpgradeSet serializado debe existir en el ledger como Temporary ContractData bajo el contractID especificado anteriormente y con la clave SCVal Bytes que contiene el hash SHA-256 del ConfigUpgradeSet.

Esto significa que alguien que desee proponer una actualización de configuración necesitará crear un contrato inteligente que escriba los bytes del ConfigUpgradeSet en ContractData (recuerda, se requiere una entrada Temporary), invocarlo para escribir el xdr de actualización, y luego compartir el ConfigUpgradeSetKey serializado para votar.

Tenemos mucho más detalle en la siguiente página sobre cómo elaborar una propuesta de actualización para estas configuraciones. Asegúrate de leer y comprender eso.

Ejemplo de comando de actualización​

Como ejemplo, aquí está el comando upgrades utilizado para actualizar la versión del protocolo a la versión 9 en el 31 de enero de 2018.

# arm the node to vote for the upgrade
stellar-core http-command 'upgrades?mode=set&upgradetime=2018-01-31T20:00:00Z&protocolversion=9'
# view the status of the node
stellar-core http-command info

En este punto, info te dirá que el nodo está configurado para votar por esta actualización:

"status" : [
  "Armed with network upgrades: upgradetime=2018-01-31T20:00:00Z, protocolversion=9"
]