e7b9c0c8bf87e14f8c64cd6ba66e581617044ed1
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CharonandClaude Opus 5.5
|
22bab19932 |
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>
|
||
|
CharonandClaude Opus 5.5
|
3cd1068893 |
feat(e2e): simulacro de set_code 16→17 — la cadena ya se actualiza sin fork, y sin 11e532e no podía
Ensayo en vivo el 2026-10-12, nodo --dev con WASM real, todo firmado por RPC como un wallet:
- A, control negativo: set_code con la MISMA spec 16 → Sudid Err(System, 1) =
SpecVersionNeedsToIncrease.
- B, el upgrade: sudo(set_code) con spec 17 → CodeUpdated + Sudid Ok.
- El RPC anuncia 17 y LastRuntimeUpgrade pasa de {16,"origin-chain"} a {17,"origin-chain"}.
- La migración del simulacro dejó su marca (0x11000000): on_runtime_upgrade corrió.
- C, un wallet tras el upgrade: firmado con spec 16 → «bad signature»; con spec 17 →
ExtrinsicSuccess.
- La finalidad siguió: el bloque del upgrade (#5) quedó finalizado.
Contrafactual, nodo sin type Version (el runtime de antes de
|
||
|
CharonandClaude Opus 5.5
|
ce91aa4572 |
feat(runtime): firmar_como_wallet — el E2E por RPC firma como un wallet, no solo mira bloques
Herramienta (example del runtime) con la que se midió el defecto de
|