The next large milestone for GRAFT is implementing checkpointing (a way to achieve finality and avoid various double spend exploits between the layers of the multi-layer blockchain).
We have been looking at checkpointing solutions from Dash, LOKI, and Ethereum Casper. All of them use slightly different approaches for validator quorum selection, conflicting checkpoints resolution, revision attacks, catastrophic crashes, etc. Our goal is to pick the best model for GRAFT by leveraging the work that’s been done on these other platforms.
Here’s a high-level checkpointing solutions analysis:
Quorum selection
- Dash: set of active large (320-400) quorums, own communication protocol
- Loki: 2 quorums (10 members)
- Casper: 2 set of validators. Size of each set isn’t specified, supposed to be dynamic
Checkpointing frequency
- Dash: every block
- Loki: every 4 blocks
- Casper: 100s (links)
Slashing
- Dash: scoring, collateral not slashed but masternode could be banned
- Loki: none, only deregistration from being active service node
- Casper: “gradual” (incremental) for lack of responsiveness, harsher for incorrect result
Conflicting checkpoints (fork choice)
- Dash: not possible. No chainlock in worst case: https://github.com/dashpay/dips/blob/master/dip-0008.md#conflicting-successful-signing-attempts
- Loki: Not possible by design. Double spend protection preferred over chain repairability: https://github.com/loki-project/loki-improvement-proposals/blob/master/LIPS/LIP-3.md#44-proposed-checkpointing-in-loki
- Casper: The most notable property of Casper is that it is impossible for any two conflicting checkpoints to be finalized unless ≥ 1/3 of the validators violate one of the two Casper Commandments/slashing conditions (Figure 2).
Double Spend
- Dash: https://github.com/dashpay/dips/blob/master/dip-0010.md#detecting-and-handling-double-spend-attempts If short – it can revert the non-chainlocked blocks same as proposed in Loki
- Loki: Blink tx vs non-blink tx: https://github.com/loki-project/loki-improvement-proposals/blob/master/LIPS/LIP-4.md#51-double-spending-blink-tx–non-blink-tx – The solution to this is that Blink transactions in the mempool are stronger for consensus purposes than non-Blink transactions on the chain. That is, if a Blink-signed transaction arrives in the mempool that conflicts with (i.e. spends the same inputs as) a transaction already mined on the chain then the block containing the conflicting non-Blink transaction is no longer a valid blockchain block and must be rolled back. Blink tx vs Blink tx: https://github.com/loki-project/loki-improvement-proposals/blob/master/LIPS/LIP-4.md#52-double-spending-blink–blink Sending two parallel Blink transactions that spend some of the same inputs at the same signing height h isn’t possible: the approving service nodes by design will not sign twice for the same outputs, and to actually be accepted a Blink transaction must be signed by a supermajority of the service nodes in the (unique) signing quorum.
- Casper: Same as conflicting checkpoints (Slashing)
Over the next couple of weeks we will be working on putting together a proof-of-concept for GRAFT checkpointing, at which point we will publish the design to collect comments and proceed with full implementation.
References:
Lyra DAG Development
As you may know, Slava has stepped away from day-to-day at GRAFT.One of the community devs who was working alongisde with Slava for a while however, has stepped up to continue Lyra work and has already built an impressive showcase application and a roadmap. Little too early to “count the chickens”, but looking quite promising that Lyra development will continue.
