The Technicals of Interoperability—Introducing the Ethereum Peg Zone

Cross-blockchain crypto-asset transfer is core of what we do at Cosmos. Within the ecosystem, crypto-assets are transferred via the IBC protocol, an Inter-Blockchain Communication protocol, which facilitates interoperability. Notably, IBC only works if both the starting and the destination chains have settlement finality.

Fortunately or unfortunately, neither Bitcoin nor Ethereum have finality guarantees; rather, they have probabilistic finality. [Edit: for now Ethereum doesn’t benefit from the property of finality; until, that is, Casper the Friendly Finality Gadget (FFG) is implemented in the near-term future.] What this means is, the deeper down the chain a block is, the less likely the chain it’s on will get reorganized, giving you a high level of confidence that the block is “final”. But because probabilistic guarantees do not protect against reorgs, transferring assets securely across chains via IBC is impossible. This prompts the question: How can Cosmos zones interoperate with pre-existing blockchains absent finality?

Peg Zones

Peg zones are our solution. A peg zone is an account-based blockchain which bridges zones within Cosmos to external chains like Bitcoin or Ethereum. It acts as an adaptor zone — or a “finality gadget”, in Casper-speak — which translates finality for probabilistically finalized blockchains by imposing a “finality threshold” at some arbitrary number of blocks to achieve pseudo-finality. Generally, this “translator” zone design can be classified as a 2-way peg (2WP).

Consensus engines such as Tendermint Core offer settlement finality. To better understand how it works, please read more about Tendermint Consensus.

Connecting to Ethereum

An Ethereum peg zone is the first of its kind that we will be implementing in Cosmos. This is very different from Ethermint, which is the EVM, stripped of Proof-of-Work mining, then layered on top of Tendermint’s consensus and networking protocol stacks. The Ethereum peg zone will enable the movement of ERC20 tokens and Ether between the canonical Ethereum chain and all IBC-connected zones within the Cosmos Network.

The specifications for the peg zone are still being ironed out but you can follow the progress in the peg zone repository, codenamed peggy, linked below.

• Cosmos GitHub: (Peggy)

Peggy

In Cosmos, interoperability is easy because we can use the IBC protocol to transfer any crypto-asset. To transfer crypto-assets between Cosmos and Ethereum, however, is very technically complex because IBC packets cannot be efficiently decoded in Ethereum, simply because the EVM isn’t designed to be IBC-compatible. That is, until we implement Peggy.

Peggy had a rough start. The first construction that attempted to connect Cosmos to Ethereum was a hackathon project called ETGate, which turned out to be a gas guzzler. It was designed by Joon, the HackAtom 2 grand prize winner, who we ended up hiring to implement what is now Peggy.

ETGate initially was a direct bridge between the Cosmos Hub and Ethereum which attempted to translate compatibility within the EVM itself. Like so:

[ Ethereum ] <- ETGate -> [ Cosmos Hub ]

This design was highly impractical when confronted with the problem of the different building blocks used in Tendermint and Ethereum. Every primitive used in Tendermint is fundamentally different than that of Ethereum’s. Translating those incompatibilities into compatible, interpretable building blocks inside the EVM, it turns out, is incredibly gas costly.

Here’s the breakdown of those building blocks:

• Serialization formats. Tendermint’s encoding method to serialize objects is go-wire. Ethereum serializes objects using RLP (Recursive Length Prefix).
• Signature schemes. Tendermint uses ed25519 whereas Ethereum uses secp256k1.
• Data structures. Tendermint stores key-values in IAVL+ trees while Ethereum stores them in Patricia Tries.

ETGate’s design was computationally expensive because it decoded IBC packets within the EVM, of which the contents were Tendermint’s headers, transactions, IAVL+ tree proofs, and ed25519 signatures.

The moment of clarity that led to the evolution of Peggy came from the realization that we could save significant amounts of gas by taking the translation mechanism out of the EVM and onto its own blockchain designed for this specific application.

