Light node and per-node instant total order

[cedricfung]

Mixin Kernel doesn't offer instant total order, but it's possible to get this order from a single node instantly. The node should sign the order along side the snapshot and guarantee the consistency.

Light node which has staked 1 XIN must send voting transactions periodically to retain its reputation to receive reward from the pool. One of their votes is vote the total order hash of some kernel node, and whenever some kernel node receives conflicting votes for its order, and this vote is valid because it includes the signature of the kernel node. Then this kernel node will be slashed instantly.

• Light node vote SDK
• Vote transaction
• Strict topology sync mode

[cedricfung]

449146f

A Kernel node may lose its data and fresh sync from the network, how could it maintain the total order consistency?

[cedricfung]

It's the node's responsibility to maintain the total order, so whenever the data loss causes total order changes, it would be slashed instantly.

The punishment should be the same as the slashing rules, 100XIN.

After a node is slashed, it can start over freshly, so a new total order would not harm.

[cedricfung]

From the punishment, 10% will be credited to the light node voter. If there are more than one voters, it's credited to the first voter based on the snapshot timestamp. But this should be discussed more to better incentivize the nodes to vote, also assure no abuses, i.e. some nodes may just copy the first voter to gain rewards if we decide to distribute punishment reward to multiple voters.

All the rewards for the light nodes, including the punishment share, can only be claimed manually by the light nodes after the second mint day. So if a node has earned some rewards on Sep 20, and it can only claim the reward after the mint on Sep 21.

[cedricfung]

1. A light node should stake 1XIN or more, and 1XIN is the smallest dividends allowed.
2. The stake can be claimed back with the same rule as claiming rewards.
3. A light node should vote at least three times per day, and with at least 1 hour window during two votes.
4. A vote is about all kernel node topology for a snapshot.
5. In case a light node finds some inconsistency for snapshot topology, its vote should includes it to win the slash punishment.
6. Each vote should cost about 0.0001XIN to prevent spam votes.

[cedricfung]

The punishment for the light node is 100% slashing, so they must never do a false vote about a full node.

There is a Stake output type, each stake transaction can only have one Stake output and at most one script output as change. In the Stake transaction, the Stake output has the same key, mask, and script as the normal Script output, so that it can only be spent by satisfying the same script output check.

The Stake transaction must include a valid extra to claim the reward, the extra will be a normal Mixin address. So whenever some reward available to claim, any user can send out a 0.0001XIN Claim transaction to claim all its available reward. The Claim output is the same as the Vote output, and the 0.0001XIN is credited to the Kernel network. In the Claim transaction, there is the same address as the extra. This means anyone who wants to spend 0.0001XIN can claim the reward to the designated address in the Stake transaction.

A light node can send more than one Stake transactions with the same Mixin address as extra, so that it can claim the reward at once. But the drawback is once some bad votes happened to this address, all of its stake and reward would be slashed.

[cedricfung]

Strict topology sync mode allows a node to backup its topology in real time.

[cedricfung]

Light node could also do transaction references, i.e. for node removal or some consensus critical transactions. Light node could compete to be the first to reference those transactions.