The Major Protocol Upgrade brings many new improvements to the Layer 1 protocol of Nervos Network. One of them is the Extensible Block Header. The main promise of this feature is to enable solutions like Flyclient in the future. In this article we’ll dive deeper into how this feature sets Nervos up to benefit from Flyclient.
Flyclient Overview
Flyclient is a form of a light-client. CKB Layer 1 light-client in practice means that you can run a CKB node on your phone, or other hardware which has less computing power than machines typically used to run Layer 1 nodes. This is all working without sacrificing security and maintaining trustless mode of communication and validation.
The Flyclient concept has been already introduced to the CKB community in greater detail by Matt Quinn in his “Introduction to super-light clients: FlyClient” article.
The reason why Flyclient implementation in the Nervos Network needs additional block storage field on Layer 1 and therefore “Extensible Block Header” is following:
“At every block height i, the prover appends the hash of the previous block, Bi−1, to the most recent MMR [Merkle Mountain Range] and records the new MMR root, Mi, in the header of Bi. As a result, each MMR root stored at every block height can be seen as a commitment to the entire blockchain”
The verifier (Flyclient) can then request relatively small number blocks from the prover (Layer 1 full node) and check their block headers (MMR root hashes) combined with Merkle proof paths to verify that all the synchronized blocks from the full node belong to the same valid blockchain.
The MMR (Merkle Mountain Range) required for FlyClient has been implemented in the block header of Beam, Grin and is proposed for Zcash and Ethereum Classic.
For more in-depth technical explanation please read Matt Quinn’s article “Introduction to super-light clients: FlyClient”.
Contributing to this improvement through RFCs
The Extensible Block Header improvement has been proposed as part of the RFC31 in July, 2021 by Ian Yang from Nervos Foundation. Feedback was gathered here. It has been implemented in CKB mainnet in May, 2022.
RFC document and the implementation lay the foundation for future softfork adding Flyclient. It also enables other experiments – such as Proof of Authority on testnet.
Zooming in, RFC31 permits adding arbitrary field to the block. Property named “extension” will be added to the block body and in block header there will be a hash of the extension field value. The extra hash in block header (“extra_hash”) will replace “uncles_hash”.
The field “extension” can be of varying size – which means it can be used by multiple future solutions. For now the only limit on the “extension” field is that it can contain up to 96 bytes. The Flyclient rules for validation of the field must be added as part of another RFC and solution-specific softfork. Keep an eye on upcoming RFCs :eyes:
If you would like to learn more technical details about the implementation of RFC31, you should consider reading the “Specification” section of the document itself.
Closing
This Flyclient upgrade preparation will lay the foundation for a faster yet still secure Layer 1 nodes and bridges to other networks. The synchronization of the Flyclient should be faster than current synchronization times. Finally blockchain data used for syncing will also take less space on disk therefore enabling more devices to run nodes! All these benefits roll up to provide an even better experience for both developers and users alike.