EOS whitepaper walk-through: Inter-blockchain communication.

bluabaleno (55)in #eos • 7 years ago (edited)

Read the Whitepaper here

Inter Blockchain Communication

EOS.IO software is designed to facilitate inter-blockchain communication. This is achieved by making it easy to generate proof of Action existence and proof of Action sequence. These proofs combined with an application architecture designed around Action passing enables the details of inter-blockchain communication and proof validation to be hidden from application developers, enabling high level abstractions to be presented to developers.

The EOS.IO software was designed for multiple, and varied implementation of blockchain technologies. At the core of blockchain technologies is the idea of immutable histories. Developers building on blockchain technologies have a high level of assurance that the information recorded on these blockchains cannot be modified easily or arbitrarily. This means that they can build applications that depend on one or more state of different blockchains.

This process of extracting information from other blockchains requires developers have some method of validating the information they have extracted.

Merkle Proofs for Light Client Validation (LCV)

Integrating with other blockchains is much easier if clients do not need to process all transactions. After all, an exchange only cares about transfers in and out of the exchange and nothing more. It would also be ideal if the exchange chain could utilize lightweight merkle proofs of deposit rather than having to trust its own block producers entirely. At the very least a chain's block producers would like to maintain the smallest possible overhead when synchronizing with another blockchain.

Merkle Proofs allow for the validation of the current state from a few pieces of transaction history rather than the entire blockchain history itself.

It is the heart of any kind of scaling solution as it allows nodes and client to have only a partial part of the entire blockchain data yet with guarantee that by validating that data they'll arrive at the state of the blockchain.

Block producer can use Merkle Proofs to validated that blocks coming in are valid instead of validating it by replaying the entire history of the blockchain. In the case where block producers gets disconnected from the network, he can quickly get his node up to date again.

Application developers can select a subset of data, the set that is of interest to him, and use Merkle proof to validate its integrity, which is this case is its presence in a validated block in a blockchain.

The goal of LCV is to enable the generation of relatively light-weight proof of existence that can be validated by anyone tracking a relatively light-weight data set. In this case the objective is to prove that a particular transaction was included in a particular block and that the block is included in the verified history of a particular blockchain.

Light Client Verification is great for mobile application that might not have the computation power necessary to perform multiple, full block verification.

Bitcoin supports validation of transactions assuming all nodes have access to the full history of block headers which amounts to 4MB of block headers per year. At 10 transactions per second, a valid proof requires about 512 bytes. This works well for a blockchain with a 10 minute block interval, but is no longer "light" for blockchains with a 0.5 second block interval.

The EOS.IO software enables lightweight proofs for anyone who has any irreversible block header after the point in which the transaction was included. Using the hash-linked structure shown it is possible to prove the existence of any transaction with a proof less than 1024 bytes in size.

The last irreversible block, again, is a block that has been validated by 15 out of 21 block producers. By using hash-link, or taking the hash of a transaction and then hashing it with the provided hash of the rest of the transactions, you should arrive at the irreversible block's hash header, thereby proving the transaction's existence in the validated block.

Given any block id for a block in the blockchain, and the headers [of] a trusted irreversible block. It is possible to prove that the block is included in the blockchain. This proof takes ceil(log2(N)) digests for its path, where N is the number of blocks in the chain. Given a digest method of SHA256, you can prove the existence of any block in a chain which contains 100 million blocks in 864 bytes.

Not only can you prove the existence of a transaction in a block, you can also prove the existence of a block in a blockchain easily and quickly.

There is little incremental overhead associated with producing blocks with the proper hash-linking to enable these proofs which means there is no reason not to generate blocks this way.

When it comes time to validate proofs on other chains there are a wide variety of time/ space/ bandwidth optimizations that can be made. Tracking all block headers (420 MB/year) will keep proof sizes small. Tracking only recent headers can offer a trade off between minimal long-term storage and proof size. Alternatively, a blockchain can use a lazy evaluation approach where it remembers intermediate hashes of past proofs. New proofs only have to include links to the known sparse tree. The exact approach used will necessarily depend upon the percentage of foreign blocks that include transactions referenced by merkle proof.

When one blockchain wants to stay in tandem with the state of another, it'll need someway to keep track of other blockchains' state. This can be done by keeping track of all block headers, which will produce about 420MB of data per year, or only keeping recent block headers, or keeping track only of recent evaluated proofs and its link to new proofs.

