Inter-blockchain communication

COFFE Multichain was created with the idea of facilitating communication between blockchains. This is achieved by simplifying the proof of the existence of Action and the proof of the sequence of Actions. This evidence, combined with the application architecture designed for transmitting Actions, allows you to hide the details of inter-blockchain communication and verification of validity from application developers.

Signature of transactions of corresponding networks

The main technical problem of inter-blockchain communications is the centralization of transaction confirmation in blockchains with a single key. The solution to the problem is to create four transaction confirmation servers and a signature server. The private key is divided into four parts and distributed among the confirmation servers.

Each part is delivered to the signature server in a form encrypted with the public key of the signature server, the key is collected at the time of signing in a protected memory area, after which it is destroyed. Thus, the signature server does not store keys.

Creating keys for corresponding networks

The keys of the corresponding networks are created by the signature server in accordance with the protocols of the corresponding blockchain. The key is divided into 4 parts in the protected memory area and transferred to the signature servers after which all key data is destroyed.

Merkle Proof for Light Client Verification (LCV)

The purpose of LCV is to allow the generation of relatively lightweight proofs of existence that can be verified by anyone who tracks a relatively lightweight dataset. In this case, the goal is to prove that a certain transaction was included in a certain block and that the block is included in the verified history of a certain blockchain.

Bitcoin supports transaction confirmation assuming that all nodes have access to the full history of block headers which is 4 MB of headers per year. With 10 transactions per second, a valid proof requires about 512 bytes. This works well on a blockchain with a 10-minute interval between blocks but it is no longer "easy" for blockchains with a 3-second interval.

COFFE Multichain allows anyone who has any irreversible block header after the point where the transaction was enabled to use lightweight proofs. Using the hash-linked structure shown below, it is possible to prove the existence of any transaction with a proof that takes less than 1024 bytes. If it is assumed that the verifying nodes were running simultaneously with all the block headers for the entire last day (2 MB of data), then only a 200-byte proof will be required to confirm these transactions.

There is a minor additional burden associated with the production of blocks with proper hash references required for the specified proofs which means that there is no reason not to create blocks in this way.

When it comes time to test the proofs on other chains, many time/space/bandwidth optimizations can be applied. Tracking all block headers (420 MB per year) will keep the size of the evidence small. Tracking only the latest headers can offer a compromise between the minimum long-term storage and the proof size. Similarly, the blockchain can use a lazy approach to evaluation where it memorizes intermediate hashes of past proofs. New proofs should contain only references to the known to the sparse tree. More precisely, the approach used will necessarily depend on the percentage of other blocks that include transactions referenced by Merkle proof.

After a certain density of relationships, it becomes more efficient to simply have one chain containing the entire block history of another chain and completely eliminate the need for proof. For performance reasons, it would be ideal to minimize the frequency of inter-blockchain proofs.

Communication delay between blockchains

When there is communication with another blockchain, block producers must wait until there is 100% confidence that this transaction has been irreversibly confirmed by another blockchain before accepting it as valid input data. When using COFFE Multichain and the DPOS algorithm with 3-second blocks and 21 producers, this will take about 45 seconds. If the producers of the blockchain blocks do not wait for irreversibility, it is as if the stock exchange accepted a deposit that was subsequently canceled which could affect the validity of the blockchain consensus.

Proof of integrity

When Merkle proofs from other blockchains are used, there is a significant difference between knowing that all processed transactions are valid and knowing that no transactions were rejected or skipped. And if there is no possibility to prove that all the latest transactions are known, then it can be proved that there were no gaps in the transaction history. COFFE Multichain facilitates this process by assigning a sequence number to each Action delivered to each account. The user can use these sequence numbers to prove that all Actions intended for a particular account were processed and that they were processed in order.

Still need help? Get in touch!
Last updated on 31st Dec 2021