Lithium updates require consensus of nodes, rather than just one

[HarryR]

So, having a single Lithium node which condenses the block chain into the merkle tree is insecure because if the single node gets compromised then any leaf can be added into the tree and all security or dependability is... gone.

One solution to this is to use a validator set, where N of M signatures are required to upload a new merkle root. This avoids the 'nominated leader' problem, where any one person can fake the root if they're nominated leader, e.g. with Paxos.

It works as such, each validator:

• Has a HTTP API, where it can be queried
• Knows the URLs of every other validator
• Runs independently, processing each block, condensing into a merkle root
• Signs the merkle root with its own key
• Gossips with other validators, providing its signed root for the specific height
  • When gossiping, provides the list of addresses for which it has signatures
  • When gossiping, returns the list of addresses not in the list of excluded signatures
  • e.g. a diff, has vs need
• When number of signatures reach required threshold, submit to LithiumLink
  • To avoid wasting gas, a validator is chosen predictably
  • If validator goes down, or doesn't submit transaction, another validator is chosen predictably
  • Gossip must include the transaction ID etc.

It's possible that this could be written as a Tendermint ABCI application, but the whole history isn't necessary, and that may over-complicate things? But it would be interesting to see how it works for Cosmos integration.

The validator set contract would be something like:

contract ValidatorSet {
    function GetAddress(uint idx) returns (address);
    function Exists(address) returns (bool);
    function GetCount() returns (uint);
    function GetThreshold() returns (uint);
    function Validate(uint8[] v, uint256[] r, uint256[] s, bytes32 message) returns (bool);
}

Iterate through using GetAddress for GetCount returns the address of each validator.

Providing Validate runs ecrecover for the message parameter, if any signatures aren't by a validator, it returns false. If the number of signatures is below the required threshold, it returns false.

Problems:

• Adding and Removing validators - see how Clique does this
• Serial / Linear nature of validator set decisions, e.g. cannot retract decisions
• Threshold in the event of dead validators
• Validator liveness tracking
• Iterating validators, removing from list leaves gaps, figure out in Solidity

[HarryR]

The POA network has implemented something similar, however it's specific to tokens and transfer of value rather than general purpose automata. Either way, they have a validator set contract which has gone through a full audit which is worth reviewing.

See:

• https://github.com/mixbytes/audits_public/blob/master/solidity/POANetwork/audit_en.md
• https://github.com/levelkdev/audits/blob/master/POA-Bridge/POA-Bridge-Audit.pdf
• https://github.com/BlockchainLabsNZ/poa-parity-bridge-contracts/tree/audit/audit
• https://poanet.zendesk.com/hc/article_attachments/360004912074/POA%20Network%20-%20POA%20Bridge%20Security%20Assessment.pdf

@rstormsf is the person behind some of bridge contract, thought it might be worth mentioning them here.

What I intend to do next is address all of the points in the bridge & relay contract audits, to ensure that all points are mitigated or avoided.