SONM Masternodes details (draft)

Summary (TL;DR)

We are working on masternodes because we would like to outsource system components maintenance, to increase transparency and raise trust.

There are a lot of components to be decentralized, not only masternodes. Currently, we talk about gates and block producing masternodes.

Below is a table with key facts. Detailed information provided as text in the remaining article.

Goals

SONM is preparing to establish masternodes. To understand this decision taken and the corresponding details it is good to understand the goals and constraints that we have.

Goals of introducing masternodes (and following a path of decentralization) are the following:

• This provides trust and value to the technology, protocol, and SONM system.
• SONM is a software development company, there is no SONM operator and we would not like to introduce such one, neither be one. As so, we would like to host and maintain as minimum key system components as possible. Preferably zero key system components, preferably no components at all. At the same time, we keep the right to host and maintain some components (in case, when our control over them is beneficial for SONM) and make operations, related to software development and migration.
• Maintaining system components is a work, which must be done in a secure way and we would like to outsource this work to people, who would like to carry it on. A typical approach in the old world is to hire a company, sign a contract (like with cloud hosting company), but we believe that technology enforcement is better than a legal agreement.

I must especially note, that there are no goals related to:

• Provide additional utilization for SNM tokens. We are not inventing masternodes because other projects have them or because we want someone to make profits on them. Goals mentioned and required work to be done are in the first place.

Work to be outsourced to community

To provide an overview of SONM system landscape and components that are to be outsourced to the community, here is the full list.

Scope of this article

Today we would like to provide details, related to:

• Sidechain block producing masternode (PoS mining).
• Gate masternode. Validation of token transfers between Ethereum masterchain and SONM sidechain.

Gate masternode

Options considered

• Centralised trusted gates.
• Vote to secure transfers. Decentralised Proof-of-Something voting evidence to secure transfers between chains (POA network-like).
• Vote to secure block headers + onchain merkelized proofs. Decentralised Proof-of-Something voting evidence to secure block headers between chains with requestor provided merkelized proofs, checked on chain (Polkadot-like).
• Single validator to secure transfer + PoS escalation. Decentralised single validator cross-chain transfer securing with Proof-of-Stake voting escalation in case of invalid transfers (inspired by Augur/REP validation escalation).
• Atomic swaps.

Comparison table and decision reasoning

Algorithms details estimation for some options

Vote to secure block headers + onchain merkelized proofs (Polkadot)

1. Hash tx params.
2. Check validator rights to release payout or its sender.
3. Verify hash is unpaid.
4. Verify that hash exists in voted merkle-root.
5. ERC20 transfer tokens.
6. Write the fact that transaction is paid.
7. Emit event.

Write to blockchain summary:

• 1–2 x uint256;
• ERC20 transfer;
• Event.

Single validator to secure transfer + PoS escalation (Augur)

1. Check that validator has right to process transaction: Time passed (in seconds) from the transaction being validated is more or equal to (TxHash-ValidatorAddr) / ValidatorStake / 2210

• If exceeded revert.
• If not — continue.

Target average access time for a standard stake (100k) validator to a transaction must be 5 minutes.

More standard validators — higher probability for a given transaction to be processed faster, than 5 minutes.

Higher stake size — higher access time, higher probability for a given transaction to be accessed instantly.

2. Check that this validator has not exceeded volume limit.

• If exceeded revert.
• If not — continue.

3. Write updated limits info:

• update last TX process time for this validator
• update this validator volume

4. ERC20 token transfer

5. Emit event.

Write to blockchain summary:

• 1–2 x uint256;
• ERC20 transfer;
• Event.

Solution details

Selected solution is “Single validator to secure transfer + PoS escalation (Augur)”.

Approximate algorithm

There could be any number of gate masternodes, one is enough, but not reliable and not fast. Ten or more would work fine.

Each transaction (deposit or withdrawal) is processed by a single gate, which is chosen on a lottery basis, functionally similar to PoW lottery. For given TX a “distance” is calculated between this TX and each gate (hash difference). Distance is influenced by (a) random and (b) stake size. Distance is measured in seconds and defines a pause each gate takes before trying to process this given TX.

Gate deposits a stake, which is used as following:

• 90% of stake is used as turnover funds;
• 10% of stake is used as a reserved bounty for first validator-gate that will catch this given gate on invalid transaction.

Gate is allowed to process transactions with total volume not exceeding gate’s turnover funds (90% of stake) per time unit. Time unit is one hour.

Example:

