[Antioch] Status Update (Apr-Jun 2020)

Announcements
2

Apr 12, 2020

“No Recent Duplicate” (NRD) Kernel RFC

tl;dr A proposal for a minimal implementation of “relative timelocks” via Grin/MW transaction kernels.

RFC is currently in an informal review period.
Assuming there is sufficient interest in taking this further, the next step will be to nudge someone to volunteer to “shepherd” this through two weeks of formal review.

Related to this is some experimental work on the “kernel index” that will be necessary for verification of NRD kernels.

header_head db index

tl;dr We experimented with using the header MMR directly in v3.0.0 to track the “head” of the header chain (by definition the latest entry in the MMR).
But this introduced some undesirable behavior that surfaced with the universally hated ERROR: failed to obtain lock for try_header_head error messages in the log file.
We have reverted these changes and gone back to simply storing the head of the header chain in the local db (lmdb).
The cost of needing to maintain this additional db index is offset by the simplicity of dealing with this transactionally.

Write node “checkpoint” to disk

This is still in review and not yet merged.

tl;dr When processing a block we update the local db and various files on disk (MMRs etc.)
It is possible to cause data corruption if these files are partially rewritten for any reason (power failure etc.)
This PR adds “checkpoint” functionality to allow the node to robustly restart from a “last known good” position.
Bonus feature: The checkpoint file contains a block header hash (hex format) and can be used to restart the node at an arbitrary recent block if you are brave enough.

cat chain_data/grin.checkpoint 
0000018ceb445195d65c6a5a86d3fd2918bf4059605f668ef3c72d56dbaba6de

Unknown Kernels

Some early thoughts around how to make our “kernel features” softfork friendly.
Still very much in early stages of thinking through what this would involve.

With the NRD Kernel RFC moving into review we should have a better idea of whether this is a worthwhile thing for me to continue focusing on.
I suspect we do have enough interest and that it would be beneficial to continue working toward getting this done for v4.0.0 (the next scheduled HF).

Alongside this I am planning to iterate on the “kernel pos” index work (https://github.com/mimblewimble/grin/pull/3273) to validate this approach makes sense.

The proposed NRD kernel variant got me thinking a bit more about what a more softwork friendly “unknown” kernel variant would look like.
I am planning on spending a bit more time playing around with this.

6 Likes