Getting Started

Requisitos, instalación y primeros pasos del ecosistema RadhikaChain.

Requisitos

• Host Linux con Docker (el nodo y los servicios corren en contenedores).
• Para el nodo L1: la cadena Radhika (fork Bitcoin v30.2 "krttika" con PoK) — imágenes publicadas en Docker Hub (delideli333/radhika-chain).
• Para contratos: Foundry + solc 0.8.24.
• Para desarrollo del core: cmake ≥3.22, gcc moderno, libboost-dev, libevent-dev, libsqlite3-dev, libcapnp-dev (IPC multiproceso), libzmq3-dev.

Instalación

• Instalador oficial del proyecto para nodos peer: curl -fsSL https://radhikachain.xyz/install | bash (crea wallet, detecta hardware, abre dashboard).
• Vía Docker: imágenes del Hub; el compose de PRANA (docker-compose.prana.yml) y el stack de observabilidad están en el monorepo.
• Atención: el instalador y el sitio son la cara pública; el estado real de cada componente se documenta con estados honestos en cada página de esta wiki.

Configuración del nodo

• chain=main, txindex=1, RPC protegido, 5 bindings ZMQ (el oráculo PRANA escucha los burns por ZMQ).
• El nodo es headless (bitcoind-style). El binario expone radhika-node/bitcoind con RPC JSON.

Desarrollo local

• Monorepo de producción con: contracts/ (Foundry), prana-engine/, servicios (dharma-sensor, dharma-eye, meruprastara, radhika-unificado), workers Cloudflare (TypeScript), dharmagate-core (Rust).
• Core C++: cmake -B build -S . && cmake --build build -j2 — el árbol debe estar COMPLETO antes de configurar (una vez se extraviaron 189 archivos y el configure fallaba por doc/CMakeLists.txt ausente).

Tests

• Contratos: forge test — 8 suites (ApexFlashArbV2.t.sol, PranaEconomy.t.sol, RadhikaArc.t.sol, etc.) + fuzzing con Echidna.
• Core: karma_tests.cpp en src/test.

Errores comunes

• Clon shallow del core: GitLab rechaza pushes con "shallow update not allowed" — hacer git fetch --unshallow o re-enraizar.
• docker rm -f sobre un nodo: vacía LevelDBs y dispara -reindex persistido — siempre docker stop graceful.
• Activar karma sin las exenciones por tiempo: el binario rechaza la cadena histórica y crash-loopea (exit 139). El consenso correcto: karma activado por TIEMPO, preservando los bloques previos.
• GPT backup header de un ISO en USB a mitad del disco: sgdisk -e antes de particionar.