Anuncio de actualización de SVP Chain Testnet v9.9
SVP Chain Testnet planea actualizarse a v9.9 mediante gobernanza on-chain. Esta actualización introduce x/blockaddr, un módulo on-chain de lista negra de direcciones que permite restricciones aprobadas por gobernanza sobre transacciones iniciadas por direcciones SVP especificadas.
Calendario de actualización: Esta actualización se aplica a SVP Chain Testnet y usa el nombre de actualización on-chain v9.9. Está prevista para el 7 de agosto de 2026. El ID de la propuesta de gobernanza, el calendario de votación, la altura de actualización, el binario de lanzamiento y el checksum se anunciarán junto con la propuesta formal de actualización.
Una vez programada, la altura devuelta por el upgrade plan on-chain es la única altura de actualización autorizada.
Qué incluye: v9.9 añade el módulo blockaddr y su almacén de estado. Tras la actualización, la gobernanza puede añadir o eliminar direcciones SVP por lotes mediante propuestas. Cada entrada registra la dirección, el motivo, la altura de adición, la hora de adición y el ID de propuesta asociado.
Cuando una dirección está en la lista negra, el Ante handler rechaza las transacciones asociadas a ella, incluidas: transacciones Cosmos firmadas por la dirección; transacciones en las que la dirección es fee payer o fee granter; la dirección from de transacciones EVM; y la colocación, cancelación y otras transacciones CLOB firmadas por la dirección.
La comprobación se ejecuta antes de la ejecución de la transacción, por lo que las transacciones de direcciones en la lista negra no se incluyen para ejecución en un bloque. La lista negra acepta solo direcciones svp, y la gobernanza controla las altas y bajas.
Esta actualización no importa entradas históricas de lista negra. La lista negra está vacía inmediatamente después de la actualización.
Impacto en usuarios e integradores: Las cuentas, saldos, posiciones, órdenes y el estado de contratos inteligentes no incluidos en la lista negra de gobernanza no se ven afectados. Las interfaces estándar de transacciones Cosmos, EVM y CLOB permanecen sin cambios. Las transacciones asociadas a una dirección en la lista negra se rechazan. Las aplicaciones e integraciones deben gestionar el error "address is blocked". La lista negra no altera la lógica de negocio de los contratos inteligentes. Restringe el punto de entrada de transacciones de la dirección SVP correspondiente.
Tras la actualización, el estado de la lista negra se puede consultar con:
svpchaind query blockaddr blocked --node https://rpc-testnet.svpchain.org/ -o json
svpchaind query blockaddr is-blocked <svp-address> --node https://rpc-testnet.svpchain.org/ -o json
Requisitos para validadores: Voten durante el periodo de votación de la propuesta de gobernanza. Descarguen y verifiquen el binario v9.9 antes de la altura de actualización, y manténganlo en una ruta de staging separada. No reemplacen el binario usado por systemd antes de la altura de actualización. En la altura de actualización, el binario antiguo se detendrá con UPGRADE "v9.9" NEEDED. Reemplacen el binario y reinicien svpchaind según el upgrade plan coordinado. La cadena se reanuda en la altura de actualización después de que los validadores que representan más de dos tercios del poder de voto hayan completado el cambio de binario. Confirmen los mensajes de registro tras el reinicio: Running v9.9 Upgrade... y Successfully completed v9.9 Upgrade.
Verificación posterior a la actualización: La altura RPC más reciente sigue avanzando y los nodos no están poniéndose al día. query blockaddr blocked devuelve una lista negra vacía. Las transferencias Cosmos estándar, las transacciones EVM y las transacciones CLOB se pueden enviar con normalidad. Tras la aprobación de una propuesta posterior de gobernanza de lista negra, is-blocked coincide con el contenido de la propuesta y las transacciones de la dirección objetivo se rechazan.
Notas importantes: Los validadores no deben iniciar un binario que contenga el handler v9.9 antes de la altura de actualización, o el nodo se detendrá porque la actualización aún no se ha activado. Los validadores no deben usar un binario sin el handler v9.9 en la altura de actualización, o el nodo no podrá reanudarse. Confíen siempre en la propuesta de gobernanza on-chain, el upgrade plan y el checksum oficial del lanzamiento. No usen binarios no verificados ni una altura de actualización no confirmada.