Ion Stage 2: Validation of External Chain Block (Part 2)
This is the second post in our series on Ion our Interoperability project being developed here at Clearmatics. Remember to look out for updates on Github and read our other posts here!
Ion Interoperability framework
In our first blog post we introduced the Ion Interoperability framework, explaining the relationship between the three components of the framework:
- Ion block store hub
- Block validation module
- Continuous execution contracts
This article goes into detail about the validation module, describing the assumptions and rationale behind the modular design, a description of a specific implementation for Clique Proof-of-Authority, and lastly detailing the roadmap of developments for the validation module.
Block Validation — Why and How?
Finality is especially important for Clearmatics as we are envisioning the future of financial market infrastructure where finality of transactions, and the constituent blocks, is critical. Finality is extremely important to the processing of financial transactions as if state transitions can be rolled back it becomes possible to double spend our money or receive a good for free — which is very bad!
Therefore, Clearmatics is focussed on developing Interoperability for protocols with deterministic finality, such as Clique PoA and IBFT. Though this is not to say that Ion is not interoperable with probabilistic finality protocols, on the contrary! The modular validation allows Ion to receive blocks from any chain — however the implementation of the module would vary greatly.
Within the context of Ion, block validation has a specific definition:
“Given two blockchains A and B which are interoperating, blocks submitted to A are only valid if they are actually included in blockchain B.”
If we can verify that a block is included in an external blockchain, then functions on the local blockchain, on which we are operating, can make assertions against the external state and execute accordingly.
Prior to making assertions of the state of externally submitted blocks, the blocks need to be validated. As previously mentioned a block is valid if it is included in the blockchain from which it hails. However, it is not enough to say it is included in the chain, but rather that is included with finality.
Validation For Ion Stage 2
As Clearmatics is working with deterministic finality protocols the validation module implementations described are centered around Clique and IBFT — concentrating on Clique for sake of simplicity. However, as part of the roadmap we aim to utilise the Casper FFG when it is implemented for the Ethereum mainnet, which will add a finality layer to PoW, and should work with the same principles as Clique and IBFT.
Common between all deterministic finality protocols proposed is that they contain a known set of validators, akin to miners, who are able to mine/seal blocks. Though the details of how each protocol achieves consensus and governs the validator set differs, through knowledge of the validator set blocks can be validated. This verification of validators occurs through recovery of single or multiple signatures. Thus the underlying consensus, the external blockchain, can leveraged to allow interoperation.
Let’s Talk About Clique
The most simple implementation of a deterministic finality protocol is Clique Proof-of-Authority. Clique uses a validator set who can propose new blocks. Validators go in and out of scope depending on when they last proposed a block, but when a validator is in scope they have the right to declare new blocks. For blocks to be included the validator needs to prove that it was indeed them, an esteemed validator, who proposed this block. To do this they create the block with all 15 fields, RLP encode it and then sign this RLP encoded block using their private key. The signed RLP block produces a 65 byte array which is then appended to the extra data field of the original block. Validators then broadcast the new “signed” block to their fellow validators, who verify that the block they received was indeed proposed by a known validator.
Thus we see that if a block is taken from an external blockchain, that uses Clique as the consensus, we can verify that the block was indeed created by an authorised validator from that chain. However, two questions arise:
- How do we know who the authorised validators are?
- How can we verify that the validator is not just creating arbitrary block?
Validator Governance
When recovering the validators signature from a submitted block we must first have an up-to-date list of the validators of the chain we are interoperating with. The initial validator set is included in the genesis block of the Clique chain, thus when we deploy a Clique validation module the RLP encoded genesis.json is passed in the constructor. The initial validator set can then be extracted and the intial blockhash derived for blocks to build upon.
Simple right?
Unfortunately not, Clique allows validators to be added and removed dynamically. Luckily validators can vote to add or remove an address once per block. This is done by placing an address in the coinbase field of the block, thus as each block is submitted to the validation module the votes can be tallied and the active validator set tracked correctly.
Block Provenance
Despite being able to verify that an authorised validator signed a proposed block, it is not sufficient to assure validity of that block. The secondary condition is that all blocks must be submitted sequentially and build on top of the previous block. Whilst this does not prevent a validator from submitting an incorrect block, the round robin nature of the Clique validator set means that subsequent valid blocks would and could not build on top of this block. Thus we see that submission of invalid blocks would create a small fork which would be disregarded as more blocks were submitted.
Indeed this issue disappears for IBFT where blocks are only valid if a supermajority of validators append their signature into the extradata field. However is should be noted that the validation module cannot give any stronger assurances of a block than the consensus protocol on which it is built.
Modular Design
As described in our previous article, the Ion interoperability framework block validation is designed to be a separate module to the Ion block storage hub. Whilst this isn’t necessary specifically to perform interoperation between blockchains, having a modular design has a number of advantanges.
Each validation module should be self-contained exposing only the final valid blocks to the Ion block storage contract. However, how a validation module is implemented is completely open, giving developers and users the power to decide what a valid block is for their requirements. Validation does not need to be limited to the consensus based approach used in the aforementioned Clique example but could use second layer mechanisms.
Clique, IBFT What Next?
So as written above it is possible to perform validation of external blocks on-chain with relative certainty that the blocks submitted are included on the blockchain with which you are interoperating. For an IBFT chain it would be extremely difficult to compromise the private keys of enough validators to successfully submit an invalid block.
However as part of Clearmatics’ vision of a distributed Financial Market Infrastructure we see economic incentives playing a key part in this. Therefore we are particularly interested in the adoption of Proof-of-Stake with Casper the Friendly Finality Gadget giving finality.
Conclusion
Validation of blocks forms the backbone of the Ion interoperability framework. Without block validation, continuous execution, to be discussed in a later article, would not be possible. Hopefully readers now understand how a validation module to be developed for a number of use cases and how the modularity allows multiple implementations to be developed allowing users to choose the appropriate validation for their requirements.
In future articles we will describe how the Ion block storage hub is designed and also how to write continuous execution contracts! In the meantime please let us know your thoughts and contribute on Github or any other channels!
Please stay tuned for more information on our Medium publication and in the meantime please take the time to review Ion Stage 2 on Github and let us know your thoughts!
Friedrich Grabner, Blockchain Engineer, Clearmatics
Chris Chung, Blockchain Engineer, Clearmatics
Duarte Aragão, Senior Blockchain Engineer, Clearmatics
Tweet us @Clearmatics
