Peer communication
How do metanode operators communicate with each other?
Last updated
Was this helpful?
How do metanode operators communicate with each other?
Last updated
Was this helpful?
Peers must send ping messages every 3 seconds, build peer list, check stakes, and ensure bad nodes are blocked. The ping message contains the status of the peer ("ok"), its state, a stake transaction, and a proof of the TSS share. Each correct ping triggers a stake check where balance must have been staked for at least 72 hours and never moved for each peer. Each one adds a peer to its peer list.
All peers look at incoming address for new tokens, put them in list, and build tx. Incoming tokens must be in confirmed transactions and exist in an unconfirmed K/V. Each transaction contains: tx inputs and outputs, reward distribution, and refunds (multi-send).
Each peer broadcasts a sign proposal (with a maximum of one per peer): <sha512_256(tx_sign_doc), sha512_256(peer_id + tx_sign_doc), tss_proof> Each peer: m[0] == own[0], m[1] == sha512_256(peer_id + our_sign_doc), ok(tss_proof)
Peers that pass are added to own signing set that each peer will broadcast. Peers that broadcast signing sets that do not meet the threshold are ignored by other peers. The minimal subset of signing sets shared across at least t peers is selected by each peer and all must be visible by each other.
Subsets are selected repeatedly until one that meets the full threshold is found (*). This solves an issue whereby two nodes would each broadast a signing list that is t in size but would contain different peers. Of this list, peers are ordered by seniority and peers with any non-unique tss_proofs are pruned from bottom-up to form the threshold set.
Each peer in this list broadcasts a checksum of its threshold set to prepare for signing. If any of these do not match up, outliers are blocked and we must wait until the next round and this round ends up aborting. To prevent double signs, peers will enter a cooldown state if they already noticde >= t+1 peers in the signing state. By making sure the signing state is aligned to 1-minute intervals, peer lists can be regularly cleared.
Peers do not participate in signing until the next round epoch once they finish signing and the transaction(s) are broadcasted.
It replaces “Signing” when in Keygen mode (time < keygen_until).
Each peer has the same “keygen until” time set in config. Keygen runs repeatedly aligned to 5-minute intervals until this time is reached. The in/out addresses will change until a certain block when it becomes “locked in” and permanent.The mainnet network needs to spend some time repeatedly generating the TSS shares for about 1 week to prove that no individuals would know the full private key.
The TSS algorithm can support reassigning shares among peers to prune out peers that have gone offline or are bad. This process happens every day at 00:00 UTC to bring in new peers and maintain the peer pool.
Peers are sorted by seniority in a descending order. If anyone misbehaves during this process, the keygen attempt is skipped and each node records this event (and the culprits) that caused it. If this happens repeatedly, a software update will be issued to address the problem. However, the protocol can continue using the old shares until then.
Important! We must not allow peers to block each other from this process as this can potentially be dangerous (e.g., a cartel can enter the network and attempt a takeover).
(*): Each peer selects a candidate tx which contains the most valid transfers (exact match or closest intersection) with correct reward distribution output in view. It must contain at least one transfer or the round is skipped. TX includes participant peer table checksum that is also verified.