Peggy’s 5 Components:

1. Ethereum Smart Contracts: There will be a set of Ethereum smart contracts acting as asset custodians, capable of taking custody of Ethereum native tokens and issuing Cosmos native tokens.
2. Witness: The witness component attests witness to events in Ethereum. It waits for 100 blocks, the finality threshold, and implements this pseudo-finality over the non-finality chain. It runs a fully validating Ethereum node in order to attest to state changes within Ethereum by submitting a WitnessTX to the peg zone. We use a shared security model here by taking the set of Cosmos Hub validators also to be peg zone Witnesses.
3. Peg zone: The peg zone is a translator blockchain, built on Tendermint, that allows users to perform and query transactions. This is how Cosmos communicates with Ethereum.
4. Signer: The signer signs messages using the secp256k1 signature scheme which Ethereum understands to make signatures efficiently verifiable by smart contracts. The signer component generates secp256k1 signatures via the SignTx message and posts it to the peg zone for relaying transactions for validation in the smart contract down the pipeline.
5. Relayer: The relayer component relays a batched list (array) of transactions—signed by the Signer component—and posts them to the Ethereum smart contract.

Tying it All Together

Real World Example: Moving a Cosmos native token→Ethereum

Let’s say, for example, you want to move some quantity of Photons out of Cosmos and convert them to Ether of equal value on Ethereum. How would this work using Peggy? For simplicity’s sake, we’ll gloss over the low-level technical details and just describe the high-level flow.

1. You start at the Cosmos Hub. You move Photons via IBC to the peg zone. The peg zone receives an incoming IBC packet: a message containing a transaction for sending Photons. Signers monitoring the peg zone then sign those IBC transactions, effectively converting the signature scheme to Ethereum-understandable private keys, in secp256k1 format. Your transaction has just been signed on the peg zone.
2. Relayers watching the peg zone are waiting until they see that +2/3 signers have signed the transaction before batching your signed transaction into a list of all the other transactions sent through IBC. They then relay the signature-appended list to the EVM where the Ethereum smart contract lives.
3. The Ethereum smart contract now checks that the list of transactions are valid. For your Photons, the smart contract needs to generate an ERC20 version of it. After the smart contract generates ERC20 Photons, it then sends the ERC20 Photons to your destination address in Ethereum.
4. At this point, converting your ERC20 Photons to ETH is as simple as using an ERC20 decentralized exchange (DEX) like the 0x protocol or OmiseGO.

In Closing

We are currently prototyping a very early-stage Peggy design. The Ethereum smart contract component is already written and is currently being tested. In many ways, Peggy is even more technically complex than the Cosmos Hub itself and will take several iterations before we get it right. Cosmonauts can expect Peggy to go live sometime mid to late summer, well after mainnet launch. We understand that a lot is at stake and the need for scalability solutions, increased throughput, and decreased gas costs is important for Ethereum-based projects. Therefore, the deployment of Peggy is high priority and the Cosmos/Tendermint team has devoted a significant portion of its resources to its development in tandem with the rest of our ecosystem projects.

Ongoing Work

Ethereum smart contracts, once deployed, are immutable and therefore very difficult to update. There is a lack of organizational structure around governing smart contract upgrades. The development roadmap for Peggy compels us to confront this uncertainty but it’s an an area of research we hope will spawn concrete solutions.

[March 7, 2018 Edit]

Regarding security. The Signer component will be the same shared set of Cosmos Validators securing the Cosmos Hub, so what we have is an accountable peg zone with the same safety guarantees as the hub itself. For a double spend attack to occur while a transaction is in flight between the Ethereum main chain and the peg zone, there must be >2/3 of the voting power taken from hostile validators.

Regarding reorgs on the Ethereum main chain. In the event that a reorg occurs on the Ethereum chain past the finality threshold on the peg zone, we defer to governance for recovery.