KlaytnLightClient is the implementation of a Klaytn light client on the Mapo Relay Chain.
Klaytn achieves fast finality by adopting and improving Istanbul BFT. Because validation and consensus are done for each block there is no fork and the block's finality is guaranteed instantly as soon as the consensus is made.
And also the issue of increasing communication volume in the BFT algorithm is solved by utilizing randomly selected Committee. CNs collectively form a Council and on each block generation, part of them are selected as a member of Committee using a VRF (Verifiable Random Function).
In the Klaytn network, all validators and CommitSeal are included in the extraData field of the block header,the length of CommitSeal should be larger than number of faulty node + 1,These validators participate in the consensus protocol by signing blocks that contain cryptographic signatures signed by each validator's private key.
If we want to validate a transaction, we need to validate the block header that the transaction is in,to validate a block header and we need to validate the signature of the block header.
by tracking validators changes light node can verify all klaytn transations.
How to verify
updateBlockHeader
Ensure that the light client validators are updated by continuously providing block headers. In the Klaytn chain, validators can join or exit at any time. Assuming an epoch consists of 3600 blocks, for each epoch, block headers submitted must be verified by validators from the previous epoch using their private keys.
Similarly, when changes occur to the validators, the voteData field in the block header will be updated accordingly. The light client will not strictly adhere to epochs but will promptly submit records of changed block headers and updated validators to maintain the authenticity of the verification process.
function isRepeat(
address[] memory _miners,
address _miner,
uint256 _limit)
external
pure
returns (bool)
{
for (uint256 i = 0; i < _limit; i++) {
if (_miners[i] == _miner) {
return true;
}
}
return false;
}
verify receipt
Due to the unique characteristics of the Klaytn chain, it upgraded to the DeriveShaOriginal mode after block number 128822400. This mode is currently the prevalent transaction receipt proof verification mode.
The light client can verify the epoch blocks after it has the epoch validatorSet.to verify the receipt should first veriy the block transation receipt in.verify the block is similar to the update block,won't go into it again.
we know that receipts from block transactions form a receipt patricia-merkle-trie. the block field receiptsRoot is the root of the tree. after we verify the block we can trust the receiptsRoot.
so we can build proof of the transation receipt off chain submit to light client to proof transaton receipts.