substraTEE-bridge proposal

[brenzi]

Grant Application

This application is (select one):

• Speculative (use this by default)
• an RFP response

This application is (select one):

• Public (fully)
• Public with private finances

Abstract

Chain interoperability is considered one of the more pressing challenges for blockchain technology. With substraTEE, we've built a tool that is well suited to solve trusted chain bridges, because the integrity of code execution is guaranteed by a TEE. We suggest to build a generic bridge between the Ethereum Ropsten chain and a substrate chain.

This bridge will allow to:

• transfer ETH to a pegged token on substrate and back (PolkaETH).
• transfer ERC-20 token on Ethereum to a pegged token on substrate and back (PolkaXYZ).
• transfer any on-chain information between Ethereum and substrate.
• transfer any token on Polkadot to an Ethereum ERC20 token.

substraTEE-bridge will build light clients of both chains where block headers are stored in SGX sealed storage and transaction inclusion proofs are verified in Intel SGX enclaves. Backed value will be in custody of a set of TEEs. Correct execution is guaranteed by TEEs (Intel SGX).

In contrast to an approach like XClaim, substraTEE-bridge provides the following advantages:

• No full collateral needed. XClaim needs vaults (or banks) to lock collateral to the amount of backed value transferred through the bridge in order to punish misbehaving vaults. Because of the opportunity cost of locked capital, this would lead to higher fees for using such a bridge. In substraTEE-bridge, SGX guarantees for integrity of computation. Therefore there is no need for full collateralization.
• No relay-contract with on-chain registry of block headers needed. Block headers are stored in the enclave's sealed storage. Less onchain storage is needed on the issuing chain.
• Less transactions needed as there is no need for a collateralized issue commitment.

Checklist

• The grants document has been read and understood.
• The Google Form will be completed accurately. Note that the Google Form requires the pull request URL.
• Abstract (above) is succinct and complete.
• The application is being included into the correct directory: either 'targeted' or 'speculative'.
• The application includes a project description.
• The application includes all names of team members.
• The application includes a description of the team's experience.
• The application includes all necessary links (e.g. GitHub and LinkedIn)
• The "Development Roadmap" section in the application has a timeline of development ("milestones").
• The "Development Roadmap" section in the application has an estimate of funds required.
• The "Development Roadmap" section gives an indication of the team's long term plans.
• The "Development Roadmap" section includes documentation as a deliverable for at least one milestone.

[brenzi]

As I'll be on vacation until Aug 19th, I will leave discussions to @electronix during my absence