Forem: smith@mcf.rocks

Dusk - Tiny Net with Staking

smith@mcf.rocks — Thu, 15 Feb 2024 18:31:18 +0000

I will make a network with one genesis staked provisioner, then add a second staked provisioner later.

We will use TWO machines, both Ubuntu 22.04 installed.

M1 - Digital Ocean Basic/Regular 4GB/2CPU - Frankfurt - 142.XX.XX.240
M2 - Digital Ocean Basic/Regular 4GB/2CPU - London - 167.XX.XX.102

// NB: I could not build Dusk with less than 4GB

I will setup M1 first...

Build Prerequisites

# update packages
apt update 
apt upgrade  -y 

# packages we need
apt install make pkg-config libssl-dev npm unzip libclang-dev build-essential -y

# rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh  # select opt 1
source "$HOME/.cargo/env"
rustup toolchain install nightly
rustup default nightly

# rust extras
cargo install wasm-pack

# nvm and node
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
exit
# and login again :-)
nvm list-remote
nvm install v20.11.0

Build Dusk - Everything

git clone https://github.com/dusk-network/rusk.git
cd rusk
make

# check it built
./target/release/rusk -V

Setup

# Consensus keys (wallet generated) for node:
mkdir -p ~/.dusk/rusk
cp examples/consensus.keys ~/.dusk/rusk/consensus.keys

# the example genesis.toml starts a staked provisioner
# note the two addresses...
cat examples/genesis.toml

# edit the file as follows -- give wallet 300k:
[[balance]]
address = '4ZH3oyfTuMHyWD1Rp4e7QKp5yK6wLrWvxHneufAiYBAjvereFvfjtDvTbBcZN5ZCsaoMo49s1LKPTwGpowik6QJG'
seed = 0xdead_beef
notes = [300_000_000_000_000]

[[stake]]
address = 'oCqYsUMRqpRn2kSabH52Gt6FQCwH5JXj5MtRdYVtjMSJ73AFvdbPf98p3gz98fQwNy9ZBiDem6m9BivzURKFSKLYWP3N9JahSPZs9PnZ996P18rTGAjQTNFsxtbrKx79yWu'
amount = 1_000_000_000_000

Launch M1 node

# Generate genesis state
cargo r --release -p rusk -- recovery-state --init examples/genesis.toml -o /tmp/example.state

# Launch node
cargo r --release -p rusk -- -s /tmp/example.state --http-listen-addr 0.0.0.0:4321 --kadcast-public-address 167.99.241.102:9000

Make Wallet

git clone https://github.com/dusk-network/wallet-cli.git
cd wallet-cli/
make build
./target/release/rusk-wallet -V

# the wallet makes / looks for a wallet.dat file in this location
# /root/.dusk/rusk-wallet/wallet.dat
# the genesis addresses are from the .dat file in the examples directory of the repo
# copy it in-place
cp ~/rusk/examples/wallet.dat /root/.dusk/rusk-wallet/

# if there is a cache in /root/.dusk/rusk-wallet/ (from some previous wallet) delete it
# run the wallet
./target/release/rusk-wallet --state http://127.0.0.1:4321 --prover http://127.0.0.1:4321

# nb: password of the example.dat is "password"

You will see the 4ZH3oy... address from the genesis toml, it should have 300k Dusk on it.

If you "Check existing stake" there should be 1000 Dusk on staking address oCqYsUM...

With this node still running, we will join a second node to the network....

on M2:

1) repeat all the build steps for rusk and wallet from M1
2) edit the genesis.toml file to be the same
3) do NOT copy example.dat file, this is new wallet

Run Wallet

cd wallet-cli
./target/release/rusk-wallet --state http://127.0.0.1:4321 --prover http://127.0.0.1:4321

create a new wallet, or recover to get same addresses;
my 12 words were: tag tide chef like history submit field minor hub ridge prepare pause
password: "password"

Export provisioner keys > will write consensus.keys to /root/.dusk/rusk-wallet
Exit Wallet

Setup M2 node

cd rusk
mkdir -p ~/.dusk/rusk

# previously we used the consensus.keys from example directory, which corresponded to the example wallet, but here we use the consensus keys for this wallet

