Collusion in Delegated Proof of Contribution Models

2infiniti (Justin Hsiao)
iconcm
Published in
7 min readJun 6, 2019

As we’re approaching the upcoming P-Rep election, where 22 main P-Reps will be elected to govern the network, and ICON will be entering its first phase of decentralization. Questions start to unfold, is the network truly decentralized? How do we prevent the rich from taking complete control, bribe attacks, and cartel formation? Today’s we will explore collusion problems under Delegated Proof of Stake models, and more specifically collusion under Delegated Proof of Contribution model — ICON.

Background on DPoS

DPoS was designed to solve a specific problem of poor voter participation, where majority of stakeholders simply don’t have the time, knowledge and skills to vote responsibly. Instead, it centralizes the decision making process to a smaller set of elected nodes known as delegates. These delegates play major roles within the network, from providing computing resources to block production and validation. They also compete against one another should one act maliciously, bad actors will be voted out and replaced with trustworthy ones.

Public Representatives (P-Reps)

Similar to DPoS (Delegated Proof of Stake), ICON is also under a proxy voting mechanism where ICONists will delegate their ICX to P-Rep candidates. With enough votes, these public representatives will receive control of the network and produce/verify blocks on behalf of their delegating ICONists.

P-Reps not only possess the power to vote on governance and monetary policies, network and protocol upgrades; they’re also incentivized handsomely with representative rewards, as well as block production and verification rewards. Significant amount of ICX is at stake and competition is fierce.

Delegated Proof of Contribution (DPoC)

From ICONstitution and Governance yellow paper,

The central philosophy of the ICON Network reward distribution is fair compensation based on relative contribution. Each participant can demonstrate their contribution through the ICON Network’s unique contribution evaluation system. In the end, contribution is the most important value shared within the ICON Network, and therefore will be the sole standard in the network. Delegated Proof of Contribution (DPoC), as described herein, is the sole justification for electing representatives.

In plain words, incentive schemes are designed around network participation, and one of the most important ‘participation criteria’ is ICX delegation. This is commonly used interchangeably with staking, which effectively freezes the tokens in reserve.

Problem: Low Voting Rate & Collusion

We briefly covered low voting rate problem in a general consensus model, and the attempt to centralize decisions to elected representatives (DPoS). However, even under DPoS, voting without enough economic incentive, people are less willing to participate. From Ricky Dodds’ research on DPoC (part 1 and part 2)

As a point of reference, there is no economic incentive for voting for an EOS BP. The only benefit is governance. As of now, ~25% of EOS community members have voted, and 47% of EOS outstanding is staked. For Tron, the amount voted for super representatives is even smaller at ~7% based on total supply. However, the 27 Super Representative Nodes with the most votes create new blocks and share the rewards with their voters. Based on estimates, this annual return is close to ~5%.

Furthermore, of the 25% voting accounts, many of which could be sock-puppet accounts from the same owner, or ‘friends helping each other out’. This can be observed from the actual votes, eg: EOS Voting Analytics to analyze vote patterns or BP relationships to find the correlations. Unfortunately, proxy voting models like DPoS depend on high voting rate from the entire community in order to work. If majority of delegates were governed by a plutocracy of the rich, they can undermine the decision making process and security of the network will be compromised.

As a consequence of low voting rates, it becomes much easier to dominate and collude on the network. Very wealthy individuals can vote themselves in and secure positions as block producers and decision makers. They can also exchange and sell votes, eg: Rampant Collusion in EOS Exposed by Huobi Leak and always stay in power.

ICON’s Mitigation: Improved Voting Rate in DPoC

ICONists have every reason to stake, I am expecting the delegation rate of circulating ICX tokens, close to that of the token swap rate (98.7%) over a span of one year. Even with some margin of error, we can expect the staking rate to be extremely high, since all participants are financially encouraged to do so. This not only applies to representative delegation rewards, but also staking rewards for Dapps and EEPs (Ecosystem Expansion Projects), the financial incentives make no sense to ignore.

