10 Commits
Author SHA1 Message Date
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 3cd1068.
- 5 procesos por pallet; se cobra el MÁXIMO con scripts/bench/max-de-n.py, porque procesos
  idénticos se separan hasta un 35 %.
- Evidencia: ~/laurha-work/banco/spec16-20261024-1631 en la rp1 (SHA256SUMS d930c5e1).
- Su perfil va en la cabecera de cada weights.rs.

Antes de cobrarlos:
- Mismos accesos a storage: el esqueleto de los 5 ficheros y sus reads/writes son idénticos a
  los de main.
- Lo que Laurha pidió mirar (cast_vote, finalize_proposal y veto_proposal, mucho más altos que
  en RV12) es esperable. Contra los interinos del Mac todos caen en la banda Pi/Mac de 2,5-3,9×:
  es trabajo nuevo de RV15/RV16 en una CPU unas 3 veces más lenta.
- Destacan los tres que verifican Ed25519 en WASM (attest_asset, register_agent_did,
  rotate_agent_key), con unas 6 veces: la criptografía pura sufre más en la Cortex-A76.
- Lo cobrado sube menos que la ejecución, entre +4 % (set_tier_profile) y +56 %
  (rotate_agent_key), porque las lecturas y escrituras de storage no cambian.
- spec_version 16 → 17, porque cambian las fees. transaction_version no cambia: ninguna llamada
  cambia su codificación.

Ensayado en la rp1 (aarch64) sobre un nodo efímero aparte, antes de la testnet de la casa, con
scripts/e2e/upgrade_en_vivo.py (nuevo):
- sudo(set_code) → CodeUpdated + Sudid Ok;
- spec 17 y LastRuntimeUpgrade sube;
- una firma con la spec vieja → «bad signature»; con la nueva, ExtrinsicSuccess;
- la finalidad pasa del bloque del upgrade.
Es la primera vez que el ejecutor ARM compila y corre un runtime nuevo.

Revisión adversarial (nivel 1 de la directiva), antes de tocar la red, con orden de tumbarlo:
no pudo. Los seis puntos aguantan:
- ningún storage ni codificación cambia, y transaction_version no debe subir;
- el más pesado (veto_proposal) cobra 1,9 ms, 344 veces por debajo del máximo por extrinsic;
- los weights.rs tienen la misma estructura y el impl () coincide;
- ninguna fee, subsidio ni test depende del valor de forma que se rompa.

scripts/rp1 (operación del nodo, medido en 23 h con los valores por defecto):
- 430 MB de WAL de RocksDB retenidos para 15 MB de datos, y el RSS subiendo de 200 a 340 MB:
  --db-cache 128. Al reiniciar, 449 → 21 MB.
- El log, de 7 líneas por bloque a ~2 (txpool, sc_basic_authorship y aura en warn; ojo: las
  líneas de autoría usan el target del módulo, no «basic-authorship»), de 16 MB/día a unos 3.
- Modo append, y medir.sh lo rota al pasar de 32 MB.

Co-Authored-By: Laurha <laurha@origin>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-25 12:33:38 -05:00
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>
2026-09-09 11:06:39 -05:00
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>
2026-07-07 22:48:26 -05:00
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>
2026-07-04 14:58:29 -05:00
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>
2026-07-03 12:04:03 -05:00
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>
2026-07-03 11:58:55 -05:00
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>
2026-07-03 10:22:05 -05:00
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>
2026-06-17 07:09:50 -05:00
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>
2026-06-17 06:58:35 -05:00
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>
2026-06-10 06:06:21 -05:00