6055faff1bf0f0f3dd0e9e68aa7b887b994dd05b
88
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
|
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
|
||
|
CharonandClaude Opus 5.5
|
11e532e251 |
fix(runtime): frame_system no sabía su propia versión — ningún wallet podía firmar
Medido en el E2E de RV16 por el canal de un wallet: Alice firmando como polkadot.js (versión de state_getRuntimeVersion, hash del génesis, era inmortal) recibía del nodo vivo «Transaction has a bad signature». Causa: SolochainDefaultConfig trae type Version = (), es decir RuntimeVersion::default() (nombre vacío, spec 0, tx 0), y el impl de frame_system lo heredaba sin declararlo — el mismo agujero que DbWeight en RV14. El RPC anunciaba spec 16 / tx 1; CheckSpecVersion y CheckTxVersion reconstruían el payload con 0 / 0. Rompía tres cosas: 1. Ningún wallet podía firmar un extrinsic (BadProof). 2. set_code habría fallado con InvalidSpecName («origin-chain» contra «»): sin upgrades. 3. Las migraciones no corrían nunca: Executive::runtime_upgraded compara 0 contra 0. Nadie lo vio en 16 specs porque ningún test firmaba por el canal del consumidor: los del pallet llaman a las funciones directamente, y los E2E anteriores solo miraban bloques. Arreglo: type Version = Version, con Version = crate::VERSION. Tests (contrafactual: sin la línea, los dos reprueban en la ASERCIÓN — spec_name "" y BadProof): - frame_system_conoce_la_version_que_anuncia_el_rpc - una_firma_de_wallet_estandar_pasa_el_check_del_runtime: firma como un wallet sobre el estado del preset development y pasa por el check real de la firma. E2E después del arreglo, nodo --dev con WASM real: dos extrinsics firmados por //Alice entran por author_submitExtrinsic, se incluyen en el bloque #3 (finalizado) y fallan con los errores que tocaban: finalize_override → ProposalNotFound, uphold_council_veto de peso 0 → ZeroWeightWindowVote. La metadata viva trae las llamadas, el storage, MinOverrideQuorum = 1e26 (100M OGC) y los errores nuevos. Tests: runtime 46, workspace 350. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
CharonandClaude Opus 5.5
|
3771a15165 |
feat(governance): RV16 — el override del veto se decide al cerrar la ventana, con 4/5 de quien participa
Cierra L-11 (override real del veto). David aprobó el 4/5 el 2026-10-01: «exigir una mayoría calificada de 4/5 en el consejo para anular un veto de emergencia es el cerrojo adecuado antes de retirar la llave Sudo». Qué cambia - La ventana de override tiene dos lados: revertir (override_council_veto) y sostener (uphold_council_veto, nuevo). Quien votó Nay puede sostener el veto; antes no tenía voz. - Nada se decide al cruzar un umbral. finalize_override (nuevo) decide UNA vez, al cerrar la ventana: se revierte si override >= ceil(4/5 * max(quórum, participación)). - El quórum se fija al vetar: max(Aye + Nay del voto original, MinOverrideQuorum). Abstain no cuenta. Así el bond que el veto devuelve no basta para revertirlo y un upgrade no lo mueve. - MinOverrideQuorum en el runtime = 100M OGC (el 10% de PILAR_4 §6.6); integrity_test exige que supere MIN_PROPOSAL_STAKE. - El periodo de voto ordinario dura al menos 14 días (MIN = DEFAULT) y el veto solo cabe dentro de él. Un voto de peso 0 en la ventana se rechaza. - spec_version 16. Pesos de uphold_council_veto y finalize_override medidos (frame-omni-bencher 0.15.0, 50 steps x 20 repeats); los demás re-medidos en el mismo banco. La revisión adversarial (nivel 1 de la directiva) tumbó la primera versión - Bloqueante: la regla de quórum no era monótona y votar «sostener» podía REVERTIR el veto. Ahora sostener nunca ayuda a revertir (test con la frontera exacta 2250/2251). - El mínimo de 48 h regalaba la vía de emergencia a cualquiera; ahora 14 días. - Las abstenciones inflaban el quórum; el quórum podía cambiar con un upgrade; la spec no subía. - 18 contrafactuales (mutaciones V1..V18), todos en rojo sin su pieza. Divergencia que queda abierta (D1 del roadmap V2): PILAR_4 §6.6 ratificó «override por 2/3» y el código implementa 4/5, que es lo que David confirmó. La constitución del DAO lo fija. Tests: gobernanza 78 (94 con runtime-benchmarks), runtime 44. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
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
|
||
|
CharonandClaude Opus 5.5
|
d37a278ba6 |
test(governance): el hueco del peso de voto ya tiene donde vivir — test en rojo con control positivo (RV15)
Palace lo midio el 2026-09-06 y escribio que no era explotable porque el nodo
no arrancaba. Desde
|
||
|
CharonandClaude Opus 5.5
|
63918f365b |
feat(node): Origin Chain produce su primer bloque — el bloqueo arquitectural era un diagnostico falso
El node nunca habia producido un bloque: service.rs y rpc.rs estaban fuera del build desde v0.0.49 por un «bloqueo arquitectural» que afirmaba que las crates publicadas sc-consensus-aura 0.52.0 y sp-consensus-aura 0.45.0 no tenian standalone::slot_duration_at ni from_timestamp_and_slot_duration. Las dos estan ahi, en crates.io. La nota guio la decision durante meses. Causa real, medida con cargo check (362 errores) y cargo tree: el workspace mezclaba dos releases de polkadot-sdk. Las sc-* del cliente arrastraban sp-runtime 43 y las frame-* del runtime sp-runtime 44: 36 crates del nucleo duplicadas y errores de la forma «Block no satisface Block». Cura: alinear diez versiones del Cargo.toml (sc-cli 0.55, sc-service 0.54, sc-network 0.53, sc-consensus 0.52, sc-consensus-aura 0.53, sc-consensus-grandpa 0.38, sc-offchain 48, sp-blockchain 42, substrate-frame-rpc-system 47, sc-telemetry 30.0.1). El lock solo PIERDE la generacion vieja (1210 -> 1123 entradas); ninguna crate que use el runtime cambia de version. rpc.rs: el client pasa a ser el FullClient concreto. Nuestro node trabaja sobre el Block completo del runtime, que lleva dentro ChainAccountId, una proyeccion (<<MultiSignature as Verify>::Signer as IdentifyAccount>::AccountId) que rustc no normaliza dentro de un where-clause generico: 6 errores de «un bound declarado en la firma no se satisface». Con el generico fallaba, con el concreto compila. main.rs: subcomando run (sc_cli::RunCmd), que arranca new_full con litep2p o libp2p. chain_spec.rs: node_chain_spec construye un GenericChainSpec con el WASM real del runtime (build-spec sigue con su JSON). run --chain mainnet se RECHAZA: sus validadores son placeholder sin llave (gate L-3) y un node con ese genesis no produciria nunca, en silencio. Test con contrafactual: sin el brazo mainnet el id cae en la rama de ruta y falla como «fichero no encontrado»; el test exige la razon, y en rojo lo dijo asi. Medido (build con --features wasm-build, run --dev --tmp): - bloque #1 importado 2026-09-23 20:04:30, uno cada ~6 s (Aura); - GRANDPA finaliza: #7 finalizado con best #9 a los 60 s; - RPC: chain_getHeader, chain_getFinalizedHead, system_accountNextIndex (Alice = 0) y system_properties (OGC, 18 decimales, ss58 42) responden; - «Essential task txpool-background failed» aparece SOLO al SIGINT (0 ocurrencias a los 50 s con RPC servido; 1 al segundo del SIGINT). - cargo test --workspace: 318 passed, 0 failed (igual que RV14) + 1 nuevo. macOS 27: el build necesita DEVELOPER_DIR=/Library/Developer/CommandLineTools mientras la licencia de Xcode 27 no este aceptada (exit 69 en cc y git). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
CharonandClaude Opus 5
|
defd3fa580 |
feat(identity): RV14 — una identidad sobrevive a perder su llave, y la revision encontro que el storage salia gratis
QUE NACE. rotate_agent_key (call_index 1 de agent-identity) y la runtime API AgentKeyApi::current_key. Hasta hoy un DID quedaba atado de hecho a su llave de nacimiento: no se re-derivaba, pero tampoco habia forma de pasar la autoridad a otra llave. Perder o filtrar la llave obligaba a registrarse otra vez con OTRO DID y perder credenciales, creditos e historial. Ahora el DID es de por vida y lo que rota es que llave manda sobre el. Es la dependencia de dos hilos abiertos: el DID del niño (Marihan) y los creditos de referido indexados por DID (Codex). Diseño: CurrentKey[did] (ausente = manda la de nacimiento, que ya vivia en creator; sin migracion), KeyToDid[llave] (una llave manda sobre un solo DID en toda la vida de la cadena; las retiradas quedan quemadas) y RotationNonce[did]. Dos firmas sobre DOMAIN || genesis || did || vigente || nueva || nonce || who: la vigente autoriza, la nueva prueba control. LO QUE LA REVISION ADVERSARIAL ENCONTRO ANTES DE PUBLICAR. Cinco lentes, 18 hallazgos, 17 confirmados. Todos arreglados aqui y cada arreglo con su contrafactual visto en ROJO: 1. DbWeight = () EN TODO EL RUNTIME. frame_system heredaba el valor por defecto de SolochainDefaultConfig sin declararlo. Cada reads(n)/writes(n) de TODOS los weights.rs valia cero: la E/S de storage no se cobraba en fees ni llenaba el bloque. Ahora RocksDbWeight, con un test que reprueba si vuelve a cero. ESTO CORRIGE LO QUE YO DIJE EN RV13: los reads/writes que medi alli no tenian efecto en el runtime. Lo que RV13 si arreglo es el proof_size y el ref_time de ejecucion, que no pasan por DbWeight. 2. LLAVES DE ORDEN PEQUEÑO. El verificador del host (ed25519-zebra, ZIP215) las acepta. Con el punto identidad como llave y la firma trivial R=identidad s=0, la «prueba de control» se superaba sin llave privada, en rotacion Y en registro: el DID quedaba bajo una llave con la que cualquiera firma en su nombre. Para un DID de un niño en Ethos eso es suplantacion. Ahora is_strong_ed25519_key descomprime el punto, exige codificacion canonica y rechaza orden pequeño (curve25519-dalek, que ya iba dentro del WASM). 3. EL REGISTRO ESCRIBIA KeyToDid PERO NO LO CONSULTABA. Una llave a la que otro DID ya habia rotado fundaba un DID nuevo y pisaba el indice. Hallado cinco veces por separado. Va detras de la colision de DID para no cambiar el error documentado de scenario_12. 4. REPLAY ENTRE CADENAS: el mensaje no llevaba genesis. Ahora si, mismo patron que provenance. Y menores: el evento nuevo va al final del enum (insertarlo en medio corria el indice SCALE de AgentUpdated); la insercion redundante de la llave vieja ya no pisa entradas; la doc dice que perder la CUENTA tambien bloquea la rotacion, no solo perder la llave; el comentario de creator decia «la cuenta que registro» y el codigo guarda la llave de nacimiento. DOS TESTS MIOS PASABAN POR LA RAZON EQUIVOCADA, y lo digo. El de «llave retirada quemada» volvia a la de nacimiento, que atrapa otra clausula. El del ladron firmaba con la llave vigente nueva, algo que un ladron real no tiene; con el pallet roto seguia verde en su mitad de ataque. Reescritos, y ahora el rojo sale de la mitad correcta (verificado por linea del panic). LO QUE QUEDA ABIERTO Y NO ES DE ESTE COMMIT: tras rotar, derive(llave_vigente) ya no es el DID. OCF y Palace hoy DERIVAN el identificador; para un usuario que roto tienen que RESOLVERLO contra KeyToDid. Es una enmienda al DC de unificacion con sus firmantes. La recuperacion por guardianes va aparte. Y KeyToDid crece sin deposito; se reevalua ahora que las escrituras cuestan de verdad. Medido sobre el WASM real (bencher 0.15.0, Mac, no canonico): rotate 97 us, 11 lecturas, 5 escrituras, proof 6100. 318 tests verde. RV13 -> RV14. TRANSACTION_VERSION intacto: call nueva en indice nuevo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
 davidherranandClaude Opus 5