With high participation from the entire community, it becomes difficult to cheat. High delegation rate increases the amount of ICX needed to win, making it extremely expensive to win majority power. Greater the total number of accounts, harder it will be to organize bribes. When the community acts together, they can also create and vote on policies to combat against bad actors. When overall difficulty to cheat increases, collusion problems naturally becomes lesser of a problem.

Collusion — Game Theory and Beyond

Let’s dig in a bit further on collusion by looking at Vitalik’s recent publication: On Collusion, where he discussed cooperative game theory that focuses on predicting which coalitions will form, the joint actions that groups take and the resulting collective payoffs. Under this class of games,

Majority games, formally described as games of N agents where any subset of more than half of them can capture a fixed reward and split it among themselves, a setup eerily similar to many situations in corporate governance, politics and many other situations in human life, are part of that set of inherently unstable games. That is to say, if there is a situation with some fixed pool of resources and some currently established mechanism for distributing those resources, and it’s unavoidably possible for 51% of the participants can conspire to seize control of the resources, no matter what the current configuration is there is always some conspiracy that can emerge that would be profitable for the participants. However, that conspiracy would then in turn be vulnerable to potential new conspiracies, possibly including a combination of previous conspirators and victims… and so on and so forth.

He proposes two ways to get around this issue. One of which is to avoid being in the class of games that are identity-free and collusion-safe, so we do not need to worry about bribes or identities. Second is to attack the problems directly heads on and actually solve them well enough that we can implement non-collusion-safe games. He went on to discuss details on identity-free and collusion-safe game design, as well as collusion resistance and identity. Concluding thought was that building out the infrastructure for making collusion-resistant mechanism possible is a difficult challenge and the aim is to succeed at making something secure enough, for at least some use cases.

Will ICON be Collusion-Safe?

I would say that the answer is no and argue that it is likely impossible for most if not all blockchain protocols to be completely collusion-safe. ICON however will be collusion-safe until a high bound, and fairly collusion-resistant overall. Even under Proof of Work protocols, they’re only collusion-safe up to the bound of one actor possessing over 50% of total hash power. Most protocols, PoW or PoS or DPoS, are relatively collusion-safe up until a high bound. Some protocols reach the high bound easily and some don’t. For example, projects with high concentration of tokens such as EOS where top 100 wallets own 75% and top 10 wallets own 50% of all tokens, in-group collusion can be plain as day as the Huobi incident we mentioned earlier. This makes it possible to cement their positions as BPs, and if at one point they reach the high bound, namely 2/3+1 or 15 block producers, they can freely act in self-interest and maximize their own profit. For ICON, besides the exchange wallets, tokens are relatively spread out , suggesting that we don’t have high concentration of tokens to select few individuals. In this case, reaching the high bound will require many more accounts colluding. We also talked about high voting rate making collusion extremely expensive, and that buying out the network will be financially discouraged and chances are, people won’t do it.

What Else Can be Done?

Another idea came from Block.one, who holds 10% of EOS tokens, talks about using their tokens to vote and to reinforce the integrity of their election. While this may seem counter-intuitive to the decentralization process, it is to ensure network safety in the mean time, before the next optimal design for future decentralized governance comes up. ICON could also take on a similar approach, voting in say, an ICON Foundation P-Rep node, just like what EOS and Tron and several other projects have done.

Even More Parties Involved

Community Representatives (C-Reps) will be introduced down the road. Recall,

A C-Rep, representing a Community connected to the ICON Network, is elected via autonomous decision-making within the respective Community in accordance to sufficient contribution verified. A C-Rep is a connection between ICON Network and Community, validating transactions on the ICON Network. A C-Rep proposes and votes on policies that represents interests of each Community.

So C-Reps will be well vetted and will be proposing and voting policies of best interest to their respective community. We will have a complementary system among the two sectors of representatives (P-Reps and C-Reps), making our governance structure more balanced and reliable. Also, from ICONstitution and Governance Yellow Paper, we know that the number of C-Reps and the P-Reps will roughly be equal. This makes collusion at least twice as difficult, and prevents biased-decision making.

TL;DR

Most protocols may never be completely collusion-safe, and it is not the goal for ICON either. ICON tries to mitigate by making it expensive and difficult to collude and stays very collusion-resistant overall.

--

--