After a certain density of interconnectedness, it becomes more efficient to simply have one chain contain the entire block history of another chain and eliminate the need for proofs all together. For performance reasons, it is ideal to minimize the frequency of inter-chain proofs.

This does not imply that there will ever be one chain that is useful, instead, it is meant to state that if two chains heavily depend on the operation of another, then it is better to run on a single chain.

However, if the network effect applies in the blockchain world as it does on the social world, then it is likely that main chains will converge, taking advantage of the efficient created by sharing resources and lower latency of communication.

Latency of Interchain Communication

When communicating with another outside blockchain, block producers must wait until there is 100% certainty that a transaction has been irreversibly confirmed by the other blockchain before accepting it as a valid input. Using an EOS.IO software-based blockchain and DPOS with 0.5 second blocks and the addition of Byzantine Fault Tolerant irreversibility, this takes approximately 0.5 second. If any chain's block producers do not wait for irreversibility it would be like an exchange crediting a deposit that was later reversed and could impact the validity of the blockchain's consensus. The EOS.IO Software uses both DPOS and aBFT to provide rapid irreversibility.

A key criteria for inter-blockchain communication is that of the irreversible transaction. This is a piece of data that connects the two state of the blockchain. Before blockchains, it is often risky to build on top one another's database because any party can change the database any time, breaking any linkage of data.

In a blockchain world, developers can be sure that the chance of this happening is drastically reduced. Meaning they can have more confident that their application will not be render useless by any one actor in the ecosystem.

What this means is that databases will become more public, more transparent. Because there is great incentive to open and connect them if they want to stay competitive.

Proof of Completeness

When using merkle proofs from outside blockchains, there is a significant difference between knowing that all transactions processed are valid and knowing that no transactions have been skipped or omitted. While it is impossible to prove that all of the most recent transactions are known, it is possible to prove that there have been no gaps in the transaction history. The EOS.IO software facilitates this by assigning a sequence number to every Action delivered to every account. A user can use these sequence numbers to prove that all Actions intended for a particular account have been processed and that they were processed in order.

Interestingly, this akin to the nonce used both in Ethereum and Bitcoin but instead of incrementing a number to generate a new hash, EOS uses this method to keep track of actions done on the account.

Since the action are processed sequentially on each account, they can all be assigned a sequential number. This can be used to ensure the entire history of action done on an account are well, accounted for.

Segregated Witness

The concept of Segregated Witness (SegWit) is that transaction signatures are not relevant after a transaction is immutably included in the blockchain. Once it is immutable the signature data can be pruned and everyone else can still derive the current state. Since signatures represent a large percentage of most transactions, SegWit represents a significant savings in disk usage and syncing time.

Once the computation to validate a signature is done, and the transaction is include in a irreversible block, there is no need to keep the signature data in blockchain. However, even though it is not necessary to keep signature data for replay, I wonder if it is not useful to keep it to see which account trigger the action.

This same concept can apply to merkle proofs used for inter-blockchain communication. Once a proof is accepted and irreversibly logged into the blockchain, the 2KB of sha256 hashes used by the proof are no longer necessary to derive the proper blockchain state. In the case of inter-blockchain communication, this savings is 32x greater than the savings on normal signatures.

Same concept applied to merkle proofs.

Another example of SegWit would be for Steem blog posts. Under this model a post would contain only the sha256(blog content) and the blog content would be in the segregated witness data. The block producer would verify that the content exists and has the given hash, but the blog content would not need to be stored in order to recover the current state from the blockchain log. This enables proof that the content was once known without having to store said content forever.

One can arrive at the state of the application without needing to store the content. The content data should still be stored somewhere else if one wishes to reconstruct it in whole. The content can be verified by generating its hash and see if it matches against the hash recorded in the blockchain.

Useful links:

https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-merkle-tree

https://steemit.com/blockchain/@dantheman/a-better-approach-to-turing-complete-smart-contracts

https://steemit.com/steem/@dantheman/smart-contracts-for-investors--how-to-separate-myth-from-reality

~~------------------------------------------------------------------------------------------------------------------~~

If you would like to know more about me and what I'm doing you can read my introduction post here.

Read my series on the Steem blockchain:

Steem: Welcome to the Matrix. Part One

Steem: Operating in the Matrix. Part Two

Steem: Construction of the Matrix. Part Three

Read my series on the EOS blockchain:

EOS whitepaper walk-through. Abstract