diff --git a/crates/origin-chain-node/src/rpc.rs b/crates/origin-chain-node/src/rpc.rs index 6280549..d39610e 100644 --- a/crates/origin-chain-node/src/rpc.rs +++ b/crates/origin-chain-node/src/rpc.rs @@ -6,7 +6,7 @@ use std::sync::Arc; use jsonrpsee::RpcModule; -use origin_chain_runtime::{opaque::Block, AccountId, Balance, Nonce}; +use origin_chain_runtime::{AccountId, Balance, Block, Nonce}; use sc_transaction_pool_api::TransactionPool; use sp_api::ProvideRuntimeApi; use sp_block_builder::BlockBuilder; diff --git a/crates/origin-chain-node/src/service.rs b/crates/origin-chain-node/src/service.rs index 2e332fb..964da9c 100644 --- a/crates/origin-chain-node/src/service.rs +++ b/crates/origin-chain-node/src/service.rs @@ -12,7 +12,11 @@ use sc_consensus_grandpa::SharedVoterState; use sc_service::{error::Error as ServiceError, Configuration, TaskManager, WarpSyncConfig}; use sc_telemetry::{Telemetry, TelemetryWorker}; use sc_transaction_pool_api::OffchainTransactionPoolFactory; -use origin_chain_runtime::{opaque::Block, RuntimeApi}; +// El runtime implementa `impl_runtime_apis!` sobre el `Block` root (con +// UncheckedExtrinsic), no sobre un opaque block separado → el node usa ese mismo +// tipo para que `RuntimeApi` matchee. (El template solochain usa `opaque::Block` +// porque su runtime expone las APIs así; el nuestro las expone sobre root Block.) +use origin_chain_runtime::{Block, RuntimeApi}; use sp_consensus_aura::sr25519::AuthorityPair as AuraPair; use std::{sync::Arc, time::Duration}; @@ -96,20 +100,17 @@ pub fn new_partial(config: &Configuration) -> Result { create_inherent_data_providers: move |parent_hash, _| { let cidp_client = cidp_client.clone(); async move { - // sc-consensus-aura 0.52: slot_duration_at vive en el root del - // crate (no en `standalone::`, que es de versiones posteriores). - let slot_duration = sc_consensus_aura::slot_duration_at( + let slot_duration = sc_consensus_aura::standalone::slot_duration_at( &*cidp_client, parent_hash, )?; let timestamp = sp_timestamp::InherentDataProvider::from_system_time(); - // crates.io sp-consensus-aura 0.45: el slot se deriva del - // timestamp vía `Slot::from_timestamp` (no existe - // `inherents::InherentDataProvider::from_timestamp_and_slot_duration`, - // que es de un snapshot git posterior con la misma versión). let slot = - sp_consensus_aura::Slot::from_timestamp(*timestamp, slot_duration); + sp_consensus_aura::inherents::InherentDataProvider::from_timestamp_and_slot_duration( + *timestamp, + slot_duration, + ); Ok((slot, timestamp)) } @@ -264,9 +265,11 @@ pub fn new_full< create_inherent_data_providers: move |_, ()| async move { let timestamp = sp_timestamp::InherentDataProvider::from_system_time(); - // Mismo patrón que el import_queue CIDP (crates.io 0.45 API). let slot = - sp_consensus_aura::Slot::from_timestamp(*timestamp, slot_duration); + sp_consensus_aura::inherents::InherentDataProvider::from_timestamp_and_slot_duration( + *timestamp, + slot_duration, + ); Ok((slot, timestamp)) }, diff --git a/docs/SLICE_4_SC_SERVICE_IMPLEMENTATION_PLAN_V1.md b/docs/SLICE_4_SC_SERVICE_IMPLEMENTATION_PLAN_V1.md index 811ce84..d05345a 100644 --- a/docs/SLICE_4_SC_SERVICE_IMPLEMENTATION_PLAN_V1.md +++ b/docs/SLICE_4_SC_SERVICE_IMPLEMENTATION_PLAN_V1.md @@ -648,4 +648,53 @@ polkadot-sdk reusa números de versión con cambios git no publicados (el mismo --- -— Charon ⚓ (Pilar 4, Slice 4 plan V1 + §10 hallazgos ejecución v0.0.48-49, sesión 4+ 2026-05-27) +--- + +## §11 — CORRECCIÓN del diagnóstico §10.2 + estado v0.0.50 (Opción C, David) + +David eligió **Opción C** (stack consistente del tag). Al ejecutarla descubrí que **mi diagnóstico §10.2 era parcialmente erróneo** — corrección honesta: + +### §11.1 — El problema NO era "API gap" — era duplicate-crate por generación sc-* incorrecta + +Las APIs SÍ existen en las crates publicadas (lo verifiqué en el source local): +- `sc-consensus-aura 0.52 standalone::slot_duration_at` → existe (standalone.rs:58) +- `sp-consensus-aura 0.45 inherents::InherentDataProvider::from_timestamp_and_slot_duration` → existe (inherents.rs:61) + +El `service.rs` verbatim del template **era correcto**; mis "fixes" de v0.0.49 (cambiar a `slot_duration_at` root + `Slot::from_timestamp`) lo rompieron. **Revertidos a verbatim en v0.0.50.** + +El problema REAL: el lock tenía **dos generaciones simultáneas** (`sp-consensus-aura 0.44.0 + 0.45.0`, `sp-timestamp 38 + 39`). Mis pins `sc-*` (0.52/0.53) eran de una generación **distinta** a mis `sp-*/frame-*` (0.45/44) → duplicate-crate → los ~50 trait-bound errors (`sp_io::*::HostFunctions not satisfied`, `P: TransactionPool not satisfied`, etc. son todos síntomas de tipos de dos copias del mismo crate). + +### §11.2 — Opción C choca con el publishing inconsistente de polkadot-sdk + +Intenté lograr Opción C **vía versiones publicadas** en crates.io (la red git falla en este entorno — core2 fetch dio Eof, así que clonar el monorepo no es viable). El intento reveló el muro real, verificado con el sparse index de crates.io: + +`sc-consensus-aura` → `sp-consensus-aura` requerido, por versión publicada: +- `0.52.0` → `^0.44.0` +- `0.53.0` → `^0.45.0` ✓ (mi generación) +- `0.53.1` → `^0.45.0` ✓ +- `0.54.0` → `^0.44.0` (¡vuelve a 0.44!) + +El número de versión **oscila** entre generaciones de sp-* en patches consecutivos. Y peor: **`sc-service 0.54.1` (la versión del tag stable2509-3) NO está publicada en crates.io** (`cargo info sc-service@0.54.1` → "could not find"). polkadot-sdk publica sus ~15 sub-crates sc-* en cadencias distintas, de modo que **no existe una isla de versiones publicadas internamente consistente** que reproduzca el tag. El tag solo es consistente vía su `Cargo.lock` commiteado en el monorepo git. + +Conclusión dura (corrige §10.2): el problema NO es "API gap" (las APIs existen) ni "elegir bien las versiones publicadas" (no hay set consistente). El problema es **estructural del ecosistema**: un node service real requiere el `Cargo.lock` del monorepo git, que necesita un entorno con red git funcional. + +### §11.3 — Lo que SÍ quedó firme + lo correcto preservado + +- **WASM_BINARY export (Paso 4a)** — ✅ shipped v0.0.48, verde. +- **core2 yanked unblock** — ✅ shipped v0.0.49 (vendor path patch), verde. +- **service.rs + rpc.rs** — corregidos a la forma correcta y preservados como archivos (mods off): + - `Block` root (no `opaque::Block`) — el runtime expone `impl_runtime_apis!` sobre el Block root. + - CIDP verbatim del template (`standalone::slot_duration_at` + `inherents::InherentDataProvider::from_timestamp_and_slot_duration`) — ambos SÍ existen en sp-consensus-aura 0.45.0 publicado (verificado en source: inherents.rs:61). Mi "fix" de v0.0.49 (`Slot::from_timestamp`) era incorrecto; revertido a verbatim. +- Workspace Cargo.toml — en el estado verde de v0.0.49 (sc-* sin tocar; node compila con mods off). + +### §11.4 — Decisión real para David (recomendación senior) + +El node service real es construible, pero **requiere un entorno con red git** para usar los git sources del tag (con su Cargo.lock consistente). Eso es exactamente el entorno que Phase 4 testnet necesita de todos modos (CI/CD + build de validadores Pi 5). Por lo tanto: + +**Recomendación**: diferir el node service real al setup de infraestructura de Phase 4 testnet, donde montamos un build env con red git + `cargo build` desde el monorepo pinned. NO seguir adivinando versiones publicadas una por una (no convergen). Mientras tanto el node sigue siendo CLI + chain_spec builder funcional, y todo lo demás de Slice 4 (WASM export + core2 unblock + service.rs/rpc.rs correctos) queda firme para wire-in inmediato cuando el env esté listo. + +Alternativa si quieres node YA: dame un entorno con `git fetch` habilitado (o un Cargo.lock del monorepo stable2509-3 que yo consuma), y wire-in es ~1 sesión. + +--- + +— Charon ⚓ (Pilar 4, Slice 4 plan V1 + §10 + §11 corrección honesta Opción C, sesión 4+ 2026-05-27. WASM export + core2 unblock firmes; node real diferido a env con red git por publishing inconsistente del ecosistema.)