Diode’s CTO Dominic Letz published a paper recently to give an introduction of BlockQuick, a super light client protocol for blockchain validation on constrained devices. One of the key concepts behind the newly proposed BlockQuick is that it plans to adopt a consensus-based reputation scheme to accept blocks. This article explores how blockchain synchronization of Internet-of-Things (IoT) devices can be achieved through BlockQuick consensus reputation table, as well as sheds some light on the current development of the project.
What is BlockQuick?
Developed by the Diode team, BlockQuick is the first super light client protocol for Ethereum that addresses the issue of man-in-the-middle (MITM) attacks and eclipse attacks. It is capable of preventing attacks because it doesn’t depend solely on choosing the longest chain with the highest difficulty on the Proof-of-Work (PoW) network when validating a block. Instead, it validates a block based on the so-called Consensus Reputation Table.
BlockQuick super light client protocol is designed for anyone who hopes to connect IoT devices to public blockchains. For resource-constrained hardware and low-end chips for IoT products such as ESP32, TI CC3220, LinkIt 7697, the biggest challenge is how do we synchronize the blockchain without running out of disk storage. For us, adopting BlockQuick’s consensus reputation table is the answer.
Unlike the current full sync, fast sync, or light sync requirements (i.e. a full sync typically requires more than 200GB of disk storage), through BlockQuick the device only needs a handshake size of 20KB to establish the most recent block hash. The design enables a client to sync up to a recent block with a consensus reputation table.
What is Consensus Reputation Table?
Consensus reputation table is a key security policy which BlockQuick adopts when validating a block. The consensus reputation table is constructed on each client based on the last known block headers in a given time frame. For instance, in a Proof-of-Work (PoW) system the client will be able to construct the consensus reputation table by reading 100 previous block headers from the last known state of the blockchain. All past block headers of the blockchain can be validated on the client using the parent block checksum alone. Thus, clients are able to fetch these block headers from untrusted nodes as the data can be validated using the existing block header and its contained parent block hash.
How is the Consensus Reputation Table created?
A client is able to create consensus reputation table based on the last 100 block headers validated. Clients will be able to cache a list of most reputable miners together with the most recent known good block for a quick update mechanism. BlockQuick is not controlling the reputation itself; the reputation is autonomously calculated and based on the number of blocks generated by each miner. The reputation scores are objectively based on the actual mining power.
Each miner will be represented in the consensus reputation table with 2 items: the Ethereum address (20 bytes); and the consensus share (1 byte). The table below illustrates what the BlockQuick consensus reputation table may look like.
BlockQuick Consensus Reputation Table Example
The proposed light client protocol establishes a reputation system on the mining nodes in the network. The reputation of each mining node corresponds directly to the percentage of blocks that each mining node contributed compared to all mining nodes in a given time frame. The time frame is the consensus group’s history length (i.e. the last 100 blocks as illustrated in the paper).
The BlockQuick consensus reputation table is not designed to keep the whole history of the blockchain. Instead, the consensus reputation table is generated based on the last 100 block headers. Block headers are much smaller than the whole block to store. The BlockQuick reputation check only requires 100 of block headers means that even very small devices such as IoT devices will be able to store and process them.
What is consensus share?
It’s the percentage of the total computational power during the last 100 blocks time frame that will be stored for each miner in the consensus reputation table. For instance, in a PoW consensus system, a miner who mined and signed 10% of the 100 recent blocks thereby having 10% of the total computational power during that time frame. In this case, the consensus share for this miner is 10%. The table below illustrates what it looks like with source data from the Etherscan website.
Consensus Reputation Table based on the data from the Etherscan website
So, what happens when an IoT device wants to validate a new block? The device will validate the cryptographic signature of the miners, and then it will compare these signatures with the known miner identities in the already established consensus reputation table. The new block would only be accepted by the client if the block receives a consensus share score of >50%; the client would turn down a chain if the total consensus share score is lower than 50%.
Consensus Reputation Table in pie chart format based on the data from the Etherscan website
With BlockQuick, the client will look at how the devices iterate the blocks and will run a slow update mechanism. So, instead of complying with the longest chain rule, BlockQuick will be running a reputation check in order to ensure that the client is accepting only the blocks with >50% reputation scores.
As blockchain technologies continue to evolve, being knowledgeable in current and possible future developments are critical to your success as a leader. Diode is here to keep you updated to the increasingly complex cryptography and blockchain technologies. So stay connected! Follow us on Twitter and our website. Stay up-to-date and subscribe to our newsletter.