BOB: Late Middle Ages

[nud3l]

Abstract

Develop a PoC for the BOB stack that allows:

1. Builders to deploy EVM contracts and use a BTC relay to interact with Bitcoin.
2. Users to bridge between a testnet and the rollup (ETH, ERC20) as well as bridge between Bitcoin (BTC) and the rollup via a mock BTC bridge.

Motivation

The Late Middle Age was a period in Europe preceding the Renaissance. It was characterized by many crisis but saw great progress in the arts and sciences. We chose this name for BOB to reflect the many decisions that will have to be made for the stack and at the same time, the new achievements we will be able to make.

BOB is a large project, and having a PoC will allow us to understand the difficulties in bringing it to the testnet and mainnet readiness.

Goals

Target completion: End of September 2023

• Builders can spin up a local testnet
• Builders can deploy EVM smart contracts on the local testnet
• Builders can interact with a BTC relay (can still be mocked in parts)
• Users can interact with a local testnet via EVM interfaces (wallets, ethers.js) bridging ETH/ERC20s/BTC
• Completed design for a novel Bitcoin bridge
• Alpha-stage documentation for the rollup design and how to build on it

Specification

Deliver a proof of concept implementation of the BOB stack rollup and builder platform.

Organizational

• Create a new GitHub org
• Publish new docs

Research

• Specification for BTC bridge
• Decide which rollup stack to use

Chain

• Spin up OP Stack rollup for testing
• BTC transaction fees: allow users to pay transactions fees in bridged BTC on BOB #15
• Bitcoin onramp: allow users to onboard from Bitcoin to BOB without additional tokens #14

Smart Contracts

Solidity/EVM

• Mock deployment for BTC bridge: supply collateral, mint synthetic BTC, redeem synthetic BTC, swap synthetic BTC with BTC
• Evaluate existing BTC relay options (Interlay, tBTC, ...) according to maturity, cost, features (taproot, segwit, ...)
• Deploy a BTC relay

UI

• Create a new UI repo
• Proof of concept
  • Setup ethers.js for account management and runtime interaction
  • WalletConnect 2.0 or MetaMask wallet integration
  • Transfer ERC20 on rollup

[gregdhill]

We have chosen to use the production ready tBTC-v2 (summa / keep-network) relay contracts and supporting libraries to support the initial development of the BOB stack. The contracts are already well-optimized for gas consumption and have been used on mainnet Ethereum for quite some time.

A specific advantage of using the Simple Payment Verification (SPV) "Light Relay" developed for tBTC is that we do not need to store all block headers from the genesis / initialization height. It uses stateless SPV proofs and provides some recency guarantee using Bitcoin's difficulty adjustment based on the latest retarget.

How does it work?

• The light relay is initialized to the beginning of a difficulty period (epoch)
• A "maintainer" submits proofLength block headers before and after the retarget
• The relay validates the chain and updates the expected difficulty for blocks in that epoch
• A user can then submit a transaction proof in that or the last period
  • Requires header chain of at least txProofDifficultyFactor

Notes

There was only one issue highlighted in the Least Authority audit related to the SPV client which was also identified in the interBTC (Substrate / Polkadot) code here. We can solve this issue by checking the coinbase proof as was implemented there. Since BOB will be deployed as a rollup we can make some tradeoffs with regard to gas consumption.

Alternatives

interlay/btc-relay-solidity

This is a Bitcoin chain relay we (Interlay) built a few years ago. It makes use of the summa libraries and provides additional tooling for alternate script types. The relay itself is a "full" SPV client which requires us to validate and store all blocks. It is not gas efficient and contains several notable bugs including reorging the chain based on the height alone - not considering work accumulated. We made the same mistake in the interBTC (Substrate / Polkadot) code here.

ethereum/btcrelay

The "official" Ethereum BTC Relay which has mostly been abandoned by this point. The code has not been updated in several years and the deployment is also unmaintained. It was built using serpent an assembly language with high-level features that compiles to EVM code - the tooling is also not maintained.

Resources

• https://github.com/keep-network/tbtc-v2/blob/9a24b10bb10d8314e6648f2ae75cebac5bb1c13d/solidity/contracts/relay/LightRelay.sol
• https://github.com/keep-network/bitcoin-spv/tree/a6f0a09c79a3c5d48abf3496b4fc65d155a0d9fe/solidity/contracts
• https://etherscan.io/address/0x836cdFE63fe2d63f8Bdb69b96f6097F36635896E
• https://leastauthority.com/static/publications/LeastAuthority_KeepNetwork_tBTC_Bridge_v2_Updated_Final_Audit_Report.pdf
• https://github.com/summa-tx/relays/tree/master/solidity
• https://github.com/makerdao/btc-market

[nud3l]

@gregdhill as a follow up, can you create a new issue on deploying the BTC relay and figuring out our open questions? Then we can close this issue.