davidherranandClaude Opus 4.8
a15a65966f
SUPER_AUDIT_V3_FINAL — 4 dimensiones finales (workflow ultracode): 3 CRITICOS nuevos: - V3-C1 replay cross-chain de atestaciones (sin domain-sep/chain-id/nonce en signing payload; firma de testnet/fork verifica identico). - V3-C2 firma de credencial almacenada pero NUNCA verificada (decorativa; verify() devuelve true con blob basura). - V3-C3 constitucion (Inmutables #16/#37/#18/#35) vive en pallet sin-cablear, NO en el fee-path vivo; #35 Children Safety es estado muerto. 4 HIGH: DID front-running, derive_did domain-sep debil, storage limit 937MB/contrato, weights ficticios en ARM. Tests: los 213 dan falsa seguridad — los 4 reentrancy + credential-sig + governance sin testear; 1 test vacio; lobo-blanco guarda lo equivocado. Provenance+agent-identity SI conductuales (credito). Perf Pi5: storage LIMPIO (contadores cacheados); riesgo = weights + storage limit. AUTO-CORRECCION honesta (red-team cazo): V2-CA4 citaba archivo inexistente (arkhe-noesis-core/attestation.rs no existe en repo). La forma del riesgo es real pero NO se construye fix contra spec fabricada — requiere DC con Ergon primero. REMEDIATION_ROADMAP_V1 — 12 criticos + ~20 highs convertidos en 6 fix groups ejecutables, ordenados por dependencia, red-team-verificados: FIX-1 contract-safety (CEI reorder, ship limpio) -> FIX-2 lifecycle (StorageVersion +key recovery+weights) -> FIX-3 crypto (domain-sep+DID binding) -> FIX-5 governability (sudo->governance) -> FIX-6 economic model real (emision+validator pay+fee unificado+subsidio financiado) -> [DC Ergon] -> FIX-4 credential verify. FIX-DEFERRED: CA4 NO se construye sin DC Ergon (red-team reject). Pregunta abierta a David: suscripcion premium debe reducir subsidio hardware anti-clasista, o son ortogonales? (codigo actual los acopla = viola Inmutable #16; mi reco: ortogonales). Trilogia completa: 12 dimensiones, 12 criticos, ~20 highs, todos con fix conocido. Cimientos grado-Parity; plomeria dinamica incompleta; auditado lo bastante hondo para saber exactamente que falta. Para plataforma de 100 anos, el rigor correcto. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
116 lines
8.5 KiB
Markdown
116 lines
8.5 KiB
Markdown
# Origin Chain — Remediation Roadmap V1 (plan ejecutable de fixes)
|
|
|
|
**Documento**: `docs/REMEDIATION_ROADMAP_V1.md`
|
|
**Versión**: 1.0
|
|
**Filed**: 2026-05-27 (sesión 4+ Charon, Opus 4.8)
|
|
**Fuente**: consolida los 12 críticos + ~20 highs de la trilogía de audits (V1+V2+V3), convertidos en planes de fix ejecutables y verificados adversarialmente (el red-team filtró 1 fix peligroso).
|
|
**Propósito**: que David tenga UN plan ordenado — qué se arregla, en qué orden, con qué esfuerzo, sin introducir regresiones. Esto es el camino de "pre-testnet con plomería incompleta" a "extremadamente bien, sin bugs".
|
|
|
|
---
|
|
|
|
## §0 — Cómo leer este roadmap
|
|
|
|
Los fixes están agrupados por causa-raíz (no por bug individual — muchos bugs comparten raíz) y ordenados por **dependencia**. El red-team de V3 verificó cada plan; sus correcciones están integradas (marcadas ⚠️). Un fix que el red-team rechazó NO está aquí como ejecutable — está como "requiere paso previo".
|
|
|
|
Esfuerzo: S (horas) · M (1-2 días) · L (varios días / requiere coordinación).
|
|
|
|
**Regla de oro greenfield**: la cadena es pre-testnet, sin estado real. Los fixes pueden cambiar storage libremente AHORA (sin carga de migración) — esta ventana se cierra cuando lance testnet. Por eso conviene arreglar antes de testnet.
|
|
|
|
---
|
|
|
|
## §1 — SECUENCIA DE FIXES (orden de ejecución)
|
|
|
|
### FIX-1 — Contract safety (reentrancy + burn real + escrow) — **el más limpio, primero**
|
|
**Bugs**: V1-C1 (reentrancy x4), V1-C4 (zero-burn), V1-H7 (escrow milestone sum).
|
|
**Red-team**: ✅ "Ship — diagnóstico exacto, fix bien-ordenado." El único con luz verde sin precondiciones.
|
|
**Fix**: reordenar a Checks-Effects-Interactions en escrow `confirm_milestone`/`resolve_dispute`, staking `withdraw`/`slash`, nft `transfer` — mutar TODO el storage ANTES de cualquier `transfer()`. Plantilla: `origin-credential-mint::issue` ya lo hace bien.
|
|
**Burn real**: reemplazar `transfer([0u8;32])` por reducir-lo-que-se-cobra (no pagar el burn) — y usar el MISMO primitivo de burn que use el fee/treasury (⚠️ red-team: evitar dos semánticas de burn).
|
|
**Escrow**: enforce `Σ milestone.amount == total_amount` + path de sweep terminal.
|
|
**Tests obligatorios**: reentrancy/double-spend en escrow+staking (los que V3 marcó ausentes).
|
|
**Esfuerzo**: M. **Riesgo de regresión**: bajo (CEI es un patrón estándar).
|
|
|
|
### FIX-2 — Lifecycle hardening (StorageVersion + AGI key recovery + weights)
|
|
**Bugs**: V1-H2/V2-CA2 (no StorageVersion/migrations), V2-H1 (AGI key irrecuperable), V1-H1/V3-H4 (placeholder weights).
|
|
**Red-team**: ✅ "Ship hardening; gate AGI key-recovery en el modelo de autoridad #41."
|
|
**Fix**: `StorageVersion::new(0)` en los 4 pallets (S, trivial). AGI key: añadir `rotate_key`/`revoke`/campo `active` a agent-identity, con recovery vía autoridad #41 (multisig humano del agent_chain). Weights: `frame-benchmarking` + `WeightInfo` por pallet (L — pero crítico para Pi 5 anti-spam).
|
|
**Esfuerzo**: S (StorageVersion) + M (key recovery) + L (benchmarking).
|
|
|
|
### FIX-3 — Crypto hardening (domain separation + replay guard + DID binding)
|
|
**Bugs**: V3-C1 (replay cross-chain), V3-H1 (DID front-running), V3-H2 (derive_did domain sep).
|
|
**Red-team**: implícito ✅ (primitivos sólidos, gaps arquitecturales).
|
|
**Fix**: (a) prefijar el signing payload de atestación con `b"origin-chain/attestation/v1" || genesis_hash`; (b) `register_agent_did` requiere firma por `public_key` sobre `who`; (c) `derive_did` usa `blake3::derive_key("origin-chain did v1", pk)`.
|
|
**Esfuerzo**: M. **Riesgo**: bajo, pero cambia el formato de firma → hacerlo ANTES de cualquier anclaje en testnet.
|
|
|
|
### FIX-4 — Credential signature verify (V3-C2 / V1-H8)
|
|
**Bugs**: la firma de credencial nunca se verifica.
|
|
**Red-team**: ⚠️ "gate en el payload real de Ergon (DC), no contra una spec fabricada."
|
|
**Fix**: verificar `issuer_signature` vía `sp_io::crypto::ed25519_verify` sobre un payload que NO incluya campos seteados on-chain (issued_at/expires_at deben venir del caller o salir del payload firmado). Requiere fijar el payload de credencial primero.
|
|
**Esfuerzo**: M. **Precondición**: definir el signing payload canónico de credencial.
|
|
|
|
### FIX-5 — Governability (Root origin + sudo→governance) — **desbloquea todo lo demás**
|
|
**Bugs**: V2-CA1 (no Root origin, cadena no-gobernable).
|
|
**Red-team**: ⚠️ "Ship después de: bound `Config: Currency` + wiring de runtime + mostrar el sudo-sunset."
|
|
**Fix**: wire `pallet-sudo` para testnet (da Root origin → las 7 dispatchables admin funcionan). Plan de sunset: migrar de sudo a governance real (pallet-collective/referenda) antes de mainnet. ⚠️ Coordinar con FIX-6 quién cablea el SessionManager (no que dos planes lo medio-cableen).
|
|
**Esfuerzo**: S (sudo) + L (governance real + sunset).
|
|
|
|
### FIX-6 — Economic model real (emisión + validator pay + fee unificado + subsidio financiado)
|
|
**Bugs**: V2-CA2 (no inflation/validators unpaid), V2-CA3 (dual compute_fee, subscription erosiona anti-clasista), V2-H3 (subsidio sin financiar), V1/V2 fake APR, V3-C3 (constitución no en fee-path vivo).
|
|
**Red-team**: ⚠️ "Ship después de: separar fee-routing de NPoS; confirmar con David la intención del sub_mult." (la pregunta: ¿debe la suscripción premium reducir el subsidio de hardware, o son ortogonales? V2 dice que erosiona el anti-clasista → probablemente deben ser ortogonales).
|
|
**Fix**: (a) wire `pallet_staking` + `EraPayout` para emisión real → validadores cobran (cierra CA2); (b) UNA sola `compute_fee` + `OnChargeTransaction` custom que la consuma → la constitución entra al fee-path vivo (cierra CA3+V3-C3); (c) `GlobalSubsidyPool` financiado (= proof-of-equity, V1 idea 1); (d) remover los números APR de staking hasta que exista motor real.
|
|
**Esfuerzo**: L (el cuerpo grande — es "Phase economía real").
|
|
|
|
### FIX-DEFERRED — Cross-pillar attestation payload (V2-CA4)
|
|
**Estado**: 🔴 **NO construir como fix de código.** El red-team probó que mi V2-CA4 citaba un archivo inexistente.
|
|
**Acción correcta**: abrir Design Contract con Ergon para ratificar el formato canónico del signing payload de atestación (SCALE vs postcard, campos, orden) ANTES de lockear cualquier verificador on-chain. Solo después FIX-4 (credential) y el verifier de provenance se construyen contra una spec real.
|
|
**Esfuerzo**: coordinación cross-pillar (no código de Charon solo).
|
|
|
|
---
|
|
|
|
## §2 — Orden recomendado + por qué
|
|
|
|
```
|
|
FIX-1 (contract safety) ← primero, limpio, sin precondiciones, alto impacto
|
|
↓
|
|
FIX-2 (lifecycle hardening) ← StorageVersion trivial + key recovery + weights
|
|
↓
|
|
FIX-3 (crypto hardening) ← antes de cualquier anclaje testnet
|
|
↓
|
|
FIX-5 (governability/sudo) ← desbloquea admin + treasury
|
|
↓
|
|
FIX-6 (economic model) ← el cuerpo grande, pre-testnet-con-valor
|
|
↓
|
|
[DC Ergon attestation payload] → FIX-4 (credential verify)
|
|
```
|
|
|
|
FIX-1/2/3 son construibles AHORA (no dependen del node ni de VPS). FIX-5/6 idealmente con el node real (VPS). FIX-4 espera el DC con Ergon.
|
|
|
|
---
|
|
|
|
## §3 — Lo que el red-team rechazó o corrigió (transparencia)
|
|
|
|
| Fix | Veredicto red-team | Acción |
|
|
|-----|-------------------|--------|
|
|
| contract-safety | ✅ Ship | FIX-1 |
|
|
| lifecycle-ops | ✅ Ship hardening | FIX-2 |
|
|
| governance-root | ⚠️ Config-bound + sudo-sunset faltaban | FIX-5 con esas adiciones |
|
|
| economic-model | ⚠️ anti-clasista invertido + NPoS muy grueso | FIX-6 con fee-routing separado de NPoS + pregunta a David |
|
|
| crosspillar-encoding CA4 | 🔴 **REJECT — citaba archivo inexistente** | FIX-DEFERRED (DC con Ergon primero) |
|
|
|
|
**Una pregunta abierta para David** (FIX-6): ¿la suscripción premium (Pro/Ultra) debe *reducir* el subsidio de hardware anti-clasista, o son dimensiones ortogonales? El código actual las acopla (un Pi 5 + Ultra-sub paga distinto que un Pi 5 + Free), lo que el V2 marcó como violación del Inmutable #16. Mi recomendación: **ortogonales** — el subsidio de hardware protege al pobre sin importar qué suscripción tenga. Pero es tu llamada constitucional.
|
|
|
|
---
|
|
|
|
## §4 — KG triples
|
|
|
|
- `(remediation_roadmap_v1, authored_by, agent:charon)`
|
|
- `(remediation_roadmap_v1, consolidates, super_audit_v1_v2_v3)`
|
|
- `(remediation_roadmap_v1, fix_groups, 6)`
|
|
- `(remediation_roadmap_v1, first_fix, contract_safety_cei)`
|
|
- `(remediation_roadmap_v1, deferred_fix, ca4_needs_ergon_dc)`
|
|
- `(remediation_roadmap_v1, open_question, subscription_vs_hardware_subsidy_orthogonality)`
|
|
- `(remediation_roadmap_v1, filed_at, 2026-05-27)`
|
|
|
|
---
|
|
|
|
— Charon ⚓ (Pilar 4 Origin Chain, Remediation Roadmap V1, sesión 4+ 2026-05-27)
|