Ideas to Reform the Chainflip Validator Network

Ideas to Reform the Chainflip Validator Network

Nearly 18 months into operation, the Chainflip Simultaneous Single Round Open Dutch Auction system needs review. While it has been reasonably successful in producing a stable set of Validators, the distribution of economic security among them has been far less efficient than expected.

The current design

The design of the auction system was supposed to encourage an even distribution of stakes across the Validator set in order to maximise the economic security of the overall keyset, given that each keyshare holds an equal weight in the threshold signature scheme. Unfortunately, we find ourselves in a situation where the top Validator in the set has staked 341k FLIP, while the lowest in the set has staked 10x less at a mere 41k FLIP. This is having a material impact on the effective economic security of Chainflip, as nodes are only bonded to the level of the lowest authority set member.

Running validators isn’t too difficult, but the time required and expense of actively managing stakes, involving spinning up and shutting down a range of machines based on a 3-day auction cycle, clearly is hampering the desired outcomes of the auction system. Perhaps if the rewards were substantially higher, this might be different, but the incentive isn’t strong enough, and I don’t think anyone would recommend increasing the emissions budget for this purpose. It is very clear that the default behaviour for most stakers and operators is more or less “set and forget” - and as such we need to reform the way Validators work to account for this observed behaviour.

Furthermore, it is quite clear that effective control over the network is shared between relatively few node operators, with a handful of professional operators operating the majority of the system. This is fine in principle, but in practice it excludes a range of smaller operators who might otherwise take a greater share of the network’s operations, diversifying the effective set and encouraging a more active Validator community.

To address these issues, I am proposing 5 reforms which could, especially combined, greatly improve Validators on the Chainflip network.These reforms are listed in order of potential delivery and importance.

Reform 1: Allow Operators to transfer stakes between their Validators more easily.Technical difficulty: Low

One of the major issues with rebalancing stakes across accounts is the major headache of having to redeem and withdraw tokens from each validator individually before depositing them back again, something that takes days to complete.

Instead of this cumbersome system, we could allow validators to transfer free (non-locked) FLIP balances between different validator accounts, effectively allowing operators to quickly and cheaply move their FLIP to respond to auction dynamics in real time.

This would require changes in the state chain’s code, and does require limitation on this, such that if a Validator is bound to a particular redemption address, free balances can only be moved to those of other Validators with the same redemption address already bound to it. However these are relatively easy changes.

This is probably the most obvious thing to do, as it would allow an operator to fully configure their nodes in an auction in a single working session, rather than having to come back days apart to adjust their staking configuration.

Reform 2: Allow running multiple Validators from one State Chain NodeTechnical difficulty: Medium

This smaller technical reform would allow one State Chain node to serve as multiple Validator slots, while maintaining multiple witnessing engines, thus cutting down the cost and complexity of syncing and managing multiple Validators.

Independent engines with their own witnessing endpoints are still needed, but as these are generally shared across an operator's entire Validator set, it likely changes very little about the effective diversity and resilience of the network.This likely helps with the incentives to manage and balance one's stakes effectively, as spinning up and shutting down machines based on the changing staking requirements is less costly and cumbersome.

Reform 3: Enable Native DelegationTechnical difficulty: Hard

At present, it is pretty much impossible for anyone to safely pool their FLIP to run a validator. This was done by design to prevent random anonymous Validators from entering the set using other user’s funds without having to commit much or any capital themselves. As such, all validator accounts, with the exception of stFLIP, are allocated to a single FLIP holder.

However, it need not be such an all-or-nothing system. We could allow accounts to delegate their tokens to other accounts natively. In order to prevent the above scenario, we would need to make it such that trust is still needed between the parties in order to assure that stakers know who their operator is and have a relationship with them, such that if anything goes wrong, the staker should be able to pursue some form of legal recourse. 

This trusted relationship would come in the form of delegation lock-ups. Anyone delegating to another party must accept that unless the delegator releases the funds on their own, they can not withdraw them unless they manually set off a 90-day timer and must wait to withdraw.This way community members can get together privately to discuss and organise their own Validators without having to have mountains of FLIP individually.

It also gives participants with mountains of FLIP the opportunity to stake their tokens to ready and willing community members who want to run nodes without having to have a relationship with the professional operator firms, who already control large percentages of the network.Delegated FLIP would be granted to the Validator account holder (who may run one or more nodes) in the form of a delegation pool which they can use to stake as they see fit, allocating to their validators at will. Any delegated FLIP will be granted their share of the rewards into the delegator pool, less a pre-determined operator fee.

Reform 4: Punish Excess StakingTechnical difficulty: Medium

Another potential remedy to the situation is to penalise those who have staked too much and are inefficiently allocating their stakes. This is perhaps more controversial than the other reforms, but could trigger more behavioural changes if the first reforms prove to be insufficient.

Rewards for each validator slot are typically fixed. It could be made such that any stake over a certain percentage over the MAB starts to impact the rewards paid to that validator. 

Purely as an example to illustrate the mechanism, rewards could be reduced by the same percentage as the excess staking percentage (after a cliff of say 10-20%), and redistributed to all the other Validators. If you stake 130% of the MAB, for example, you end up losing 30% of your rewards, which are then distributed to other operators. The exact numbers would be decided later.

This mechanism directly rewards those that are spreading their stakes effectively, and punishes those who are not spreading around their collateral as much as possible to maximise the economic security of the network.This would encourage Validators on the lower end to remain active in the auction cycle and dramatically even out the staking distribution of the network by forcing larger holders to delegate excess tokens or start a new node to stake to when this threshold is reached.

That said, the other reforms could already be sufficient to address the behaviour seen on the network, and so this can likely be implemented as a follow-up step in the reform program if the first few prove to be insufficient.

Reform 5: Reduce the Set SizeTechnical difficulty: Very low

As another simple measure, one step that could be taken is to reduce the authority set size from 150 to 120, and with a drop from 50 to 30 backup validators. This would immediately improve the MAB from 41k to 138k (at the time of writing) with additional gains expected based on expected staking consolidation, almost quadrupling the amount of locked FLIP with no further actions required. This doesn't really address the fundamental issues with the auction system, but it would mean that validators as a collective have to spend less on infrastructure, thus requiring less emissions to remain profitable. It also has the nice added benefit of reducing chain bloat by cutting down the amount of witness votes needed.

While having 150 authorities compared to just 120 is nice, there is no material difference in security or decentralisation of the network with so many nodes, given that the bottom quartile is so under-collateralised in this current paradigm. With delegation and the other measures mentioned also implemented, we wouldn’t expect such a reduction to squeeze out smaller operators. Instead, it is likely to give more power to active operators who promote their delegation services, and put pressure on passive operators who now are far less likely to remain in the set without intervention.

This reform could also allow the emissions budget to be dropped by up to 20% on the main budget and 33% on the backup budget cap to further bolster Chainflip’s token economics. This would take emissions below 4% and would make Chainflip even more deflationary based on current monthly volume levels and price, probably helping existing operators by boosting the potential value of their rewards and collateral.There is a potential debate around this, but with fewer nodes comes fewer costs, and thus a reduction could be justified as rewards would remain flat for the remaining slots, or somewhere in between.

Next Steps

In order to determine which of these reforms to implement, we need to consider which have popular support amongst operators and in what order to deliver them. We’ve already spoken to some operators and providers about their thoughts on this.Within the Chainflip team, there is some debate around which to implement and in what order. Reforms 4 & 5 are the most controversial. We have already slated Reform 1 for the 1.9 release in anticipation.

Your thoughts and opinions are welcomed in this community proposal.