Category: Development update

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:

• Dash
• Loki Blink
• Ethereum Casper FFG

Lyra DAG Development

https://github.com/graft-project/GraftMobile/releases

This release gives us the confidence that we can maintain and enhance the wallet going forward, with a new team make up.

Next

Next, we will now focus on analyzing the double spend protection as we’re exploring finishing up RTA in the near term.

Updated: MAY 17, 2019

We’re very close on the merge release but still dealing with some last minute issues.

FWIW, the merge may sound easy, but it is an incredible amount of work – 100s’ of Monero unit tests have to pass and then GRAFT’s on top. Every change potentially has consequences in other places that have to be found and reconciled.

We’re getting there though. At this point we’re looking into next week for public Testnet.

Main Track

We’re almost finished with the M13 merge – it has been a LOT of work – picking apart and putting back together a very complex and not that easy to follow code base that is Monero, following and retesting all the changes with the code we’ve added, but we’re pretty much there though with no blocker issues left at this point and only few non-blockers to get through.

Some devs are taking a break this week and part of next week for national and family holidays, so will push out the network update rollout until mid May when everyone’s back and are able to support any issues that might come up.