So just what is a ‘blockchain relay’ anyway? Is it essential? How does it work? What would happen if it stopped working? Why trust it? Is it ‘centralized’ or ‘decentralized’? This blog post is an attempt to answer these nagging questions and more.
Relaying info from one chain to another
There is information on Bitcoin, and there is information on Ethereum. Neither of these chains knows anything about the other unless you send information from one chain to the other. For separate chains to receive information about one another, they need to use relays. Relays are smart contracts that exist on the Ethereum blockchain. Their purpose is to relay information between separate “member” blockchains (e.g., Bitcoin and Ethereum.) Relays track parts of the “state” (a technical term for data) of their connected chains in order to help prove the existence of transactions from one chain to another. In addition, relays can be granted partial control over assets present on connected chains.
Any deeper explanation of relays first requires an explanation of SPV proofs (“Simple Payment Verification proof”) Merkle Roots, and The Difficulty Change, since all of these factor into the functionality of the relay.
SPV proofs explained
Here is a list of 8 numbers:
32962
48981
11326
17191
22129
18909
49568
3032
What if one wanted to store information about this list in such a manner that, at a later time, someone could prove that they had a number that was originally in the list? There is a naive, if straightforward, way to approach this: stick the whole list into storage. Later, when someone provides their number, the verifier can check the number against the entirety of the list. If the number is there, it is verified. If it isn’t, the verification fails. This method requires that the verifier provide and perform a great deal of computation, as well as a great deal of storage (at scale) and therefore, eventually, foot a rather large bill in terms of cost.
An alternative approach is to put the burden on the individual attempting to prove their number was part of the original list. One method of doing so is to pair up each of the numbers and then "hash" them (hash functions are important tools in programming because they turn an arbitrary amount of data into a deterministic value of a fixed size), like so:
The first round of pairing would look like this:
hash("32962+48981") = "08836"
hash("11326+17191") = "12de5"
hash("22129+18909") = "3f79b"
hash("49568+3032") = "2e34c"
This process is repeated until there is just 1 number. The second round would be:
hash("08836+12de5") = "799ea"
hash("3f79b+2e34c") = "8de9b"
And the final round compresses into a single 5-digit value:
hash("799ea+8de9b") = "80e51"
What is taking place here can be thought of as similar to a sports tournament bracket: one transaction is “played against” another transaction. Then the winning transaction produces a hash, which is then played against another hash, which then creates another hash, etc. - until this process finally produces the root (called a "Merkle root" after its inventor, Ralph C. Merkle - no relation to the German prime minister).
If the roots match and the tournament bracket included the transaction that the person making the claim said was part of the block, then this proves the transaction was in fact part of the block; otherwise it wouldn’t have created the same final root that the block had. Therefore, one can prove that a block has a transaction even though the only thing that was ever recorded was a single, compact hash.
Putting the onus on the prover rather than the verifier is ideal because Bitcoin is already recording all of these transactions. It’s far easier to simply ask Bitcoin “what’s the tournament bracket?” when it comes time to prove that a transaction occurred to Ethereum.
So in short, an SPV proof is what proves that a transaction is included in a block, thus minimizing storage, computation - and most importantly, cost - as all that needs to be copied and sent over to the other blockchain is the single Merkle root.
Publishing the Merkle root to Ethereum
Each Bitcoin block has a Merkle root for all of that block’s transactions. The relay publishes the Merkle root to Ethereum. To prove that a transaction is part of a block, applications like tBTC can then use these Merkle roots to perform an SPV proof.
This likely sparks a couple more questions: How frequently do Bitcoin blocks need to be published? What specific information from the block needs to be published? This brings us to the concept of the ‘Difficulty Change’.
The Difficulty Change
Bitcoin has a feature called the “Difficulty Change”, which is how the network keeps average block time to approximately 10 minutes. If blocks are being mined more quickly, the algorithm adjusts the difficulty to push the time closer to 10 minutes (conversely, if blocks are taking longer). The ‘difficulty’ here refers to the measure of how hard it is to find a hash below a given target. In other words, the difficulty is related to the necessary proof of work.
Valid blocks need to prove that they have a hash below this given target. If a difficulty number does not match what the chain has decreed, then the block will not be verified. The numerical difficulty of this target changes every 2,016 blocks.
The first Bitcoin to Ethereum relay was BTC Relay, developed by ConsenSys in 2016. Cosmos and Polkadot are projects that provide two-way interoperability between chains by creating a ‘relay chain’ that serves as a light client for the chains it connects, the main difference being that the latter is more complex, as validators are responsible for the validity and availability of member chain blocks.
In a follow-up blog post we will cover the history and functionality of the relay deployed in tBTC, the trust-minimized Bitcoin-to-Ethereum bridge that allows people to deposit and redeem BTC for participation in decentralized finance (DeFi) without intermediaries.
