Grin Coin Code Review: A Fresh Slice Of Mimblewimble
Share this article
Grin Coin is a community-based project that launched with no “funny business”. It’s natively private, lightweight, resistant to ASIC mining, and it has made a big impact on the crypto sector despite the ongoing bear market. It’s based on Mimblewimble.
“Grin empowers anyone to transact or save modern money without the fear of external control or oppression. Grin is designed for the decades to come, not just tomorrow. “
No big promises, no big statements, clean value proposition. Off to a good start.
“Grin has no amounts and no addresses. Transactions can be trivially aggregated. To hide where a newly created transaction comes from, it gets relayed privately (a “random walk”) among peers before it is publicly announced.”
“MimbleWimble leverages cryptography to allow most of the past transaction data to be removed.”
I’ve covered MimbleWimble a few times before in other released reviews, so I won’t go into it to much, if you need a refresher you can look at my Beam review or my state compacting article.
1,856 commits, 109 contributors. I’ll repeat 109 contributors. That is a testament to open source work, no ICO, no expensive developers (and yes, blockchain developers are insanely expensive, just adding the word blockchain to their CV and they up their salary by 300%… that’s a rant for a different day, let’s dig in)
Rust development language. Normally I would skip the boiler plate, API/RPC/Crypto, but in this case I think it speaks a lot towards the overall project, since the value here isn’t how they do the “unicorn” stuff, but instead how they do the basics.
Great encapsulation, looking at the code shows equally fantastic abstraction;
Concise, well named and descriptive functions.
When functions aren’t self descriptive they add hefty comments;
Very neat and concise code. I’m going to run through the rest of the boilerplate, but so far it confirms my suspicions, this is a great code base to work off of.
/config/ is good
/util/ is good
/storage/ is good
A quick note on development. As a developer you often start out with a requirement, and your first code is beautiful, if fits that requirement perfectly, it’s well designed, architecture is solid, just the right balance between abstraction and ease of readability. Then come the scope changes, and additional requirements, and deadlines, and very quickly that once beautiful work of art changes to a horrible mess of spaghetti code.
All clearly defined projects start out beautiful.
This is a wonderful example of that, the specification was clear, what they wanted to achieve was clear, and the code is beautiful. Will it still be this beautiful in a year from now after scope creep? How will this wonderful code base accommodate changes? I don’t know, I’m excited to see though.
Wonderful documentation just as an fyi, great place for anyone to start that wants to know more about Grin.
Enough of the boilerplate, time for core and chain.
We want create_pow_context, and find_cycles()
I really don’t have much comment on the above, it’s exactly what they state it is. So… good job.
Short hashes for compacted blocks. Didn’t even read about that. Cool idea.
A freakishly simple, but beautiful implementation of compacting.
block.outputs — get all outputs in the block — filter out |x| x.is_coinbase() — cloned — collect.
Cut through compacting.
Grin Code Review Conclusion
Rangeproofs, cut through, Pedersen commitments. This is exactly what it set out to be, a secure (pow), private (rangeproofs), compactable (cut through) distributed solution built completely open source.
What I’ll add, it was built with passion, dedication, and love. The builders should be proud, it is a work of art. Simple, yet elegant. Concise, yet descriptive. Great implementation of a great idea.
You can chat about Grin Coin in our Telegram group.
Disclaimer: Crypto Briefing code reviews are performed by auditing what is on display in the master branch of the repo’s made available. This was performed as an educational review and any comments in the article are the opinion of the writer. It is normal for code to change rapidly, hence we timestamp our code reviews so that they present a snapshot at a moment in time. Information contained herein should not be used as any comment or advice on the project as a whole.
Grin Code Review Timestamp: January 30th 2019
Share this article
