ADD: Opt-in Chain Clients

Overview

Currently 100+ nodes observe all chains, making a new chain expensive (for the network) and slow to add.

Solution

Per-chain Vaults

For each churning vault, do a separate key-gen per chain, pulling only from a pool of validators that are correctly observing on each chain. Accumulate rewards in per-chain buckets, paying out each bucket to the separate pools of validators.

{
chain: BTC
available_validators: [xxxx,xxxx....]
accumulated_rewards: XXXX
}...

Implementation

Validator Availability

Mark validators as available for a chain if they are synced to tip on that chain (based on network).

Per-chain Vaults Sorting

Sort the validators into as few vaults as possible, overlapping their chains. To do this efficiently, give each validator a canonically-sorted k-bit binary:

[BTC, ETH, BCH, XRP, DOGE, SOL, TRON, BASE] // k=8
k-bit: 11111111

NODE_W: 11111111 // All chains observing
NODE_X: 11111000 // Not observing last 3 chains
NODE_Y: 10000000 // Only observing BTC
NODE_Z: 00011111 // Not observing first 3 chains

Then arrange this descending order and slice into groups of 20 (Asgard-size) per chain. De-dupe the final list and drop any validator-groups that have more than one group, with the extra group less than 20 long. This will create the smallest list of chain-vaults as possible.

Vault_X: 
Chains: [BTC, ETH, SOL, XRP, DOGE]
Membership: [NodeX, NodeY, NodeZ]

Vault_Y: 
chains: [BTC, ETH, SOL]
Membership: [NodeX, NodeY]

Vault_Z: 
Chains: [BTC, ETH]
Membership: [NodeY, NodeZ]

Vault Management

Everything else remains the same. The amount of an asset in TC is the sum of all the balances in all the vaults. When a txOut is scheduled, assign it to a vault, the nodes in the vault will retrieve the correct key share and join the key-sign.

Per-chain Bucket Rewards

Every time a fee is collected in a pool/chain, add it to system income, but also add it to a per-chain accumulated rewards. At the conclusion of a chain, divy up the rewards to only the available validators.