|
7f68c5b656 |
docs(runtime): el comentario del vault decia que el 25% de la Fundacion va a FNDT — no va
`GovernanceTreasuryPalletId` llevaba una nota que decia «PRE-LAUNCH: el genesis mainnet debe rutear la Foundation 250M a esta cuenta (hoy va a FNDT — follow-up)». El follow-up ya estaba hecho y la nota no se enteró. MEDIDO en genesis_config_presets.rs: el preset mainnet asigna FOUNDATION_ALLOCATION − SUDO_OPERATIONAL_FLOAT = 249.000.000 OGC al vault og/gvtry (cuenta derivada de PalletId, sin llave privada) y 1.000.000 al placeholder FNDT, que es el sudo_key interim y necesita ese flotante porque el OriginFeeAdapter le cobra sus propios extrinsics Root. Importa porque la nota vieja hacía creer que la Fundación custodia el tesoro. No lo custodia: vive en una cuenta sin llave desde el bloque 0. Y salió al escribir la recomendacion de donde vive el DAO, donde ese dato es la premisa central. La nota nueva ademas separa lo que la vieja confundia: «sin llave privada» NO es «gobernado por los votantes». treasury_disbursement es ensure_root, Root hoy es pallet-sudo, y el amount/recipient los pone quien llama — el cuerpo de la propuesta es un hash y la cadena no puede leerlo. Cerrar esa brecha es el sunset. Solo comentario. Sin cambio de comportamiento, sin bump de version. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
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
|
b7010db328 |
fix(runtime): RV12 — el blob no sabia decir quien era y el genesis no construia
Tres defectos encontrados al montar el benchmarking real sobre el WASM. Ninguno era visible desde los tests nativos, y los tres bloqueaban frame-omni-bencher, que es el instrumento que mide los weights de mainnet. 1. LA SECCION runtime_version NO EXISTIA. Faltaba el atributo sp_version::runtime_version sobre VERSION. Esa custom section es la unica via para leer la version del runtime SIN ejecutarlo, que es de lo que depende set_code / forkless upgrade. wasm-builder abortaba con "Couldn't find the runtime_version section". El atributo exige literales, asi que la direccion queda INVERTIDA: VERSION es la fuente unica y las siete constantes publicas se derivan de sus campos. La deriva ya no es cuestion de disciplina, es imposible por construccion (contrafactual verificado: mover el literal pone rojo el test). 2. LOS PRESETS DE GENESIS NO EXISTIAN EN no_std. get_preset y preset_names devolvian None/vacio bajo un cfg(feature = "std") cuyo comentario afirmaba que los presets "solo se consultan en chain_spec generation, no en runtime execution". Falso: en el modelo runtime-driven chain spec el estado se construye DENTRO del WASM. omni-bencher fallaba con "The preset with name development is not available", y chain-spec-builder habria fallado igual. 3. NINGUN PRESET HABIA CONSTRUIDO UN GENESIS VALIDO JAMAS. Los tres poblaban aura.authorities Y session.keys a la vez; con pallet-session cableado, session instala las authorities de Aura via on_genesis_session y el build de Aura revienta con "Authorities are already initialized!". Sobrevivio toda la vida del crate porque todos los tests inspeccionaban el JSON del preset y ninguno llamaba a build_state: se miraba la caja por fuera. Ahora la abre los_tres_presets_construyen_estado (dev-dep sp-io), con contrafactual verificado: repoblar authorities lo pone rojo con el panic exacto. Tambien: el test que fijaba la version llevaba la version en el NOMBRE (runtime_version_v11_did_newtype) y su comentario quedaba mintiendo en cuanto la spec subia. Renombrado a spec_version_vigente_y_transaction_version_intacta. MEDIDO: WASM build exit 0; seccion runtime_version presente y decodificada (spec_name origin-chain, spec_version 12, tx 1); omni-bencher enumera los 19 benchmarks de los 5 pallets custom; 290 tests verde. RV11 -> RV12. TRANSACTION_VERSION intacto. Sin migracion: no hay cadena viva y ninguna transicion de estado cambia. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
4bdd0409f9 |
test(identity): la condición de Mathi — el DID no porta el kind, y el test sabe reprobar
Cierra la ÚLTIMA condición viva del DC ORIGIN IDENTITY UNIFICATION V1. CONTEXTO: Mathi RETIRÓ su condición #4 (meter `kind` en el material hasheado del KDF) tras mi objeción, y su ruling la retiró con un argumento mejor que el mío: si `kind` entra al KDF, un Human que pasa a Hybrid —transición que el Inmutable #41 PERMITE— rota su identidad entera. No es un trade-off: es una contradicción de diseño, porque el sistema declararía legal una transición que destruye al sujeto que la hace. Una identidad tiene que sobrevivir a aquello en lo que se le permite convertirse. Pero la retiró CON UNA CONDICIÓN, y es esta: el prefijo `did:origin:<kind>:` es etiqueta de DISPLAY, jamás autoridad — «ningún consumidor puede decidir leyendo el prefijo, y debe existir un test que lo demuestre». LO QUE PRUEBA EL TEST (`kind_authority_is_the_attestation_never_the_did`): En mi capa la condición se satisface de RAÍZ, no por convención: si el DID no PORTA el kind, ningún consumidor puede inferirlo de él aunque quiera. Es una imposibilidad aritmética, no una regla de etiqueta. 1. El DID de un HYBRID registrado es byte-idéntico a `derive_did(pubkey)` puro — un Human con la misma llave tendría EXACTAMENTE el mismo DID. 2. El kind autoritativo vive en `Identities[account].kind`, respaldado por la firma de binding del registro. Ahí es donde hay que preguntarlo. 3. CONTRAFACTUAL incorporado: computa el DID que resultaría de meter el kind al material (lo que proponía la #4) y verifica que DIFIERE del real. 4. Corolario: cambiar de rol deja el DID intacto — la identidad SOBREVIVE a la transición que el #41 permite. Y MEDIDO EN MI PALLET, no asumido: cero `did:origin`, cero `starts_with`, cero `prefix` en el camino de decisión. Mi cadena nunca ve el prefijo de display. EL TEST SABE REPROBAR — verificado, no prometido: saboteé `derive_did` inyectando el discriminante del kind al material (exactamente la condición #4) y el test se puso ROJO con su diagnóstico propio («la condición #4 RETIRADA volvió a entrar por la puerta de atrás»); restaurado, verde. Un test que solo se ha visto pasar no prueba nada. Sin cambio de runtime: es test puro, RUNTIME_VERSION sigue en 11. Verificado: 289 tests verdes en el workspace, 0 fallos. Con esto el DC 35e764d3 queda cerrado de verdad: #3 cumplida (Did newtype, RV11), #4 resuelta por retirada razonada — no por caducidad ni por omisión. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
2d44042bd6 |
feat(identity): Did pasa a newtype propio — condición #3 de Mathi (RV 10→11)
Condición VINCULANTE #3 de la firma de Mathi que ratificó el DC ORIGIN IDENTITY UNIFICATION V1 (3/3, 2026-07-29): `Did` deja de ser `pub type Did = AssetHash` y pasa a ser un newtype propio en origin-chain-types::identity. POR QUÉ (su argumento, que resultó más fuerte de lo que parecía): Mientras cada capa derivaba con SU propio contexto KDF, un DID y un hash de asset eran valores de dominios separados por construcción. Con el contexto COMPARTIDO `origin/identity/v1` ambos pasaron a ser "32 bytes canónicos de Origin", y el alias dejaba que el compilador aceptara silenciosamente un `AssetHash` donde se espera un `Did` — anclar una attestation bajo un DID, o resolver `DidToAccount` con el hash de un asset. La unificación AGRAVÓ el riesgo que el alias escondía; el newtype convierte esa clase entera de confusión en error de compilación. GARANTÍAS PRESERVADAS (medidas, no asumidas): - Encoding SCALE byte-IDÉNTICO (newtype sobre [u8;32] con los mismos derives) ⇒ `DidToAccount` NO requiere migración. Probado: assert_eq!(did.encode(), as_asset.encode()) + size_of::<Did>() == 32. - `derive_did` produce los MISMOS bytes: los 3 golden vectors del DC (D-ID-7) siguen verdes ⇒ la paridad con fabric-core (9e51e58) y Palace (7a0b82a) intacta. - El cruce de dominio sigue disponible pero EXPLÍCITO: `Did::from_asset_hash` / `into_asset_hash`. Legítimo cuando hace falta, legible en el código. UN TEST MÍO AFIRMABA EL DEFECTO Y LO MATÉ: let _did_alias: Did = AssetHash::new([0u8; 32]); // compilaba: era alias Ese assert pinneaba exactamente lo que Mathi señaló. Reemplazado por `did_is_a_newtype_not_an_alias_of_asset_hash`, que pinnea la separación de dominios + la invariante de wire. RUNTIME_VERSION 10→11 — y con la severidad SIN inflar: esto NO es consenso-relevante (misma transición de estado, mismos bytes, mismo encoding). El bump es higiene de metadata: el `TypeInfo` de la clave de storage ahora se llama `Did` y los clientes que cachean metadata deben re-leerla. TRANSACTION_VERSION intacto. Blast radius real medido: 1 solo error de compilación en todo el workspace (el test obsoleto de arriba). Verificado: 288 tests verdes, 0 fallos. Queda abierta la condición #4 de Mathi (`kind` dentro del material hasheado): objetada por escrito con razones (rompe la unificación —misma pubkey daría N ids por kind—, vuelve el kind inmutable —Human→Hybrid rotaría la identidad entera— y rompe la paridad digest recién cerrada). Contrapropuesta: binding del kind vía atestación on-chain autenticada + firmas domain-tagged, y el prefijo `did:origin:<kind>:` tratado como etiqueta de display, nunca como autoridad. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
13f8ac00a5 |
feat(identity): UNA identidad para todo Origin — contexto KDF compartido (RV 9→10)
DC ORIGIN IDENTITY UNIFICATION V1 (Larihana), Opción A + enmienda D-ID-7 mía.
Ratificado por David 2026-07-28. Firmado approve (pendientes Larihana + Mathi).
EL PROBLEMA (medido por Larihana, verificado por mí en ambos lados):
chain: blake3::derive_key("origin-chain/agent-did/v1", pk) → Did
OCF: blake3::hash(pk) → OitFingerprint
La MISMA pubkey Ed25519 producía 32 bytes DISTINTOS en cada capa. No era un bug
de criptografía: cada capa hizo domain separation correctamente por separado y
nadie decidió la relación entre las dos. Consecuencia: viendo un fingerprint en
un canal de chat NO se podía resolver el DID on-chain sin la pubkey completa —
un usuario tenía una identidad en el chat y otra en la blockchain. Directiva de
David: "que todo lo que creamos tenga una misma identidad para poder acceder".
EL CAMBIO:
- Nueva constante pública ORIGIN_IDENTITY_KDF_CONTEXT = "origin/identity/v1",
el contexto CANÓNICO compartido por todas las capas de Origin.
- derive_did pasa a derivar con ese contexto ⇒ el identificador de 32 bytes es
ahora EL MISMO en chain, chat (OCF), assets y credenciales.
- RUNTIME_VERSION 9→10: cambia la transición de estado de register_agent_did (el
DID calculado y almacenado) ⇒ spec bump obligatorio. Las FIRMAS de los
extrinsics NO cambian ⇒ TRANSACTION_VERSION intacto.
POR QUÉ SIN MIGRACIÓN (la verificación que el DC me delegó, medida no asumida):
- Sin GenesisConfig en el pallet → no se siembran identidades en génesis.
- Sin DIDs en los 3 presets de génesis.
- Sin golden vectors ni DID hex hardcodeado en el repo.
- StorageVersion = 0, nunca migrado — greenfield puro.
- derive_did = UNA función, UN call-site; los tests lo invocan (no pinnean bytes).
⇒ Ningún estado on-chain dependía del esquema viejo. La ventana pre-mainnet
estaba abierta y el costo fue una constante de string.
ENMIENDA D-ID-7 — golden vectors cross-repo (lo que aporté al DC):
El DC arreglaba la INSTANCIA pero no la CLASE. Origin Chain es submódulo y NO
puede depender de arkhe-fabric-core (dep-direction submódulo→monorepo = ILEGAL,
la misma ley que impide el swap del attestation SSOT), así que las dos capas no
pueden compartir la constante por Cargo — y sin ancla podían volver a divergir en
silencio, que es justo el bug que cerramos. Añadidos 3 vectores pinneados a bytes
(2 patrones + 1 pubkey Ed25519 real) para que fabric-core pinnee LOS MISMOS.
Si cualquiera de los dos lados cambia el contexto o la función, su test falla.
Mismo patrón que ya nos salvó con el attestation SSOT: paridad por matemática,
no por disciplina humana.
NO VACUO — verificado empíricamente: saboteé el contexto a "v2-DRIFT" y AMBOS
tests fallaron con el diagnóstico correcto; restaurado, verdes de nuevo. (Un test
que pasa no prueba nada hasta que se le ve fallar sin el fix.)
TRADE-OFF asumido y dejado explícito en el acta del DC: un identificador único en
chat + chain + assets + credenciales implica que ver el fingerprint de alguien en
un canal permite resolver sus activos y transacciones on-chain — no hay frontera
de seudonimato entre capas. Es INHERENTE a "una identidad para todo"; la
alternativa (derivación por-contexto tipo HD) reintroduce los dos identificadores
en dos pantallas que justamente eliminamos. Decisión consciente, no efecto
secundario descubierto después.
Verificado: workspace completo verde (0 fallos), 20/20 en agent-identity.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
davidherranandClaude Opus 4.8
|
266ee4084d |
polish(gov+attestation): test de empate en finalize + ancla SSOT de attestation
Polish pass MEDIUM/LOW post-audit (2 items limpios + triage de los invasivos): governance — cobertura del desempate (consenso-relevante, sin cobertura previa): - scenario_8b_finalize_tie_rejected_canonical: yes==nay ⇒ `yes > nay` es false ⇒ Rejected. Fija que se exige MAYORÍA ESTRICTA (el empate favorece el status quo). Entre scenario_7 (yes-majority→Approved) y scenario_8 (nay-majority→Rejected) faltaba justo el borde del empate. origin-chain-types — SSOT de attestation ahora que el crate aterrizó: - `arkhe-noesis-attestation-types` ya existe (crate standalone no_std + feature scale en el monorepo). El vendor-copy SE QUEDA como type-mirror deliberado: el chain es submódulo y depender del crate del monorepo invierte la dep-direction (submódulo→monorepo = ILEGAL). La SSOT se preserva por los golden vectors del oráculo real (decode_golden_vector_1/3/4), no por Cargo. - attestation_verify: §SSOT parity anchor doc — documenta que esos vectores pinnean el decoder al field-order de `SigningPayload` y cómo regenerar ante deriva. - attestation.rs: comentario del mirror actualizado (el crate aterrizó; diferencia conocida schema_version [u8;8] vs String es irrelevante — el mirror no serializa el wire; el decoder secuencial sí es byte-fiel al postcard, probado por vectores). Triage documentado (items considerados y DIFERIDOS con rationale, no olvidados): - register_agent_did unbounded Vec: bound del arg a ConstU32<10> movería el rechazo a decode-time, volvería AgentChainOverflow inalcanzable + rompería el test de overflow + exigiría spec bump — invasivo para un DoS ya mitigado por length-fee + límite de bloque. Diferido. - SS58 prefix (42): NO es bug — placeholder testnet correcto, gated en un DC de ss58-registry pre-mainnet. Sin cambio. - no-author path (emission): requiere un FindAuthor mock que devuelva None (segundo runtime o toggle) — ripple > valor. Diferido. Verificado: origin-chain-types 77 tests verde (incl. golden parity) + tie test verde. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
c7fc6a88fc |
feat(bench): maquinaria FRAME v2 de benchmarking para los 5 pallets custom (RV 8→9)
Los 19 extrinsics de provenance/fees/agent-identity/emission/governance pasan de weights placeholder `from_parts(10_000, 0)` (proof_size=0, sin contar reads/writes de DB — vector de DoS real) a weights INTERIM hand-derived DB-aware vía el trait `WeightInfo`. Cierra el mispricing de DoS en TODOS los extrinsics del chain. Cada pallet gana: - weights.rs: trait WeightInfo + SubstrateWeight<T> (DB-aware vía T::DbWeight) + impl () - benchmarking.rs: benchmarks FRAME v2, VERIFICADOS por impl_benchmark_test_suite! (19 benchmarks ejecutan+pasan en los mocks — cargo test --features runtime-benchmarks) - Config: `type WeightInfo` + swap de los `#[pallet::weight]` Runtime: - define_benchmarks! con los 5 pallets + runtime API Benchmark (inerte sin la feature) - WeightInfo cableado a SubstrateWeight<Runtime> en cada Config - RUNTIME_VERSION 8→9 (weights = consenso-relevante: fee + llenado de bloque; las firmas de los extrinsics NO cambian ⇒ TRANSACTION_VERSION intacto) 3 bugs latentes cerrados (territorio virgen — el runtime NUNCA se compiló con runtime-benchmarks; las dimensiones nuevas cazan lo que no se había visto): - pallet-grandpa/try-runtime mal ubicado en la feature runtime-benchmarks (copy-paste erróneo: features ortogonales; NUNCA activaba los benchmarks de grandpa) - feature runtime-benchmarks incompleta → E0046 en OriginFeeAdapter (métodos benchmark-gated de OnChargeTransaction) + pallet-staking (StakingUnchecked::migrate_to_direct_staker); ahora lista TODOS los pallets como un runtime de producción Substrate - pallet-revive/runtime-benchmarks omitido a propósito (fixtures RISC-V/PolkaVM indisponibles; ReviveApi deferred, no benchmarkeado) emission: mock extraído del `mod tests` inline a `pub mod mock` (reuso del test-suite, sin duplicar el scaffold; los 15 tests existentes + el benchmark verdes). GATED (documentado en el §Estado de cada weights.rs): la generación de números CANÓNICOS por CLI requiere el node sc-service o omni-bencher+WASM (ambos bloqueados hace sesiones). Los weights interinos son DB-aware/DoS-safe y regenerables de forma mecánica cuando aterrice el HW de referencia (Pi5/VPS) — benchmarking.rs es la fuente de verdad de la FORMA. Verificado: 5 test-suites de pallet verdes (con y sin runtime-benchmarks) + runtime compila en ambos modos + workspace sin regresión + 40 tests de runtime (incl. v9). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
9f48723ca5 |
feat(governance): flujo 5/7 de emergencia REAL — dos fases (audit B, David · RV 7→8)
Decisión B (David 2026-07-04). El audit ultra encontró que el gate 5/7 de submit_emergency_proposal era TAUTOLÓGICO: `council_size >= threshold(council_size)` es siempre true, y solo exigía UN council member — así que un solo miembro fast-trackeaba una propuesta a 48h (vs 14 días) sin la pre-aprobación 5/7. Fix (flujo de dos fases, como anticipaba el propio doc "gather signatures then promote"): - FASE 1: `endorse_emergency_proposal` (nueva, call_index 12) — un council member endosa por content-id (blake2 de title++body). - FASE 2: `submit_emergency_proposal` ahora exige `live_endorsements >= 5/7 real` (conteo EN VIVO, solo miembros aún en el council — consistente con el fix de veto). Limpia los endosos consumidos tras promover. +2 tests (flujo 5/7 completo con boundary 4→5, y regresión "un solo miembro NO fast-trackea"). RUNTIME_VERSION 7→8 (call aditiva + metadata; TRANSACTION_VERSION intacto). Workspace 284 verde. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
304072173e |
feat(governance): reserva REAL del stake de propuesta — bond og/props (audit A, David)
Decisión A (David 2026-07-04). El audit ultra encontró [HIGH] que el "mínimo 1.000 OGC" de submit_proposal era un número caller-supplied SIN respaldo: una cuenta vacía podía spamear propuestas ilimitadas, y ese `stake` fabricado era el `baseline` denominador del override_council_veto (manipulable). Fix (sin esperar a NPoS — el stake de propuesta es piel-en-el-juego anti-spam, distinto del voto pesado por stake): el stake se RETIENE de verdad en una cuenta- bond determinista `og/props` (transfer, Preservation::Preserve → falla si el proponente no tiene fondos) y se DEVUELVE al proponente cuando la propuesta se decide. Clave del lifecycle: el release ocurre en AMBAS transiciones fuera de Voting — finalize_proposal Y veto_proposal — o el bond de una propuesta vetada quedaría atrapado (no hay withdraw dispatchable). `og/props` separada del vault para que treasury_disbursement jamás toque un bond. Enfoque escrow-account: usa solo Currency::transfer (ya en el bound) — cero cambios de Config/runtime-wiring. submit_proposal + submit_emergency_proposal ambos bond. +3 regression tests (retiene+devuelve al finalizar, devuelve al vetar, rechaza si no alcanza). Mock refondeado >= MIN_PROPOSAL_STAKE. 48 gov tests, workspace 283 verde. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
f3de48b1b8 |
test(genesis): ata el pool og/ecosy (400M) a la cuenta que libera la emisión
Invariante de cableado del techo duro (audit ultra 2026-07-04): la cuenta que el génesis fondea con ECOSYSTEM_ALLOCATION DEBE ser exactamente la que pallet-origin-emission transfiere (EmissionEcosystemPalletId → og/ecosy). Si divergieran, el pool de la emisión estaría vacío y los validadores nunca cobrarían. El test ata génesis ←→ runtime Config. Workspace 280 verde. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
4ee178fbd5 |
docs(consistency): comentarios stale post-RV7 + guard ficticio de tiers (audit ultra LOW)
Audit ultra 2026-07-04 (dimensión consistency-crosscheck): - Reconciliada la contradicción del horizonte de agotamiento del pool: docs decían ~10-15 años (marco viejo de tasa variable) Y ~7.6 años (la matemática real de 10 OGC/bloque). Todo a ~7.6 años + nota de que BlockReward es el dial. - Fijados comentarios "mintea"/"inflación" que contradecían el techo duro RV7 (la emisión LIBERA del pool, no acuña): runtime lib.rs:408, emission doc, genesis. - tiers.rs: el comentario prometía un "regression test en origin-coin-tokenomics" que NO existe (ese crate es stub) — corregido a la verdad: la sincronía con arkhe-core es disciplina MANUAL (la cadena no depende de arkhe-core por diseño); los #[test] locales pinnean la escalera actual pero no cazan drift cross-crate. Workspace 279 tests verde. Solo comentarios — cero cambio de comportamiento. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
80bf7e5ddf |
fix(governance): 3 bugs de correctitud del audit ultra (CRITICAL override + HIGH ×2)
Audit ultra 2026-07-04 (dimensión governance-hardening, nunca antes corrida): 1. [CRITICAL] override_council_veto revertía CUALQUIER propuesta Rejected a Approved — incluidas las que la COMUNIDAD votó en contra (finalize_proposal marca Rejected cuando nay>=yes). Un proponente podía resucitar una propuesta rechazada en las urnas y drenar el treasury, invirtiendo el voto popular. Fix: marca VetoRejected (solo la pone veto_proposal al alcanzar el umbral); el override exige esa marca ⇒ solo revierte VETOS del council, no votos. 2. [HIGH] treasury_disbursement podía re-desembolsar la MISMA propuesta Approved N veces (drenaje por replay) — el guard status==Approved no cambiaba tras el pago. Fix: marca Disbursed (single-use) + Error::AlreadyDisbursed. 3. [HIGH] veto_proposal usaba un contador MONÓTONO: el veto de un miembro removido seguía contando y encoger el council bajaba el umbral retroactivamente ⇒ una minoría podía vetar (derrota el safeguard 2/3). Fix: conteo EN VIVO (itera VetoVotes filtrando por membresía actual del council, O(≤7)). +3 regression tests. Governance 45 tests verde. Storage aditivo (VetoRejected, Disbursed) — sin migración (pre-mainnet, StorageVersion 0). Pendientes para David (diseño): reserva real del stake de propuesta (HoldReason), emergency 5/7. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
d6dd08da66 |
fix(emission): integrity_test guard — shares autor+treasury ≤ 100% (audit ultra)
Hallazgo MEDIUM del audit ultra: si un cambio de config hiciera AuthorShareBps + TreasuryShareBps > 10_000 bps, el `subsidy = reward.saturating_sub(author). saturating_sub(treasury)` daría subsidy = 0 SILENCIOSAMENTE (el pool #16 se quedaría sin fondos sin ruido). El hook `integrity_test()` lo convierte en un fallo ruidoso del integrity-check del runtime. +test. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
1fdc47e859 |
feat(economía): techo duro 1B + fees con dientes (David Level A 2026-07-03, RV 6→7)
Dos decisiones económicas ratificadas por David, verificadas en fuente:
1. TECHO DURO 1B (Opción A) — la emisión TRANSFIERE del pool Ecosystem finito
(og/ecosy, 400M pre-asignado en génesis), JAMÁS mint_into. La aserción de
compilación de 1.000M deja de ser promesa de génesis y se vuelve ley que la
producción de bloques obedece: el total issuance nunca crece, el pool se
agota en ~7.6 años (10 OGC/bloque), después economía circular pura. Cuando el
pool no cubre el reward completo, libera el remanente y emite
EcosystemPoolDepleted una vez. Evento renombrado BlockRewardMinted →
BlockRewardReleased (honestidad: es redistribución, no acuñación).
- origin-chain-emission: Currency.transfer (Expendable) desde ecosystem_account;
+EcosystemPalletId config, +DepletionAnnounced storage one-shot, +2 tests
(hard_cap_pool_se_agota_y_para, depletion_event_se_anuncia_una_sola_vez).
- runtime: EmissionEcosystemPalletId (og/ecosy) wired; génesis asigna el 40%
a la cuenta PalletId determinista (sin llave humana), no al placeholder ECO!.
2. FEES CON DIENTES — WeightToFee/LengthToFee de IdentityFee (polvo ~10^-10 OGC,
#16 = adorno) a ConstantMultiplier calibrado: un transfer simple ≈ 1 MILLI_OGC
(0.001 OGC). Consecuencias: el descuento Pi5 (0.1×) = ahorro real (0.0001 OGC);
la quema del 100% de gas es deflación medible desde el testnet; el spam cuesta
OGC real. Factor 7e6 (weight) + 1e11 (length). Test de regresión
weight_to_fee_transfer_tiene_dientes_no_polvo blinda contra revertir a polvo.
Calibrado a pesos placeholder — re-tunear con benchmarks reales (leftover FIX-2).
RUNTIME_VERSION 6→7. Workspace 275 tests verde, 0 fallos. TRANSACTION_VERSION intacto.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
davidherranandClaude Fable 5
|
7b8863fd47 |
fix(runtime+emission): audit ultra 2026-07-02 — 3 fixes verificados en fuente (RV 5→6)
Audit ultra-profundo (Fable 5, refute-by-default): 3 dimensiones completadas
(economía, fee-path, attestation) → 23 hallazgos crudos → verificación manual
en fuente de los HIGH. Los 3 inequívocos, corregidos:
(a) FeeMultiplierUpdate = () COLAPSABA NextFeeMultiplier a 0 tras el bloque 1
[HIGH]: impl<A, B: Default> Convert<A,B> for () devuelve Default (=0) y
on_finalize hace *fm = convert(*fm) — el componente weight-fee desaparecía
de TODA la cadena desde el bloque 2. Verificado en pallet-transaction-
payment-43.0.0 src (líneas 158-171, 446-448). Fix: ConstFeeMultiplier<1>
+ test de regresión fee_multiplier_update_never_collapses_to_zero.
(b) NativeToEthRatio = 1_000_000 con comentario "OGC 12 decimals" [HIGH]:
OGC tiene 18 decimales (Ogc::DECIMALS=18) = precisión ETH ⇒ ratio 1:1.
El 10^6 (herencia del template de 12 dec) distorsionaba TODO valor visto
por la capa EVM ×10^6. Fix: ConstU32<1> + test derivado de la delta de
decimales (guard de coherencia, no número mágico).
(c) Emisión: let _ = mint_into ×3 descartaba resultados [MEDIUM] mientras
TotalEmitted y el evento BlockRewardMinted registraban incondicionalmente
⇒ la contabilidad podía mentir si un mint fallaba (e.g. bajo ED). Fix:
TotalEmitted + evento registran SOLO lo realmente acuñado.
RUNTIME_VERSION 5→6 (cambios de comportamiento; TRANSACTION_VERSION intacto).
Workspace verde: 272 checks, 0 fallos. Pendientes de decisión de David (Level
A economía): emisión-mint vs Ecosystem 400M pool (doble fuente del mismo
propósito) · IdentityFee dust con 18 decimales (calibración WeightToFee).
Audit continúa post-reset (6 dimensiones + verify formal de los 23).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
||
|
davidherranandClaude Opus 4.8
|
1a0364db99 |
fix(genesis): float operacional al sudo_key — cierra MEDIUM de la auditoría ultra
La auditoría ultra adversarial del commit
|
||
|
davidherranandClaude Opus 4.8
|
8e72496901 |
feat(fees,genesis): FeesApi account-aligned query + 250M Foundation→vault og/gvtry
Dos endurecimientos pre-mainnet (leftovers del remediation roadmap): 1. genesis vault (#16/CHN-4): el preset mainnet asigna el 25% Foundation Treasury (250M OGC) al VAULT de governance (og/gvtry, GovernanceTreasuryPalletId), NO a una cuenta key-controlada. Es la MISMA cuenta de la que treasury_disbursement gasta (gated por governance council) y que emission/staking alimentan → el treasury queda DAO-governed desde el bloque 0, materializando "Foundation Treasury → DAO governed (CHN-4)". El placeholder FNDT queda SOLO como sudo_key interim hasta el sunset (DC ORIGIN_CHAIN_GOVERNANCE_SUNSET_V1). Las allocations BM V2 (40/25/15/15/5 = 1B) no cambian de monto. 2. FeesApi alignment: nuevo método query_fee_for_account(action, base, account) que estima el fee con el TierProfile REAL on-chain del account (storage TierProfiles, ValueQuery default Desktop+Free), NO caller-supplied — alineado con el fee-path vivo OriginFeeAdapter (FIX-6 Stage 2a). Cierra el "el cliente adivinaba hw/sub": la estimación off-chain ahora usa la misma fórmula sobre el MISMO tier que cobra la cadena. Método aditivo al Runtime API ⇒ TRANSACTION_VERSION 1 intacto. RUNTIME_VERSION 4→5 (nueva metadata de FeesApi). 268 workspace tests verde (native, SKIP_WASM_BUILD — WASM VPS-gated), 0 regresión. Test sella que query_fee_for_account usa el perfil real (EmbeddedArm piso < default Desktop). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
112747ab44 |
chore(emission): contabilizar la lectura de EmissionPaused en el weight del path activo
Cierre de higiene post-auditoría ultra (la auditoría adversarial dio 0 bugs reales en 18 hallazgos; esta era la única observación de estilo sobre código que toqué): el guard del kill-switch añadió una lectura de storage a on_initialize que el path activo no contabilizaba. Ahora ambos paths (pausado y activo) declaran la lectura. El resto del weight sigue siendo placeholder pendiente de benchmarking (leftover FIX-2). Sin cambio de lógica — 11 tests emisión verde. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
af1c75b329 |
feat(emission): governance kill-switch — set_emission_paused (FIX-6 Stage 2b)
Añade EmissionPaused (StorageValue<bool>, ValueQuery default false = emisión ACTIVA, sin migración) + set_emission_paused(paused) Root-gated + guard en on_initialize. Palanca de governance para pausar la inflación per-block. Es el kill-switch anti-doble-emisión para la activación de NPoS: cuando pallet_staking::EraPayout empiece a pagar por-era (en el spec upgrade de activación que swap-ea SessionManager→Staking + historical + multi-phase/ bags-list), Root pausa esta emisión en el MISMO upgrade. Mientras EraPayout esté dormido (ForceNone), esta es la única fuente de emisión: cero doble-emisión posible hoy. TotalEmitted se PRESERVA al pausar (histórico de inflación intacto). Idempotencia rechazada (EmissionPauseUnchanged) para que cada cambio de governance sea un evento observable on-chain. HALLAZGO (audit-before-claims contra la fuente): los Pasos B-E originales asumían que la activación sería un flag-flip, pero (1) #[frame_support::runtime] ordena los pallets por índice (Session=6 < Staking=14) y el génesis de Session invoca la elección de staking → el génesis de Staking debe ir ANTES (requiere legacy_ordering o renumerar índices); (2) la activación con nominación masiva necesita multi-phase + bags-list = spec upgrade de todas formas, donde el session-swap viaja gratis. Por eso el session-swap se difiere a la activación (decisión David) y aquí shippeo solo lo seguro e incondicional. EraPayout/RewardRemainder ya probados (Paso A). RUNTIME_VERSION 3→4 (nuevo call ⇒ metadata cambia; call aditivo en call_index nuevo ⇒ TRANSACTION_VERSION 1 intacto). 21 suites / 267 workspace verde, 0 regresión. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
ca50938495 |
feat(tiers): EmbeddedAI on-chain — base_multiplier + subsidy piso EmbeddedArm (#16)
Espejea HardwareTier::EmbeddedAI (Jetson Orin Nano) en el mirror de la cadena, en lockstep con arkhe-core bbac1b2 (Ergon Fase 1 EmbeddedAI, ADR-0072 / DC 2ba235e1). Trampa de la fuente preservada byte-fiel: EmbeddedAI APPEND discriminante 4 (SCALE wire-safe, attestations runtime_tier:u8 viejas válidas) PERO rank de capacidad 1 (entre EmbeddedArm=0 y Portable=2). Por eso Ord es MANUAL por rank() (no derive — un derive pondría EmbeddedAI > Ultra, falso) y el gating Hero es por rank, no por discriminante. - tiers.rs: variant EmbeddedAI (last) + Ord/PartialOrd manual por rank() + rank()/ordinal()/from_ordinal() SSOT (el reverse-map que evita perder el tier-floor al deserializar, #16) + base_multiplier_x100=10 (piso, el estudiante en Jetson no paga más que en Pi 5) + surcharge Hero gated=0 + supports_hero=false. - fee_schedule.rs: 6 arms EmbeddedAI = piso EmbeddedArm en subsidy_basis_points + educational override incluye EmbeddedAI (device de estudiante). - fees.rs / unified.rs: cobertura — compute_fee(EmbeddedAI)==EmbeddedArm + grid de paridad OCAFB-5 extendido a EmbeddedAI. Tests: 21 suites / 261 workspace verde, 0 regresión. SCALE index == ordinal sellado. FIX-4 (verificador attestation) ortogonal — no mapea el enum, intacto. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
fcf768b046 |
test(npos): tests de la aritmética constitucional 70/20/10 (meta-audit)
Meta-auditoría de mi propio trabajo (NPoS Paso A se shippeó en checkpoint sin verificación adversarial). Verificado contra el source de pallet-staking 43.0.0 que la infra es REALMENTE inerte (on_initialize=weight-only; on_finalize no-op con ActiveEra=None sin session) — cero regresión confirmada. Mejora aplicada: la aritmetica constitucional de OriginEraPayout + DealWithEraRemainder estaba escrita pero SIN tests (dormida, no se ejercita). Antes de encenderla en Paso C/D conviene probar el split: - era_remainder_split extraido a fn pura testeable (sin mock). - 5 tests: era_payout preserva tasa lineal + split 70/30 exacto + cero perdida; no overflow en era de 1 anio; remainder 20/10 del total; residual-al-subsidy (el dust del redondeo favorece el pool anti-clasista #16); invariante en montos reales. Sin bugs encontrados en Paso A. cargo +1.88. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
1f0122beda |
feat(npos): FIX-6 Stage 2b Paso A — pallet_staking Config cableado (infra dormida)
Materializa la infra NPoS DORMIDA del DC ORIGIN_CHAIN_NPOS_V1 (decisiones de fundador ratificadas). pallet_staking 43.0.0 wired como Index 14: los 31 associated types cableados contra el tren stable2509-3 (mapeo quirúrgico audit-before-claims; compiló en 2 iteraciones). Piezas (crates/origin-chain-runtime/src/staking.rs, nuevo): - OriginEraPayout: emisión por-era LINEAL que preserva EXACTAMENTE la tasa de FIX-6 Stage 1 (BlockReward 10 OGC/bloque, 70% validadores / 30% rest). NO la curva ideal-staking-rate de Polkadot (ignora total_staked/issuance a propósito). - DealWithEraRemainder (RewardRemainder): reparte el rest 2/3 treasury (og/gvtry) + 1/3 subsidy (og/subsy) = 20%/10% del total. CRÍTICO #16: mantiene og/subsy alimentado bajo NPoS (sin él, el OriginFeeAdapter de Stage 2a degradaría a pool_covered=0 y el usuario pagaría el 100%). - OnChainExecution<OnChainSeqPhragmen> como (Genesis)ElectionProvider (dormido: ForceNone no dispara elección). VoterList=UseNominatorsAndValidatorsMap + TargetList=UseValidatorsMap (Scores distintos, evitan bags-list + sus asserts). - Params ratificados: MaxValidatorSet=150 (NPoS-6) · SessionsPerEra=6 (era 24h) · BondingDuration=7 eras=7d (NPoS-8) · SlashDeferDuration=0 (sin slashes dormido). - fungible::hold (NPoS-10): Currency/OldCurrency=Balances; el RuntimeHoldReason agregado del macro absorbe HoldReason::Staking automáticamente. Estado: staking PRESENTE pero INERTE — SessionInterface/NextNewSession=() (no avanza eras), genesis force_era=ForceNone sin stakers (PoA-equivalente, cero regresión). El emission pallet Index 13 sigue siendo la fuente de emisión. NO hay doble-emisión (staking no emite mientras no avance eras). Pendiente (sesión fresca, encienden NPoS de verdad → verificación adversarial): Paso B genesis poblado (invulnerables+stakers, asserts-trampa) · Paso C SessionManager=Staking + historical (enciende EraPayout) · Paso D emission on_initialize off (kill-switch anti-doble-emisión) · Paso E tests E2E. spec_version 2→3 (nuevo pallet ⇒ metadata; TRANSACTION_VERSION=1 intacto). 21 suites workspace verde. cargo +1.88. WASM VPS-gated (UnknownOpcode 252). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
440135293e |
chore(npos): FIX-6 Stage 2b kickoff — DC ORIGIN_CHAIN_NPOS_V1 + deps stable2509 verificadas
Arranque de Stage 2b (transición de consenso PoA→NPoS). DC abierto (ORIGIN_CHAIN_NPOS_V1, 11 sub-decisiones) con las 3 decisiones de fundador de David ratificadas 2026-06-12: - NPoS-5 INFRA DORMIDA: construir toda la maquinaria pallet_staking + EraPayout + genesis + tests LISTA pero dormida (invulnerables=genesis + ForceEra::ForceNone), la cadena corre PoA-equivalente, la emisión SÍ migra a EraPayout (resuelve la doble-emisión). Activación de elección-por-stake = governance flag post los 5 criterios empíricos de CHN-1. Respeta el gating. - NPoS-6 MaxValidatorSet 150 (techo CHN-1). - NPoS-7 VPS/Foundation validan; Pi5/Jetson = light client soberano (ADR-0072 §11 C.3) — disuelve la tensión min_bond/slash-por-mala-conexión. Catálogo de deps verificado audit-before-claims (resuelven contra frame-support 43.0.2): pallet-staking 43.0.0 + frame-election-provider-support 43.0.0 + sp-staking 41.0.0. (multi-block 0.4.0 YANKED; multi-phase + bags-list entran al ACTIVAR la elección post-gates, no en la infra dormida.) Declaradas en el workspace catalog; se wirean al runtime con el Config en la sesión dedicada (cambio de consenso + migración fungible::hold merecen contexto fresco). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
ce18e191d0 |
feat(provenance): FIX-4 — verificador attestation on-chain (cierra V3-C1 + squat)
El verificador attestation queda VIVO: una firma producida por el código REAL de Ergon (arkhe-noesis-core, postcard + mensaje domain-separado) verifica byte-fiel en el pallet Substrate. Cierra el FIX-DEFERRED del roadmap (helper de Ergon ya en árbol) + el replay cross-chain V3-C1. origin-chain-types/attestation_verify.rs (nuevo): - ATTESTATION_DOMAIN_TAG + attestation_signed_message: espejo BYTE-IDÉNTICO del oráculo (DC 076d15cc ASP-3). Mensaje = TAG ‖ genesis_hash(32) ‖ payload. - decode_signing_payload: lector postcard SECUENCIAL total y estricto del SigningPayload de Ergon (sin dep nueva en el runtime wasm frágil). Lectores varint u64/u32 con los bounds exactos de postcard (cierra el LOW de fidelidad flagged: verdict/severity/constraints son u32, máx 5 bytes / 5º ≤ 15). Cotas DoS en strings. NUNCA re-serializa (contrato ASP-3). pallet-origin-provenance: - attest_asset(signing_payload: BoundedVec<u8,512>, signature: [u8;64]): recibe los bytes postcard OPACOS + la firma; decodifica, verifica Ed25519 vía sp_io::crypto::ed25519_verify (host function, no bloatea wasm, precedente FIX-3) sobre el mensaje domain-separado con el genesis_hash de ESTA cadena. La pubkey se decodifica del payload (no param aparte). creator = el validador, anchored_at_block real (cerró los placeholders del scaffold). - Dedup-by-BLAKE3 con rechazo EXPLÍCITO (asset_id = BLAKE3 content hash, dentro del payload firmado → replay del mismo blob reusa el asset_id → AlreadyAttested). Hallazgos de la verificación adversarial (workflow ultracode, 3 lentes) cerrados de RAÍZ: - HIGH asset-id squat / provenance poisoning + MEDIUM tier-forgery: el gate era self-attested (level del payload) → cualquiera con una clave Ed25519 anclaba basura institucional bajo el hash PÚBLICO de un asset legítimo y lo envenenaba de forma inmutable. FIX: registro on-chain AuthorizedValidators (pubkey → nivel OIT) gobernado por Root (register_validator/revoke_validator); la membresía es la VERDAD, no el payload. Mismo patrón que TierProfiles de FIX-6 Stage 2a (legitimidad on-chain, no caller-supplied). Sunset a attestation-driven cuando aterrice el registro OIT de Mathi. - MEDIUM método muerto: removido el ValidationAttestation::signing_payload() SCALE divergente (producía bytes que jamás verificarían — footgun). Decisiones (autoridad Pilar 4): sp_io ed25519_verify (consistente FIX-3, estándar Substrate) · dedup-by-asset_id subsume replay exacto · golden vectors generados desde el oráculo REAL de Ergon (seed [7u8;32], genesis 0xAB) = prueba cross-runtime. PENDIENTE (gap legítimo, no bug): OriginChainAttestationSink (impl del trait ValidationAttestationSink de Ergon) es código cliente off-chain — vive en un crate bridge del monorepo (subxt), NO en el chain repo (dependency direction submódulo→monorepo prohibida). Se cablea con la integración Noesis→chain. Tests: 19 provenance (golden vectors cross-runtime + squat cerrado + revoke + anti-replay cross/intra-chain + tamper + malformed) + 72 types (decoder fuzz- equivalente a postcard + fidelidad u32) + 21 suites workspace verde. cargo +1.88. WASM: build VPS-gated (UnknownOpcode 252 ambiental, ver v0.0.58). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Fable 5
|
3364994cce |
feat(fees): FIX-6 Stage 2a — fee unificado (cierra V2-CA3)
Pone la fórmula OCAFB-5 en el fee-path VIVO: OriginFeeAdapter (OnChargeTransaction custom) reemplaza al FungibleAdapter tier-blind. El firmante paga su fracción según (HardwareTier × ChainAction × SubscriptionTier, tiers leídos ON-CHAIN de TierProfiles — jamás caller-supplied), y el subsidy pool og/subsy (alimentado por la emisión Stage 1) cubre la fracción subsidiada. Inmutable #16 en cada transacción. OU=() = burn 100% gas fees (matriz CHN-2). unified_fee (u128, outcome tipado FeeOutcome — sin el sentinel u64::MAX in-band): user = fórmula vendor Mathi byte-fiel (test de paridad grid contra ce4fafb); pool = net × subsidy_bp/1e4 sobre el COSTO BASE (anti-regresivo, sub_mult ORTOGONAL: un Ultra NO drena el pool más que un Free — el premium lo paga el usuario, no el commons). Hallazgos de la verificación adversarial (workflow ultracode, 4 lentes) cerrados de raíz: - HIGH: clasificador cubre eth_instantiate_with_code (call_index 10) — evadía el entitlement-gate DeployContract vía fallback Write. - MEDIUM ledger envenenable: removido el dispatchable legacy compute_fee_for_action (tiers caller-supplied, escribía AccountFees sin cobrar). AccountFees ahora escrito SOLO por el fee-path vivo (note_settlement). Eventos que nunca se emitían eliminados; el preview read-only vive en query_fee / FeesApi. - MEDIUM drenaje del pool por sub_mult: pool sobre net, no sobre el precio premium (Opción B anti-regresiva). - Dev UX: GenesisConfig siembra perfiles iniciales; dev/local arrancan Ultra (los Slices 3.x de contracts no se bloquean por Free+DeployContract); mainnet vacío (Default conservador hasta attestation). Decisión de diseño (autoridad Pilar 4): replay de attestation = RECHAZO explícito, no dedup silencioso (notificado a Ergon para el reference impl). Orden OCAFB-5 subsidy-antes-de-entitlement preservado byte-fiel + notificado a Mathi para el ratify 2026-06-21. set_tier_profile Root-only interim (sunset a attestation-driven vía Mathi PerceptionAdapter + DID binding FIX-3/FIX-4). spec_version 1→2 (formato de extrinsic intacto, TRANSACTION_VERSION=1). Tests: 49 crate fees (paridad grid + lobo blanco ortogonalidad + refund + pool seco + tip passthrough + entitlement blocked) + 21 suites workspace verde. Toolchain cargo +1.88. Nota WASM: el build local del runtime WASM falla en la post-validación del substrate-wasm-builder con UnknownOpcode(252) — límite del toolchain (Rust 1.88 emite opcodes 0xFC que el parser del builder de stable2509 no deserializa). Reproducido idéntico en el HEAD intacto (v0.0.57): es ambiental, no de este cambio. El node real + WASM artifact siguen VPS-gated (toolchain alineado / wasm32v1-none cuando el wasm-builder lo soporte). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
e6a803b54f |
feat(emission): FIX-6 Stage 1 — emision que paga validadores (V2-CA2) + remover APR falso
Build + tests verde: emission pallet 5 + runtime 28 (incl. emission_pallet_index_13)
+ staking contract 4. Verificacion adversarial ultracode (2 skeptics): correctitud
+ seguridad CONFIRMADAS (split exacto, sin overflow, autor solo-desde-Aura sin
input de usuario, mint-None-seguro, sin dispatchable explotable, APR removal
honesto). 'partial' solo por cobertura de tests en ramas triviales (None /
reward==0), NO por vulnerabilidad.
Cierra V2-CA2 (la cadena no tenia emision -> los validadores ganaban 0 OGC):
NUEVO pallet origin-chain-emission (Index 13):
- on_initialize cada bloque: identifica al autor Aura (FindAuthor =
pallet_session::FindAccountFromAuthorIndex<Runtime, Aura>), mintea un
BlockReward (10 OGC, ~5.26% inflacion anual) y lo reparte:
- 70% al autor (el validador que produjo el bloque).
- 20% al treasury (og/gvtry — la MISMA cuenta-vault de governance FIX-6).
- 10% al subsidy pool (og/subsy — proof-of-equity que financia el subsidio
de hardware anti-clasista #16).
- El residual del split va al subsidy (no pierde unidades por redondeo de bps).
- TotalEmitted trackea la inflacion acumulada on-chain. mint_into (fungible::
Mutate) = emision real (aumenta total issuance).
- El autor viene SOLO de FindAuthor/Aura (no de input de usuario) -> nadie puede
mintear a una cuenta arbitraria. Si FindAuthor devuelve None, no mintea. Sin
overflow (saturating_mul/div, 10^19 << u128::MAX).
sub_mult ORTOGONAL (David 2026-06-10): el subsidy pool financia el subsidio de
hardware SIN importar la suscripcion premium. Esta emision lo alimenta; el
OnChargeTransaction de Stage 2 lo consumira.
Remover APR falso (V1/V2 fake APR): staking contract default_chn3 reward rates
8/5/3% -> 0. Era enganoso (no habia motor que los pagara; los campos
reward_rate_bps se almacenaban pero NUNCA se leian, rewards_accumulated jamas se
acreditaba). Los validadores ahora cobran via la emision real; las tasas de
staking reales las define Stage 2 (NPoS por stake).
FIX-6 Stage 1 COMPLETO (con v0.0.56 treasury real): emision + treasury real +
APR removido. Stage 2: NPoS (pallet_staking + EraPayout) + fee unificado
(OnChargeTransaction con sub_mult ortogonal).
FOLLOW-UPS (low, documentados): anadir tests de cobertura para las ramas
FindAuthor==None (no mintea) y reward==0 (requieren un 2o mock runtime);
BlockReward fijo (decay schedule = Stage 2); el subsidy pool acumula pero no se
consume hasta el OnChargeTransaction de Stage 2; genesis mainnet del treasury
vault (pre-launch).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
davidherranandClaude Opus 4.8
|
1a9e37021d |
fix(governance): FIX-6 Stage 1 — tesoreria real Currency (cierra hallazgo de FIX-5)
Build + tests verde: governance 42 + runtime 27. Verificacion adversarial ultracode (2 skeptics): 2 confirmed/low, sin blockers. Cierra el hallazgo HIGH de FIX-5: treasury_disbursement era simbolico (solo decrementaba un contador u128 desconectado de pallet_balances). Ahora: - governance Config: type Currency (fungible Inspect+Mutate) + type TreasuryPalletId (pallet::constant). - Eliminado el contador Treasury<StorageValue<u128>> (0 referencias colgantes). - treasury_account() = PalletId.into_account_truncating() — vault keyless deterministico (nadie lo controla por wallet; honor Inmutable #16). - treasury_balance() lee el balance REAL (Inspect::balance), no un contador. - treasury_disbursement: T::Currency::transfer real desde el vault al recipient (ensure_root + proposal Approved). treasury_deposit: signed, dona del propio balance del caller (cualquiera fondea, no requiere Root, imposible robar). - runtime configs.rs: Currency=Balances + GovernanceTreasuryPalletId(og/gvtry). - mock con pallet_balances + scenario_4 prueba que el RECIPIENT recibe OGC REAL en pallet_balances (bob 100M -> 100M+300k), no solo que el contador baja. Decision constitucional (FIX-6 V2-CA3): David ratifico sub_mult = ORTOGONALES (la suscripcion premium NO reduce el subsidio anti-clasista de hardware, #16). Input para el OnChargeTransaction de Stage 2. Registrado en KG. FOLLOW-UPS (low, documentados, no bloquean): - genesis mainnet: rutear los 250M Foundation a la cuenta og/gvtry (hoy van a FNDT) — detalle de pre-launch que David ratifica. El vault arranca en 0 hasta fondear. - treasury_disbursement no vincula amount/recipient al proposal Approved, y el mismo proposal es reusable (no se marca disbursed). Check ceremonial, no autorizacion per-desembolso. Sin escalada nueva (Root ya puede todo via sudo). Endurecer antes del sunset sudo->governance. FIX-6 Stage 1 restante (next): emision que paga Aura authors (cierra V2-CA2) + remover APR falso del staking contract. Stage 2: NPoS + fee unificado (OnChargeTransaction con el sub_mult ortogonal). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
88e277e1fd |
fix(agent-identity): FIX-3 crypto — DID binding (anti-front-running) + derive_did domain-sep
Build + tests verde: agent-identity 18 (4 unit + 14 integration) + runtime 27.
Verificacion adversarial ultracode (3 skeptics): 2 confirmed + 1 partial/low,
todos los gaps PRE-EXISTENTES (no introducidos por FIX-3). Invariante "no
puedes registrar un public_key que no controlas" SE SOSTIENE.
FIX-3 (b) DID binding — V3-H1 anti-front-running:
- register_agent_did ahora exige signature: [u8;64] — una firma Ed25519 (por la
private key de public_key) sobre AGENT_DID_REGISTER_DOMAIN || who.encode().
- Verificacion on-chain via sp_io::crypto::ed25519_verify (host function, no
bloatea el wasm). Nuevo dep sp-io (no_std).
- Cierra el front-running: un atacante no puede registrar un public_key ajeno
(no produce la firma); el who en el mensaje ata la firma a este caller (no
replay-able a otra cuenta). Error InvalidSignature. Malleabilidad Ed25519
rechazada por ed25519-zebra (S canonico).
- Una sola fuente de verdad del mensaje (agent_did_register_message) compartida
entre verificador y firmante (evita divergencia tipo postcard-vs-SCALE).
- Orden: idempotency ANTES del verify (no gasta crypto en duplicados).
FIX-3 (c) derive_did domain-sep — V3-H2:
- blake3::derive_key("origin-chain/agent-did/v1", pk) en vez del concat ad-hoc
BLAKE3(pk || version). KDF domain-separado. Inmutable #16 preservado.
Tests: mock con keypairs Ed25519 reales (sp_core::ed25519::Pair) + sign helper.
12 scenarios (scenario_6 reformulado a front-running -> InvalidSignature, +
scenario_11 firma invalida, scenario_12 DID collision genuino del key-holder).
NOTA: la (a) domain-sep del attestation signing payload (el otro tercio de
FIX-3) ya esta cubierta por el DC ORIGIN_ATTESTATION_SIGNING_PAYLOAD_V1 (helper
de Ergon attestation_signed_message), pendiente su ship Cap 45+.
FOLLOW-UPS (low, pre-existentes, no bloquean):
- (a) anadir genesis_hash/chain-id al mensaje de registro (hardening cross-chain
replay) — ideal chain-wide junto al signing_payload de attestation.
- (b) DC para ratificar el modelo de autoridad Hybrid (quien firma) + si los
co_authors requieren prueba de consentimiento (lineage hoy no autenticado).
- (c) weight benchmarking real que contabilice el ed25519_verify (chain-wide,
post-testnet — ya en roadmap FIX-2 weights).
- creator = AccountId::new(public_key) (la cuenta del key-holder, no el caller):
coherente con el binding, semantica documentada.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
davidherranandClaude Opus 4.8
|
8a1f779c32 |
fix(runtime): FIX-5 governability (pallet-sudo to Root) + FIX-2 StorageVersion (4 pallets)
Build + tests verde (exit 0, runtime 27 tests incl. sudo_pallet_index_12). Verificacion adversarial ultracode (5 skeptics): 4 confirmed + 1 partial. FIX-5 — governability (audit V2-CA1): - pallet-sudo 43.0.0 wired Index 12 (workspace + runtime Cargo.toml + std). - impl pallet_sudo::Config (RuntimeEvent/RuntimeCall/WeightInfo) en configs.rs. - genesis: sudo key en los 3 presets — dev/local=Alice, mainnet=foundation_treasury (NO una dev key; el verificador confirmo que no hay backdoor critico). - Da Root origin -> las dispatchables ensure_root de Governance (add/remove council, mark/unmark advisor, treasury_disbursement) dejan de ser no-invocables. Verificado extremo-a-extremo: sudo() despacha RawOrigin::Root, que es exactamente lo que ensure_root acepta. - Sunset documentado (codigo + doc): sudo -> governance real (pallet-collective/ referenda) ANTES de mainnet. Sudo key unica = riesgo de centralizacion aceptable solo como interim/testnet. FIX-2 — lifecycle (audit V1-H2/V2-CA2): - StorageVersion::new(0) + pallet::storage_version en los 4 pallets (provenance/fees/agent-identity/governance). Aditivo, in-code==on-chain==0, sin migracion forzada. Habilita migraciones futuras. CAVEAT honesto (hallazgo high del red-team, NO defecto de FIX-5/FIX-2): treasury_disbursement solo DECREMENTA un contador u128 (Treasury StorageValue), NO mueve OGC real via pallet_balances. FIX-5 restaura la GOBERNABILIDAD (la dispatchable es invocable), pero mover los 250M reales es FIX-6: anadir type Currency al Config + T::Currency::transfer desde una cuenta-tesoreria derivada (PalletId) + financiarla en genesis + test del free_balance. NO se afirma "tesoreria descongelada de verdad" — solo "gobernabilidad restaurada". PENDIENTE: - FIX-2 AGI key recovery (rotate/revoke/active en agent-identity): diferido — necesita un DC de semantica de recovery #41 (single-sig vs multisig threshold, DID estable vs rota, recovery de agent_chain vacio). No se construye contra spec no-ratificada. - pallet-sudo no en feature runtime-benchmarks (inerte hoy: el runtime no impl el Benchmark API). Follow-up con weights benchmarking. - mainnet Foundation sudo key (FNDT placeholder): David ratifica la key real (multisig) pre-launch Q1 2027 (documentado). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
4485bb8683 |
fix(slice-4): service.rs/rpc.rs corrected (Block root + verbatim CIDP) + §11 honest finding
Slice 4 checkpoint tras intentar Opción C (David: stack consistente del tag). Build verde, 213 tests, sin regresiones. Node sigue CLI+chain_spec (mods off). === Correcciones a service.rs/rpc.rs (preservadas para wire-in) === - Block root (no opaque::Block): el runtime expone impl_runtime_apis! sobre el Block root con UncheckedExtrinsic, no un opaque block separado. rpc.rs igual. - CIDP verbatim del template restaurado: standalone::slot_duration_at + inherents::InherentDataProvider::from_timestamp_and_slot_duration. AMBOS existen en sp-consensus-aura 0.45.0 PUBLICADO (verificado inherents.rs:61). Mi 'fix' v0.0.49 (Slot::from_timestamp) era incorrecto — revertido. === §11 corrige §10.2 (diagnóstico honesto) === El problema NO era API gap (las APIs existen) ni elegir bien versiones publicadas. Es estructural del ecosistema: polkadot-sdk publica sus ~15 sub-crates sc-* en cadencias distintas → NO existe isla de versiones publicadas internamente consistente que reproduzca el tag. Verificado vía sparse index: - sc-consensus-aura 0.52.0 → sp-consensus-aura ^0.44; 0.53.0/0.53.1 → ^0.45; 0.54.0 → ^0.44 (oscila entre generaciones en patches consecutivos) - sc-service 0.54.1 (versión del tag) NO publicada en crates.io El tag solo es consistente vía su Cargo.lock commiteado en el monorepo git. === Recomendación senior para David (§11.4) === Diferir node service real al setup de infra Phase 4 testnet (que necesita build env con red git de todos modos). NO seguir adivinando versiones publicadas (no convergen). Firmes: WASM export (v0.0.48) + core2 unblock (v0.0.49) + service.rs/rpc.rs correctos. Wire-in ~1 sesión cuando haya env con git fetch O un Cargo.lock del monorepo stable2509-3. Verificación: cargo check -p origin-chain-node verde (mods off) + 213 tests verde. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
davidherranandClaude Opus 4.8
|
e0e0b907b7 |
feat(slice-4): v0.0.49 — core2 yanked unblock + sc-service WIP (crates.io API gap found)
Slice 4 Ship 2 parcial. RESUELVE el blocker real que difirió sc-service 3
sesiones (core2 yanked), pero DESCUBRE un segundo bloqueo arquitectural que
requiere decisión de David. Build verde, 213 tests, sin regresiones.
=== RESUELTO: core2 yanked (el muro de 3 sesiones) ===
sc-network-types 0.16 → cid ^0.9 (0.9.0 yanked) → core2 ^0.4 (0.4.0 yanked,
las no-yanked son 0.3.x que no satisfacen ^0.4). Cargo no auto-selecciona
versiones yanked → resolución fallaba. Era exactamente lo documentado en
chain_spec.rs Slice 3 que difirió sc-service.
Fix: vendorizado el .crate publicado de core2 0.4.0 (yanked pero descargable)
en vendor/core2-0.4.0/ + [patch.crates-io] core2 = { path = ... }. Una path
source es seleccionable independiente del estado yanked. El git source
(technocreatives/core2 master) resultó ser workspace ≤0.3.x, no servía.
=== DESCUBIERTO: crates.io consensus crates ≠ git tag API ===
Las crates sc-/sp- consensus PUBLICADAS (sc-consensus-aura 0.52.0 +
sp-consensus-aura 0.45.0) tienen API DISTINTA al git tag polkadot-stable2509-3
bajo el MISMO número de versión:
- git tag: sc_consensus_aura::standalone::slot_duration_at +
sp_consensus_aura::inherents::InherentDataProvider::from_timestamp_and_slot_duration
- crates.io: slot_duration_at en root + NO existe slot InherentDataProvider
(Slot no implementa el trait; Slot::from_timestamp toma 1 arg)
polkadot-sdk reusa números de versión con cambios git no publicados.
Construir un node service real requiere migrar TODO el stack sc-/sp- consensus
a git sources del tag — la misma cirugía duplicate-crate que golpeó pallet-revive
(Ship 2 v0.0.39). Decisión arquitectural para David.
Cambios:
- Cargo.toml: [patch.crates-io] core2 path vendor + sp-timestamp 39 + sp-blockchain 41
- vendor/core2-0.4.0/: crate vendorizado (yanked artifact original)
- node Cargo.toml: 13 sc-* + sp- consensus deps + jsonrpsee/rpc + core2 unblock dep
- node src/service.rs + rpc.rs: WIP escritos (verbatim stable2509-3 + 2 fixes API
crates.io), NO mod-declarados (preservados para siguiente fase)
- node src/main.rs: finding documentado, mods service/rpc neutralizados
Verificación:
- cargo check -p origin-chain-node: EXIT 0 (deps resuelven vía core2, mods off)
- cargo test --workspace: 213 verde, 0 fail, sin regresiones
- core2 0.4.0 + cid 0.9.0 ahora en Cargo.lock (vía path patch)
Próximo: decisión David — (A) migrar sc-/sp- consensus a git sources tag
stable2509-3 (real node, riesgo duplicate-crate) vs (B) mantener publicadas
(node service diferido a futura generación Substrate). Ver SLICE_4 plan §10.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|
davidherranandClaude Opus 4.8
|
05b6c70fca |
feat(slice-4): v0.0.48 — runtime exporta WASM_BINARY (Paso 4a)
Slice 4 Ship 1 — prerequisito para el full sc-service. El runtime ahora exporta WASM_BINARY que el node consumirá para construir ChainSpecs reales (Paso 4b). build.rs ya generaba OUT_DIR/wasm_binary.rs vía substrate-wasm-builder (Slice 2e), pero lib.rs no lo incluía. Esta ship añade el include! gateado: - #[cfg(feature = wasm-build)] include!(OUT_DIR/wasm_binary.rs) → WASM_BINARY real - #[cfg(not(wasm-build))] pub const WASM_BINARY: Option<&[u8]> = None → host-only - wasm_binary_unwrap() helper con mensaje de error claro El gate evita: (1) error de compilación cuando wasm-build off (archivo no existe), (2) recursión en build.rs (el inner build wasm32 no hereda wasm-build, no es default). Verificación: - cargo check -p origin-chain-runtime (host, wasm-build off): clean, WASM_BINARY=None - cargo build --features wasm-build + CC=LLVM: clean 39s, include! compila → WASM_BINARY=Some (real binary 2.8 MB) - cargo test --workspace: 213 verde, 0 fail, sin regresiones Próximo Ship 2 (v0.0.49): Paso 4b chain_spec GenericChainSpec + Paso 4c service.rs + rpc.rs + node sc-* deps. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
davidherran
|
1c097c1855 |
feat(revive): v0.0.41 — Phase 3 Slice 3.1 SCAFFOLD COMPLETE (ReviveApi deferred a 3.2) 🎉🎉🎉
Ship 4 v0.0.41 — Phase 3 Slice 3.1 SCAFFOLD COMPLETE end-to-end marker. pallet-revive 0.10.1 integration foundation listo: Config 22 types wired runtime Index 11 + GenesisConfig + 10 integration tests E2E + integrity_test canonical PASS + WASM rebuild 2.8 MB. Decisión pragmática canonical: ReviveApi Runtime API exposure DEFERRED a Slice 3.2+ post audit empírico 18 compile errors (API 0.10.1 signatures significativamente divergent vs initial audit 0.12.2 assumption): - Weight import scope - Generic arity 5 (Block param requerido) - Pallet bare_call() arity 8 not 7 - AddressMapper.to_account_id() method name differs - bare_eth_transact() vs eth_transact_inner naming - Trace.default() no derived - DepositLimit::Balance enum wrapping Cambios: - crates/origin-chain-runtime/src/lib.rs: ReviveApi impl placeholder commented out (/* ... */) con documentation extensive de API diffs encontrados + rationale defer + Phase 3.x maduración path. Slice 3.1 SCAFFOLD COMPLETE summary: ✅ Ship 1 v0.0.37 — ChainAction Phase 3 extension + workspace dep scaffold ✅ Ship 1.5 v0.0.38 — Substrate workspace bump stable2509-3 atómico (audit calibration error fix — SBS-1 label incorrectly "stable2512" pre-bump actually stable2506 hybrid) ✅ Ship 2 v0.0.39 — pallet-revive 0.10.1 wired runtime Index 11 con 22 Config types + GenesisConfig + WASM rebuild 2.8 MB ✅ Ship 3 v0.0.40 — 10 integration tests E2E SCAFFOLD-level verifying Config wiring + integrity_test passes + AddressMapper trait bound + ChainId EIP-155 + EVM bytecode enabled + memory limits validated ✅ Ship 4 v0.0.41 — SCAFFOLD COMPLETE marker (ReviveApi deferred 3.2) Métricas Sesión 4+ Charon: - 4 ships shipped Gitea direct-to-main TOTAL canonical (v0.0.37-41) - 213 tests verde 0 failures (baseline 202 + 11 new tests across actions extension + revive integration) - WASM_BINARY 2.8 MB shipped (grew +1 MB de baseline 1.8 MB v0.0.36 pallet-revive PolkaVM bytecode integrado) - 12 pallets composed runtime (System...Governance...Revive Index 11) - 39 ships canonical TOTAL Origin Chain Gitea (v0.0.1 → v0.0.41) - 0 structural blockers — Path A Phase 3 Slice 3.1 FOUNDATION canonical preserva Path B + Path C unblocked Próximos paths posibles canonical sesión 5+: - Slices 3.2-3.6: NFT mint + Escrow + Credentials + Staking + MDK reconciliation (contract templates ink! v6 + ReviveApi exposure final) - Path B Phase 1.6+ Slice 4: sc-service full wire (consensus + JSON-RPC + libp2p + telemetry) — desbloqueado por workspace bump - Path C Phase 4 Testnet v0.1 prep: multi-validator + faucet + block explorer CHARON_ROADMAP_V1.3 refresh + monorepo bump + Palace LANDMARK files canonical post-commit incremental ships. ⚓ Phase 3 Slice 3.1 SCAFFOLD COMPLETE. La nave Origin Chain anclada en puerto smart contracts. Path A fundación PolkaVM RISC-V listo. Mission progress 70% → ~75%. 🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
davidherran
|
c02f525b9a |
feat(revive): v0.0.40 — pallet-revive 10 integration tests E2E SCAFFOLD-level + integrity validation 🎉
Ship 3 v0.0.40 SHIPPED — pallet-revive Config wiring validation tests E2E.
Slice 3.1 SCAFFOLD-level scope: verify Config types correctly wired + constants
preserved + AddressMapper trait bound satisfied + integrity formula passes.
Real PolkaVM bytecode E2E (upload_code + bare_call + storage deposits actual)
deferred a Phase 3.x maduración post cargo-contract v6 install + ink! v6
contract templates Slices 3.2-3.6.
Cambios:
- crates/origin-chain-runtime/src/lib.rs: +10 tests #[cfg(test)] mod tests:
1. revive_chain_id_eip155_unique_origin_metaverse — ChainId=9_120_005 verified
2. revive_native_to_eth_ratio_one_million_canonical — NativeToEthRatio=1_000_000
3. revive_deposit_per_byte_canonical_milli_ogc — DepositPerByte=MILLI_OGC
4. revive_deposit_per_item_canonical_one_ogc — DepositPerItem=Ogc::ONE
5. revive_evm_bytecode_allowed_canonical — AllowEVMBytecode=true per SBS-5
6. revive_runtime_memory_128_mb_canonical — RuntimeMemory=128 MB
7. revive_pvf_memory_2_gb_canonical_integrity_pass — PVFMemory=2 GB + formula
`storage_limit = (PVF-RuntimeMemory)/2 > 700 MB` validated
8. revive_safety_toggles_production_safe_canonical — UnsafeUnstableInterface=false
9. revive_pallet_index_11_canonical_post_governance — Index=11 post Governance
10. revive_address_mapper_account32_returns_h160_canonical — AddressMapper trait
bound satisfied compile-time canonical
Verificación:
- cargo check --workspace clean (27 warnings pre-existentes deprecated)
- cargo test --workspace: 213 tests verde 0 failures NO regresiones
(baseline 203 + 10 nuevos revive integration tests)
- cargo test -p origin-chain-runtime: 26 tests verde
(16 baseline + 10 nuevos)
- cargo build --features wasm-build: WASM_BINARY 2.8 MB clean
- __construct_runtime_integrity_test pallet-revive 0.10.1 PASS empírico
Próximo Ship 4 v0.0.41: ReviveApi Runtime API exposure via sp_api::impl_runtime_apis!
+ LANDMARK Palace Phase 3 SCAFFOLD COMPLETE + monorepo bump + CHARON_ROADMAP_V1.3
refresh sesión 4+ comprehensive.
⚓ Phase 3 Slice 3.1 Ship 3/4 SHIPPED. 213 verde. La nave canonical lista para API exposure.
🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
davidherran
|
86d9251908 |
feat(revive): v0.0.39 — pallet-revive wired runtime Index 11 (22 Config types + GenesisConfig + WASM rebuild) 🎉🎉
Ship 2 v0.0.39 SHIPPED — pallet-revive 0.10.1 integration end-to-end post
Ship 1.5 v0.0.38 workspace bump stable2509-3 atómico. SBS-5 ratificado
(supersedes CHN-6 v1.0): smart contracts PolkaVM RISC-V + ink! v6 + Solidity
deployables canonical post Slice 3.1 SCAFFOLD COMPLETE pending Ship 3+4
(v0.0.40 integration tests + v0.0.41 ReviveApi).
Cambios:
- Cargo.toml workspace.dependencies: pallet-revive 0.10.1 crates.io
(NOT git source — git source pulled duplicate frame-system/sp-runtime copies
rompiendo trait bounds canonical. Crates.io 0.10.1 deps match workspace
bumped stable2509-3 generation clean canonical empírico).
- crates/origin-chain-runtime/Cargo.toml: pallet-revive added dep + features.std.
- crates/origin-chain-runtime/src/lib.rs: Runtime macro Index 11 added
`pub type Revive = pallet_revive::Pallet<Runtime>` canonical.
- crates/origin-chain-runtime/src/configs.rs: pallet_revive::Config impl con
22 associated types per pallet-revive 0.10.1 docs.rs canonical surface:
* Runtime types: RuntimeEvent, RuntimeCall, RuntimeHoldReason
* Currency/Balance: Currency=Balances, Time=Timestamp, WeightPrice=TransactionPayment
* Storage/Deposit: DepositPerByte=MILLI_OGC, DepositPerItem=OGC,
CodeHashLockupDepositPercent=30%
* EVM/Mapping: AddressMapper=AccountId32Mapper, ChainId=9_120_005 (EIP-155
unique Origin Metaverse), NativeToEthRatio=1_000_000 (OGC 12 dec → ETH 18),
AllowEVMBytecode=true, EthGasEncoder=()
* Precompiles=() Slice 3.1 SCAFFOLD interim
* Limits: WeightInfo=SubstrateWeight, RuntimeMemory=128 MB, PVFMemory=2 GB
(per integrity_test formula `storage_limit = (PVFMemory-RuntimeMemory)/2`
needed PVFMemory > 1.5 GB para pass max_storage_size ~650 MB check)
* Access Control: UploadOrigin=EnsureSigned, InstantiateOrigin=EnsureSigned
* Safety: FindAuthor=() (no pallet_authorship), UnsafeUnstableInterface=false
- crates/origin-chain-runtime/src/genesis_config_presets.rs: ReviveConfig::default()
added a build_genesis canonical (Slice 3.1 SCAFFOLD: no pre-mapped accounts,
no genesis contracts — Phase 3.x maduración añade dev mapped_accounts +
templates contracts Slices 3.2-3.6).
API diffs encontrados empírico pallet-revive 0.10.1 vs 0.12.2 audit inicial:
- 0.10.1 NO expone: RuntimeOrigin, DebugEnabled, FeeInfo, MaxEthExtrinsicWeight,
GasScale, DepositPerChildTrieItem (todos added en 0.12+ Asset Hub generation).
- 0.10.1 SÍ require: WeightPrice (Convert<Weight, Balance>) + EthGasEncoder
(gas conversion helper) — NO en 0.12.2 audit anterior.
Verificación:
- cargo check --workspace clean (warnings pre-existentes deprecated patterns)
- cargo test --workspace: 203 tests verde 0 failures NO regresiones
- cargo build --features wasm-build: WASM_BINARY 2.8 MB shipped clean
(grew from 1.8 MB v0.0.36 baseline — +1 MB pallet-revive PolkaVM bytecode)
- Runtime integrity test (__construct_runtime_integrity_test) PASS post memory
tuning empírico-validated (16/16 runtime tests verde).
Próximo Ship 3 v0.0.40: pallet-revive real impl + 10 integration tests E2E
(upload_code + instantiate + bare_call + storage deposit + AddressMapper +
gas metering + access control + ChainId EIP-155 + contract destruction).
⚓ Phase 3 Slice 3.1 Ship 2/4 SHIPPED. La nave entra zone canonical smart contracts.
🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
davidherran
|
ebe09f1b2e |
feat(substrate-bump): v0.0.38 — Substrate workspace bump stable2509-3 (Phase 3 precondition) 🎉
Ship 1.5 v0.0.38 SHIPPED — Substrate workspace bump empírico audit-validated post Ship 1 v0.0.37 pallet-revive scaffold. Phase 3 pallet-revive integration revealed SBS-1 ratificado label "stable2512-3" sesión 1 awakening era audit calibration error — workspace pre-bump era generation híbrida stable2506-ish con pins inconsistentes (sp-runtime 41.1.0 + sp-core 36.1.0 + frame-support 40.1.0 = no clean-match ningún polkadot-stable tag publicado). Audit empírico Ship 2 v0.0.38 attempted 3 tags polkadot-stable (2512-3 + 2509-3 + 2506-2) — todos fallaron por version mismatch transitive deps (alloy-* rustc 1.91 + CheckMortality vs CheckEra + sp-runtime version drift). Honest disclosure pattern aplicado per memory directive — revert + audit + reshuffle plan. Solución canonical: workspace bump atómico a polkadot-stable2509-3 generation puro (pallet-revive 0.10.1 disponible + rustc 1.88 compat preserved + WASM build Slice 2e preserved). Cambios: - Cargo.toml workspace.dependencies: ALL sp-* + frame-* + pallet-* + sc-* bumped a stable2509-3 versions verified empírico via WebFetch per-crate Cargo.toml: * sp-core 36.1.0 → 38.1.0 * sp-runtime 41.1.0 → 44.0.0 * sp-io 40.0.1 → 43.0.0 * sp-api 36.0.1 → 39.0.0 * sp-version 39.0.0 → 42.0.0 * frame-system 40.1.0 → 43.0.1 * frame-support 40.1.0 → 43.0.0 * frame-executive 40.0.0 → 43.0.1 * pallet-balances 41.1.0 → 44.0.0 * pallet-timestamp 39.0.0 → 42.0.0 * pallet-transaction-payment 40.0.0 → 43.0.0 * pallet-aura 39.0.0 → 42.0.0 * pallet-grandpa 40.0.0 → 43.0.0 * pallet-session 40.0.1 → 43.0.0 * sc-* (cli/service/network/consensus/etc) bumped proporcional * substrate-wasm-builder 26.0.1 → 29.0.0 * frame-system-rpc-runtime-api 36.0.0 → 39.0.0 * pallet-transaction-payment-rpc-runtime-api 40.0.0 → 43.0.0 * sp-genesis-builder 0.17.0 → 0.20.0 * sp-consensus-aura 0.42.0 → 0.45.0 * sp-consensus-grandpa 23.1.0 → 26.0.0 * sp-session 38.1.0 → 41.0.0 * frame-benchmarking 40.0.0 → 43.0.0 * frame-metadata-hash-extension 0.8.0 → 0.11.0 - Cargo.toml workspace.dependencies: serde pin relajado =1.0.217 → 1.0.219 (Slice 2b workaround obsoleto post-Slice 2e RESUELTO Layer 4 sp-io std leak fix vía default-features=false discipline — strict pin causaba parity-scale-codec 3.7.5 conflict requiriendo ^1.0.219). - crates/origin-chain-runtime/src/configs.rs: pallet_session::Config Stable2509-3 API additions — Currency type (= crate::Balances) + KeyDeposit (= ConstU128<0>) para session key registration deposit economy. Phase 1 PoA simple: zero deposit canonical (genesis validators static). Phase 2 NPoS introduces real deposit. Verificación: - cargo check --workspace clean (26 warnings pre-existentes deprecated patterns) - cargo test --workspace: 203 tests verde 0 failures NO regresiones - cargo build --features wasm-build: WASM_BINARY 1.5 MB shipped clean post-bump (Slice 2e infrastructure CC=LLVM + WASM_BUILD_STD=0 preserved canonical) - Cargo.lock: +511 lines (new transitive deps for stable2509-3 ecosystem) Próximo Ship 2 v0.0.39: pallet-revive 0.10.1 from stable2509-3 source wired runtime Index 11 (27 Config types per Asset Hub Westend reference). Workspace bump DESBLOQUEA Phase 3 integration end-to-end canonical. Audit calibration update: SBS-1 ratificado labeling error documentado para sesión seal CHARON_ROADMAP_V1.3 refresh — Phase 0 awakening cold-start assumption error preserved transparency canonical. ⚓ Ship 1.5 SHIPPED. Phase 3 UNBLOCKED. La nave continúa con generation purificada. 🤖 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |