- Welcome to Boba
- Basics
- Documentation
- Deploying standard contracts
- Example contracts ready to deploy
- Boba-feature: Using Turing Hybrid Compute
- Boba-feature: Obtaining on-chain price data
- Boba-feature: Bridging NFTs from L2 to L1
- Running a Boba rpc node (replica)
- Running a Community verifier and fraud detector
- Helping to Develop Boba
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, andprovider.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
Developer-focused documentation lives in this folder and within the service and contract sub-directories.
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.
-
Turing Monsters NFTs with on-chain svg and using the Turing random number generator
-
Truffle ERC20 A basic ERC20 deployment using Truffle
-
Bitcoin Price Feeds A smart contract that pulls price data from a connecrcial off-chain endpoint
-
Stableswap using off-chain compute A smart contract using an off-chain compute endpoint to solve the stableswap quadratic using floating point math
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 - External API
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:
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.
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.
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.
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.