iPollo G1-Mini launch|Appreciate John Tromp’s spirit of “minimalism”
16:00, December 15, 2020 iPollo、Interhash and POW POWER co-hosted iPollo G1-Mini new product launch event with great success，At the same time represents the household distributed computing node will really open!For this presentation we have John Tromp, inventor of the Cuckoo Cycle Cuckoo algorithm.
The following is the highlights of the live broadcast selected by the EDITORIAL department of POW POWER:
Q1. As the inventor of CuckooCycle Algorithm, could you please talk about what CuckooCycle Algorithm actually achieves and the story behind its birth? Do you still remember the scene when you designed the algorithm in 2014?
John Tromp : Cuckoo Cycle is the first instantly verifiable memory hard PoW. In contrast
with other such PoW that appeared later, such as Equihash and Merkle-TreeProof,it can take much better advantage of Static RAM (SRAM), in particular its ability to access bits completely at random with minimal latency. The SRAM based solver, also known as the *lean* solver, is also conceptually verysimple, as shown on the Cuckoo Cycle github
(https://github.com/tromp/cuckoo/blob/master/doc/simplesolve).
Since ASICs generally have only two types of circuitry, namely logic
and memory (in the form of SRAM), with quite different characteristics,
an ASIC friendly PoW should focus on one or the other, and avoid any
unnecessary complexity.Bitcoin’s SHA256 based PoW is a candidate for the ultimate Proof-of-Logic.One can think of Cuckatoo Cycle as a candidate for the ultimate Proof-of-SRAM.
The story of Cuckoo Cycle started in late 2013, when Dan Larimer (aka bytemaster) proposed the “Momentum” Proof-of-Work, claiming memory hardness, and offering a 30BTC bounty for for a disproof.
(https://bitcointalk.org/index.php?topic=313479.0).
That got me thinking about possible alternatives for memory based PoW. I don’t remember exactly how, but as a Computer Scientist with a background in Algorithms and Data Structures, I somehow made a link to so-called Cuckoo Hashtables, whose behaviour is related to cycles in bipartite graphs, and came up with an initial design.
On the github Cuckoo page at https://github.com/tromp/cuckoo you can find two videos of presentations I made at GrinCon’s explaining Cuckoo’s origins in Hashtables.
On the 2nd last day of that year, I posted on the bitcointalk forum (https://bitcointalk.org/index.php?topic=392128.msg4225174):
“I’m interested in alternatives to bitcoin’s ASIC-friendly proof-of-work (pow).
A memory-hard pow offers two main advantages:
1) reduce energy waste
2) shift the mining balance back from ASIC-farms to desktops,
allowing many more people fair odds in the mining lottery
scrypt was developed with memory-hardness in mind, but turned out only
very mildly successful in that regard.
More recently, Invictus Innovations proposed the Momentum pow with the exact
same goals in mind, but that turns out to allow a memory-time trade-off as
well; see the discussion at
https://bitsharestalk.org/index.php?PHPSESSID=8cf66a1c5dbb5822f255c4a37bb0e8f4&topic=22.60
The ideal pow function would require a certain amount of memory (several GB) with no reasonable memory-time trade-off; in other words it should become grossly inefficient with, say, only half that minimum amount of memory.
Has there been any other research done in this area?
Have any other pow schemes been proposed with memory-hardness in mind?
I have some ideas that I’m considering putting in a whitepaper,
but I’d like to make sure I’m aware of all previously published efforts.
regards,
-John”
In January/February 2014 I announced Cuckoo Cycle with a whitepaper and
implementation in the github repo. Within a few months, David Andersen
identified the edge trimming technique that yields a big memory saving, which was quickly incorporated into the implementation. In January of the next year, the whitepaper was presented at the Bitcoin 2015 workshop. At that conference, I spoke at length with Zooko Wilcox about the possible use of Cuckoo for his upcoming ZCash, but he ultimately prefered a PoW designed by cryptographers. Cuckoo Cycle would have to wait for the arrival of Grin to see adoption.
Q2. CuckooCycle Algorithm has been used to mine Grin, and you are definitely one of the core developers of Grin. We think that there is no need to introduce what the program-Grin is in this Q&A section, but we are still curious about the time when you joined this program and the reason why you joined and has been involved with its development until now. Could you please talk about what and why you think highly of Grin?
John Tromp : I was excited about MimbleWimble from the moment it was first announced in August 2016, showing great elegance in design, and promising improvements in scalability, privacy, and simplicity.
I’ve long been a fan of simplicity, and of stripping away unnecessary complexity. This can be seen in my research on Algorithm Information Theory, in which one considers the smallest possible program that computes a certain output. To make this theory concrete, I designed the simplest possible programming language, called Binary Lambda Calculus. I was even more excited when 2 months later I heard of Ignotus plan’s to implement Mimblewimble with Cuckoo Cycle as its PoW. Not only would Cuckoo Cycle be adopted after so many years, but it would be adopted by the most promising blockchain design! That led me to contact Ignotus and discuss the proper use of Cuckoo Cycle parameters. I found that his preferences in blockchain design matched my own pretty well, so I became eager to contribute where I could. I’m particularly pleased with his embrace of a fixed block reward, as I’ve always thought that a rapid decline in block reward makes for a poor wealth distribution. The choice of Rust as implementation language is also quite forward thinking, with features like strong typing, algebraic data types, memory safety, consistent formatting, and with a rapidly developing library of high quality crates.
I cannot think of a single feature of Grin that I do not like. And before I forget, I should mention that my fellow Grin developers are some of the most skillful, capable, reasonable, and likeable people I’ve ever worked with.
Q3. Last June, Grin Official Forum confirmed that anonymous founder Ignotus Peverell left for personal reasons, which reminded us about the leaving of Nakamoto from Bitcoin and caused some concerns of some supporters in the community. What are the changes happening in the community and Grin you think because of the department of Ignotus Peverell? And how many core developers involved with the code development of Grin currently? Could you please talk about how the program is going and the outcomes that has been achieved up to now?
John Tromp : With the Hard Fork schedule in place at launch, we didn’t expect Ignotus to leave us before seeing it completed. So it came as something as a surprise. Just as with Satoshi’s departure, people initially felt the loss of leadership, and especially among core developers, the loss of a friend we enjoyed having conversations with. It took a while to adjust to the new reality. To not having a single source of guidance and vision, to not have someone who can break an impasse in differing views on how to proceed. But we realize that this is what it means for a coin to be truly decentralized. There should not be a single voice of authority.
On the Grin github repo, there have been code commits by 5 contributors in recent times. The Grin++ repo has 2 active contributors, Ironbelly has 1, and various contributors are coding on support projects, such as the recent Grin Defender Online and IPFS block explorer.
Despite the recent 51% attack, Grin price has somewhat recovered and I see community sentiment increasing accordingly. Seeing exchanges starting to adopt Slatepacks at last is a big confidence boost, as is the excellent progress made on mobile clients.
Q4. Next January, Grin will do its last Hard Fork, when it has already completed its Hard Forks three times before. Could you please explain what functions have been completed and what changes have been brought to Grin because of the four Hard Forks separately? And please introduce Grin’s growth route within the last two years.
John Tromp : The coming Hard Fork in mid January 2021 is not Grin’s last one, but it is the last of the 4 pre-planned ones that were already scheduled before launch.
True ASIC resistance requires a two-pronged approach. The first is to frustrate ASIC design, by either memory use, or complexity, or some combination of both. The second is make frequent, unpredictable tweaks, that will brick any operating ASICs before they could achieve ROI. Before Grin, all so-called ASIC resistant PoW failed in the latter respect (Scrypt, X11, Cryptonight, Equihash, ethash, X16R to name but a few).
- Cuckaroo29 -> Cuckarood29 (from undirected cycle in bipartite graph to directed cycle in bipartite graph)
- Node API change
- new bulletproof rewind scheme
- Wallet API change V1 -> V2
- Slate change V0,V1 -> V2
- Fix critical vulnerability in txhashset zip file https://forum.grin.mw/t/critical-vulnerability-in-grin-1-0-1-and-older-fixed-in-1-0-2)
https://forum.grin.mw/t/grin-v3-0-0-hard-fork-upgrade-jan-2020
https://forum.grin.mw/t/grin-grin-wallet-3-0-0-released
- Cuckaroo29d deprecated for Cuckarood29m (directed cycle in monopartite graph)
- Node API change
- Commit to spent bitmap (fixes critical vulnerability https://forum.grin.mw/t/medium-severity-vulnerability-sucessfully-patched-in-grin-v3-0-0-public-disclosure-of-cve-2020-6638/6969)
https://forum.grin.mw/t/grin-grin-wallet-4-0-0-beta-1-released
- Cuckaroo29m deprecated for Cuckarood29z (undirected cycle in monopartite graph)
- Node API change
- Fixes critical vulnerability in Cuckaroom node bits setting https://forum.grin.mw/t/critical-pow-vulnerability-closed-the-accidental-birth-of-a-new-pow
https://forum.grin.mw/t/grin-v5-0-0-network-upgrade-hard-fork-4-january-2021
- Cuckaroo29z deprecated, no more secondary PoW
- change fee calculation, limit to 40 bits, add 16 priority levels
- change Difficulty Adjustment Algorithm to wtema-240
- add support for Parallel Initial Bytes Download
- no critical vulnerability fix that I’m aware of:-)
I’m not sure what you mean by Grin’s growth route within the last two years.
Q5. What will be focused on next technically? In your opinion, what will happen to Grin in the coming year? And how much power will the birth of ASIC chips inject into Grin?
John Tromp : To start with the latter, generating 1.4gps with only 100W represents a nearly four-fold increase in mining efficieny, so we can look forward to seeing much higher graph rates. The resulting loss in profitability for GPUs has an obvious downside in making Grin mining less accessible. But at the same time it makes the rental of graphpower much harder, as Grin ASIC owners will be much less inclined to rent out their graphpower than GPU owners. So the less profitable GPUs are for Grin, the better Grin will be able to resist 51% attacks, which is crucial for long term security. Together with the fixed reward of 1 Grin per second forever this will make Grin one of the most secure PoW coins not depending on huge fees.
There will likely be another Hard Fork in the years to come, for instance to enable NRD Kernels on mainnet, and to replace BulletProof by the more space-efficient BulletProof+.
In 2021, Grin can also look forward to many improvement that do not require a Hard Fork, as exemplified by the existing RFCs
https://github.com/mimblewimble/grin-rfcs/pulls.
These include payment proofs for both transaction flows, safe transaction cancellation, payjoin support, and full PIBD. A two step transaction flow would also be greatly welcomed, but whether this is possible with the existing Schnorr signatures, or less ideally, with a different signature scheme, is an open question.
Beyond that, we hope to work on transaction aggregation services, so that users have the option to send transactions to a daily or hourly aggregation server to trade-off confirmation speed for unlinkability.
If we ever achieve enough transaction volume and hourly aggregation to surpass Monero in unlinkability, then the future will be very bright indeed.
