Overview
Currently, the blockchain-cli stores the entire blockchain inside an in-memory JavaScript array ([]). While this is great for simplicity and learning, it means every single block mined or synced is completely lost the moment you close the command-line interface or restart your terminal.
This feature request proposes integrating a lightweight, file-based embedded database (such as LevelDB or SQLite) to ensure the blockchain data persists across sessions.
Detailed Requirements
-
Database Engine: Use a Node.js-compatible key-value store like
level (LevelDB) or a lightweight SQL database like sqlite3. LevelDB is particularly well-suited because blockchains are fundamentally sequential chains of key-value pairs (Block Hash $\rightarrow$ Block Data).
-
Initialization on Startup: When the CLI app starts (
npm start), it should check if a local database file exists. If it does, load the existing blockchain into memory; if not, initialize a brand new database with the Genesis block.
-
Automatic Write Operations: Every time a new block is successfully mined, validated, and added to the chain, it must be immediately committed and saved to the database.
-
Chain Validation on Load: When restarting the application, the CLI should run a quick integrity check on the loaded database blocks to ensure no local file tampering has occurred.
Technical Implementation Steps
- Install Dependencies:
-
Create a Storage Module (database.js):
Set up functions to open a database connection, save individual blocks using their index or hash as the key, and retrieve the latest block.
-
Refactor main.js / Vorpal Commands:
Replace references to the global JavaScript array (let blockchain = [...]) with asynchronous database calls (db.put and db.get).
Why This Matters
Adding persistent storage transforms this project from a temporary demonstration script into a functional prototype. It allows developers to test long-running peer-to-peer synchronization scenarios without losing data every time a node restarts.
Overview
Currently, the
blockchain-clistores the entire blockchain inside an in-memory JavaScript array ([]). While this is great for simplicity and learning, it means every single block mined or synced is completely lost the moment you close the command-line interface or restart your terminal.This feature request proposes integrating a lightweight, file-based embedded database (such as LevelDB or SQLite) to ensure the blockchain data persists across sessions.
Detailed Requirements
level(LevelDB) or a lightweight SQL database likesqlite3. LevelDB is particularly well-suited because blockchains are fundamentally sequential chains of key-value pairs (Block Hashnpm start), it should check if a local database file exists. If it does, load the existing blockchain into memory; if not, initialize a brand new database with the Genesis block.Technical Implementation Steps
Create a Storage Module (
database.js):Set up functions to open a database connection, save individual blocks using their index or hash as the key, and retrieve the latest block.
Refactor
main.js/ Vorpal Commands:Replace references to the global JavaScript array (
let blockchain = [...]) with asynchronous database calls (db.putanddb.get).Why This Matters
Adding persistent storage transforms this project from a temporary demonstration script into a functional prototype. It allows developers to test long-running peer-to-peer synchronization scenarios without losing data every time a node restarts.