Klaytn
How it works
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.
struct BlockHeader {
bytes parentHash;
address reward;
bytes stateRoot;
bytes transactionsRoot;
bytes receiptsRoot;
bytes logsBloom;
uint256 blockScore;
uint256 number;
uint256 gasUsed;
uint256 timestamp;
uint256 timestampFoS;
bytes extraData;
bytes governanceData;
bytes voteData;
uint256 baseFee;
}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.
updateBlockHeader take a few steps
1.check that the first committed block is the next epoch block.
Verify the submitted block header.
validate the field of the block
verify the signature of the block
Check if the
CommitSealis a valid signature and if the quantity requirements are met.Verify that miner is duplicate
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.
Proof Data
Last updated
Was this helpful?