e7b9c0c8bf
Los 23 weights de spec 16, certificados por Laurha en el santuario de la rp1 (origin-banco):
- Núcleo 3 aislado, governor performance a 2,4 GHz, CI parada, 45-49 °C.
- frame-omni-bencher 0.15.0 sobre el wasm 40cb5a1d de 3cd1068.
- 5 procesos por pallet; se cobra el MÁXIMO con scripts/bench/max-de-n.py, porque procesos
idénticos se separan hasta un 35 %.
- Evidencia: ~/laurha-work/banco/spec16-20261024-1631 en la rp1 (SHA256SUMS d930c5e1).
- Su perfil va en la cabecera de cada weights.rs.
Antes de cobrarlos:
- Mismos accesos a storage: el esqueleto de los 5 ficheros y sus reads/writes son idénticos a
los de main.
- Lo que Laurha pidió mirar (cast_vote, finalize_proposal y veto_proposal, mucho más altos que
en RV12) es esperable. Contra los interinos del Mac todos caen en la banda Pi/Mac de 2,5-3,9×:
es trabajo nuevo de RV15/RV16 en una CPU unas 3 veces más lenta.
- Destacan los tres que verifican Ed25519 en WASM (attest_asset, register_agent_did,
rotate_agent_key), con unas 6 veces: la criptografía pura sufre más en la Cortex-A76.
- Lo cobrado sube menos que la ejecución, entre +4 % (set_tier_profile) y +56 %
(rotate_agent_key), porque las lecturas y escrituras de storage no cambian.
- spec_version 16 → 17, porque cambian las fees. transaction_version no cambia: ninguna llamada
cambia su codificación.
Ensayado en la rp1 (aarch64) sobre un nodo efímero aparte, antes de la testnet de la casa, con
scripts/e2e/upgrade_en_vivo.py (nuevo):
- sudo(set_code) → CodeUpdated + Sudid Ok;
- spec 17 y LastRuntimeUpgrade sube;
- una firma con la spec vieja → «bad signature»; con la nueva, ExtrinsicSuccess;
- la finalidad pasa del bloque del upgrade.
Es la primera vez que el ejecutor ARM compila y corre un runtime nuevo.
Revisión adversarial (nivel 1 de la directiva), antes de tocar la red, con orden de tumbarlo:
no pudo. Los seis puntos aguantan:
- ningún storage ni codificación cambia, y transaction_version no debe subir;
- el más pesado (veto_proposal) cobra 1,9 ms, 344 veces por debajo del máximo por extrinsic;
- los weights.rs tienen la misma estructura y el impl () coincide;
- ninguna fee, subsidio ni test depende del valor de forma que se rompa.
scripts/rp1 (operación del nodo, medido en 23 h con los valores por defecto):
- 430 MB de WAL de RocksDB retenidos para 15 MB de datos, y el RSS subiendo de 200 a 340 MB:
--db-cache 128. Al reiniciar, 449 → 21 MB.
- El log, de 7 líneas por bloque a ~2 (txpool, sc_basic_authorship y aura en warn; ojo: las
líneas de autoría usan el target del módulo, no «basic-authorship»), de 16 MB/día a unos 3.
- Modo append, y medir.sh lo rota al pasar de 32 MB.
Co-Authored-By: Laurha <laurha@origin>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
56 lines
2.7 KiB
Bash
Executable File
56 lines
2.7 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Arranca el nodo de Origin Chain en la rp1 si no está corriendo. Idempotente: lo llaman
|
|
# cron @reboot y el vigilante cada 5 min. Sin root.
|
|
#
|
|
# Convivencia con la casa (la rp1 es también el runner de CI y el banco de Laurha):
|
|
# - taskset -c 0-2: el nodo NUNCA toca el núcleo 3, que es el santuario de origin-banco.
|
|
# - nice 10 + ionice best-effort 7: la CI tiene prioridad sobre el nodo.
|
|
# - RPC sólo en 127.0.0.1: se entra por túnel SSH. P2P en 30333 para la LAN.
|
|
#
|
|
# Disco y memoria (medido el 2026-10-25, 23 h con los valores por defecto): 430 MB de WAL de
|
|
# RocksDB retenidos para 15 MB de datos, y el RSS subiendo de 200 a 340 MB. RocksDB guarda el
|
|
# WAL hasta que TODAS las columnas vacían su memtable, y con --db-cache por defecto (1 GiB)
|
|
# eso tarda. --db-cache 128 lo acota. El log pasa de 7 líneas por bloque a ~2: se silencian
|
|
# txpool, basic-authorship y aura (16 MB/día → unos 3). Va en modo append (>>) para que
|
|
# medir.sh pueda rotarlo truncándolo sin dejar huecos.
|
|
#
|
|
# Cadena: `dev` (Alice, llaves de desarrollo PÚBLICAS). Es la testnet de la casa, no la
|
|
# testnet pública: ningún valor real vive aquí.
|
|
set -euo pipefail
|
|
BASE="$HOME/origin-chain"
|
|
BIN="$BASE/bin/origin-chain-node"
|
|
PIDF="$BASE/nodo.pid"
|
|
mkdir -p "$BASE/data" "$BASE/logs"
|
|
|
|
if [ -f "$PIDF" ] && kill -0 "$(cat "$PIDF")" 2>/dev/null; then
|
|
exit 0
|
|
fi
|
|
|
|
LOG="$BASE/logs/nodo-$(date +%Y%m%d-%H%M%S).log"
|
|
# Un validador fuera de --dev exige una llave de red estable, y este CLI no trae `key`. Se
|
|
# genera UNA vez (la vía 4 del propio nodo) y queda en el base-path; en los arranques
|
|
# siguientes la bandera no se pasa, así que el peer id del bootnode no cambia nunca.
|
|
LLAVE_RED="$BASE/data/chains/origin_chain_dev/network/secret_ed25519"
|
|
EXTRA=()
|
|
[ -f "$LLAVE_RED" ] || EXTRA=(--unsafe-force-node-key-generation)
|
|
# El génesis lo fija casa.json (chain spec raw con el :code dentro), no el binario: el WASM no
|
|
# es reproducible entre máquinas, y con `--chain dev` un binario nuevo crearía OTRO génesis
|
|
# sobre los mismos datos. Sin casa.json (el primer arranque) se usa el `dev` embebido; después
|
|
# se exporta con `bin/origin-chain-node build-spec --chain dev --raw > casa.json`.
|
|
CADENA=dev
|
|
[ -f "$BASE/casa.json" ] && CADENA="$BASE/casa.json"
|
|
nohup taskset -c 0-2 nice -n 10 ionice -c2 -n7 "$BIN" run \
|
|
--chain "$CADENA" \
|
|
--validator --alice \
|
|
--name rp1-origin-casa \
|
|
--base-path "$BASE/data" \
|
|
--port 30333 \
|
|
--rpc-port 9944 --rpc-methods safe \
|
|
--no-telemetry --no-prometheus "${EXTRA[@]}" \
|
|
--db-cache 128 \
|
|
--log info,txpool=warn,basic-authorship=warn,sc_basic_authorship=warn,aura=warn \
|
|
>>"$LOG" 2>&1 &
|
|
echo $! >"$PIDF"
|
|
ln -sfn "$LOG" "$BASE/logs/actual.log"
|
|
echo "$(date -Is) arrancado pid $(cat "$PIDF") log $LOG" >>"$BASE/logs/arranques.log"
|