feat(rp1): la cadena corre en la Pi 5 de la casa — binario aarch64, despliegue sin root y medida continua

David, 24-oct: «lo que podamos hacer en la rp1 hagamoslo no esperemos la VPS porfavor». Y ese
mismo día, por Ergon: la rp1 aloja el servidor de arranque de la red.

scripts/rp1/:
- construir-aarch64.sh + Dockerfile.aarch64: origin-chain-node release, con el WASM real, para
  linux/aarch64 en el Mac.
  - Imagen bookworm (glibc 2.36; la rp1 tiene 2.41).
  - Target en un volumen de Docker: la VM no ve el disco externo de compilación si se montó
    después de arrancar Docker, y reiniciarla tiraría los contenedores de otras hermanas.
  - Copia el binario con docker cp y avisa de cómo borrar el volumen.
- desplegar.sh: copia el binario con su sha256 (y deja el anterior para volver atrás), copia
  arrancar.sh y medir.sh, e instala tres líneas en el crontab del usuario: @reboot, vigilante
  cada 5 min y medida cada 5 min. Sin root y sin systemd.
- arrancar.sh: idempotente.
  - taskset -c 0-2: el nodo nunca toca el núcleo 3, el santuario de origin-banco de Laurha.
  - nice 10 + ionice 7: la CI de la casa va primero.
  - RPC sólo en 127.0.0.1; P2P en el 30333.
  - Cadena dev con Alice: es la testnet de la casa, con llaves públicas de desarrollo; ningún
    valor real.
- medir.sh: una fila CSV cada 5 min con best, finalizado, pares, RSS, CPU, MB de datos, load,
  temperatura y estado de la CI.

scripts/bench/max-de-n.py: funde N weights.rs del mismo pallet cobrando el MÁXIMO de cada
coeficiente.
- Por qué: Laurha midió el 24-oct en su santuario que 8 procesos idénticos de frame-omni-bencher
  separan el base weight hasta un 66 %.
- Se niega si los esqueletos difieren (otra lista de extrinsics o de storage) o si los conteos
  de reads/writes no coinciden. Avisa si N < 5.
- Controles: tres copias idénticas salen idénticas byte a byte; el máximo cae sólo donde se
  subió; un conteo de reads distinto se rechaza; un extrinsic renombrado se rechaza.

