ba5d1d8e85cbc11127eac0f2572a4e3504bb9abc
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CharonandClaude Opus 5.5
|
6055faff1b |
feat(pesos): spec 20, los 17 pesos del gobierno salen de los certificados de Laurha
Ya no queda ningun smoke de Charon. weights.rs se ENSAMBLA desde los tres certificados del banco de referencia (la Pi 5) con scripts/bench/ensamblar-pesos.py: - Cada funcion cobra el maximo, coeficiente a coeficiente, de todos los certificados que midieron su mismo codigo (mismo esqueleto de lecturas, escrituras y proof que el del ultimo, que es el del codigo que corre). - Con --comprobar dice si el fichero es exactamente ese ensamblado: probado en rojo cambiando a mano un peso. - Los tres certificados quedan en scripts/bench/certificados/ (sha256 18b8fcd6, 1e15d04e y 6f5cfec1), con su perfil y su evidencia en la cabecera. Por que el maximo de todos y no solo el ultimo: «El maximo de 5 de un dia no es el de otro» (Laurha). La revision adversaria de spec 20 encontro que cobrar solo el certificado vigente de cada funcion dejaba treasury_disbursement en 136 us, cuando el certificado del 2-nov, sobre el wasm que corre, mide 155 us, y otros siete por debajo de lo medido. Con la regla, ningun peso baja respecto a spec 19; los que suben, entre el +1 % y el +33 % de ejecucion. Probado: - 365 tests verdes. - Ensayo en la rp1 sobre una cadena con el codigo vivo de spec 19. Contrafactual: con estos pesos, el E2E reprueba contra spec 19, porque la cadena cobra los viejos. Tras el upgrade a 20 pasa entero, y lo cobrado es weights.rs + extensiones. Ademas: configs.rs ya no dice «Weights INTERIM hand-derived» en los cinco pallets, que cobran pesos certificados desde spec 17. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
CharonandClaude Opus 5.5
|
158060bfe4 |
feat(gobierno): spec 19, el quorum es el 10 % de lo que puede votar
Decision de David, 2026-10-29: «Si, del 10 % de lo que puede votar». Que puede votar: - Es la emision vigente menos el saldo que nadie puede votar ni recuperar: el pool de emision, el de subsidios y el vault de gobierno (cuentas_sin_llave en configs.rs). - Los bonds (og/props) y los depositos de pallet-revive NO se restan, porque vuelven enteros a una cuenta con llave. La revision adversaria de spec 19 lo demostro con sonda: restarlos dejaba bajar el quorum un 14 % en el genesis de mainnet, aparcando un bond en una propuesta de relleno y recuperandolo despues. Efecto: - En mainnet el quorum pasa de ~100M a ~35,1M OGC (10 % de 351M). - En la testnet de la casa apenas cambia. - Las propuestas abiertas conservan el quorum que guardaron al crearse. Pruebas: - quorums_del_runtime clasifica cada cuenta de pallet por su nombre. - aparcar_un_bond_no_baja_el_quorum reproduce la sonda con la configuracion real. - toda_cuenta_de_pallet_con_saldo_esta_clasificada vigila las cuentas modl del genesis. - 10 contrafactuales en rojo. - El E2E (paso 2b) descubre las cuentas de pallet recorriendo el storage, no copia la lista, y exige el quorum exacto. La comision se quema despues de despachar, y eso se mide en el BurnedDebt de la propia transaccion. Pesos: submit_proposal, submit_treasury_proposal y veto_proposal leen 3 cuentas mas. Medidos en la Pi: 5 procesos limpios, el nucleo calentado 3 s antes de cada uno, a 2,4 GHz. Operacion de la rp1, arrancar.sh: - en cada encendido desde el 26-oct el nodo moria al segundo porque la red no estaba; ahora espera a la ruta por defecto; - un cerrojo flock impide dos instancias; - el pid vivo se reconoce por su linea de comandos. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
CharonandClaude Opus 5.5
|
b6d05eaf45 |
feat(gobierno): spec 18 (RV17), quorum del voto ordinario y pago del tesoro atado a la propuesta
Gobierno (origin-chain-governance): - El voto ordinario exige un quorum de Aye, el 10 % de PILAR_4 §6.6. Se fija AL CREAR la propuesta (VoteQuorumOf) y se consume al decidirla: un set_code no mueve la meta de un voto abierto. Cuenta solo el Aye: con el Nay, un voto en contra podria aprobar; con la abstencion, el mismo OGC inflaria el quorum de muchas propuestas. - Un override del veto tiene que alcanzar ese quorum y superar el Nay original, las dos condiciones del voto ordinario. Sin ellas, vetar abarataba una aprobacion (dos bloqueantes de las revisiones adversariales). - submit_treasury_proposal (call 16) fija destinatario y monto (TreasuryActions), y treasury_disbursement solo paga exactamente eso, una vez. Rechaza montos bajo el deposito existencial y como destinatario la propia tesoreria o la cuenta-bond. - Sin entrada en VoteQuorumOf no hay quorum: la emergencia (que nunca lleva accion de tesoro) y lo creado antes de RV17, que se abrio y voto sin quorum. Runtime: los dos quorums son el 10 % de la emision VIGENTE, redondeado hacia arriba y nunca por debajo del bond (DiezPorCientoDeLaEmision). Con 100M fijos, en la testnet de la casa (100M emitidos, todos de Alice) nada se habria aprobado nunca; en mainnet sigue siendo ~100M. Spec 18, transaction_version 1: todo lo nuevo es aditivo, sin migracion. Node: pasa a opaque::Block. Decodificaba los extrinsics con tipos nativos y rechazaba en el pool la llamada que anadia el set_code (1040, el mismo error que una llamada inexistente). Los bytes y los hashes no cambian: el binario nuevo sincronizo desde cero los 39 273 bloques de la testnet de la casa con los mismos hashes en 8 alturas. El RPC sirve los extrinsics en hex. Pesos: seis extrinsics cambiaron de codigo y se midieron en la Pi 5 (smoke declarado: 5 procesos limpios, sin CI en ningun segundo, maximo de los 5). Los otros once siguen siendo los certificados por Laurha. Se descarto una medida contaminada: su muestreador no veia los tests de la CI. Pruebas: - 363 tests verdes en el workspace. - 24 contrafactuales, los 24 en rojo. - Ensayo en la rp1 sobre una cadena con el codigo vivo de spec 17: upgrade a 18 y E2E firmando como un wallet (scripts/e2e/rv17_tesoro.py). - Ejemplo firmar_como_wallet con tesoro, pagar, votar, depositar y finalizar; los eventos llevan su fase. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
e7b9c0c8bf |
feat(runtime): spec 17 — los pesos se cobran como en la Pi 5, medidos por Laurha en el banco de referencia
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
|
||
|
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
|
a694cbd9f0 |
feat(governance): RV15 — el peso de un voto sale del saldo, y la revision adversaria tumbo la primera version
Cierra L-10. cast_vote y override_council_veto sumaban el stake_weight que
DECLARABA el votante (hueco medido por Palace el 2026-09-06; test en rojo
publicado en
|
||
 davidherranandClaude Opus 5
|
38e5602d78 |
feat(weights): RV13 — los 19 estaban subdeclarados, los 19
Primera medicion real de los weights con frame-omni-bencher sobre el propio blob WASM. El resultado no es un ajuste fino: los 19 extrinsics de los 5 pallets custom declaraban MENOS de lo que cuestan. EL PATRON SISTEMATICO. Se costeo el storage del pallet y se olvido el que cuesta emitir un evento — System::Events, EventCount, ExecutionPhase y Number son reads y writes reales en cada extrinsic que deposita evento. Ejemplos medidos: attest_asset declaraba 4 reads / 1 write y cuesta 7/3; submit_proposal declaraba 12 us y cuesta 62; register_agent_did declaraba 3/2 y cuesta 6/4. EL PEOR, Y ES UN ERROR MIO DOCUMENTADO AL REVES. proof_size valia 0 en los 19. La cabecera de los interinos afirmaba que T::DbWeight "puebla tanto ref_time como proof_size ... cerrando el hueco". Es falso y se comprueba en la fuente: sp_weights::RuntimeDbWeight solo tiene los campos read y write, y reads(r) devuelve from_parts(read * r, 0). Los interinos arreglaron reads/writes y dejaron el proof_size exactamente donde estaba. Un proof_size en cero miente al block-builder sobre el peso PoV: es el vector de DoS que la nota decia haber cerrado. La afirmacion sobrevivio mas de un mes sin que ninguna lectura la desmintiera; la desmintio una medicion. Cada fichero generado lleva ahora un guard GENERADO desde la lista real de benchmarks que reprueba cualquier proof_size = 0 o ref_time = 0. Verificado que sabe reprobar: contra los weights anteriores se pone rojo con "`attest_asset` declara proof_size = 0". ADVERTENCIA QUE VA EN EL CODIGO, NO SOLO AQUI: son numeros de un MacBook Pro M3 Max, NO del banco de referencia BM V2. La forma (reads/writes/proof_size) no depende del hardware y es correcta; el ref_time si, y en un Pi 5 sera mayor. Un caso lo enseña solo: attest_asset BAJA de 50 a 44 us, y es el extrinsic dominado por el verify Ed25519, el mas sensible al silicio. Antes de mainnet hay que regenerar en el Pi 5 con governor y aislamiento declarados — peticion abierta a Laurha (request:66f500d54e28a80c) con el blob, el comando y la version exacta del bencher. RV12 -> RV13 (weights = consenso). TRANSACTION_VERSION intacto. 295 tests verde. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 5
|
b72650974d |
feat(bench): regenerar weights deja de ser una promesa y pasa a ser un comando
Durante meses la cabecera de los cinco weights.rs prometia que regenerar "es mecanico". No lo era: no habia comando, ni plantilla, ni forma de correrlo. La promesa costo lo que cuestan las promesas sin codigo — al medir por primera vez, los 19 extrinsics estaban SUBDECLARADOS, los 19. Tres piezas: · scripts/bench/regen-weights.sh — construye el WASM con runtime-benchmarks y mide los 5 pallets. SKIP_BUILD=1 + WASM=<ruta> mide un blob YA construido: es el modo del banco de referencia, donde el Pi 5 no compila Substrate sino que recibe el blob que se despliega, de modo que el binario medido y el desplegado son el MISMO. · scripts/bench/origin-weights-template.hbs — emite la forma de la casa (trait + SubstrateWeight<T> + impl para ()) y, dentro, un guard GENERADO a partir de los benchmarks reales que reprueba cualquier proof_size = 0 o ref_time = 0. Generado, no escrito: no puede quedarse corto cuando se anada un extrinsic. · scripts/bench/HEADER.txt — la cabecera que va dentro de cada fichero generado, diciendo que un weight es una latencia y que sin su hardware y su perfil de potencia no se reproduce. El script documenta ademas dos cosas medidas hoy que cuestan horas si no estan escritas: (1) hay que usar frame-omni-bencher 0.15.0, porque la 0.23 trae sp-storage 25 contra el sp-storage 22 de este runtime y TrackedStorageKey no decodifica al cruzar el FFI — falla con "unexpected first byte decoding Option", que no se parece a "version equivocada"; (2) el governor ondemand arranca a 1600 MHz y sube a 2400, asi que las primeras muestras salen ~50% lentas y el weight sale de la rampa. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |