Run a node

Run your own SciChain node for independent verification of the chain, a private high-throughput RPC endpoint, or to participate in consensus as a validator. A node is a single Java 21 process built on the Hyperledger Besu 25.x lineage, extended with post-quantum (ML-DSA / FIPS 204) signature support so it validates classical and quantum-safe transactions alike.

Requirements

SciChain nodes run comfortably on modest hardware. The one hard requirement is a Java 21 runtime.

Node types

Every node runs the same binary — the role is a matter of configuration and consensus membership.

• Full node — downloads and independently validates every block (including verifying ML-DSA signatures on post-quantum transactions), maintains state, and can serve JSON-RPC. This is the default.
• Validator node — a full node that additionally holds a validator key and sits in the active QBFT validator set, taking turns proposing and sealing blocks. A validator must be voted in by the existing validators; see Consensus (QBFT) for the mechanics.

Install & verify Java 21

Confirm you have a compatible runtime:

java -version
# openjdk version "21.0.x" ...  — anything 21+ is fine

If Java 21 is not installed, use your platform package manager:

# Debian / Ubuntu
sudo apt-get install -y openjdk-21-jdk

# macOS (Homebrew)
brew install openjdk@21

Directory layout & genesis

A node needs the SciChain genesis.json, which pins the network's identity: chainId 481, the QBFT consensus parameters, the Shanghai fork activation, the initial validator set, and the genesis account allocations. The canonical genesis file is distributed with the network — the skeleton below is representative and shows the fields that matter.

A minimal node directory looks like this:

/opt/scichain/
├── config.toml        # node configuration
├── genesis.json       # SciChain genesis (chainId 481)
└── data/              # chain data, keys, state

Representative genesis.json skeleton:

{
  "config": {
    "chainId": 481,
    "shanghaiTime": 0,
    "qbft": {
      "blockperiodseconds": 5,
      "epochlength": 30000,
      "requesttimeoutseconds": 10
    }
  },
  "gasLimit": "0x1c9c380",
  "difficulty": "0x1",
  // extraData RLP-encodes the initial QBFT validator set — PLACEHOLDER
  "extraData": "0x<RLP-ENCODED-INITIAL-VALIDATORS>",
  // genesis account balances — PLACEHOLDER
  "alloc": {
    "0x<ADDRESS>": { "balance": "0x<WEI>" }
  }
}

Configuration

Put node settings in config.toml. Enable only the RPC namespaces you need, and replace the placeholder bootnode with a real SciChain enode.

# /opt/scichain/config.toml
data-path="/opt/scichain/data"
genesis-file="/opt/scichain/genesis.json"

# peer-to-peer
p2p-port=30303
bootnodes=["enode://<PLACEHOLDER-NODE-ID>@<HOST>:30303"]  # replace with a real SciChain bootnode

# JSON-RPC
rpc-http-enabled=true
rpc-http-host="127.0.0.1"
rpc-http-port=8545
rpc-http-api=["ETH","NET","WEB3","QBFT","ADMIN"]
host-allowlist=["localhost","127.0.0.1"]

Start the node

The client is the Besu-lineage scichain binary. Set the JVM heap before launching — 4 GB is a sound default for a validator or a busy RPC node; smaller heaps risk long GC pauses that can make a validator miss its slot.

export JAVA_OPTS="-Xmx4g"
scichain --config-file=/opt/scichain/config.toml

On first start the node discovers peers via the configured bootnodes and begins importing and validating blocks from genesis forward.

Run as a systemd service

For production, run the node under systemd so it restarts on failure and starts at boot. Create a dedicated scichain user first, then add the unit:

# /etc/systemd/system/scichain.service
[Unit]
Description=SciChain node
After=network-online.target
Wants=network-online.target

[Service]
User=scichain
Environment="JAVA_OPTS=-Xmx4g"
ExecStart=/usr/local/bin/scichain --config-file=/opt/scichain/config.toml
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Enable and start it:

sudo systemctl daemon-reload
sudo systemctl enable --now scichain
sudo systemctl status scichain

Verify your node is synced

Ask the node whether it is still catching up. eth_syncing returns false once fully synced:

curl http://localhost:8545 \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'

# synced => {"jsonrpc":"2.0","id":1,"result":false}

Then compare your local height against the public explorer at explorer.scimatic.net:

curl http://localhost:8545 \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Confirm you can see the validator set through the QBFT namespace:

curl http://localhost:8545 \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"qbft_getValidatorsByBlockNumber","params":["latest"],"id":1}'

Becoming a validator

A synced full node can be promoted into the active QBFT validator set. Validator membership is governed on-chain: existing validators cast votes, and a candidate is added (or removed) once it has more than 50% of the current validators voting in favor. Each validator submits its vote with qbft_proposeValidatorVote.

See Consensus (QBFT) for the full voting workflow, block time and finality guarantees, and validator key management.