Litecoin MimbleWimble July Update.

https://litecoin.com/en/news/litecoin-mimblewimble-july-update

Franklyn Richards
3.8.2020

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.

마침내 암호화 시장이 3년 만에 붕괴되면서, 자신감이 우주로 돌아왔고 기술로서의 암호화된 상태로 돌아가고 있다. 그렇기 때문에 우리는 LitecoinNetwork에서 MimbleWimble출시를 향한 또 다른 도약을 했습니다. 이제 새로운 것에 대해 이야기해 보도록 하겠습니다. DavidBurkett, 이 프로젝트를 이끄는 개발자가 진행 과정을 공유하도록 하겠습니다.
이번 달에는 초기 블록 다운로드에 초점을 맞추었습니다. 진행 상황을 자세히 설명하기 전에, 저는 mimblewimble에 익숙하지 않은 사람들을 위해 약간의 배경 정보를 제공할 필요가 있습니다.

mimblewimble이면에 있는 가장 큰 혁신은 체인을 확인하기 위해서는 단지 모든 unspentcoins/outputs와 "Kernel"이라고 불리는 각 거래의 작은 부분을 알 필요가 있다는 것이다. 이 두가지가 합쳐져서"체인 상태"라고 불립니다.

bitcoin//litecoin에서 각 블록 헤더는 Merkle트리를 사용하여 해당 블록의 트랜잭션만 커밋 합니다. 우리는 모든 사람이 오래 된 mimblemble블록을 다운로드하거나, 오래 되고 사용된 모든 출력물을 알도록 요구하고 싶지 않기 때문에, 우리는 거래에 다른 구조를 사용한다. 각 Mimblewimble헤더는 2개의 서로 다른 MMR(MerkleMountainRanges)의 루트를 커밋 합니다. 하나는 해당 블록까지의 모든 기록 커널을 나타내고 다른 하나는 모든 기록 결과/결과를 나타냅니다. MerkleMountainRanges는 "가지 치기"를 지원하는 다른 종류의 나무입니다, 그것은 우리가 모든 구성원들을 알지 못하고 구조의 뿌리를 확인할 수 있다는 것을 의미합니다. 어떻게 작동하는지에 대한 자세한 내용은 https://github.com/mimblewimble/grin/blob/master/doc/mmr.md를 참조하십시오. 3

이전 블록은 다운로드할 필요가 없으므로, 초기 상태 다운로드(ISD)는 이번 달에 작업한 초기 동기화 프로세스에 대한 보다 정확한 용어입니다. ISD를 용이하게 하기 위해 나는 다음과 같은 P2P메시지를 정의하게 되었다.

GETMWSTATE-최근에 발생한 헤더의 해시로 구성됩니다. 우리는 이것을 "수평선"헤더라고 부를 것이다. 체인에 있는 대부분의 표준(비mblewimble)블록을 동기화한 후 새 노드가 이 메시지를 단일 피어로 보내 해당 블록의 시간에 mimblewimble체인 상태를 요청합니다.

MWSTATE:GETMWState메시지에 대한 응답입니다. 여기에는 전체 체인 상태가 포함되어 있으며, 이는 수평선의 점까지 확장 체인의 유효성을 확인하는 데 필요한 모든 것입니다. 체인 상태는 다음으로 구성됩니다.

커널—체인에 있는 모든 커널을 순서대로 지정합니다.

분류 법—수평선 상의 시간에 아직 사용되지 않은 모든 결과들, 연관된 범위/루프들을 포함하여 순서대로 나열됩니다.

unspent_bitmap—제공된 분류의 MMR리프 인덱스를 나타내는 간단한 구조입니다.

parent/esshess—과거의 사용된 출력을 모두 알지 못한 상태에서 MMR루트를 확인할 수 있는 추가 메타 데이터입니다.

빠른 사이드 노트-이 디자인은 한번에 상당히 많은 데이터를 제공하는 하나의 피어에 의존합니다. 실행 후 https://github.com/jaspervdm/grin-rfcs/blob/pibd/text/0000-parallel_ibd.md 1또는 https://github.com/BeamMW/beam/wiki/UTXO-set,-horizons-and-cut-through 1과 같은 기능을 사용하여 동기화 프로세스를 병렬로 조정하는 것이 좋습니다.

메시지를 언제 보낼지 선택할 뿐만 아니라 메시지를 직렬화하고 직렬화하는 모든 논리가 구현되었습니다. 또한 커널 서명과 커널 MMR루트를 확인하는 논리를 구현했다.

불행하게도, 이번 달에 그린++에서 지원하기 위해 엄청난 노력이 필요한 그라인 하드 작업으로 인해 시간이 부족했다. 결과적으로 MWSTATE메시지의 유효성을 확인하고 처리하는 논리를 마칠 수 없었습니다. 특히 출력 루트가 아직 확인되지 않았으며 커널이 각 블록의 pegin및 pegout과 일치하는지 확인해야 합니다. 그린++는 남은 한해 동안 유지 보수 모드에 있으므로, 리테이콘 진행을 방해하는 마지막 시간이 될 것입니다.

업데이트된 계획:

계획은 8월에 구조 조정 논리에 초점을 맞추어 보내는 것이었지만, 나는 9월까지 그것을 연기할 것이다. 대신, MWSTATE/STATE메시지 처리를 마무리하는 데 초점을 맞추고, 코드 정리, 테스트 추가, 심지어 문서화 작업에 집중할 것입니다. 만약 제가 정말 거칠게 느낀다면 말이죠. 이렇게 큰 프로젝트를 개발할 때는 계획한 대로 진행되는 경우가 드물기 때문에 시간이 지남에 따라 설계가 변경됩니다. 이와 같은 기회를 갖고 코드를 다시 검토하고 문제를 해결하고 결정 사항을 재평가하는 것은 9월 말에 순조로운 첫 시험 발사를 가능하게 해 줄 것이다.

!