firmar_como_wallet: modo cuenta "<frase>" [//derivación], que da la llave sr25519 y la SS58 que
verá un wallet Substrate. Son los vectores para la migración de la wallet Origin! (Irhis).

fix(node): build-spec emite el chain spec REAL cuando el binario lleva el WASM.
- Antes, aunque el binario llevara el WASM real, emitía siempre el de mayo, con :code = «0x»
  simulado, y --raw no sacaba el génesis en crudo.
- Ahora usa el mismo spec con el que arranca run (node_chain_spec), y --raw lleva el génesis
  entero.
- Sin WASM sigue el simulado, pero avisa de que no sirve para unirse a una red. Mainnet sigue
  cerrada por la compuerta L-3.
- Por qué importa, medido hoy: el WASM del runtime NO es reproducible entre máquinas. El mismo
  commit compilado en el Mac y en Linux da génesis distintos (0xe80c… frente a 0x0926…), y el
  nodo del Mac baneó al de la rp1 con «Genesis mismatch». El génesis tiene que fijarlo un chain
  spec que se reparte, no quien compila.
- arrancar.sh usa ~/origin-chain/casa.json cuando existe (exportado en la propia rp1). Así un
  binario nuevo nunca crea otro génesis sobre los mismos datos.

Medido en vivo el 24-oct, todo por RPC firmado como un wallet:
- Nodo en la rp1 (Pi 5, Debian 13): bloques cada 6 s y finalidad a 2-3 bloques. RSS ~200 MB y
  afinidad 0-2 con nice 10.
- El vigilante de cron lo resucita con el mismo peer id
  (12D3KooWDWm5p3Z8Y5DddRki6M6nM1A2xUVQzPqNU1DW53uB6BVi) y sin regenerar la llave.
- E2E en la rp1: remark → ExtrinsicSuccess; finalize_override → ProposalNotFound; uphold0 →
  ZeroWeightWindowVote.
- casa.json exportado en la rp1 = estado del bloque 0 de la cadena viva: 46 de 46 claves
  idénticas. El nodo reinició sobre él con el mismo génesis y siguió desde el #155.
- Red de dos máquinas por la LAN: el nodo del Mac, con casa.json y la rp1 como bootnode,
  sincronizó (mismo best, mismo finalizado). Una transacción enviada al nodo del Mac la incluyó
  la rp1 en el bloque #167, con el mismo hash blake2-256 que devolvió author_submitExtrinsic.

Defectos encontrados en mis propios scripts antes de dejarlos publicados:
- desplegar.sh instalaba un crontab VACÍO: con set -e, el grep -v sobre un crontab vacío
  abortaba la subshell antes de los echo.
- medir.sh dejaba best/finalizado en NA: set -u con $2 sin definir, y stderr se iba con cron.
- max-de-n.py reescribía 16416 como 16_416 (la prueba de identidad lo cazó).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

crates/origin-chain-node/src/main.rs

@@ -243,6 +243,29 @@ fn print_preset(id: &str) {
 /// JSON canonical via [`chain_spec::serialize_chain_spec`]. Exit code canonical 1
 /// si chain id canonical unknown o JSON serialization canonical fails.
 fn build_spec(chain: &str, raw: bool) {
+    // Con el WASM real, el chain spec que se emite es el MISMO con el que arranca `run`
+    // (`node_chain_spec`), y `--raw` lleva el génesis entero, `:code` incluido. Es lo que se
+    // reparte para que otro nodo se una a la red: el WASM no es reproducible entre máquinas
+    // (Mac y Linux dan génesis distintos con el mismo commit, medido el 2026-10-24), así que
+    // el génesis lo fija el chain spec, no quien compila.
+    if origin_chain_runtime::WASM_BINARY.is_some()
+        && !matches!(chain, "mainnet" | "mainnet_genesis")
+    {
+        match chain_spec::node_chain_spec(chain).and_then(|spec| spec.as_json(raw)) {
+            Ok(json) => println!("{json}"),
+            Err(e) => {
+                eprintln!("❌ Chain spec no resuelto: {e}");
+                std::process::exit(1);
+            }
+        }
+        return;
+    }
+    if origin_chain_runtime::WASM_BINARY.is_none() {
+        eprintln!(
+            "⚠ binario sin el WASM del runtime: este chain spec lleva un WASM SIMULADO (\"0x\") \
+             y no sirve para arrancar ni para unirse a una red (--features wasm-build)."
+        );
+    }
     match chain_spec::load_spec(chain) {
         Ok(spec) => match chain_spec::serialize_chain_spec(&spec, raw) {
             Ok(json) => println!("{}", json),

crates/origin-chain-runtime/examples/firmar_como_wallet.rs

@@ -17,6 +17,8 @@
 //!     compilado. Tras un `set_code` hay que pasarlos: el wallet firma con la versión
 //!     nueva que anuncia el nodo, no con la que se compiló aquí.
 //! eventos <hex de System::Events>          decodifica los eventos de un bloque
+//! cuenta "<frase BIP39>" [//derivación]  llave sr25519 y dirección SS58 (42) que verá un wallet
+//!     Substrate (substrate-bip39 → mini-secret → sr25519): vectores para la wallet Origin!
 //! verificar <hex_extrinsic> <genesis_hex>  pasa la firma por el check del runtime nativo
 //!                                          sobre el preset development (sin nodo)
 //! ```
@@ -124,6 +126,14 @@ fn main() {
                 println!("{:?}", e.event);
             }
         }
+        "cuenta" => {
+            use sp_core::crypto::Ss58Codec;
+            let uri = format!("{}{}", args[2], args.get(3).map(String::as_str).unwrap_or(""));
+            let par = sr25519::Pair::from_string(&uri, None).expect("frase o derivación inválida");
+            let publica = par.public();
+            println!("sr25519 publica 0x{}", sp_core::hexdisplay::HexDisplay::from(&publica.0));
+            println!("ss58 (42)       {}", publica.to_ss58check());
+        }
         "verificar" => {
             use sp_runtime::traits::Checkable;
             let bytes = hex(&args[2]);
@@ -145,6 +155,6 @@ fn main() {
                 println!("check del runtime: {:?}", r.map(|_| "firma aceptada"));
             });
         }
-        _ => panic!("modo: firmar · eventos · verificar (ver la cabecera del fichero)"),
+        _ => panic!("modo: firmar · eventos · verificar · cuenta (ver la cabecera del fichero)"),
     }
 }