EOS.IO software is designed to promote inter-block link communication. This is achieved by generating action existence proof and action sequence proof. The combination of these proofs and the application architecture designed around Action transmission instructions allows application developers to hide the details of the communication between blockchains and confirm the proofs, thereby presenting them to developers in a highly abstract manner.
9.1 Light Client Verification (LCV) Merkle Proof
If the customer does not need to process all transactions, it will be easier to integrate with other blockchains. After all, the exchange only cares about the import and export of transactions. If the exchange can use a lightweight certificate of deposit instead of completely trusting its own block producer, this would be an ideal choice. If the exchange can effectively use the lightweight certificate of deposit without completely trusting its own block producer, this would be an ideal choice. At least, a blockchain producer wants to maintain the lowest possible cost when synchronizing with another blockchain.
The goal of LCV is to be able to generate relatively light evidence of existence, and anyone can track a lightweight data set for verification. In this case, the goal is to prove that a particular transaction is included in a specific block and that block is included in the verified history of a specific blockchain.
Bitcoin supports transaction verification by assuming that all nodes have the ability to read the complete record of block header data, and the block header grows by 4MB every year. Assuming 10 transactions per second, a valid proof requires approximately 512 bytes. This is feasible for a blockchain with a block time of 10 minutes, but it is no longer "light" for a blockchain with a block interval of 0.5 seconds.
EOS.IO software provides a lightweight proof for anyone who has any irreversible block headers after including transaction processing. Using the displayed hash link structure, the existence of any transaction can be proved, and the proof is less than 1024 bytes.
In the blockchain, each blockchain has an ID, and the header is set as a credible irreversible block. It is possible to prove that the block is included in the blockchain. The proof uses ceil(log2(N)) to extract its path, where N is the number of blocks in the chain. The specified SHA256 digest method can prove the existence of all 100 million blocks contained in 864 bytes.
When it is necessary to verify evidence on other chains, various time/space/bandwidth optimizations can be performed. Tracking all blocks (420 MB/year) will keep the proof small. Tracking only recent titles can be a compromise between minimal long-term storage and proof size. In addition, the blockchain can use a slow evaluation method to memorize the intermediate hash value of past proofs. The new proof only needs to include links to known sparse trees. The exact method used will necessarily depend on the percentage of external blocks containing transactions that reference merkle proofs.
After a certain density of interconnection, it becomes more efficient to have only one chain containing the entire block history of the other chain and not need to provide all samples. For performance reasons, the ideal approach is to minimize the frequency of inter-chain evidence.