gregdhill
commented
1 year ago 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
proofLengthblock 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
- Requires header chain of at least
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
Abstract
Develop a PoC for the BOB stack that allows:
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
Specification
Deliver a proof of concept implementation of the BOB stack rollup and builder platform.
Organizational
Research
Chain
Smart Contracts
Solidity/EVM
UI