Skip to content

Bluepaper

Jump to bottom
Jérémy Pansier edited this page Oct 17, 2023 · 13 revisions

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 the address is registered in the Proof of Humanity registry or not.

1.1 Block

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

1.2 Transaction

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

1.3 Input

The term "input" refers to a data package 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 package that stores an amount to be sent to a wallet address. Each output contains:

  • The address.
  • Whether the address is registered in the Proof of Humanity registry or not.
  • The value.

2 Network Operation

The noticeable particularities of Ruthenium's network are:

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 registered 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.

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 registered transaction 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 output signature is valid.
  3. Check that each transaction output has not 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.8 Proof of Humanity

Proof of Humanity was conceptualized by Santiago Siri. It is a system combining social verification with video submission in order to create a Sybil-proof list of humans. It is meant to be used by individuals as a point-of-entry to a myriad of new use cases that require Sybil-resistance to be able to be deployed at scale and also to be plugged into a variety of existing and new applications in need for such identity systems.

This ensures that each real human owns only one registered wallet address.

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 Currency

The Ruthenium network includes its own built-in currency, called Ruthenium as well.

Rutheniums can be split into smaller units to facilitate smaller transactions. A particle is the smallest denomination of Ruthenium, equivalent to 100 millionth of a Ruthenium.

4 Balance Evolution

The main difference compared to most of cryptocurrencies is that the wallet balance is evolving over time. Some of them propose a basic income (like Ğ1), others have demurrage fees (like Freicoin). Ruthenium includes both.

4.1. Income Distribution

Ruthenium introduces a unique income distribution model designed to promote fairness and economic stability. Every single human is eligible to receive an income after fulfilling the following:

4.2. Capitalization Limit

Similar to the natural decay of the ruthenium 106 $(^{106}Ru)$ radioisotope, wallet amounts in Ruthenium also experience disintegration. The wallet amount is calculated based on a decay formula that considers elapsed time, and the initial wallet amount. This disintegration ensures that wallet values evolve over time, contributing to the project's economic model.

Ruthenium implements a capitalization limit to discourage excessive speculation and promote the fair distribution of income. Beyond a wallet amount of 100,000 tokens, capitalization becomes unprofitable.

This design choice aligns with the project's vision of a cryptocurrency that prioritizes fair trade and income distribution over speculative investments.

4.3 Formula

${x}$: the time in days
${h}$: the $^{106}Ru$ half-life in days
${N_0}$: the wallet initial balance
${l}$: the capitalization limit
${b}$: the base income after a period of h for x = 0

Balance evolution formula for non-registered addresses:

$$ f(x)=N_0·e^{-x·ln(2)/h} $$

Balance evolution formula for registered addresses above capitalization limit:

$$ g_l(x)=(N_0-l)·e^{-x·ln(2)/h}+l $$

Balance evolution formula for registered addresses below capitalization limit:

$$ k_1=3-2ln(2b)/ln(l) $$

$$ k_2=ln(2)/(-ln(1-b/l))^{1/k_1} $$

$$ g_l(x)=-l·e^{-(x·ln(2)/(k_2·h)+(-ln((l-y)/l))^{1/k_1})^{k_1}}+l $$

5 Roadmap

roadmap

Jérémy Pansier - jeremypansier@gmail.com

Clone this wiki locally