Skip to content

Latest commit

 

History

History
69 lines (42 loc) · 6.87 KB

getting-started.md

File metadata and controls

69 lines (42 loc) · 6.87 KB
description
Everything you need to know to get started building on Boba Network

Getting Started

Basics

Welcome to Boba. Boba is a compute-focused L2. We believe that L2s can play a unique role in augmenting the base compute capabilities of the Ethereum ecosystem. You can learn more about Turing hybrid compute here. Boba is built on the Optimistic Rollup developed by Optimism. Aside from its main focus, augmenting compute, Boba differs from Optimism by:

  • providing additional cross-chain messaging such as a message-relayer-fast
  • using different gas pricing logic
  • providing a swap-based system for rapid L2->L1 exits (without the 7 day delay)
  • providing a community fraud-detector that allows transactions to be independently verified by anyone
  • interacting with L2 ETH using the normal ETH methods (msg.value, send eth_sendTransaction, and provider.getBalance(address) rather than as WETH
  • being organized as a DAO
  • native NFT bridging
  • automatically relaying classical 7-day exit messages to L1 for you, rather than this being a separate step

Documentation

Developer-focused documentation lives in this folder and within the service and contract sub-directories.

Deploying standard contracts

For most contracts, the deploy experience is exactly like deploying on Ethereum. You will need to have some ETH (or Rinkeby ETH) on Boba and you will have to change your RPC endpoint to either https://mainnet.boba.network or https://rinkeby.boba.network. That's it!

The Mainnet blockexplorer and the Rinkeby blockexplorer are similar to Etherscan. The Mainnet gateway and the Rinkeby gateway allow you to see your balances and bridge funds, among many other functions.

Example contracts ready to deploy

  1. Turing Monsters NFTs with on-chain svg and using the Turing random number generator
  2. Truffle ERC20 A basic ERC20 deployment using Truffle
  3. Bitcoin Price Feeds A smart contract that pulls price data from a connecrcial off-chain endpoint
  4. Stableswap using off-chain compute A smart contract using an off-chain compute endpoint to solve the stableswap quadratic using floating point math

Boba-feature: Using Turing Hybrid Compute

Turing is a system for interacting with the outside world from within solidity smart contracts. All data returned from external APIs, such as random numbers and real-time financial data, are deposited into a public data-storage contract on Ethereum Mainnet. This extra data allows replicas, verifiers, and fraud-detectors to reproduce and validate the Boba L2 blockchain, block by block.

Turing Getting Started - NFTs

Turing Getting Started - External API

Boba-feature: Obtaining on-chain price data

Price Feed oracles are an essential part of Boba, which allow smart contracts to work with external data and open the path to many more use cases. Currently Boba has several options to get real world price data directly into your contracts - each different in the way they operate to procure data for smart contracts to consume. This list will be updated frequently:

  1. Boba-Straw
  2. Witnet
  3. Turing

Full Price Feed documentation

Boba-feature: Bridging NFTs from L2 to L1

NFTs can be minted on Boba and can also be exported to Ethereum, if desired. The minting process is identical to Ethereum. The Boba-specific interchain NFT bridging system and contracts are documented here.

Running a Boba rpc node (replica)

The boba-node repo runs a local replica of the Boba L2geth, which is useful for generating analytics for blockexplorers. A Boba node can also relay transactions to the sequencer.

Running a Community verifier and fraud detector

The fraud-detector repo runs a Verfier geth and a fraud-detector service on your computer. In Verifier mode, the geth will sync from L1 and use the transaction data from the L1 contracts to compute what the state roots should be, if the operator is honest. A separate service, the fraud-detector, can then be used to discover potential fraud. Fraud detection consists of requesting a state root from Boba and requesting a state root from your Verifier. If those state roots match, then the operator has been honest. If they do not match, then, that might be due to fraud, or, could also indicate indexing errors, timestamp errors, or chain configuration errors. The central idea is that if two (or more) geths injects the same transactions, then they should write the same blocks with the same state roots. If they don't, then there is a problem somewhere. Fundamentally, the security of rollups has little to do with math or cryptography - rather, security arises from the operator publicly depositing transactions and their corresponding state roots, and then having many independent nodes check those data for possible discrepancies.

Helping to Develop Boba

If you would like to help develop Boba, it is straightforward to run the entire system locally, with just a few commands. Note: this is only relevant to developers who wish to develop Boba core services. For most test uses, it's simpler to use the live testnet.