[ad_1]
Litecoin MimbleWimble July Update.
With the crypto markets finally breaking out above the 3 year downtrend, confidence is returning to the space and to cryptocurrency as a technology. With that said, we have also taken another leap towards the launch of MimbleWimble on the Litecoin Network, so let’s jump into what’s new and without further ado let David Burkett, the projects lead developer share his progress:
The focus this month was on the Initial Block Download. Before I can detail the progress made, I need to give some background info for those not intimately familiar with mimblewimble.
The biggest innovation behind mimblewimble is that, in order to verify the chain, you just need to know all of the unspent coins/outputs, and a small part of each transaction called the “Kernel.” These 2 things together are called the “chain state.”
In bitcoin/litecoin, each block header uses a merkle tree to commit to only the transactions in that block. Since we don’t want to require everyone to download all old mimblewimble blocks, or to know about all old, spent outputs, we use a different structure to commit to the transactions. Each mimblewimble header commits to the root of 2 different Merkle Mountain Ranges(MMRs). One represents all historical kernels up to that block, and the other represents all historical outputs/coins. Merkle Mountain Ranges are a different sort of tree that supports “pruning”, which means we can verify the root of the structure without knowing all of its members (called leaves). For an in-depth look at how this works, I recommend reading https://github.com/mimblewimble/grin/blob/master/doc/mmr.md 3
Since old blocks don’t need to be downloaded, Initial State Download (ISD) is a more accurate term for the initial sync process that I worked on this month. To facilitate the ISD I ended up defining the following P2P messages:
-
GETMWSTATE — This simply consists of the hash of a header sometime in the recent past. We’ll call this the “horizon” header. A new node, after syncing most of the canonical (non-mimblewimble) blocks in the chain, sends this message to a single peer, requesting the mimblewimble chain state at the time of that block.
-
MWSTATE — The response to a GETMWSTATE message. This contains the entire chain state, which is everything you need to validate the extension chain up to the point of the horizon. The chain state consists of:
-
kernels — All of the kernels in the chain, in order.
-
utxos — All of the outputs that had not yet been spent at the time of the horizon, including their associated rangeproofs, in order.
-
unspent_bitmap — A compact structure that indicates the MMR leaf indices of the provided utxos.
-
parent_hashes — Some additional metadata that allows you to verify the MMR root without knowing all of the past, spent outputs.
Quick sidenote — This design relies on one peer providing quite a bit of data at once. After launch, it would be ideal to parallelize the sync process using something like https://github.com/jaspervdm/grin-rfcs/blob/pibd/text/0000-parallel_ibd.md 1 or https://github.com/BeamMW/beam/wiki/UTXO-set,-horizons-and-cut-through 1
All of the logic for serializing and deserializing those messages, as well as choosing when to send them has been implemented. I also implemented the logic for verifying the kernel signatures, and the kernel MMR roots.
Unfortunately, I was short on time this month due to a Grin hardfork that ended up requiring an enormous amount of effort to support in Grin++. As a result, I was unable to finish up the logic for validating and processing MWSTATE messages — in particular, the output roots are not yet verified, and I still need to validate that the kernels match up with the pegins and pegouts for each block. Grin++ is now in maintenance mode for the remainder of the year, so this should be the last time it interferes with litecoin progress.
Updated Plan:
The plan was to spend August focusing on reorg logic, but I’m going to delay that until September. Instead, I’m just going to focus on wrapping up the MWSTATE message processing, and focus on cleaning up the code, adding more tests, and maybe even some documentation if I’m feeling really wild. When developing projects this large, things rarely go exactly as planned, so the design changes over time. Having a chance like this to go back through the code and clean things up, re-evaluate decisions made, etc. will really pay off in terms of code quality, hopefully allowing for a smooth first testnet launch at the end of September.
[ad_2]
Source link