Congratulating @jfkwn and the community on this very important accomplishment!
P.S. we need at least 20 live nodes to get the real testing and benchmarking under way so please join the testnet! (Lyra Testnet TG channel is the best place to ask for help)
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:
- 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
- Dash: every block
- Loki: every 4 blocks
- Casper: 100s (links)
- 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)
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.
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.
Long overdue, a wallet update with transaction history is now ready for desktop and being pushed out to mobile.
This release gives us the confidence that we can maintain and enhance the wallet going forward, with a new team make up.
Next, we will now focus on analyzing the double spend protection as we’re exploring finishing up RTA in the near term.
Good day/evening/morning GRAFTers!
We wanted to start this engineering update by describing the work we’ve been doing on development methodology and processes. We continue to make steady progress towards improving transparency and openness when it comes to development practices, embracing community open source development model.
To that end, we have been migrating tasks and issues from JIRA, which is a closed development focused tracking/planning system to Github. Most tasks and issues are now in Github, and are open to the community to see and comment on. We have also added “projects” – Kanban boards representing the status of various sub projects: https://github.com/orgs/graft-project/projects
We have a number of tasks that are tagged as “help wanted” and are open to the community development, with GRFT rewards attached to them. You can pull up the “help wanted” tasks by running a filter.
You can find the proposed community task guidelines here. We will be adding more community dev tasks in the near future.
If you know of capable SW engineers who would like to work on interesting problems and make a contribution to the project that has solid potential to improve the world, please refer them to the open community tasks.
Lastly on this subject, we would like to welcome to the team Nick Willson, @DaDudster on TG, who will help oversee the open source community development efforts at GRAFT. Nick comes to the project with extensive background in computer science, artificial intelligence, and a keen interest in the blockchain space. Nick has a PhD from RPI in Cognitive Science. Coordinating open source development is not a trivial task and we’re very happy that Nick stepped up to the challenge!
Here’s the recount of development progress over the past two weeks:
Yesterday the network was upgraded to “bulletproofs” version of Monero.
This is a significant upgrade that brings important new features and improvements to the network such as much smaller block sizes, multi-signature wallets, and better security.
The merge has been quite a bit of work and we’re excited to get this done as it paves the path to other network features on the roadmap.
Congratulations to the team and community. Thanks for the hard work!
You can find the latest 1.8.2 Release HERE
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.
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.
We hit a big first milestone with LYRA
DPoS architecture this week – a very early first proof-of-concept version was shown by Slava. LYRA combines delegated proof-of-stake (DPoS), private transactions, and chain collection (no single blockchain!).
Why are we working on LYRA now?
There are several reasons for that:
1) we’re in the field that is developing extremely rapidly and favors projects that not only deliver the functionality, but also (and perhaps most importantly) offer technology leadership.
2) A DPoS architecture will be useful in different ways over time, starting tentatively as a sidechain solution for merchant tokens / loyalty programs.