Files
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>
2026-05-30 11:33:57 -05:00

76 lines
3.4 KiB
TOML

[package]
name = "origin-chain-node"
version.workspace = true
edition.workspace = true
rust-version.workspace = true
license.workspace = true
authors.workspace = true
repository.workspace = true
homepage.workspace = true
description = "Origin Chain node binary. Phase 1.6+ Slice 4 (v0.0.49+): full sc-service builder (Aura + Grandpa consensus + JSON-RPC + libp2p networking + telemetry) + sc_service::GenericChainSpec con WASM_BINARY real. Pilar 4 settlement layer."
[[bin]]
name = "origin-chain-node"
path = "src/main.rs"
[dependencies]
# Runtime (std host-side). El feature `wasm-build` (opt-in, ver [features]) se
# propaga al runtime para poblar WASM_BINARY consumido por chain_spec.
origin-chain-runtime = { workspace = true, features = ["std"] }
# ── Substrate client (sc-service stack, stable2509-3) ──────────
sc-cli.workspace = true
sc-service.workspace = true
sc-executor.workspace = true
sc-network.workspace = true
sc-consensus.workspace = true
sc-consensus-aura.workspace = true
sc-consensus-grandpa.workspace = true
sc-transaction-pool.workspace = true
sc-transaction-pool-api.workspace = true
sc-client-api.workspace = true
sc-basic-authorship.workspace = true
sc-telemetry.workspace = true
sc-offchain.workspace = true
# ── Substrate primitives (host-side, std) ─────────────────────
sp-core = { workspace = true, features = ["std"] }
sp-runtime = { workspace = true, features = ["std"] }
sp-io = { workspace = true, features = ["std"] }
sp-timestamp = { workspace = true, features = ["std"] }
sp-consensus-aura = { workspace = true, features = ["std"] }
sp-api = { workspace = true, features = ["std"] }
sp-block-builder = { workspace = true, features = ["std"] }
sp-genesis-builder = { workspace = true, features = ["std"] }
sp-blockchain.workspace = true
# ── RPC server (jsonrpsee) ────────────────────────────────────
jsonrpsee.workspace = true
substrate-frame-rpc-system.workspace = true
pallet-transaction-payment-rpc.workspace = true
# ── CLI + async + utils ───────────────────────────────────────
clap = { workspace = true }
futures.workspace = true
serde_json.workspace = true
log.workspace = true
# ── Yanked-version unblock (Slice 4 stable2509-3 ecosystem wart) ──
# `sc-network-types 0.16.0` depende de `cid ^0.9`, y `cid 0.9.0` (única 0.9.x,
# yanked) requiere `core2 ^0.4` — y `core2 0.4.0` también está yanked (las
# no-yanked son 0.3.x, que NO satisfacen ^0.4). La resolución falla porque cargo
# no auto-selecciona versiones yanked. El pin exacto `=` SÍ permite versiones
# yanked, forzando 0.4.0 al grafo para satisfacer la dependencia transitiva de
# cid. Dep no usada en código — solo desbloquea el resolver. Era el blocker real
# que difirió sc-service en Slice 3 (documentado en chain_spec.rs).
core2 = { version = "=0.4.0", default-features = false }
[features]
default = []
# Slice 4: activa la generación del WASM_BINARY real (runtime build vía
# substrate-wasm-builder). Requiere env vars CC=LLVM (ver SLICE_2E). Sin este
# feature el node compila host-only pero `--dev` falla en runtime con mensaje
# claro (WASM_BINARY=None). Mantiene `cargo test --workspace` rápido sin env vars.
wasm-build = ["origin-chain-runtime/wasm-build"]
runtime-benchmarks = ["origin-chain-runtime/runtime-benchmarks"]