Inspired by Research at EDCON 2018, ChronoLogic Explores Partial Slashing

One thing we learned during EDCON was the newly introduced concept of partial slashing in Casper, the Proof of Stake consensus algorithm. Karl Floersch and Vitalik Buterin described this approach at length and we think we can apply a similar concept for our TimeNodes.

In Casper, partial slashing basically works as follow ; if you commit a fault but no-one else does simultaneously, then we can assume it was potentially a “mistake” and the protocol will penalize you only slightly (e.g. you lose 5% of your stake)*. This is fine since your single “malicious” action is not actually threatening the security of the network. However, having 30% of the network trying to act maliciously at the same time could be considered as a security threat for the network and nodes that participated in this malicious act will be more harshly penalized (e.g. lose 40% of their stake)*.

One interesting, yet not obvious consequence of this approach is that it creates a stronger incentive for the network to be more decentralized. Indeed, as an example, imagine if we have 35% of the Casper validator nodes running on the same software client. If this client contains a bug and is exploited, you suddenly have 35% of the nodes that start behaving maliciously, even if unintentional. This leads to all nodes using this client be penalized harshly and as a consequence creates an incentive for people to not all use the same client as all the others. In general, you want to make sure that if your node goes down or gets compromised, you should ideally be the only one affected. If that’s the case, you will only be penalized lightly. This creates a stronger incentive for validators node to be as decentralized as possible.

A similar logic can be applied for ChronoLogic, where a small group of TimeNodes misbehaving could be penalized less harshly than a larger group. For instance, if a single TimeNode does not execute a transaction they claim, we could conclude that this is not a significant threat to the network. However, if a large portion of the scheduled transactions are not executed around the same time, we can conclude that the network is at risk and malicious actors could be penalized more harshly.

This creates an incentive for TimeNodes to be as independent as possible from each others to minimize the cost of having their nodes fail. Users will therefore be less willing to join large TimeNodes staking pools or use the same software as the others in order to minimize their chance of falling at the same time as many others. On the higher level, a more decentralize network is inherently more resilient, which creates a stronger guarantee that scheduled and conditional transactions will be executed as expected. This increase in decentralization via partial slashing is not guaranteed in practice, but the additional incentive will most likely have an impact on decentralization.

* The number provided as slashing weights are only examples and do not reflect the actual values that will be used for Casper.

Account abstraction

This one is more of a long-term research topic, but it is likely that in the next few years Ethereum will implement what is known as Account Abstraction (see Vitalik’s recent recap on this topic). ChronoLogic is mostly focused on developing secondary layer services, but things like account abstraction could open the gate for us to build on a lower level. We currently do not clearly understand whether or not ChronoLogic can benefit from this significant change to the protocol, but as the specifications get more precise over the next years, we intend to spend more time on researching this.

Conclusion

The topics presented here are all active areas of research within ChronoLogic, and are not exhaustive. We hope to have some more in-depth articles for the research being done at ChronoLogic over the next few months. In the mean time, if you’re interested in the work we’re doing on the Chronos Protocol and want to collaborate or share ideas, follow the progress on our public GitHub. You can also connect with the Chronologic team directly on our Gitter channel or Telegram.