• stake 1000 SNM;
• gate is allowed to process 900 SNM / hour;
• 21 600 SNM / day.

Transactions are processed by a single gate. Gate, that won lottery, has the right to validate, that a given transaction has frozen N tokens on source chain. If gate validates this fact, it has the right to release N tokens on target chain with a single decision of its own. This decision is not a vote, it is a single decision.

To validate transactions, a gate is monitoring source blockchain events and works on target blockchain. It is performing its own autonomous validations.

After a validation is done and funds are released, a challenge (dispute) time window starts. Any of the other gates must check offchain, that performed validation is correct:

• if the validation is correct, the other node is skipping;
• else other node raises a claim (a dispute) and escalation starts.

Escalation is a procedure of stake-based voting on the validity of a transaction processed by a gate. Any conscientious gate may and should take part in escalation. Escalation is settled by a stake majority on one of the outcomes:

• initial transaction was valid;
• it was invalid, escalation is valid.

The right outcome is the one, which was supported with higher stake or other nodes. If the initial translation was considered invalid, it is refunded from the deposit stake of the gate under trial. This gate loses its bounty part of stake, which is transferred to a challenge opener. In any case the opposite outcome supporters loose 100% of their stakes, which are divided among escalation winning gates.

Escalation is an event, that should normally never occur. It is merciless, very slow and expensive in terms of gas price. It is a measure, that must enforce gates to behave correctly without the need of voting.

Profitability explained

Target ROI = 20% of stake, annual.

This is not a guaranteed ROI, but a target, for the case of full gate utilization.

Expected practical ROI = 10–15% of stake, annual.

Transaction fee size is fixed at a value, that will allow to achieve target ROI in case of full utilization.

Transaction fee size = 0.2 / 365 / 24 / 0.9

= 0.000025 = 2,5 x 10^-5

= 0.0025%

ROI could be even lower in case of excessive gates availability.

Gates availability and ROI is regulated on a market basis (similar to mining profitability):

• Expected ROI will attract new gates, raising gates capacity to a level higher, than existing average transaction volume.
• When total gates capacity is higher, than existing average TX volume, gates will not be fully utilized and will have reduced ROI. This will at lead to some gate owners with higher ROI expectations to abandon running a masternode and thus reducing gates capacity and raising ROI of the remaining gates.

Stake reasoning

Values below 10k would be not effective, because full stake must be enough to completely cover a series of typical deposit/widthdrawals, which could be as high as 1–5k SNM.

Values higher, than 10k (closer to 100k) seem to be high enough for series of transactions or for single big transactions.

Any deposit/withdraw transaction must be carried out by a single validator (masternode), so there must be masternodes with high stakes always ready.

Could be technically reduced to 10 000 SNM, but will probably kept as 100k.

Full technical requirements

No special requirements on performance:

• Linux x86/64
• Common CPU
• RAM 4+ Gb
• Fast network

High availability and redundancy:

• High availability options.
• Redundant power supply.
• Redundant internet connectivity.
• Reliable hardware.
• Reliable OS and software setup.
• Monitoring.

Special caution must be taken to secure this PC from network and physical attacks:

• Carefully set up firewall. Machine must have only outbound internet connectivity.
• Incoming connections not required.
• Carefully chosen location to prevent physical access and screwdriver attack.

Full OS strong encryption (linux) is a must, together with on-machine firewall setup will do the work.

Block producing masternode

The goal is to have an Ethereum sidechain with PoS block producing scheme. This type of masternode is currently in development by Ethereum Foundation.

We find it highly probable, that Ethereum Foundation and Vitalic Buterin will do this better, than we could. We would not like to reinvent the wheel (at least in this case :), this is not SONM’s primary focus neither business priority.

We see a great future in Ethereum (in case scalability issues will be effectively resolved as promised), plan to stay with this leading ecosystem and highly support it.

That said will wait until a solid and mature PoS block producing masternode will be implemented by professional team and plan to adopt it for the benefit of SONM according to existing licence options (we expect it would be available).

There is another high probability, that with new Ethereum releases, introduction of PoS, sharding and other ecosystem improvements (such as leaded by Parity and Polkadot) we will have an opportunity to migrate to stock Ethereum and in that case we will not require our dedicated blockchain masternodes at all!

Possible solution description

Stake reasoning

A typical PoS stake layout is ~100 voting nodes with sensible amount of token allocation.

This way minimal stake would look like:

500k x 100 = 50m (out of 444m allocation)

~11% of total allocation

Could be resized according to future implementation details.