It’s been almost two years since Dan and I have come up with the idea of GRAFT— an open, real-time payment processing network. Back then, GRAFT was a super innovative thing, and in fact it’s still is. But everything changes and evolves so fast these days, especially in crypto industry. As of today, we have learned a lot of things we didn’t know about two years ago, while some of them simply did not exist. Hence is Lyra — the next evolutionary step, which is not supposed to fully replace GRAFT but rather extend and enhance its ideas and principles by enabling instant, frictionless payments, banking, and digital asset management, for business and personal use.
My job at GRAFT is to make sure that we have an absolutely most technologically advanced payment processing platform on the market. Because of the rapid pace of blockchain development, this market rewards technological breakthroughs over mere traction. At the end of the day we want GRAFT to be a “unicorn” project (a project with billion dollar valuation) and that requires having a break-through platform. I also want you to know that work we’re doing with Lyra is not affecting the work we’re doing on RTA — our engineering team is fully self-sufficient there.
Unlike GRAFT, Lyra is not a cryptocurrency, and not even a blockchain per se (I will explain why in the next post, unless you want to read through the full LYRA white paper and its references). Lyra is bigger: it is intended to move various things, including GRAFT, between people and businesses. One can say that was the declared purpose of GRAFT as well. That’s correct. But Lyra can do it in more efficient way with less efforts— thanks to new technologies and techniques that we would be unable to use in GRAFT, because GRAFT was forked from the existing platform, while Lyra is being designed and coded from scratch. GRFT, however, is the perfect fit for the first exclusive token on Lyra platform that is eligible for paying transaction and token generation fees as well as voting for authorizing nodes (more details also in the next post).
Now enough with introductions, let’s go straight to the business. Right after LYRA white paper was published two months ago, I started working on Lyra proof of concept. The Lyra PoC is supposed to become a “live white paper” — something that probably was never done before. Instead of just reading the boring document and trying to figure out by yourself whether all the proposed solutions are really going to work, you will be able to play with live demo apps and see the real code in action. Although it’s not going to be the final product, eventually it is supposed to be pretty close. And maybe one day, after some good refactoring and even redesign, and with your support, it will become a production network.
The main objective of the “live white paper” is to prove, polish, and test-drive the basic concepts declared in the white paper: distributed proof of stake combined with chain collection and private transactions, and all “tricks” around them. Once PoC is complete, it will be used as a base for creating the actual product. The proof of concept plan consists of several phases, where each phase is intended to prove at least one of the innovative Lyra design concepts. Below is the list of deliverables for each Lyra “live white paper” phases.
Phase 1: Chain collection, full node, standalone authorizer node, console client, Client RPC, transfer transaction, genesis block, single-node testnet, single authorizer node, Mac OS binaries
Phase 2: Handling multiple custom tokens, loyalty and store credit points use case, multi-currency transaction fees, Mac OS, Windows, and Linux binaries
Phase 3: Private transactions (Stealth address, RingCT)
Phase 4: Multi-node network
Phase 5: Voting, authorizers’ list update, authorization quorum, double-spending resolution with multiple authorizers
Phase 6: GUI clients for desktop and mobile devices. Maybe: payment card
First, I reserve the right to change this plan anytime by adding, removing, or reshuffling the phases or/and their content.
Second, no timelines (not yet).
The source code and binaries will be published at some point (when and how — to be decided).
In the next post I will provide more details about objectives of phase one and technologies involved in that phase, which is actually complete as I already started coding for the second phase.
Stay tuned! You can send your questions and suggestions to firstname.lastname@example.org.