Registro de compromisos firmados: diseño, estado actual y límites
El registro de compromisos de registros de MemChain ordena en bloques firmados compromisos opacos con registros de memoria cifrados. Está congelado desde el 2026-07-13 porque su único coordinador fue dado de baja y el traspaso requiere la firma de ese coordinador; nunca proporcionó consenso.
El registro de compromisos de registros de MemChain es una cadena de bloques firmados que registra el orden de compromisos opacos con registros de memoria cifrados. Actualmente está congelado. No ha producido ningún bloque desde el 2026-07-13, porque su único coordinador autorizado fue dado de baja y el diseño no puede transferir la autoridad a otro nodo sin la firma de ese coordinador. Nunca ha proporcionado consenso global.
Estado actual
| Elemento | Estado |
|---|---|
| Bloques | 33 bloques. El último se produjo el 2026-07-13 |
| Coordinador | Un único nodo coordinador fijado (US1), dado de baja el 2026-10-03 |
| Seguidores | Siguen conservando y auditando el historial. Cuando intentan sincronizarse, informan active_coordinator_unavailable |
| Traspaso del coordinador | Requiere una prueba firmada tanto por el coordinador anterior como por el nuevo. El código de producción no tiene forma de emitirla |
| Bloques nuevos | Ninguno. El registro está congelado |
| Consenso | Ninguno. No hay elección de bifurcación, finalidad por quórum ni confirmación en una cadena pública |
Los agregados en vivo se publican en GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/ bajo data.protocol_status.memory_chain. Los campos que reflejan el estado actual son coordinator_nodes, follower_nodes, verified_nodes, max_verified_tip_height y block_confirmation_state. Algunos campos de texto descriptivo de esa respuesta todavía describen el diseño de testigos previsto en lugar del estado actual, así que lea los campos numéricos.
Qué registra el registro
Cada bloque contiene un encabezado (versión del protocolo, ID de la cadena, altura, marca de tiempo, hash del bloque anterior, raíz de Merkle, número de registros y clave del proponente), una lista de ID de registro y la firma Ed25519 del proponente sobre el encabezado.
Un ID de registro es un hash SHA-256 calculado sobre un registro de memoria cifrado: la clave del propietario, la marca de tiempo, la capa, las etiquetas, el origen y el texto cifrado. El registro nunca contiene contenido de memoria, claves de descifrado ni texto plano. Puede demostrar que un registro opaco existía, y en qué orden, a una altura determinada. No puede mostrar lo que dice un registro, y no almacena el registro.
Los registros de memoria en sí se describen en MemChain y Blind Vault.
Cómo funciona el diseño
- Un coordinador anexa los bloques. Exactamente un nodo configurado puede anexar. Firma cada bloque y mantiene una marca de nivel máximo firmada junto a su base de datos, de modo que una copia más antigua del archivo de la base de datos se detecta al arrancar.
- Los seguidores replican y auditan. Cada seguidor obtiene páginas solo del coordinador fijado. Comprueba las firmas, la continuidad de la altura y los enlaces de hash, y se detiene ante una reversión, una bifurcación o errores de firma. Nunca fusiona historiales en conflicto.
- Los testigos comprueban si hay reversiones. Los nodos testigo fijados por el operador devuelven puntos de control firmados. Al arrancar, un punto de control que muestre que un testigo tiene un historial posterior o divergente detiene al coordinador antes de que abra sus escuchas.
- Una concesión opcional limita los escritores duplicados. Si está habilitada, el coordinador solo puede producir bloques mientras todos los testigos fijados le concedan una concesión breve de 60 a 300 segundos. Cuando la concesión vence, la producción se detiene.
- El traspaso usa una prueba con doble firma. La autoridad pasa a un nuevo coordinador solo mediante una prueba
RecordCoordinatorHandoverV1firmada tanto por el coordinador saliente como por el entrante. Los bloques históricos nunca se reescriben.
El requisito de testigos y la concesión están ambos desactivados de forma predeterminada en el software de nodo.
Por qué está congelado
El diseño depende de un único coordinador. Ese coordinador fue dado de baja el 2026-10-03. Un traspaso requiere su firma, y ninguna ruta del código de producción crea una prueba de traspaso. Por tanto, los seguidores no pueden aceptar un nuevo proponente y no se pueden añadir bloques nuevos. Un único coordinador es un punto único de fallo, y este es ese fallo.
La memoria no se ve afectada. El registro solo contiene compromisos. Sus recuerdos cifrados se almacenan en su dispositivo y, opcionalmente, en el nodo al que se conecta, con independencia del registro.
Comprobación de los bloques históricos
Los 33 bloques históricos siguen siendo verificables:
- Todo nodo que tiene una copia la audita al arrancar. Decodifica cada bloque almacenado, verifica la firma del proponente, la continuidad de la altura, los enlaces al hash anterior y el índice de registros, y se niega a arrancar si alguna comprobación falla. Los resultados aparecen como agregados (
verified_nodes,max_verified_tip_height) en el endpoint público de estadísticas. aeronyx-server memchain verify-aofrealiza una comprobación independiente. Verifica el archivo de solo anexado heredado de MemChain del nodo (el entramado, los ID de contenido, las raíces de Merkle y la ascendencia de los bloques) y solo imprime recuentos agregados. No lee el registro de compromisos, que se almacena en la base de datos SQLite del nodo.
sudo aeronyx-server memchain verify-aof --config /etc/aeronyx/server.toml
Límites
- Un único coordinador significa un único punto de fallo. Cuando no está disponible, no se registran compromisos nuevos.
- No hay consenso, elección de bifurcación ni finalidad. Un orden firmado no es un acuerdo entre partes independientes.
- Los testigos los fija el operador. Hoy todos los nodos de producción los opera AeroNyx, por lo que las comprobaciones de testigos no demuestran independencia.
- No es un registro de tokens, una plataforma de contratos inteligentes ni un sistema de prueba de participación.
- Un compromiso demuestra que un registro opaco existió. No demuestra que el registro siga almacenado en algún lugar.
Qué está previsto
El diseño de reemplazo elimina el coordinador único. Cada nodo mantendrá su propio registro firmado, otros nodos lo replicarán y los pares atestiguarán mutuamente los registros. Este es el modelo que la Directory Chain ya usa hoy para los descriptores de nodo. No se ha fijado ninguna fecha de lanzamiento. Los 33 bloques históricos siguen siendo auditables como se describe arriba.
<!-- faq:start -->Preguntas frecuentes
¿Está en funcionamiento el registro de compromisos de AeroNyx?
No. No ha producido ningún bloque desde el 2026-07-13. Su único coordinador fue dado de baja el 2026-10-03, y el código de producción no tiene ninguna ruta para transferir la autoridad a un nuevo coordinador, por lo que el registro está congelado.
¿AeroNyx es una cadena de bloques?
No. El registro de compromisos usaba bloques firmados por un único coordinador, sin consenso, sin elección de bifurcación y sin token. Ahora está congelado, y AeroNyx no lo describe como una cadena de bloques pública ni como una red de consenso global.
¿Perdí mis recuerdos porque el registro está congelado?
No. El registro solo almacena compromisos opacos, nunca contenido de memoria. Sus recuerdos cifrados se guardan en su dispositivo y, opcionalmente, en el nodo al que se conecta, con independencia del registro.
¿Se pueden seguir verificando los bloques existentes?
Sí. Todo nodo que tiene los 33 bloques vuelve a auditar las firmas y los enlaces de hash en cada arranque y no arranca si fallan. El resultado agregado es visible en el endpoint público de estadísticas de la red.
¿Qué sustituirá al registro con coordinador único?
El diseño previsto usa registros firmados por nodo que otros nodos replican y atestiguan mutuamente. Es el mismo modelo que la Directory Chain, que ya funciona para los descriptores de nodo. No se ha fijado ninguna fecha de lanzamiento.
<!-- faq:end -->