b6d05eaf45e3ec894cf5ac1c4f8c4d125e96c396
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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> |
||
|
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> |
||
 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>
|