A trustless, general-purpose Polkadot <> Ethereum bridge

Snowfork is building a Polkadot <> Ethereum bridge!

Aug 27, 2020

Snowfork is happy to announce that we will be building a bridge between Polkadot and Ethereum. We're working closely with developers and researchers from the Web3 Foundation to build what fits the ecosystem best. We’re excited to start sharing our progress and results with the Polkadot community over the coming months!

What/Who is Snowfork?

Snowfork is an agency consisting of a collection of developers, designers and product managers that have collaborated on many projects together over the last few years. We’ve done research and development across a wide range of technologies, stacks and industries, and blockchain + peer to peer technologies has been a strong focus of ours.

The team working on the Polkadot bridge has extensive experience in blockchain interoperability, having worked on interoperability projects in other ecosystems like Cosmos and Ethereum previously. We believe that interoperability is a core problem that needs to be solved across the industry, as essentially, interoperability contains a microcosm of all the problems that are still to be solved in the blockchain space - scaling, user experience and custodianship problems and solutions all come down to some kind of interoperability and distribution of trust across different components.

We’re excited to become part of the Polkadot ecosystem and build atop its fancy new parachain technology, helping improve interoperability within and across its ecosystem, with new tools that can be used to solve some of the above problems.

We have an initial minimalist website setup, so check it out if you want to know more: http://snowbridge.snowfork.com/

What do we mean by a trustless, general-purpose bridge?

Trustless

First, let’s talk about the concept of being trustless: In the blockchain space, most applications are driven by or augmented with financial use cases. This means that end users are giving up some control over their finances to whatever system they use. By giving up this control, they trust that the systems they use will protect their funds and stick to the expectations they have about how the system functions.

We define a trustless system as a system in which the end user does not need to trust any participants or group of participants in the system in order to maintain protection of their funds and expectations of functionality. They only need to trust the protocols, mathematics, cryptography, code and economics.

This can be achieved in various ways. The important thing here is for safety of user funds and expectations to be preserved, irrespective of the participants in the system.

100% trustlessness cannot always be guaranteed - there always needs to be some set of basic assumptions that must be taken on, (eg: like assuming that an EMP wont hit the earth and wipe out all digital data) so we aim to cater to a set of assumptions that will be mostly uncontroversial and acceptable by the community. We’ll be detailing these in upcoming posts.

General-Purpose

Next, what do we mean by general-purpose? Well, in the interoperability and bridge space, the default thing that comes to mind for most people and projects is the transfer of tokens from one blockchain to another. Most bridges tackle this piece of functionality first and design with it in mind.

However, interoperability is about more than just token transfers. Other kinds of assets, like non-fungible tokens, loan contracts, option/future contracts and generalized, type agnostic asset transfers across chains would be valuable functionality.

Beyond just asset transfer, blockchain systems are essentially databases that contain state with some state transition business logic, and so being able to read/write arbitrary state across multiple databases/chains is also valuable.

With the term general-purpose, our goal is to build a bridge that can facilitate transfer of arbitrary state across chains through arbitrary messages that are not tied to any particular application. We plan to have a bridge that any application can plug into and use, irrespective of whether that application’s functionality is around asset transfer/control, or otherwise.

Putting the two together

When targeting both trustless and general-purpose functionality, certain challenges emerge. Many conventional bridge designs and protocols use trust-minimizing techniques that only work for basic token/asset transfer.

We’re hoping to build not just a single bridge, but a set of components that can be combined and configured to meet the trust-minimization and generality-level needs of the application that decides to integrate with them, finding the right place in the space of trade-offs of different solutions.

Timeline

Our project started a few weeks ago and is broken down into 3 phases:

Phase 1: Abstractions, Modularity and Proof of Concept
In Phase 1 we’re implementing our modular, layered architecture and building out the abstract interfaces and components that will facilitate our goals. We’re also building a MVP bridge that fulfills these interface designs and has working, demoable general-purpose functionality and abstractions for verification that can clearly and cleanly evolve from a more trusted proof of concept into production-grade trustlessness.
Phase 2: Reading Ethereum State Trustlessly from Polkadot
In Phase 2, we’re implementing components in Substrate that will allow us to read state from Ethereum in a trustless way. We’ll be building a SVP-like light client that runs within a Substrate module that can verify transactions from any Ethereum smart contract and so effectively allows any user to submit a message to Substrate which results in it reading state directly and trustlessly from Ethereum.
Phase 3: Reading Polkadot State Trustlessly from Ethereum
In Phase 3, we’re implementing components that will allow Ethereum to read state trustlessly from Polkadot. This becomes a little more complex, as there are compute/gas cost challenges in doing this. We have two potential plans for this. First is to build a BABE/Grandpa light client within Ethereum, effectively giving Ethereum the same capability to read from Polkadot as the above reverse in Phase 2. The second is to build an insurance/collateralization system on Polkadot that will cover user losses in the event of system compromise. Essentially, this means that although the base layer bridge protocol remains vulnerable and semi-trusted, users will have a fully trustless insurance contract that pays them out in the event of an attack. Thus at an end-user/application level, user safety is still fully protected and our requirement for trustlessness is fulfilled.

Phase 1 is ongoing and expected to be completed mid-September 2020.

Phase 2 is expected to be completed early November.

Phase 3 is expected to be completed in Feb/March 2021.

Keep up to date

Snowfork is excited to be working on the above goals and is committed to delivering the project to the community. We’ll be sharing more details in the coming weeks as we progress.

If you’re a potential customer/user of the bridge, please reach out to us so that we can incorporate feedback and try to meet your requirements! You can contact us via email and we have a Riot chat room setup.

Snowbridge Website: http://snowbridge.snowfork.com/
Snowfork Website: http://www.snowfork.com/
Contact: polkaeth@snowfork.com
Riot/Element Chat: Snowbridge