cp /root/.dusk/rusk-wallet/*.keys ~/.dusk/rusk/

# I renamed the file to con.keys to make it simpler

Run M2 node

# run the node, specifying the first node as bootstrap node
# note that it is the Kadcast port (9000) that must be referenced
# nb: port needs to be open, check using telnet

./target/release/rusk -s /tmp/example.state --http-listen-addr 0.0.0.0:4321 --kadcast-bootstrap "<M2-IP>:9000" --consensus-keys-path="$HOME/.dusk/rusk/<filename.keys>" --kadcast-public-address <THIS-IP>:9000

eg:

export DUSK_CONSENSUS_KEYS_PASS=password
./target/release/rusk -s /tmp/example.state --http-listen-addr 0.0.0.0:4321 --kadcast-bootstrap "167.XX.XX.102:9000" --consensus-keys-path="/$HOME/.dusk/rusk/con.keys" --kadcast-public-address 142.XX.XX.240:9000

# note: Kadcast uses UDP, you can check the port is listening with netstat -ulpn

In a new session start the M2 wallet and fund from M1:

cd wallet-cli
./target/release/rusk-wallet --state http://127.0.0.1:4321 --prover http://127.0.0.1:4321

# address1 is 4oPWfmo... with a balance of zero.

# on the M1 wallet, transfer 200k to this address1 

after a short while (if node and wallet is fully synced) M2 - 4oPWfmo... should have 200k balance.

At this point both nodes are on the same network, with the respective wallets connected to their nodes. We will now stake M2 node.

If you observe the logs of both running nodes, you will see that M1 node has "Proposal" in the log output, whereas the M2 node does not, immediately after "Proposal" you will see pk="oCqYsUMR..." which is the public staking key from the wallet. M2 node does not propose blocks, as it is not yet staked.

From the M2 wallet stake 100k.

After doing that, in the wallet do "Check existing stake", this will tell you that the stake becomes eligible from some future block number and epoch. Stake becomes active at the next epoch boundary. You will see the current block height of the node in the log output, so you will know how long you have to wait.

Once the block height is reached, you will see "Proposal" messages in the M2 node log, as the node is now making blocks. Indeed, as the staked amount on the M2 node is 100k and the staked amount on the M1 node is 1k, almost ALL blocks are made on the M2 node.

If you "Check existing stake" in the wallet, you will see the stake is now active and rewards are accumulating.

Until next time.

Dusk - Tiny Net with Staking.

smith@mcf.rocks — Thu, 15 Feb 2024 18:30:23 +0000

I will make a network with one genesis staked provisioner, then add a second staked provisioner later.

We will use TWO machines, both Ubuntu 22.04 installed.

M1 - Digital Ocean Basic/Regular 4GB/2CPU - Frankfurt - 142.XX.XX.240
M2 - Digital Ocean Basic/Regular 4GB/2CPU - London - 167.XX.XX.102

NB: I could not build Dusk with less than 4GB

I will setup M1 first...

Build Prerequisites

# update packages
apt update 
apt upgrade  -y 

# packages we need
apt install make pkg-config libssl-dev npm unzip libclang-dev build-essential -y

# rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh  # select opt 1
source "$HOME/.cargo/env"
rustup toolchain install nightly
rustup default nightly

# rust extras
cargo install wasm-pack

# nvm and node
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash
exit
# and login again :-)
nvm list-remote
nvm install v20.11.0

Build Dusk - Everything

git clone https://github.com/dusk-network/rusk.git
cd rusk
make

# check it built
./target/release/rusk -V

Setup

# Consensus keys (wallet generated) for node:
mkdir -p ~/.dusk/rusk
cp examples/consensus.keys ~/.dusk/rusk/consensus.keys

# the example genesis.toml starts a staked provisioner
# note the two addresses...
cat examples/genesis.toml

# edit the file as follows -- give wallet 300k:
[[balance]]
address = '4ZH3oyfTuMHyWD1Rp4e7QKp5yK6wLrWvxHneufAiYBAjvereFvfjtDvTbBcZN5ZCsaoMo49s1LKPTwGpowik6QJG'
seed = 0xdead_beef
notes = [300_000_000_000_000]

[[stake]]
address = 'oCqYsUMRqpRn2kSabH52Gt6FQCwH5JXj5MtRdYVtjMSJ73AFvdbPf98p3gz98fQwNy9ZBiDem6m9BivzURKFSKLYWP3N9JahSPZs9PnZ996P18rTGAjQTNFsxtbrKx79yWu'
amount = 1_000_000_000_000

Launch M1 node

# Generate genesis state
cargo r --release -p rusk -- recovery-state --init examples/genesis.toml -o /tmp/example.state

# Launch node
cargo r --release -p rusk -- -s /tmp/example.state --http-listen-addr 0.0.0.0:4321 --kadcast-public-address 167.99.241.102:9000

Make Wallet

git clone https://github.com/dusk-network/wallet-cli.git
cd wallet-cli/
make build
./target/release/rusk-wallet -V

# the wallet makes / looks for a wallet.dat file in this location
# /root/.dusk/rusk-wallet/wallet.dat
# the genesis addresses are from the .dat file in the examples directory of the repo
# copy it in-place
cp ~/rusk/examples/wallet.dat /root/.dusk/rusk-wallet/

# if there is a cache in /root/.dusk/rusk-wallet/ (from some previous wallet) delete it
# run the wallet
./target/release/rusk-wallet --state http://127.0.0.1:4321 --prover http://127.0.0.1:4321

# nb: password of the example.dat is "password"

You will see the 4ZH3oy... address from the genesis toml, it should have 300k Dusk on it
If you "Check existing stake" there should be 1000 Dusk on staking address oCqYsUM...

With this node still running, we will join a second node to the network....

on M2:

1) repeat all the build steps for rusk and wallet from M1
2) edit the genesis.toml file to be the same
3) do NOT copy example.dat file, this is new wallet

*Run Wallet

cd wallet-cli
./target/release/rusk-wallet --state http://127.0.0.1:4321 --prover http://127.0.0.1:4321

create a new wallet, or recover to get same addresses;
my 12 words were: tag tide chef like history submit field minor hub ridge prepare pause
password: "password"

Export provisioner keys > will write consensus.keys to /root/.dusk/rusk-wallet
Exit Wallet

Setup M2 node

cd rusk
mkdir -p ~/.dusk/rusk

# previously we used the consensus.keys from example directory, which corresponded to the example wallet, but here we use the consensus keys for this wallet

cp /root/.dusk/rusk-wallet/*.keys ~/.dusk/rusk/

# I renamed the file to con.keys to make it simpler

Run M2 node

# run the node, specifying the first node as bootstrap node
# note that it is the Kadcast port (9000) that must be referenced
# nb: port needs to be open, check using telnet

./target/release/rusk -s /tmp/example.state --http-listen-addr 0.0.0.0:4321 --kadcast-bootstrap "<M2-IP>:9000" --consensus-keys-path="$HOME/.dusk/rusk/<filename.keys>" --kadcast-public-address <THIS-IP>:9000

eg:

export DUSK_CONSENSUS_KEYS_PASS=password
./target/release/rusk -s /tmp/example.state --http-listen-addr 0.0.0.0:4321 --kadcast-bootstrap "167.XX.XX.102:9000" --consensus-keys-path="/$HOME/.dusk/rusk/con.keys" --kadcast-public-address 142.XX.XX.240:9000

# note: Kadcast uses UDP, you can check the port is listening with netstat -ulpn

In a new session start the M2 wallet and fund from M1:

cd wallet-cli
./target/release/rusk-wallet --state http://127.0.0.1:4321 --prover http://127.0.0.1:4321

# address1 is 4oPWfmo... with a balance of zero.

# on the M1 wallet, transfer 200k to this address1 

after a short while (if node and wallet is fully synced) M2 - 4oPWfmo... should have 200k balance.

At this point both nodes are on the same network, with the respective wallets connected to their nodes. We will now stake M2 node.

From the M2 wallet stake 100k.

If you "Check existing stake" in the wallet, you will see the stake is now active and rewards are accumulating.

Until next time.

Dusk - Standalone Prover

smith@mcf.rocks — Mon, 01 Jan 2024 18:23:40 +0000

Dusk uses ZKPs (Zero-Knowledge-Proofs) to maintain transaction privacy; for example, when doing a simple transfer, a proof must be constructed by the wallet demonstrating the notes involved belong to that wallet and are nullified, later the proof is verified on-chain by the consensus nodes.

So there are two parts 1) proof creation 2) proof verification. Each contract (in this example, the genesis Transfer contract) contains both prover and verification circuits. Verification is fast with constant time. Proof creation can take longer depending on how many notes are involved, in some cases on slower hardware it can be really quite lengthy (>20s) leading to poor UX in the wallet.

Fortunately, proof creation is trustless and can therefore be done by a third party. Dusk allows a node to run in "Prover" mode, where it only does proof creation.

Right now the web-wallet is hard coded to use Dusk Foundation provers. In the wallet-core code, an UnprovenTransaction structure is converted and sent as bytes to a prover in ./src/compat/tx.rs unproven_tx_to_bytes(), the prover returns the proof, which is checked in prove_tx() -- however, right now, the web-wallet code is in a private repo, so we can't mess with that.

On the other hand, the CLI Wallet allows specification of two endpoints, one for state and one for prover. In our previous tutorials, both point at the local node, like this:

# ./wallet-cli/target/release/rusk-wallet \
  --state http://127.0.0.1:4321 \
  --prover http://127.0.0.1:4321

However they can be different... We will use the same setup as before with a local node and wallet.

On another server, we will make a Prover node, listening on 4322:

# git clone https://github.com/dusk-network/rusk.git
# cd rusk
# make
# ./target/release/rusk -V
rusk 0.7.0 (16cd2d58 2023-12-31)
# cp examples/consensus.keys ~/.dusk/rusk/consensus.keys
# export DUSK_CONSENSUS_KEYS_PASS=password
# ./target/release/rusk --http-listen-addr 0.0.0.0:4322

NB: remember to allow the machine with the state node and wallet access to port 4322 on this machine.

Run the CLI wallet referencing the prover on the other machine:

# ./wallet-cli/target/release/rusk-wallet \
  --state http://127.0.0.1:4321 \
  --prover http://<myOtherServerIP>:4322

Do a transfer from the wallet:

Send 50 Dusk to 3uVEjrfzdhjN1a5o48SpiVU9AFzF5o9FZ9mFR9GfeV7U3nfDpDGfVrLJveFPokHsQiXUjjrQHYZSWNz4PY2UQ4xU

Observe the log output of our Prover node, you will see:

2024-01-01T15:50:18.664338Z  INFO rusk::http: Received Host("rusk"):prove_execute request

The proof creation has taken place on the Prover node, not the local state node.

The action takes place in ./rusk-prover/src/prover/execute.rs

If you look, you will notice there are 4 different proving circuits:

pub static EXEC_1_2_PROVER: Lazy<PlonkProver> =
    Lazy::new(|| fetch_prover("ExecuteCircuitOneTwo"));

pub static EXEC_2_2_PROVER: Lazy<PlonkProver> =
    Lazy::new(|| fetch_prover("ExecuteCircuitTwoTwo"));

pub static EXEC_3_2_PROVER: Lazy<PlonkProver> =
    Lazy::new(|| fetch_prover("ExecuteCircuitThreeTwo"));

pub static EXEC_4_2_PROVER: Lazy<PlonkProver> =
    Lazy::new(|| fetch_prover("ExecuteCircuitFourTwo"));

and

        match utx.inputs().len() {
            1 => local_prove_exec_1_2(&utx, rng),
            2 => local_prove_exec_2_2(&utx, rng),
            3 => local_prove_exec_3_2(&utx, rng),
            4 => local_prove_exec_4_2(&utx, rng),
            _ => Err

The circuit used depends on the number of inputs (notes from the user's wallet); the output is always 2 notes (a new note owned by someone else & the change). The maximum number of notes that can be used is 4, I have no idea what happens if the wallet needs to use more than 4 input notes.

The log output from the node does not really tell us much. I want to know a) which circuit was used, and b) how long the operation took. Let's make some code changes to add this to the log.

In ./rusk/src/lib/http/prover.rs handle() function I amend as follows:

        // smith 
        let utx = UnprovenTransaction::from_slice(request.event_data()).unwrap();
        info!("LocalProver Start inputs:{:?}",utx.inputs().len());

        let response = match topic {
            "prove_execute" => self.prove_execute(request.event_data())?,
            "prove_stct" => self.prove_stct(request.event_data())?,
            "prove_stco" => self.prove_stco(request.event_data())?,
            "prove_wfct" => self.prove_wfct(request.event_data())?,
            "prove_wfco" => self.prove_wfco(request.event_data())?,
            _ => anyhow::bail!("Unsupported"),
        };

        info!("LocalProver End");  // smith

Then recompile and run the modified node:

# make
# ./target/release/rusk \
  --http-listen-addr 0.0.0.0:4322 \
  | grep rusk::http::prover

In the wallet:

Send 1 Dusk to 3uVEjrfzdhjN1a5o48SpiVU9AFzF5o9FZ9mFR9GfeV7U3nfDpDGfVrLJveFPokHsQiXUjjrQHYZSWNz4PY2UQ4xU

For me, the log reported the following:

2024-01-01T17:26:24.444775Z  INFO rusk::http::prover: LocalProver Start inputs:2
2024-01-01T17:26:30.191910Z  INFO rusk::http::prover: LocalProver End

We can see the proof creation took 6s for a Transfer using 2 input notes.

Although the server I am running the Prover on is decent (AMD EPYC 9374F 32-Core) proof creation cannot be multithreaded, so a single fast core is what matters, something like an Intel Core i9-14900K maybe, or perhaps some kind of FPGA solution, who knows.

Dusk - GraphQL RPC

smith@mcf.rocks — Sun, 31 Dec 2023 17:56:42 +0000

Explore the Dusk node's RPC capabilities, especially GraphQL... in under 10 minutes.

Use the setup as described previously to run a local node, regenerate the initial state, the file examples/genesis.toml has been edited to give 100,000 coins to our wallet.

# cd rusk
# rm /tmp/example.state
# cargo r --release -p rusk -- recovery-state \
  --init examples/genesis.toml \
  -o /tmp/example.state

Start the node:

# export DUSK_CONSENSUS_KEYS_PASS=password
# ./rusk/target/release/rusk \
  -s /tmp/example.state \
  --http-listen-addr 0.0.0.0:4321

We will use the same wallet as before, but the wallet software has local caching, so after resetting state we need to clear that cache and restart the wallet:

# rm ~/.dusk/rusk-wallet/cache
# ./wallet-cli/target/release/rusk-wallet \
  --state http://127.0.0.1:4321 \
  --prover http://127.0.0.1:4321

When restarting the wallet there will be some delay while it reads the chain to find the notes associated with the wallet.

Make an RPC call to the node, like this:

# curl -X POST http://127.0.0.1:4321/2/Chain \
  -H 'Content-Type: application/json' \
  -d '{"topic":"info","data":""}'
> {"bootstrapping_nodes":[],"chain_id":null,"kadcast_address":"127.0.0.1:9000","version":"0.7.0","version_build":"0.7.0 (16cd2d58 2023-12-31)"}

This call returns some basic information including version and build. There are some parts that are noteworthy; the digit in the url (in this case 2) can be 1, 2, or 3 (contract, host, debugger); the final part of the url, in the event the digit is 2 can be "chain" or "rusk". If "chain" then the topic passed can be any of "info", "gas", "alive_nodes", "propagate_tx", or "gql". The data field contains arguments required for the call (for "info", there are no arguments)...

Where the topic is "gql" we are passing a Graph Query Language call. This is what we are interested in.

Passing the topic without data returns the schema:

# curl -s -X POST http://127.0.0.1:4321/2/Chain \
  -d '{"topic":"gql","data":""}' \
  -H 'Content-Type: application/json'

type Block {
    header: Header!
    transactions: [SpentTransaction!]!
    reward: Int!
    fees: Int!
    gasSpent: Int!
}

type CallData {
    contractId: String!
    fnName: String!
    data: String!
}

type Header {
    version: Int!
    height: Int!
    prevBlockHash: String!
    timestamp: Int!
    hash: String!
    stateHash: String!
    generatorBlsPubkey: String!
    txRoot: String!
    gasLimit: Int!
    seed: String!
    iteration: Int!
}

type Query {
    block(height: Float, hash: String): Block
    tx(hash: String!): SpentTransaction
    transactions(last: Int!): [SpentTransaction!]!
    blockTxs(last: Int, range: [Int!], contract: String): [SpentTransaction!]!
    blocks(last: Int, range: [Int!]): [Block!]!
    mempoolTxs: [Transaction!]!
    mempoolTx(hash: String!): Transaction
}

type SpentTransaction {
    tx: Transaction!
    err: String
    gasSpent: Int!
    blockHash: String!
    blockHeight: Int!
    blockTimestamp: Int!
    id: String!
    raw: String!
}

type Transaction {
    raw: String!
    id: String!
    gasLimit: Int!
    gasPrice: Int!
    callData: CallData
}

schema {
    query: Query
}

You can see the queries that are available. For example:

transactions(last: Int!): [SpentTransaction!]!

This query returns the last N transactions. We can test this by running the query before any transactions are made:

# curl -X POST http://127.0.0.1:4321/2/Chain \
  -d '{"topic":"gql","data":"query {transactions(last: 10){id}} "}' \
  -H 'Content-Type: application/json'
> {"transactions":[]}

Now do two transfers from the wallet to some other address, for example 3uVEjrfzdhjN1a5o48SpiVU9AFzF5o9FZ9mFR9GfeV7U3nfDpDGfVrLJveFPokHsQiXUjjrQHYZSWNz4PY2UQ4xU, note the transaction hashes:

Transfer 100 - txid 8ffa359e732ccad500b16996662a6edb2033d3ecfa868cf68cbadc4ca4e7760d

Transfer 200 - txid
95f58e4b8e7fc5658540cd01064ae93ab07d34c1a91d5a848d32384a3951b100

And finally, execute the query again:

# curl -X POST http://127.0.0.1:4321/2/Chain \
  -d '{"topic":"gql","data":"query {transactions(last: 10){id}} "}' \
  -H 'Content-Type: application/json'
> {"transactions":[{"id":"95f58e4b8e7fc5658540cd01064ae93ab07d34c1a91d5a848d32384a3951b100"},{"id":"8ffa359e732ccad500b16996662a6edb2033d3ecfa868cf68cbadc4ca4e7760d"}]}

The transactions can be seen, newest first.

At this time the node is ephemeral, so if it is restarted, this information is no longer available. The node should soon be runnable in "persistent" mode, in which case this would not apply.

You can see the query part of the curl call, this string is in Graph Query Language, I have hidden the rest of the curl call using a small script:

# cat ./run_query

#!/usr/bin/perl -w
my $cmd = q#curl -s -X POST http://127.0.0.1:4321/2/Chain -d '{"topic":"gql","data":"#;
$cmd .= $ARGV[0];
$cmd .= q#"}' -H 'Content-Type: application/json'#;
print `$cmd`;

From this point on, I just give that string, not the entire call, which remains constant. Also we can use the Linux command jq to format the json output.

The query just executed returns "SpentTransaction" objects, we returned only the "id" field. It is only allowed to return fields, not objects.

Here we return the Block Height and Block hash that the most recent transaction was mined:

# ./run_query "query {transactions(last: 1){blockHeight, blockHash}}"  | jq
{
  "transactions": [
    {
      "blockHash": "0925fc9ff94d445ffecead0e0bfeda70ca184e74d101fbc41a7cc4e5d4412060",
      "blockHeight": 184
    }
  ]
}

From the schema, we see objects can include nested objects. Here we return attributes from the enclosed Transaction object; the Gas Limit and Gas Price:

# ./run_query "query {transactions(last: 1){tx{gasLimit, gasPrice}}}"  | jq
{
  "transactions": [
    {
      "tx": {
        "gasLimit": 500000000,
        "gasPrice": 1
      }
    }
  ]
}

NB: the Gas Price is not in Dusk, but in the smallest fraction of the token, called Lux.

Let's try a different query. Plugging in the Block Height returned previously, we know what Block Hash to expect:

# ./run_query "query {block(height: 184){header{hash}}}" | jq
{
  "block": {
    "header": {
      "hash": "0925fc9ff94d445ffecead0e0bfeda70ca184e74d101fbc41a7cc4e5d4412060"
    }
  }
}

Or using the Block Hash to get the block reward:

# ./run_query 'query {block(hash: \"0925fc9ff94d445ffecead0e0bfeda70ca184e74d101fbc41a7cc4e5d4412060\"){reward}}' | jq
{
  "block": {
    "reward": 16000000000
  }
}

Or fees:

# ./run_query 'query {block(hash: \"0925fc9ff94d445ffecead0e0bfeda70ca184e74d101fbc41a7cc4e5d4412060\"){fees}}' | jq
{
  "block": {
    "fees": 283239
  }
}

Or the Ids of transactions in a block:

# ./run_query "query {block(height: 184){transactions{id}}}" | jq
{
  "block": {
    "transactions": [
      {
        "id": "95f58e4b8e7fc5658540cd01064ae93ab07d34c1a91d5a848d32384a3951b100"
      }
    ]
  }
}

That's all folks.

Dusk - Running a Local Node

smith@mcf.rocks — Wed, 27 Dec 2023 16:15:42 +0000

Run a local node on your machine, give yourself some coins, create two wallets and transfer coins... in under 10 minutes.

You will need Ubuntu 22.04 LTS (20.04 doesn't have the required libraries) and then clone the rusk github repo and build:

# git clone https://github.com/dusk-network/rusk.git
# cd rusk
# make

There will now be a binary:

# ./target/release/rusk -V
rusk 0.7.0-rc.0 (cbd5c504 2023-12-22)

Copy consensus keys:

# cp examples/consensus.keys ~/.dusk/rusk/consensus.keys

Generate the genesis state. It uses the .toml file to create the binary .state file, we will do this again with coins in a moment, but for now just to show how it works:

# cargo r --release -p rusk -- recovery-state \
  --init examples/genesis.toml -o /tmp/example.state

And run the node:

# export DUSK_CONSENSUS_KEYS_PASS=password 
# cargo r --release -p rusk -- -s /tmp/example.state

You will see a bunch of output on the console, and if you check in another session, you will see port 8080 listening.

# netstat -tlpn | grep target
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      77261/target/releas

note: the 127.0.0.1 means the port (8080) will only accept connections from that server.

Stop the process and have it listen on a specific port:

# export DUSK_CONSENSUS_KEYS_PASS=password 
# ./target/release/rusk -s /tmp/example.state \
  --http-listen-addr 0.0.0.0:4321

And observe:

# netstat -tlpn | grep target
tcp        0      0 0.0.0.0:4321            0.0.0.0:*               LISTEN      114057/./target/rel

note: the 0.0.0.0 indicates the port accepts connections from anywhere (firewall permitting).

Can't do much without a wallet. Go back to home directory, clone the wallet-cli github repo and build:

# git clone https://github.com/dusk-network/wallet-cli.git
# cd wallet-cli/
# make build
# cd target
# cd release
# ./rusk-wallet -V
Dusk Wallet CLI 0.20.1

We need to connect the wallet to a running node, in this case our local node:

# ./target/release/rusk-wallet \
  --state http://127.0.0.1:4321 \
  --prover http://127.0.0.1:4321

Select the recover wallet option and enter the 12 words:

cost hungry lounge anger hint cheap buddy across road excuse vendor area

it's deterministic, so the first address will be:

471s2wnF6e5rEv3d6DgSmRHR5mjJGvXTitueNSMGDRV2U9WzhZHRHLJZNbNPZeVAoaGvtwoxRc4R8urC7oNeAueY

You will note the balance is zero.

We need to fund the wallet, to do that we stop the node and generate the initial state again:

# rm /tmp/example.state
# cd ~/rusk
# vi examples/genesis.toml

Add these lines to give initial balance of 100,000:

[[balance]]
address = '471s2wnF6e5rEv3d6DgSmRHR5mjJGvXTitueNSMGDRV2U9WzhZHRHLJZNbNPZeVAoaGvtwoxRc4R8urC7oNeAueY'
seed = 0xdead_beef
notes = [100_000_000_000_000]

note: the last 9 zeros are decimals

Then regenerate the state:

# cargo r --release -p rusk -- recovery-state \
  --init examples/genesis.toml \
  -o /tmp/example.state

Restart the node:

# export DUSK_CONSENSUS_KEYS_PASS=password 
# ./target/release/rusk -s /tmp/example.state \
  --http-listen-addr 0.0.0.0:4321

In a second session, start the wallet as before:

# cd ~/wallet-cli
# ./target/release/rusk-wallet \
  --state http://127.0.0.1:4321 \
  --prover http://127.0.0.1:4321

Recover the wallet, with our words:

cost hungry lounge anger hint cheap buddy across road excuse vendor area

You will see a balance of 100,000

We now need to fake a second wallet, open a third session and create another linux user account:

# sudo useradd -m testdusk
# sudo usermod --shell /bin/bash testdusk

Copy the wallet directory to the new user and chown it:

# cp -R wallet-cli /home/testdusk/
# chown -R testdusk:testdusk /home/testdusk

Create a new wallet:

# su - testdusk
# cd wallet-cli
# ./target/release/rusk-wallet \
  --state http://127.0.0.1:4321 \
  --prover http://127.0.0.1:4321
> Create a new wallet

This will give you some new wallet with an address, with zero balance.

Copy the new address, and on the original wallet, send 100 coins to the new address.

> Transfer Dusk
// use suggested gas limit and price and proceed

You will see the balance is less by 100 plus a very small amount for gas. Switching to the new wallet, you should see a balance of 100.