Bluepaper

1. Blockchain Structure

Ruthenium's blockchain structure shares similarities with Bitcoin, as it serves as the underlying ledger for all transactions within the network. It does have some differences though. The main differences are:

• The block data structure holds additional fields for added and removed registered addresses.
• The output data structure holds an additional field to know whether it is yielding or not.

1. 1. Block

The term "block" refers to a data structure that stores transactions. Each block contains:

• The previous block hash.
• The addresses newly added in the Proof of Humanity registry.
• The addresses newly removed from the Proof of Humanity registry.
• The creation timestamp.
• The transactions.

1. 2. Transaction

The term "transaction" refers to a data structure that stores inputs and outputs. Each transaction contains:

• The ID.
• The inputs.
• The outputs.
• The creation timestamp.

1. 3. Input

The term "input" refers to a data structure that stores a reference to an output. Each input contains:

• The output index.
• The transaction ID.
• The public key.
• The signature.

1. 4. Output

The term "output" refers to a data structure that stores an amount to be sent to a wallet address. Each output contains:

• The address.
• Whether this output is yielding or not (used for balance evolution calculation).
• The value.

2. Network Operation

The noticeable specificities of Ruthenium's network are:

• The blocks are created at fixed intervals of time.
• The consensus mechanism is based on Proof of Humanity.

2. 1. Process

The steps to run the network are as follows:

1. Every 10 seconds, each node is randomly connected to 8 other nodes called neighbors.
2. New transactions are broadcast to all nodes.
3. Every minute, each node collects pending transactions into a block.
4. Every 10 seconds, each node verifies the new blocks of the neighbor’s nodes and selects one of them.
5. Nodes express their acceptance of the block by including it in their local copy of the blockchain; creating the next block in the chain, using the hash of the accepted block as the previous hash.

2. 2. Validation

Each node checks the pending transactions before adding them to the next block.

Each rejected transaction is removed from the transactions pool.

Additionally, the following checks are done:

1. Check that each yielding transaction output address that is not in the local registered addresses is registered in Proof of Humanity. The address will be included to the next block as added registered address if true.
2. Check that each local registered address is registered in Proof of Humanity. The address will be included to the next block as removed registered address if false.

Then, all valid transactions are added to the next block with an additional reward transaction.

2. 3. Verification

Each node verifies neighbor's blockchain by checking all new blocks. A block whose reference is not known by the validator node is considered a new block.

Additionally, the following checks are done for the last block:

1. Check that the reward recipient’s address is registered in Proof of Humanity.
2. Check that each added registered address is registered in Proof of Humanity.
3. Check that each removed registered address is not registered in Proof of Humanity.

If the verification succeeds, the neighbor blockchain is eligible to be selected.

2. 3. 1. Block Checking

The algorithm for checking if a block is valid is as follows:

1. Check if the previous block referenced by the block exists and is valid.
2. Check that the block timestamp is valid.
3. Check that there is one or only one reward per block.
4. Check that the reward amount is valid.
5. Check that each transaction is valid.
6. Check that each transaction yielding output address is in the local registered addresses.

2. 3. 2. Transaction Checking

The algorithm for checking if a transaction is valid is as follows:

1. Check that the transaction timestamp is valid.
2. Check that each transaction input is valid.
3. Check that each transaction output is valid.

2. 3. 3. Input Checking

The algorithm for checking if an input is valid is as follows:

1. Check that each input signature is valid.
2. Check that each input references an existing unspent output.
3. Check that each input public key correspond to the address of the output it references.

2. 3. 4. Output Checking

The algorithm for checking if an output is valid is as follows:

1. Check that each output has not already been spent.
2. Check that there is only one yielding output by address in the already been spent.

2. 4. Transactions Pool

The transactions pool is a local node storage for transactions that have not already been included into a block.

The pool is updated each time the blockchain changes and each time a transaction is broadcast to the node.

2. 5. Registered Addresses Pool

The registered addresses pool is a local node storage for addresses that are known to be registered in Proof of Humanity.

The pool is updated each time the blockchain changes.

2. 6. Unspent Transaction Outputs Pool

The unspent transaction outputs (UTXOs) pool is a local node storage for transaction outputs that are not already referenced by an input that is in the blockchain.

The pool is updated each time the blockchain changes.

2. 7. Consensus Mechanism

A fundamental aspect of Ruthenium's design is its unique consensus mechanism based on Proof of Humanity. Unlike traditional Proof of Work (PoW) or Proof of Stake (PoS) systems, Proof of Humanity ensures that only one validator node is run by a real human.

The validator node adds a reward transaction to the newly created block. The output address is considered as the validator address.

A validator is trusted only if its address is registered in Proof of Humanity. The network will only accept blocks that have been created by a trusted validator node

Among trusted nodes, the system selects the one with the longest blockchain that has not been selected for the longest period. Each node, upon verifying this selected node's blockchain, will substitute its own with the selected one. Nodes favor the longest chains and select the one created by the oldest validator

2. 9. Reward

A validator adds a reward transaction to a newly created block. The reward amount is equivalent to the addition of the fees of each transaction of the created block.

The reward transaction does not contain any input and contains a single output.

3. Balance Evolution

While the balance evolution philosophy is described in the whitepaper, this section focus on a technical and mathematical explanation of the mechanism.

3. 1. Principle

The output data structure holds the initial value (i.e. the value at its block creation time). The current value of an output is calculated on demand according to different formula depending on if it is yielding.

The network will accept only one yielding output by address.

3. 2. Formula

• Balance evolution formula for non-yielding output:
  $f(x)=N_0·e^{-x·ln(2)/h}$
• Balance evolution formula for yielding output:
  • above the balance limit ($l$):
    $g_L(x)=(N_0-l)·e^{-x·ln(2)/h}+l$
  • below the balance limit ($l$):
    $g_l(x)=-l·e^{-(x·ln(2)/(k_2·h)+(-ln((l-y)/l))^{1/k_1})^{k_1}}+l$

Variables:
${x}$: the time in days
${N_0}$: the wallet initial balance

Constants:
${h}$: the $^{106}Ru$ half-life in days
${l}$: the balance limit
${i}$: the income after a period of $h$ for $x = 0$
$k_1=3-2ln(2i)/ln(l)$
$k_2=ln(2)/(-ln(1-i/l))^{1/k_1}$