bobanetwork/boba_legacy

Monorepo implementing Boba, a compute layer for Ethereum

description
Introduction to Boba Network

Welcome to Boba

This is the primary place where Boba works on the Boba L2, a compute-focused L2. Fundamentally, Ethereum is a distributed computer. 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 it focus on 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

User focused documentation is available on the Boba docs website. Developer-focused documentation lives in ./boba_documentation and within the service and contract directories. If you have questions or feel like something is missing check out our Discord server where we are actively responding, or open an issue in the GitHub repo for this site.

Direct Support

Telegram for Developers
Project Telegram
Discord

Directory Structure

Base Layer (generally similar to Optimistic Ethereum)

• packages: Contains all the typescript packages and contracts
  • contracts: Solidity smart contracts implementing the OVM
  • core-utils: Low-level utilities and encoding packages
  • common-ts: Common tools for TypeScript code that runs in Node
  • data-transport-layer: Event indexer, allowing the l2geth node to access L1 data
  • batch-submitter: Daemon for submitting L2 transaction and state root batches to L1
  • message-relayer: Service for relaying L2 messages to L1
  • replica-healthcheck: Service to monitor the health of different replica deployments
• l2geth: Fork of go-ethereum v1.9.10 implementing the OVM.
• integration-tests: Integration tests between a L1 testnet and the l2geth
• ops: Contains Dockerfiles for containerizing each service involved in the protocol, as well as a docker-compose file for bringing up local testnets easily

Boba Layer

• packages/boba/turing: System for hybrid compute
• boba_community: Code for running your own Boba node/replica and the fraud detector
• boba_documentation: Boba-specific documentation
• boba_examples: Basic examples of deploying contracts on Boba
• boba_utilities: A stress-tester for discovering bugs under load
• ops_boba: Parts of the Boba back-end, including the api-watcher service
• packages/boba: Contains all the Boba typescript packages and contracts
  • contracts: Solidity smart contracts implementing the fast bridges, the DAO, etc.
  • gas-price-oracle: A custom gas price oracle
  • gateway: The Boba Web gateway
  • message-relayer-fast: A batch message relayer that can be run for the fast mode without a 7 day delay
  • register: Code for registering addresses in the AddressManager
  • subgraph: Subgraphs for indexing the StandardBridge and LiquidityPool contracts

Contributing

Follow these instructions to set up your local development environment.

Dependencies

You'll need the following:

• Git
• NodeJS
• Yarn
• Docker
• Docker Compose

Note: this is only relevant to developers who wish to work on Boba core services. For most test uses, e.g. deploying your contracts, it's simpler to use https://goerli.boba.network.

Ensure that you have installed and are using nodejs v16.16.0:

$ node --version
v16.16.0

If you have multiple versions of node installed and use nvm, ensure you are using nodejs v16.16.0

$ nvm use

Install nodejs packages with yarn:

$ git clone [email protected]:bobanetwork/boba.git
$ cd boba
$ yarn clean # only needed / will only work if you had it installed previously
$ yarn
$ yarn build

Then, make sure you have Docker installed and make sure Docker is running.

Spinning up the stack

Build and run the entire stack:

$ cd ops
$ BUILD=1 DAEMON=0 ./up_local.sh

Build side services such as aa_deployer and bundler

$ cd ops
$ docker-compose -f docker-compose.yml -f docker-compose-side.yml build bundler aa_deployer

Spinning up the side services

$ cd ops
$ docker-compose -f docker-compose.yml -f docker-compose-side.yml up bundler aa_deployer

Stack spinup can take 15 minutes or more. There are many interdependent services to bring up with two waves of contract deployment and initialization. Recommended settings in docker - 10 CPUs, 30 to 40 GB of memory. You can either inspect the Docker Dashboard>Containers/All>Ops for the progress of the ops_deployer or you can run this script to wait for the sequencer to be fully up:

./scripts/wait-for-sequencer.sh

If the command returns with no log output, the sequencer is up. Once the sequencer is up, you can inspect the Docker Dashboard>Containers/All>Ops for the progress of ops_boba_deployer or you can run the following script to wait for all the Boba contracts (e.g. the fast message relay system) to be deployed and up:

./scripts/wait-for-boba.sh

When the command returns with Pass: Found L2 Liquidity Pool contract address, the entire Boba stack has come up correctly.

Helpful commands

• Running out of space on your Docker, or having other having hard to debug issues? Try running docker system prune -a --volumes and then rebuild the images.
• To (re)build individual base services: docker-compose build -- l2geth
• To (re)build individual Boba ts services: docker-compose build -- builder then docker-compose build -- dtl, for example

Running unit tests

To run unit test coverage for whole stack:

yarn test:coverage

To run unit tests for a specific package:

cd packages/<package-to-test>
yarn test

Running integration tests

Make sure you are in the ops folder and then run

docker-compose run integration_tests

Expect the full test suite with more than 110 tests including load tests to complete in between 30 minutes to two hours depending on your computer hardware.

Viewing docker container logs

By default, the docker-compose up command will show logs from all services, and that can be hard to filter through. In order to view the logs from a specific service, you can run:

docker-compose logs --follow <service name>

License

Code forked from go-ethereum under the name l2geth is licensed under the GNU GPLv3 in accordance with the original license.

All other files within this repository are licensed under the MIT License unless stated otherwise.

boba_legacy's Issues

Self-delegated xBOBA not being counted correctly

Potential bug People with zero BOBA but xBOBA:

(1) self delegate - which seems to work correctly - but then
(2) when they vote, only their zero BOBA is counted, but their self-delegated xBOBA is not counted.

Expected behavior - their vote total is the sum of BOBA and xBOBa.

Based on a first read, the contracts look good, and this is definitely something that was checked in the integrations tests. So something more subtle.

Minor - also noticed that the two key DAO contracts are not verified, which should definitely be done.

[gateway] Gateway testing

omgnetwork/optimism-v2#35

Add a functional test (with CI - gh actions integration) for the gateway:

Perhaps use Robotframework
https://medium.com/@joonasvenlinen/ui-regression-testing-with-robot-framework-part-1-578f2f50b721

Integrate Sentry with Gateway

In order to polish the frontend gateway code we'd like to integrate Sentry (https://sentry.io).

@sk-enya please reach out to me for credentials

[GATEWAY] Zendesk integration

Issue Type

[ ] bug report
[ X] feature request

Current Behavior

At the moment, we don't have a way to get feedback from the users using the Gateway, we'd like to integrate Zendesk and see what the feedback is.

Expected Behavior

Gateway Zendesk integration

Steps to Reproduce

/

Suggested Fix

We already have a development account with Zendesk cc @sk-enya reach out when you need integration details

URL subpages

on gateway: https://gateway.boba.network/
it is currently impossible to link to a subpage, like:

• https://gateway.boba.network/bridge
• https://gateway.boba.network/ecosystem
• https://gateway.boba.network/ecosystem/defi
• https://gateway.boba.network/ecosystem/nft
• https://gateway.boba.network/ecosystem/wallet
• https://gateway.boba.network/ecosystem/tool
• https://gateway.boba.network/ecosystem/token
• https://gateway.boba.network/wallet
• https://gateway.boba.network/history
• https://gateway.boba.network/earn
• https://gateway.boba.network/stake
• https://gateway.boba.network/dao

this would give us way better SEO and it's easier to navigate!

Bug - Staking 5% Error Message

Hi, MUI here...

I ran into some problems during staking on the fixed 5% page. Main problem is, after you fill out the amount you want to stake, you will get a metamask "permission" transaction. After you complete/pay this transaction, an error will occur: "Internal JSON-RPC error". The error does nothing, because the permission transaction is still approved succesfully. The annoying thing is, you have to manually fill out the amount again after the "Internal JSON-RPC error" and hit "stake" again. Now a second metamask pops-up with the completion of the staking. So the staking still works, but the UX is butchered by the error.

As far as I can remember, in the past you just had to fill out the amount to stake > hit the stake button > approve permission transaction > approve the second transaction > staked!

Now there is an error that forces the user to fill out the staked amount again.

[Multi-chain] Merge `alt-l1` branch to develop branch

Discussion

Things have to be done for merging alt-l1 branch to develop branch

l2geth

• [need to check] The new token price logic might not be compatible with the geth client for Ethereum L2

contracts

• [change] The function names for multi chain contracts are different. How to solve it?
• [change] The unit tests for those contracts
• [change] The native token on Ethereum L2 is ETH, but it's BOBA on other chains

integration tests

• [change] The function names for multi chain contracts are different. How to solve it?

Gateway

• [change] Some pages need to be hidden
• [change] The function names are different

unreliable integration tests

Integration tests should not be coupled with each other (such that we need to preserve order of how they're executed) because it breaks test isolation and parallelism.

Integration tests are also very time consuming and we should utilize --split-by=timings. https://circleci.com/blog/a-guide-to-test-splitting/

Notifying @souradeep-das @boyuan-chen

How to build rinkeby Boba node, is Boba rinkeby Layer 1 based on Ethereum rinkeky?

I have a problem, I want to build Boba rinkeby node, I deployed it based on docker-compose, but encountered the following error：

Here is my docker-compose configuration, how do I go about solving it

enhance supportInterface on NFT Bridges

Issue

currently, the L1/L2StandardERC721 has EIP165 supportInterfaces() implemented to query the implementation and compatibility withe the NFT Bridges, when fulfilling the bridge transaction.

In addition to which, it must also be able to return its support for ERC721 and ERC721Metadata interfaces

The NFTBridges, while registering the ERC721 pair contracts on each side - do not have checks set up which ensure the contracts to be registered implements ERC721 interface,
if a token is wrongly registered, bridge finalisation cannot happen

Suggestion

• modify the supportsInterface() on L1/L2StandardERC721 to include the check for parent contract interfaces, something like _interfaceId == bridgeCompatibleInterface || super.supportsInterface(_interfaceId)

• on the NFT Bridges registerNFTPair should check the (layer)contract (opposite to the baseLayer) should confirm to 0x80ac58cd //erc721 and either 0x3899b238(l1) or 0x646dd6ec(l2)

Gateway Bridge screen first impressions

1/ Key button is labeled transfer - this should be called Fast Bridge, MultiBridge or Classic Bridge?
2/ The Bridge switcher does nothing? When I click ’switch’ nothing seems to happen
3/ Unclear which bridge I’m about to use - could change the Botton label to say ‘classic bridge’ or ‘fast bridge’ to reduce confusion - see #1
4/ Prices/fees/labels do not change with bridge type setting - for example, when I go to the classic bridge, there should be no 0.1% fee etc. The percent fees are only relevant to the fast bridge
5/ “To classic bridge” button, resulting popup message is misleading - for example, when you are on Boba L2, there is no such thing as the multibridge. So the bridge switcher wording needs to depend on the layer you are on
6/ The amount +/- buttons don’t seem to do anything?
6/ Fast bridge, the percent fee (that depends on the amount you want to fast exit) is fixed == 0 in the present version?
7/ When on L1, how does the person toggle from the multi bridge to the normal bridges? Could not select multiple tokens. Suggest if(layer1) then show multi bridge yes/no picker. If multibridge, enable multiple token selection in the token picker (as many as 4 tokens can be bridged at once IF L1 == true and MULTIBRIDGE == true)

Boba Rinkeby node state-dump.lastest.json

I want to build Rinkeby Boba Node, can you give me the configuration of Rinkeby state-dump.lastest.json

Failure tests for Avalanche L2

1. [Fixed]

"after all" hook for "{tag:boba} Should not increase balance for EOA accounts as helper contract address":
     Error: Timeout of 80000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/boyuanchen/Documents/GitHub/boba.nosync/integration-tests/test/boba_turing_credit.spec.ts)

It's highly likely that it's a small issue.

   2) Boba API Tests
       Meta Transaction API Tests
         Mainnet
           {tag:boba} should swap L2 secondary token for BOBA:

      AssertionError: expected 400 to equal 201
      + expected - actual

      -400
      +201
  3) Boba API Tests
       Meta Transaction API Tests
         Mainnet
           {tag:boba} should return reverted reason from API if Boba_GasPriceOracle has insufficient BOBA:

      AssertionError: expected 'execution reverted: ERC20Permit: inva…' to equal 'execution reverted: Failed to send BO…'
      + expected - actual

      -execution reverted: ERC20Permit: invalid signature
      +execution reverted: Failed to send BOBA
  4) Boba API Tests
       Meta Transaction API Tests
         Rinkeby
           {tag:boba} should swap L2 secondary fee token for BOBA:

      AssertionError: expected 400 to equal 201
      + expected - actual

      -400
      +201
  5) Boba API Tests
       Meta Transaction API Tests
         Rinkeby
           {tag:boba} should return reverted reason from API if Boba_GasPriceOracle has insufficient BOBA:

      AssertionError: expected 'execution reverted: ERC20Permit: inva…' to equal 'execution reverted: Failed to send BO…'
      + expected - actual

      -execution reverted: ERC20Permit: invalid signature
      +execution reverted: Failed to send BOBA
  6) Boba Fee Payment Integration Tests
       Meta transaction tests
         {tag:boba} should submit the meta transaction:
     Error: cannot estimate gas; transaction may fail or may require manual gas limit (error={"reason":"cannot estimate gas; transaction may fail or may require manual gas limit","code":"UNPREDICTABLE_GAS_LIMIT","error":{"reason":"processing response error","code":"SERVER_ERROR","body":"{\"jsonrpc\":\"2.0\",\"id\":5260,\"error\":{\"code\":-32000,\"message\":\"execution reverted: ERC20Permit: invalid signature\"}}\n","error":{"code":-32000},"requestBody":"{\"method\":\"eth_estimateGas\",\"params\":[{\"gasPrice\":\"0x1\",\"from\":\"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc\",\"to\":\"0x4200000000000000000000000000000000000024\",\"data\":\"0x3cb8dd88000000000000000000000000dae74d7327d123a1e1732c14a75599cead1aeec000000000000000000000000042000000000000000000000000000000000000240000000000000000000000000000000000000000000000003dc1936c427d00000000000000000000000000000000000000000000000000000000000062d7350e000000000000000000000000000000000000000000000000000000000000001bf83dc8fd50d578d8d155da53c1e4d96365968cd94db2395fb388905f862f84340afc30993ca243b93a6d4e86e6f53d014235633396e5e361b59647f8e749236a\"}],\"id\":5260,\"jsonrpc\":\"2.0\"}","requestMethod":"POST","url":"http://localhost:8545"},"method":"estimateGas","transaction":{"from":"0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC","gasPrice":{"type":"BigNumber","hex":"0x01"},"to":"0x4200000000000000000000000000000000000024","data":"0x3cb8dd88000000000000000000000000dae74d7327d123a1e1732c14a75599cead1aeec000000000000000000000000042000000000000000000000000000000000000240000000000000000000000000000000000000000000000003dc1936c427d00000000000000000000000000000000000000000000000000000000000062d7350e000000000000000000000000000000000000000000000000000000000000001bf83dc8fd50d578d8d155da53c1e4d96365968cd94db2395fb388905f862f84340afc30993ca243b93a6d4e86e6f53d014235633396e5e361b59647f8e749236a","accessList":null}}, tx={"data":"0x3cb8dd88000000000000000000000000dae74d7327d123a1e1732c14a75599cead1aeec000000000000000000000000042000000000000000000000000000000000000240000000000000000000000000000000000000000000000003dc1936c427d00000000000000000000000000000000000000000000000000000000000062d7350e000000000000000000000000000000000000000000000000000000000000001bf83dc8fd50d578d8d155da53c1e4d96365968cd94db2395fb388905f862f84340afc30993ca243b93a6d4e86e6f53d014235633396e5e361b59647f8e749236a","to":{},"from":"0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC","gasPrice":{"type":"BigNumber","hex":"0x01"},"type":0,"nonce":{},"gasLimit":{},"chainId":{}}, code=UNPREDICTABLE_GAS_LIMIT, version=abstract-signer/5.5.0)
  8) Boba Fee Payment Integration Tests
       Meta transaction tests
         {tag:boba} should swap secondary fee token for BOBA using secondary fee token as the fee token:
     Error: cannot estimate gas; transaction may fail or may require manual gas limit (error={"reason":"cannot estimate gas; transaction may fail or may require manual gas limit","code":"UNPREDICTABLE_GAS_LIMIT","error":{"reason":"processing response error","code":"SERVER_ERROR","body":"{\"jsonrpc\":\"2.0\",\"id\":5434,\"error\":{\"code\":-32000,\"message\":\"execution reverted: ERC20Permit: invalid signature\"}}\n","error":{"code":-32000},"requestBody":"{\"method\":\"eth_estimateGas\",\"params\":[{\"gasPrice\":\"0x1\",\"from\":\"0x8db97c7cece249c2b98bdc0226cc4c2a57bf52fc\",\"to\":\"0x4200000000000000000000000000000000000024\",\"data\":\"0x3cb8dd880000000000000000000000006b11bf72fb344260b14bf69de348277979d26b3000000000000000000000000042000000000000000000000000000000000000240000000000000000000000000000000000000000000000003dc1936c427d00000000000000000000000000000000000000000000000000000000000062d7350f000000000000000000000000000000000000000000000000000000000000001c97996277eac360abc5697a27a866194a799dc04716a1092b6d0651f7efb077ae48db8f962863f5fbcb78c9086d73904f6cbc501b70ead3ea5255aa5eadb46ab5\"}],\"id\":5434,\"jsonrpc\":\"2.0\"}","requestMethod":"POST","url":"http://localhost:8545"},"method":"estimateGas","transaction":{"from":"0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC","gasPrice":{"type":"BigNumber","hex":"0x01"},"to":"0x4200000000000000000000000000000000000024","data":"0x3cb8dd880000000000000000000000006b11bf72fb344260b14bf69de348277979d26b3000000000000000000000000042000000000000000000000000000000000000240000000000000000000000000000000000000000000000003dc1936c427d00000000000000000000000000000000000000000000000000000000000062d7350f000000000000000000000000000000000000000000000000000000000000001c97996277eac360abc5697a27a866194a799dc04716a1092b6d0651f7efb077ae48db8f962863f5fbcb78c9086d73904f6cbc501b70ead3ea5255aa5eadb46ab5","accessList":null}}, tx={"data":"0x3cb8dd880000000000000000000000006b11bf72fb344260b14bf69de348277979d26b3000000000000000000000000042000000000000000000000000000000000000240000000000000000000000000000000000000000000000003dc1936c427d00000000000000000000000000000000000000000000000000000000000062d7350f000000000000000000000000000000000000000000000000000000000000001c97996277eac360abc5697a27a866194a799dc04716a1092b6d0651f7efb077ae48db8f962863f5fbcb78c9086d73904f6cbc501b70ead3ea5255aa5eadb46ab5","to":{},"from":"0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC","gasPrice":{"type":"BigNumber","hex":"0x01"},"type":0,"nonce":{},"gasLimit":{},"chainId":{}}, code=UNPREDICTABLE_GAS_LIMIT, version=abstract-signer/5.5.0)

The bytecode for the AVAX token is wrong!

  9) Liquidity Pool Test
       {tag:mrf} should fast onramp:
     Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":1703,\"error\":{\"code\":-32000,\"message\":\"exceeds block gas limit: tx gas (9000000) \\u003e current max gas (8000000)\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_sendRawTransaction\",\"params\":[\"0x02f8b482a86881cc849502f900850c393e6d008389544094a0706ea5cc0386eea5b8b4fa6ecb143d2019520f80b844095ea7b30000000000000000000000003c4a9b7353e37f57a91fb183d1c03032964f79f00000000000000000000000000000000000000000000000008ac7230489e80000c001a0af2cabc27ada84876d55100c3bcb66ce7c1157a89a2a75a8467ec0b408f1c815a00b5cd19109a02760bc9ad7e10a79184af8b5c080b60d328b3d8a38dffaed63c9\"],\"id\":1703,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="http://localhost:9650/ext/bc/C/rpc", code=SERVER_ERROR, version=web/5.5.1)
  10) Liquidity Pool Test
       Onramp batch tests
         {tag:mrf} should deposit l1 native token:
     Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":3587,\"error\":{\"code\":-32000,\"message\":\"exceeds block gas limit: tx gas (9000000) \\u003e current max gas (8000000)\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_sendRawTransaction\",\"params\":[\"0x02f8fc82a86881ef849502f900850c393e6d0083895440943c4a9b7353e37f57a91fb183d1c03032964f79f0888ac7230489e80000b884a44c80e30000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008ac7230489e80000c080a07562ef41318e4b78049ec17828492b20162eb3da988f3a14999cf528e950ea34a0620f92df3aea6e6aa44dc59353e54c72ee4e4e5f5bbba8be75bd7541b1df2231\"],\"id\":3587,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="http://localhost:9650/ext/bc/C/rpc", code=SERVER_ERROR, version=web/5.5.1)
  11) Liquidity Pool Test
       Onramp batch tests
         {tag:mrf} should depoist l1 native token and ERC20 together:
     Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":3638,\"error\":{\"code\":-32000,\"message\":\"exceeds block gas limit: tx gas (9000000) \\u003e current max gas (8000000)\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_sendRawTransaction\",\"params\":[\"0x02f9013c82a86881f0849502f900850c393e6d0083895440943c4a9b7353e37f57a91fb183d1c03032964f79f0888ac7230489e80000b8c4a44c80e30000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008ac7230489e800000000000000000000000000003c44deae8f4e1a034b3385b449673b795357271d0000000000000000000000000000000000000000000000008ac7230489e80000c001a05cd60e8a24ab63e868b2a5e6375bbc2ae21fc23f9c85cdc35fb540184a90f00ca041341e0e254da3bdfcbcc1d70dfa1b8707a691cbd9ce25850722b315523561d2\"],\"id\":3638,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="http://localhost:9650/ext/bc/C/rpc", code=SERVER_ERROR, version=web/5.5.1)
  12) Liquidity Pool Test
       Onramp batch tests
         {tag:mrf} should deposit l1 native token and three ERC20 together:
     Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":3869,\"error\":{\"code\":-32000,\"message\":\"exceeds block gas limit: tx gas (9000000) \\u003e current max gas (8000000)\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_sendRawTransaction\",\"params\":[\"0x02f901bd82a86881f4849502f900850c393e6d0083895440943c4a9b7353e37f57a91fb183d1c03032964f79f0888ac7230489e80000b90144a44c80e30000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008ac7230489e800000000000000000000000000003c44deae8f4e1a034b3385b449673b795357271d0000000000000000000000000000000000000000000000008ac7230489e8000000000000000000000000000020b188ae94691e9bcf1efa360f15b10bafca77420000000000000000000000000000000000000000000000008ac7230489e800000000000000000000000000007d4d845e159b10259f9569998171c45f3d67afdb0000000000000000000000000000000000000000000000008ac7230489e80000c080a0785267c1be2cbcbc25a4f0cf47df26039a84cea3fe39fbaf2e91e5bf437d189ea0685d6cf7aefa6951b737e79b2d120770cc13c2c8c093256d5e50caa3e17494cc\"],\"id\":3869,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="http://localhost:9650/ext/bc/C/rpc", code=SERVER_ERROR, version=web/5.5.1)
  13) Liquidity Pool Test
       Onramp batch tests
         {tag:mrf} should revert an unfulfillable swap-on in batch:
     Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":4563,\"error\":{\"code\":-32000,\"message\":\"exceeds block gas limit: tx gas (9000000) \\u003e current max gas (8000000)\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_sendRawTransaction\",\"params\":[\"0x02f9013e82a868820105849502f900850c393e6d0083895440943c4a9b7353e37f57a91fb183d1c03032964f79f089047cbf74ad64bcf198b8c4a44c80e30000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000047cbf74ad64bcf1980000000000000000000000003c44deae8f4e1a034b3385b449673b795357271d0000000000000000000000000000000000000000000000008ac7230489e80000c001a0d101d21f295a6720433cc8a7f9690400152c497dfa0ee0c3d6b9186736c14e1fa07ef8e94090d3db10d4351368a78d761901771a5d90248c9fc1f92bae22d209f4\"],\"id\":4563,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="http://localhost:9650/ext/bc/C/rpc", code=SERVER_ERROR, version=web/5.5.1)
  14) Liquidity Pool Test
       Onramp batch tests
         {tag:mrf} should revert unfulfillable swap-ons in batch:
     Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":4662,\"error\":{\"code\":-32000,\"message\":\"exceeds block gas limit: tx gas (9000000) \\u003e current max gas (8000000)\"}}\n", error={"code":-32000}, requestBody="{\"method\":\"eth_sendRawTransaction\",\"params\":[\"0x02f9017f82a868820107849502f900850c393e6d0083895440943c4a9b7353e37f57a91fb183d1c03032964f79f089047cbf74ad64bcf198b90104a44c80e30000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000047cbf74ad64bcf1980000000000000000000000003c44deae8f4e1a034b3385b449673b795357271d0000000000000000000000000000000000000000000000008ac7230489e8000000000000000000000000000020b188ae94691e9bcf1efa360f15b10bafca77420000000000000000000000000000000000000000000002445df6adcde5fc3c3cc080a083fd825da9ab4115a8911162b1293308c9e5690001066305e988f579e0f223bba019fe3cfd23fb82a5fb3fcabb94ec7d3b64cc34d0adaef20095308897f18d1170\"],\"id\":4662,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="http://localhost:9650/ext/bc/C/rpc", code=SERVER_ERROR, version=web/5.5.1)
15) Native BOBA Integration Tests
       {tag:other} deposit passes with a large data argument:
     Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":6019,\"error\":{\"code\":-32000,\"message\":\"oversized data tx size 49818 \\u003e max size 32768\"}}\n"

The L1 gas limit for Avalanche is different from other chains.

4.[Fixed]

  16) Replica Tests
       Matching blocks
         {tag:other} should sync a transaction:
     Error: Timeout of 80000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/boyuanchen/Documents/GitHub/boba.nosync/integration-tests/test/replica.spec.ts)
      at listOnTimeout (internal/timers.js:557:17)
      at processTimers (internal/timers.js:500:7)

  17) Replica Tests
       Matching blocks
         {tag:other} sync an unprotected tx (eip155):
     Error: Timeout of 80000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/boyuanchen/Documents/GitHub/boba.nosync/integration-tests/test/replica.spec.ts)
      at listOnTimeout (internal/timers.js:557:17)
      at processTimers (internal/timers.js:500:7)

  18) Replica Tests
       Matching blocks
         {tag:other} should forward tx to sequencer:
     Error: Timeout of 80000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/boyuanchen/Documents/GitHub/boba.nosync/integration-tests/test/replica.spec.ts)
      at listOnTimeout (internal/timers.js:557:17)
      at processTimers (internal/timers.js:500:7)

Replica issue - unknown

5. [Fixed]

  19) Self Destruct Tests
       Use secondary fee token as fee token
         {tag:other} should use secondary fee token as fee token:
     Error: cannot estimate gas; transaction may fail or may require manual gas limit (error={"reason":"cannot estimate gas; transaction may fail or may require manual gas limit","code":"UNPREDICTABLE_GAS_LIMIT","error":{"reason":"processing response error","code":"SERVER_ERROR","body":"{\"jsonrpc\":\"2.0\",\"id\":11219,\"error\":{\"code\":-32000,\"message\":\"execution reverted: Insufficient secondary fee token balance\"}}\n","error":{"code":-32000},"requestBody":"{\"method\":\"eth_estimateGas\",\"params\":[{\"gasPrice\":\"0x1\",\"from\":\"0xdae74d7327d123a1e1732c14a75599cead1aeec0\",\"to\":\"0x4200000000000000000000000000000000000024\",\"data\":\"0x03bb2b2d\"}],\"id\":11219,\"jsonrpc\":\"2.0\"}","requestMethod":"POST","url":"http://localhost:8545"},"method":"estimateGas","transaction":{"from":"0xdae74D7327d123a1E1732C14a75599ceAd1aeeC0","gasPrice":{"type":"BigNumber","hex":"0x01"},"to":"0x4200000000000000000000000000000000000024","data":"0x03bb2b2d","accessList":null}}, tx={"data":"0x03bb2b2d","to":{},"from":"0xdae74D7327d123a1E1732C14a75599ceAd1aeeC0","gasPrice":{"type":"BigNumber","hex":"0x01"},"type":0,"nonce":{},"gasLimit":{},"chainId":{}}, code=UNPREDICTABLE_GAS_LIMIT, version=abstract-signer/5.5.0)
      at Logger.makeError (/Users/boyuanchen/Documents/GitHub/boba.nosync/node_modules/@ethersproject/logger/src.ts/index.ts:225:28)
      at Logger.throwError (/Users/boyuanchen/Documents/GitHub/boba.nosync/node_modules/@ethersproject/logger/src.ts/index.ts:237:20)
      at /Users/boyuanchen/Documents/GitHub/boba.nosync/node_modules/@ethersproject/abstract-signer/src.ts/index.ts:301:31
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (internal/process/task_queues.js:95:5)
      at async Promise.all (index 6)

  20) SSTORE tests
       Use secondary fee token as fee token
         {tag:other} should use secondary fee token as fee token:
     Error: cannot estimate gas; transaction may fail or may require manual gas limit (error={"reason":"cannot estimate gas; transaction may fail or may require manual gas limit","code":"UNPREDICTABLE_GAS_LIMIT","error":{"reason":"processing response error","code":"SERVER_ERROR","body":"{\"jsonrpc\":\"2.0\",\"id\":11467,\"error\":{\"code\":-32000,\"message\":\"execution reverted: Insufficient secondary fee token balance\"}}\n","error":{"code":-32000},"requestBody":"{\"method\":\"eth_estimateGas\",\"params\":[{\"gasPrice\":\"0x1\",\"from\":\"0xdae74d7327d123a1e1732c14a75599cead1aeec0\",\"to\":\"0x4200000000000000000000000000000000000024\",\"data\":\"0x03bb2b2d\"}],\"id\":11467,\"jsonrpc\":\"2.0\"}","requestMethod":"POST","url":"http://localhost:8545"},"method":"estimateGas","transaction":{"from":"0xdae74D7327d123a1E1732C14a75599ceAd1aeeC0","gasPrice":{"type":"BigNumber","hex":"0x01"},"to":"0x4200000000000000000000000000000000000024","data":"0x03bb2b2d","accessList":null}}, tx={"data":"0x03bb2b2d","to":{},"from":"0xdae74D7327d123a1E1732C14a75599ceAd1aeeC0","gasPrice":{"type":"BigNumber","hex":"0x01"},"type":0,"nonce":{},"gasLimit":{},"chainId":{}}, code=UNPREDICTABLE_GAS_LIMIT, version=abstract-signer/5.5.0)
      at Logger.makeError (/Users/boyuanchen/Documents/GitHub/boba.nosync/node_modules/@ethersproject/logger/src.ts/index.ts:225:28)
      at Logger.throwError (/Users/boyuanchen/Documents/GitHub/boba.nosync/node_modules/@ethersproject/logger/src.ts/index.ts:237:20)
      at /Users/boyuanchen/Documents/GitHub/boba.nosync/node_modules/@ethersproject/abstract-signer/src.ts/index.ts:301:31
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (internal/process/task_queues.js:95:5)
      at async Promise.all (index 6)

  21) SSTORE tests
       Use secondary fee token as fee token
         {tag:other} should delete testInt slot storage:

      AssertionError: Expected "5001999999999999651390" to be equal 5001999999999999678689
      + expected - actual

       {
      -  "_hex": "0x010f28b1d244a7e318e1"
      +  "_hex": "0x010f28b1d244a7e2ae3e"
         "_isBigNumber": true
       }
      
      at Context.<anonymous> (test/selfdestruct.spec.ts:425:41)
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (internal/process/task_queues.js:95:5)

  22) SSTORE tests
       Use secondary fee token as fee token
         {tag:other} should delete testArray slot storage:

      AssertionError: Expected "5001999999999999623662" to be equal 5001999999999999651390
      + expected - actual

       {
      -  "_hex": "0x010f28b1d244a7e2ae3e"
      +  "_hex": "0x010f28b1d244a7e241ee"
         "_isBigNumber": true
       }
      
      at Context.<anonymous> (test/selfdestruct.spec.ts:460:41)
      at runMicrotasks (<anonymous>)
      at processTicksAndRejections (internal/process/task_queues.js:95:5)

Unknown

6. [Fixed]

  23) Turing 256 Bit Random Number Test
       "after all" hook for "should get a 256 bit random number":
     Error: Timeout of 80000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/boyuanchen/Documents/GitHub/boba.nosync/integration-tests/test/turing.spec.ts)
      at listOnTimeout (internal/timers.js:557:17)
      at processTimers (internal/timers.js:500:7)

Unknown

7. [Fixed]

  24) Batch Serialization
       should fetch batches:
     Error: Timeout of 80000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/boyuanchen/Documents/GitHub/boba.nosync/integration-tests/test/z-brotli-batch-serialization.spec.ts)
      at listOnTimeout (internal/timers.js:557:17)
      at processTimers (internal/timers.js:500:7)

Unknown

Do a comparison between execution clients based on Bedrock specifications

Do a comparison between Nethermind and Erigon based on Bedrock specifications

Requirements:

• https://github.com/ethereum-optimism/optimism/blob/develop/specs/exec-engine.md
• https://github.com/ethereum-optimism/reference-optimistic-geth

Figure out how Boba v3 can live side-by-side to Boba V2

Project structure that best suites us?
Requirements:

• Current Boba version needs to live side by side with future Boba version
  • contracts from Optimism, and slowly introducing services (the first one being the execution engine (aka l2geth but not really geth)
• Future Boba version needs to be tested in CirleCI (our preferred tool going forwards)
• the intial client implementation would need to be tested against Optimisms stack (as we have more core changes (dual fees, turing,...)
• ... any other. you think of? Place them here.
• Figure out the final way of state migration between v2 and v3 (could be the same way bedrock is applied)

Gather healthcheck endpoints for all applications

Boba deployer regularly hangs integration tests

Issue Type

[ x] bug report
[ ] feature request

Current Behavior

boba_deployer_1              | {
boba_deployer_1              |   "error": "ERROR processing /opt/optimism/packages/boba/contracts/deploy/013-BobaDao.deploy.ts:\nError: transaction failed (transactionHash=\"0x8ffd6c1d48cf5a9265a9b895812e4a36b407980c9609274d4569b6d5f86c93af\", transaction={\"nonce\":61,\"gasPrice\":{\"type\":\"BigNumber\",\"hex\":\"0x3b9aca00\"},\"gasLimit\":{\"type\":\"BigNumber\",\"hex\":\"0xd9b8\"},\"to\":\"0xc351628EB244ec633d5f21fBD6621e1a683B1181\",\"value\":{\"type\":\"BigNumber\",\"hex\":\"0x00\"},\"data\":\"0x3a66f901000000000000000000000000c351628eb244ec633d5f21fbd6621e1a683b1181000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000062bb1f55000000000000000000000000000000000000000000000000000000000000001873657450656e64696e6741646d696e28616464726573732900000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000cbeaf3bde82155f56486fb5a1072cb8baaf547cc\",\"chainId\":31338,\"v\":62711,\"r\":\"0xf02b88cca3193364df19bb62139e29610fb2662ebc6d7f0778e9da2a4a436c5c\",\"s\":\"0x5f9701e17cfe492b92fa0a373d73ff68cc81b8ec82907da869c68a0c5c61b30f\",\"from\":\"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266\",\"hash\":\"0x8ffd6c1d48cf5a9265a9b895812e4a36b407980c9609274d4569b6d5f86c93af\",\"type\":null,\"confirmations\":0}, receipt={\"to\":\"0xc351628EB244ec633d5f21fBD6621e1a683B1181\",\"from\":\"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266\",\"contractAddress\":null,\"transactionIndex\":0,\"gasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x6f34\"},\"logsBloom\":\"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\"blockHash\":\"0xe0b80b71cbd4db8825b307ee4b7858dd02a280e0a668a35fca31c88c680163d0\",\"transactionHash\":\"0x8ffd6c1d48cf5a9265a9b895812e4a36b407980c9609274d4569b6d5f86c93af\",\"logs\":[],\"blockNumber\":102,\"confirmations\":1,\"cumulativeGasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x6f34\"},\"status\":0,\"type\":0,\"byzantium\":true}, code=CALL_EXCEPTION, version=providers/5.5.3)\n    at Logger.makeError (/opt/optimism/node_modules/@ethersproject/logger/src.ts/index.ts:225:28)\n    at Logger.throwError (/opt/optimism/node_modules/@ethersproject/logger/src.ts/index.ts:237:20)\n    at JsonRpcProvider.<anonymous> (/opt/optimism/node_modules/@ethersproject/providers/src.ts/base-provider.ts:1352:24)\n    at step (/opt/optimism/node_modules/@ethersproject/providers/lib/base-provider.js:48:23)\n    at Object.next (/opt/optimism/node_modules/@ethersproject/providers/lib/base-provider.js:29:53)\n    at fulfilled (/opt/optimism/node_modules/@ethersproject/providers/lib/base-provider.js:20:58)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)",
boba_deployer_1              |   "stack": "Error: ERROR processing /opt/optimism/packages/boba/contracts/deploy/013-BobaDao.deploy.ts:\nError: transaction failed (transactionHash=\"0x8ffd6c1d48cf5a9265a9b895812e4a36b407980c9609274d4569b6d5f86c93af\", transaction={\"nonce\":61,\"gasPrice\":{\"type\":\"BigNumber\",\"hex\":\"0x3b9aca00\"},\"gasLimit\":{\"type\":\"BigNumber\",\"hex\":\"0xd9b8\"},\"to\":\"0xc351628EB244ec633d5f21fBD6621e1a683B1181\",\"value\":{\"type\":\"BigNumber\",\"hex\":\"0x00\"},\"data\":\"0x3a66f901000000000000000000000000c351628eb244ec633d5f21fbd6621e1a683b1181000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000e00000000000000000000000000000000000000000000000000000000062bb1f55000000000000000000000000000000000000000000000000000000000000001873657450656e64696e6741646d696e28616464726573732900000000000000000000000000000000000000000000000000000000000000000000000000000020000000000000000000000000cbeaf3bde82155f56486fb5a1072cb8baaf547cc\",\"chainId\":31338,\"v\":62711,\"r\":\"0xf02b88cca3193364df19bb62139e29610fb2662ebc6d7f0778e9da2a4a436c5c\",\"s\":\"0x5f9701e17cfe492b92fa0a373d73ff68cc81b8ec82907da869c68a0c5c61b30f\",\"from\":\"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266\",\"hash\":\"0x8ffd6c1d48cf5a9265a9b895812e4a36b407980c9609274d4569b6d5f86c93af\",\"type\":null,\"confirmations\":0}, receipt={\"to\":\"0xc351628EB244ec633d5f21fBD6621e1a683B1181\",\"from\":\"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266\",\"contractAddress\":null,\"transactionIndex\":0,\"gasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x6f34\"},\"logsBloom\":\"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\",\"blockHash\":\"0xe0b80b71cbd4db8825b307ee4b7858dd02a280e0a668a35fca31c88c680163d0\",\"transactionHash\":\"0x8ffd6c1d48cf5a9265a9b895812e4a36b407980c9609274d4569b6d5f86c93af\",\"logs\":[],\"blockNumber\":102,\"confirmations\":1,\"cumulativeGasUsed\":{\"type\":\"BigNumber\",\"hex\":\"0x6f34\"},\"status\":0,\"type\":0,\"byzantium\":true}, code=CALL_EXCEPTION, version=providers/5.5.3)\n    at Logger.makeError (/opt/optimism/node_modules/@ethersproject/logger/src.ts/index.ts:225:28)\n    at Logger.throwError (/opt/optimism/node_modules/@ethersproject/logger/src.ts/index.ts:237:20)\n    at JsonRpcProvider.<anonymous> (/opt/optimism/node_modules/@ethersproject/providers/src.ts/base-provider.ts:1352:24)\n    at step (/opt/optimism/node_modules/@ethersproject/providers/lib/base-provider.js:48:23)\n    at Object.next (/opt/optimism/node_modules/@ethersproject/providers/lib/base-provider.js:29:53)\n    at fulfilled (/opt/optimism/node_modules/@ethersproject/providers/lib/base-provider.js:20:58)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n    at DeploymentsManager.executeDeployScripts (/opt/optimism/node_modules/hardhat-deploy/src/DeploymentsManager.ts:1223:19)\n    at runMicrotasks (<anonymous>)\n    at processTicksAndRejections (internal/process/task_queues.js:95:5)\n    at DeploymentsManager.runDeploy (/opt/optimism/node_modules/hardhat-deploy/src/DeploymentsManager.ts:1053:5)\n    at SimpleTaskDefinition.action (/opt/optimism/node_modules/hardhat-deploy/src/index.ts:409:5)\n    at Environment._runTaskDefinition (/opt/optimism/node_modules/hardhat/src/internal/core/runtime-environment.ts:219:14)\n    at Environment.run (/opt/optimism/node_modules/hardhat/src/internal/core/runtime-environment.ts:131:14)\n    at SimpleTaskDefinition.action (/opt/optimism/node_modules/hardhat-deploy/src/index.ts:555:32)\n    at Environment._runTaskDefinition (/opt/optimism/node_modules/hardhat/src/internal/core/runtime-environment.ts:219:14)\n    at Environment.run (/opt/optimism/node_modules/hardhat/src/internal/core/runtime-environment.ts:131:14)"
boba_deployer_1              | }

Expected Behavior

SHould complete without errors!

Steps to Reproduce

1. Push to a branch and wait :-)

Suggested Fix

The DAO is going through a refactor so fixing the DAO might not make sense.
I'll fix this with retrying the boba_deployer process when it detects failure like above!

Boba SDK

ToDo:

• Plug & Play deployment of AWS endpoint, e.g.:

sam deploy \
  --template-file turing.yml \
  --stack-name priceFeed \
  --capabilities CAPABILITY_IAM

---

• NPM package for common use cases (KYC, Turing Examples Price Feed, etc.) --> all of them should have a ready to deploy template file for AWS.

---

• DevOps / VCS / Tests pipeline, etc. whatever is needed for safe usage.

Add alerts for database and cache instances that go to #aws-chatbot in Slack

Feedback - Rinkeby Fee Switcher & Ecosystem page

Hey guys,
I have some feedback for the new rinkeby gateway features. I sincerely apologize for the upcoming MUI inconvenience and potential PTSD.

Ecosystem page
(1) Change the color of the ‘non selected’ filter buttons to a more neutral color on the new and improved ecosystem page to make it more visable.

Fee switcher
(1) Change the menu picker of the “switch fee” button to a more professional look. At the moment it’s very simple looking, and out of design compared with the rest. This also applies to the DAO menu filter.

(2) Give the user a feedback message that they switched the fee token.

(3) We need to inform the user more about the new “ fee switcher” with a simple help/ learn more button next to the fee switcher. Because a lot of users will just yolo on buttons and that will cost them money

Fee switcher limitations
I encountered a couple of scenarios where the user experience could be disturbed. I think in almost all of the scenarios, the best solution could be impossible to implement. Let me explain this further:

(1)
Metamask account with 0.10 Ether (No Boba funds)
Change fee from Ether > Boba (Successful)

When the user switch their fee token from Ether > Boba. The user will be unable to pay for transactions, because he doesn't own any Boba tokens. When he realizes he needs to switch back to Ether as the main fee token. The user is forced to add Boba to his wallet by either bridging it from L1 or sending it from another wallet on L2. Because he has to pay the ‘switch fee’ in Boba, which he can’t. So that's not ideal.

Solution 1:
Let the user not switch to Boba as a fee token IF his wallet does not contain enough Boba. So block the switch button and let the user know: Not enough funds to cover transactions. Do you want to continue? You have to add more funds.

Solution 2:
Let the user switch back to Ether as a fee token and let him pay for this “switch fee” transaction in Ether IF his boba balance is zero or close to zero. In other words (if it’s even possible) make the “switch fee” transaction payable by EITHER boba/ether. If the user doesn't have enough funds of both in his account, then his last option would be to add funds.

(2)
Metamask account with 0.25 Boba (No Ether funds)
Change fee from Boba > Ether (Un-Successful)

If the user only has boba in his account, he can’t change the fee switcher from Ether > Boba. Therefore the user is forced to add Ether to his account. That really sucks for onboarding new people, especially for the next billion users. Let say people won some boba tokens through twitter giveaways, trivia contests or discord promotions. They have to first bridge ether (can cost more than the prize they won) to access their boba tokens. It would be more user friendly to let them switch the fee token to boba WITH their boba tokens. Now they could use the boba tokens and explore the boba network. They could swap their boba tokens on oolongswap for ether.

(3)
Metamask account with 0.34 Ether and 0.01 Boba
Fee token: BOBA
Change fee from BOBA > Ether (Not possible)

By now we know all the transactions will fail, because there is not enough boba to cover the “switch fee” transaction cost. Even if the user got $900 worth of ETH sitting in his account. The funny thing is, they can't even swap it on oolongswap (eth>boba) because they need to pay that "swap transaction" with boba. This can be fixed if the user can pay the “switch fee” transaction in either Ether or Boba. But if this is not possible because of the limitations of the system. We should make it more clearly to the user that they can't transact when there funds are getting low.

1 Add a message on the gateway that the user needs to add more funds to cover the cost/switch cost
2 Add this message also on all the other gateway interactions. For example the transfer pop-up menu. Give the user feedback that they need to top up their account. Maybe block or grey out all the interactions/buttons. Because I know for a fact that users will get stuck with the switcher.

Conclusion:
There are a couple of scenarios where the user will get stuck and forced to bridge more funds to get "unstuck". That will be a super user unfriendly experience. For the time being, if there is no real solution to solve this problem, then we need to inform the user to the max that they can't switch back if they don't have any boba left in their wallet. But in the future, we need to come up with some sort of solution/relayer. Because if we are going to deal with more users, moderators will be flooded with users that are stuck and need some boba to get unstuck. At least, thats my take of it. I could be wrong.

Anyhow, good job on adding all the good stuff (turing, monsters, hackathon, ecosystem page, fee token and all the other cool stuff) The network is getting better and better each day. <3

Stop subsidising relaying fast messages

With multiple instant third-party cross-chain liquidity providers in the ecosystem, the inherent need of still maintaining and subsidising fast exits lessens.
A starting step to disincentivize using the fast-bridges could be to stop running the message-relayer-fast. The associated steps would be:

• determine if relaying fast messages is authenticated. If it is - update access control to everyone
• provide tooling/sdk, or an interface for users to call relayMessage() at their own expense (for the gas)

associated with bobanetwork/gateway#84

Document the monitoring tools in use for each application

Gateway Boba Rinkeby Faucet does not distribute $BOBA

Issue Type

[x ] bug report
[ ] feature request

Current Behavior

When one requests Rinkeby Boba and Eth on the faucet only ETH is distributed.

Expected Behavior

Should get BOBA and ETH.

Steps to Reproduce

1. Tweet boba bubble
2. Wait for ETH arrival
3. There’s no Boba token!

Suggested Fix

Add list of addresses of bridges and liquidity pools

Hi, I think we should add addresses of all bridges and liquidity pools to our LP and bridge pages in the developer docs:

Liquidity pools
Current page: https://docs.boba.network/other/lp

Bridges
Current page: https://docs.boba.network/other/bridges

GH actions hangs and bugs

1. GH actions sometimes hang at the very last step:

2. Other times, the test runs fail at the image download step.

3. Other times, integration test runs 3 or 4 fail due to timeouts - 1 and 2 tend to pass reliably.

4. Finally, in about 1/4 of GH action runs, the integration tests fail to stop correctly:

Turn off broken faucet

This faucet is broken. The new one uses turing. Use redirect to the working faucet.
https://faucets.boba.network/

Dev turingMonsters representation contract to work with NFTBridges

[GATEWAY]: Change copyright to boba network.

Issue Type

[x] bug report
[ ] feature request

Current Behavior

Curently we have copyright with company name OmiseGO Pte Ltd.

Expected Behavior

Copy right should has to be on name of boba network.

Suggested Fix

Change copyright from OmiseGo => 'Boba network' where we can find.

Brotli lib issue in gateway

Gateway was not able to stand up for developers.

Boba Layer0 integration

What we want for Boba Layer0 integration

• We need a gate contract on ethereum.
  The gate contract is used to keep funds on ethereum and send messages via Layer0 to other l1s.
• We need a gate contract on Moonbeam
  The gate contract is very similar to the gate contract on ethereum. It should have these two behaviors. When users move funds from ethereum to this gate contract, the new BOBA token is minted. When users move funds from Moonbeam to other l1s, the token should be burned.
• We need a BOBA contract on Moonbeam
  The BOBA token can only be minted via the gate contract

How to integration Layer0 to our smart contract

• How to send messages
  https://layerzero.gitbook.io/docs/guides/master/how-to-send-a-message
• How to receive messages
  https://layerzero.gitbook.io/docs/guides/master/receive-messages
• Testnets
  https://layerzero.gitbook.io/docs/technical-reference/testnet/testnet-addresses
• Example
  https://github.com/LayerZero-Labs/solidity-examples

Client implementation breakdown tasks

Breaking down execution engine implementation tasks here (not related to specific client which we will do further down the road).
This is just general requirements per Bedrock specification.

Assumptions / Questions

After reading a lot of documentation, I assume we basically fork one of the Eth clients (L1) and modify it to be a Bedrock compliant L2 client, right? Just thinking logically, wouldn't there be an OpenSource L2 client supporting Bedrock then as well very soon? Or why don't we just use what Optimism is using, since they need to do these modifications anyway? What is the general motivation behind switching the ETH client?

From the docs:
The second part of the Optimism node, the Optimism client software, is an almost completely vanilla version of Geth (opens new window). This means Optimism is close to identical to Ethereum under the hood. In particular, Optimism shares the same Ethereum Virtual Machine (opens new window), the same account and state structure (opens new window), and the same gas metering mechanism and fee schedule (opens new window).

Differences

Some differences from prev OVM and Bedrock OVM:

• L1BLOCKNUMBER opcode doesn't exist anymore.
• BASEFEE opcode now supported (since Bedrock includes London fork upgrade)
• TIMESTAMP will now be updated every two seconds (every new block).
• BLOCKNUMBER will advance every two seconds because we'll create a new block every two seconds, regardless of the amount of transactions.

Source: https://community.optimism.io/docs/developers/bedrock/

JSON RPC differences:

• eth_sendMessage and eth_getAccounts now supported. Non-standard eth_getBlockRange not supported anymore.

USDC Doesn't Show a Value in Wallet on Gateway

I bridged USDC to Boba. The USDC amount appears, but there is no value next to it. It just shows $0.00. I also have ETH and BOBA in my wallet and the amounts and values show for both of those. Everything else looks fine on the page.

L2->L1 Ethereum is not coming in

Through the Boba Network Mainnet Bridge,
Whether the Ethereum is requested to be moved through the L2->L1 Classic Bridge
It's the 10th day.
My Ethereum doesn't come into L1
Mainnet history is still Pending

L2 hash: 0xbbe575e7f5f92f138862a7858bef6b518d02d868feb7440070a0653b72e88e08

node is stuck at block 239336

DEBUG[04-04|05:38:37.735] VM returned with error err="insufficient balance for transfer" ret=0x
DEBUG[04-04|05:38:37.736] Transaction failed, account skipped hash=2a57dd…bd0205 err="insufficient balance for transfer"
ERROR[04-04|05:38:37.736] Problem committing transaction msg="Cannot commit transaction in miner"
ERROR[04-04|05:38:37.736] Got error waiting for transaction to be added to chain msg="Cannot commit transaction in miner"
ERROR[04-04|05:38:37.736] Could not verify error="Verifier cannot sync transactions with BackendL2: Verifier cannot sync transactions with backend l2: Cannot sync transactions with backend l2: Cannot apply transaction: Cannot commit transaction in miner"

Document contract changes needed for Bedrock specs

Document know-how for Bedrock level changes (comparing it to the current system) and leave them here.

Contract relevant: https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock

The point of this issue is to provide know-how for the rest of the team.
Output should be resources and an understanding what the purpose of L1 and L2 contract is, how they fit in the grand schema of the system overall.

Gateway ToDos

At least actions involved hardcoded fees - those all need to be looked up / estimated.

Actions affected:

• Save: getMaxTransferValue
• FarmDepositModal: getMaxTransferValue

calldata compression

https://github.com/Boyuan-Chen/calldata-compression/tree/main/result

We can save about 28.49% by compressing calldata that goes into the CTC contract using Zlib.
We can save about 42.82% by compressing calldata that goes into the CTC contract using Brotli.

The compression and gas saving results for the last 100K single transactions:

Method	Compression Ratio	Estimated Fee Savings
Zlib	24.34%	-8.15%
Zlib Dictionary	22.36%	-11.12%
Brotli	25.03%	-5.48%

I studied 5K events. The compression and gas saving results for the batch transaction that goes into the CTC contract:

Method	Compression Ratio	Estimated Fee Savings
Zlib	51.08%	29.47%
Zlib Dictionary	51.05%	29.44%
Brotli	59.93%	42.96%

I also did the speed test for decompressing the data. Since only data transport layer needs to decompress the payload, I ran the speed test in node.js.

Method	Number of Batches	Time Duration
Brotli	5385	8.2058988s
Zlib	5385	3.022597383

The average l2 block number in one batch is 82. The worst case and best case for decompressing data is

Method	Number of Batches	Time Duration
Zlib (best case)	100	1.6ms
Brotli (best case)	100	32.2ms
Zlib (worst case)	100	42.4ms
Brotli (worst case)	100	166.8ms

The worst case means that each batch has 272 L2 blocks and the best case means that each batch only has 2 L2 blocks. I found those two cases and got the rawTransactions. I copied and pasted those data 100 times and used them as the input for the above calculation.

ERC721 Metadata and NFT Bridges

Categorizing ERC721s into three types on the basis of metadata, as per our interests

1. ERC721 with derivable metaData (more common)
   tokenURI returns in the form baseURI + tokenID
2. ERC721 with custom metaData
   not 1) andtokenURI is unique for each token (non-derivable on-chain) or is dependent on custom salt or fully on-chain metadata
3. ERC721 with no metadata (non- ERC721Metadata)

Currently, we can support 1).
With the StandardERC721 representation, the baseURI can be specified while deploying the representation on the opposite layer. so, metadata can be derivable for representation ERC721s on the other side

We also support 3). However - the representation ERC721 would still be ERC721Metadata compliant and would return "" for tokenURI, which we can avoid by having a second plain ERC721Standard(without metaData interfaces). Associated with #12, checks to make sure both original-representation contracts comply to same ERC165 ids can be made on registerPair()

We do not have support for 2). yet. Some forms of these - which do not confirm to the type 1) but still can be fully derived with existing data - can be supported with the customERC721 here - #8

Other forms - where the metadata generated depends on unique user/oracle inputs (for example Turing Monsters) might require - sending this extra data between layers ( just so because this metadata cannot be generated one the representation ERC721) However, To make the bridge support generally all-kinds of these ERC721s we need to send the tokenURI between the layers (since the bridge cannot or doesn't know how to access the unique salts)

Approach -1
could be- If the ERC721 confirms to ERC721Metadata, get the tokenURI and add a new param while sending the xDomain message. If it doesn't send "". On the message receiving end -make the bridge: mint + setTokenURI on the representation ERC721.

Approach -2
To further reduce gas, since most of the ERC721s confirm to the baseURI+tokenId, format - sending over tokenURI for each could just be wasting gas. With this approach we separate and provide choice to either bridge With/Without Metadata. and we keep baseURI on representation contract to allow resolving

	baseURI contracts	non baseURI (onchain)
with Metadata	overriden by baseURI	sets to actual metadata
without Metadata	baseURI handles data	sets to empty metadata

The problem though is with sending over the tokenURI of contracts like (TuringMonsters - which have onchain metadata and rely on inputs/salt etc to recreate the metadata)

The onchain tokenURI for these will be too long, taking up gas 10x, and so maybe communicating the metadata directly may not be usable.
other on-chain NFTs could have dynamic metadata factors which might make it hard to use anything but the tokenURI - which i think makes it hard to have a general bridge for every on-chain ones? (unless they can be fully derived on the opposite layer)

For Turing monsters specifically, to make it bridgeable then, i think would require a customised solution? Which would mean- specifying a notion - to work with the NFT Bridges an on-chain ERC721 would need to reveal a second method with encoded salt data it wants to pass?

Ideas, concerns, suggestions? any other approaches? did I miss something? Is it worth adding either approach-1 or approach-2 for supporting the smaller set of NFTs

Register chainIds

https://github.com/ethereum-lists/chains/tree/master/_data/chains

We need to register chainIds for Moonbase and Moonbeam deployments.
Same for Fantom and Fantom testnet(4051).

eth_sendRawTransaction throws a error when account balances are equal cost

Hi there,
I wonder that when we create a transaction and send it with eth_sendRawTransaction RPC method, how the Geth can make sure the error(Insufficient funds for gas * price + value) was happened?

I mean i know the source code in here:

// Transactor should have enough funds to cover the costs

// cost == V + GP * GL
if b := currentState.GetBalance(from); b.Cmp(tx.Cost()) < 0 {
return core.ErrInsufficientFunds
}
my account balance: 0.004246
gas fee + value = 0.004246
I can be sure that my account balance is equal the cost, but it still throws "invalid transaction: insufficient funds for gas * price + value" error. why?

Thanks in advance!!

withdraw all of my funds error

When I transfer all my eth to another address via boba gateway
I get the following error

insufficient funds for intrinsic transaction cost (error={"code":-32603,"message":"[ethjs-query] while formatting outputs from RPC '{\"value\":{\"code\":-32603,\"data\":{\"code\":-32000,\"message\":\"invalid transaction: insufficient funds for gas * price + value\"}}}'","stack":"{\n \"code\": -32603,\n \"message\": \"[ethjs-query] while formatting outputs from RPC '{\\\"value\\\":{\\\"code\\\":-32603,\\\"data\\\":{\\\"code\\\":-32000,\\\"message\\\":\\\"invalid transaction: insufficient funds for gas * price + value\\\"}}}'\",\n \"stack\": \"Error: [ethjs-query] while formatting outputs from RPC '{\\\"value\\\":{\\\"code\\\":-32603,\\\"data\\\":{\\\"code\\\":-32000,\\\"message\\\":\\\"invalid transaction: insufficient funds for gas * price + value\\\"}}}'\\n at new n (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:27:365128)\\n at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:27:368078)\\n at Object.internal (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:27:368688)\\n at y.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-3.js:3:397736)\\n at Object.u (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:46:9164)\\n at u (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-6.js:3:1209)\\n at y.s.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-6.js:3:1745)\\n at y._setTransactionStatus (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-3.js:3:442090)\\n at y.setTxStatusFailed (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-3.js:3:441322)\\n at j._failTransaction (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-3.js:3:422188)\\n at j.approveTransaction (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-3.js:3:408837)\\n at async j.updateAndApproveTransaction (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-3.js:3:408061)\\n at async s.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:10:14895)\"\n}\n at new n (chrome-

operation screenshot：

address:0x431D42027B5F33cDC26082818c9E5daf96dbEC44

balance:

why on this error

sporadic test failures with new watcher

some integ tests occasionally fails with "Provided message has already been received."

1. Basic L1<>L2 Communication
   L2 => L1
   {tag:other} should be able to perform a withdrawal from L2 -> L1:
2. Bridged tokens
   {tag:other} should withdraw tokens from L2 to the transfer recipient:

hints: fast-relayer might compete with message-relayer

No logs for a new block

Issue Type

[x] bug report
[ ] feature request

Current Behavior

Sometimes the RPC endpoint at https://mainnet.boba.network returns no logs for block that actually has logs.
For example, for block 716730 we have these logs:
https://blockexplorer.boba.network/tx/0x7275eaae0d3e607b58b4407c4941a6708c14c277f229c3443d66f0705ac5cb5a/logs

however, when making a call to get_logs, the returned list of logs is empty.
We're using Python and web3py and the call to get_logs specifies the starting block, the end block and the address
to filter by.

Expected Behavior

The call to get_logs should return all the logs.

Steps to Reproduce

1. Poll https://mainnet.boba.network regularly (e.g. every 2s) for new blocks.
2. As soon as the new block arrives, call get_logs.
3. Observe the empty result, even though the block has logs. Note: a couple of tries might be needed before hitting this behaviour.

Suggested Fix

This could be a problem with the RPC announcing the new block before the block data and logs are ready.

Additional Option: Get Turing result not in the same TX (async)

Having a specific "use-case" in mind, which might be interesting marketing wise and from a scientific standpoint. But this would require Turing to be able to make calls which may take e.g. 600 seconds.

Nevertheless, as discussed with @InoMurko having that option could also solve future scaling problems. Some snippets for more context from our conversation:

• Ino: so now we do it inside estimateGas RPC call . it could be longer, but the implications to geth are unknown. so if you’re not in california (your API) having just 1200 latency is going to be problematic
• Kevin: true that, nevertheless it would just cover one more spectrum of the universe + the scaling issue. Just as an option, the call per tx is really useful, but having the option for greater calculations might have interesting implications.
• Ino: yeah sure it makes sense. having an RPC endpoint to request data + proof of payment and async data push

@jliphard @souradeep-das @InoMurko Opinions?

Migrate DataDog

Issue Type

[x] Update DataDog agent with new key (Staging, Production, other L2,...)
[x] Migrate metrics ( Staging, Production, other L2,...)
[x] Migrate system alerts (Staging, Production, other L2,...)
[x] Migrate balance monitoring alert (Staging, Production, other L2,...)

documentation needed updates

1. Fee overview needs checking: https://github.com/bobanetwork/boba/blob/docs-in-monrepo/boba_documentation/developer/fee-scheme.md (@boyuan-chen )
2. Fee switching needs a one para overview https://github.com/bobanetwork/boba/blob/docs-in-monrepo/boba_examples/boba-fee/README.md (@boyuan-chen )
3. RPC methods https://github.com/bobanetwork/boba/blob/docs-in-monrepo/boba_documentation/developer/json-rpc-api.md needs complete update (@souradeep-das or @InoMurko )
4. Contract verification needs checking: https://github.com/bobanetwork/boba/blob/docs-in-monrepo/boba_documentation/developer/verify-smart-contracts.md
5. Init fund example probably broken https://github.com/bobanetwork/boba/blob/docs-in-monrepo/boba_examples/init-fund-l2/src/index.js - update to use the new watcher? (@souradeep-das )
6. NFT bridging please check for correct function: https://github.com/bobanetwork/boba/tree/docs-in-monrepo/boba_examples/nft_bridging

Boba node sync issue

My node seems to be stuck on block 534100. How can I resolve this issue? I thought my database was corrupted and I have already re-sync from 0 and still the issue persists.

DEBUG[05-03|07:58:15.602] Ancient blocks frozen already            number=534100 hash=131c82…4ec578 frozen=444100
INFO [05-03|07:58:20.515] Syncing transaction range                start=534100 end=13759 backend=l2
INFO [05-03|07:58:20.519] Syncing transaction range                start=534100 end=13761 backend=l2
INFO [05-03|07:58:30.517] Syncing transaction range                start=534100 end=16000 backend=l2
INFO [05-03|07:58:41.012] Syncing transaction range                start=534100 end=18000 backend=l2
INFO [05-03|07:58:50.841] Syncing transaction range                start=534100 end=20000 backend=l2
INFO [05-03|07:59:00.522] Syncing transaction range                start=534100 end=22291 backend=l2
INFO [05-03|07:59:10.518] Syncing transaction range                start=534100 end=25000 backend=l2
DEBUG[05-03|07:59:15.603] Ancient blocks frozen already            number=534100 hash=131c82…4ec578 frozen=444100
INFO [05-03|07:59:20.911] Syncing transaction range                start=534100 end=27000 backend=l2
INFO [05-03|07:59:30.781] Syncing transaction range                start=534100 end=29000 backend=l2
INFO [05-03|07:59:40.909] Syncing transaction range                start=534100 end=31000 backend=l2
INFO [05-03|07:59:50.836] Syncing transaction range                start=534100 end=33000 backend=l2
INFO [05-03|08:00:00.971] Syncing transaction range                start=534100 end=35000 backend=l2
INFO [05-03|08:00:10.515] Syncing transaction range                start=534100 end=37142 backend=l2
INFO [05-03|08:00:10.518] Syncing transaction range                start=534100 end=37144 backend=l2
INFO [05-03|08:00:10.521] Syncing transaction range                start=534100 end=37145 backend=l2
INFO [05-03|08:00:10.524] Syncing transaction range                start=534100 end=37147 backend=l2
DEBUG[05-03|08:00:15.603] Ancient blocks frozen already            number=534100 hash=131c82…4ec578 frozen=444100

Gateway for the multichain environment - task breakdown

The idea is to have the gateway look similar to: https://gnosis-safe.io/app/welcome
Where on the top right you can switch between different chain environments.
We would gradually provide inputs on what features are disabled/enabled on which chain.
For example:
Ecosystem subpage would have less items to show on Moonbeam/Fantom/Ethereum.

Boba turing package misplaced

Issue Type

The package in packages/boba/turing
seems to be misplaced. It's an example that needs more documentation on it's purpose.

[ x] bug report
[ ] feature request

Current Behavior

Review the purpose and coupling of the package. Move it to examples or community - depends on the outcome of the review.

Expected Behavior

Only core stuff that is deployed to mainnet or rinkeby in packages.

How long should Fast Bridge to L1 take?

I initiated a Fast Bridge to L1 approximately 18 hours ago. The history shows Success for each hash. It was a large amount of BOBA and I know there has been low liquidity recently, but I want to make sure something is not stuck. My wallet is on a Ledger Nano X connected through MetaMask.

I know a couple of months ago, bridging transactions were failing with using a Ledger wallet and wonder if that is still a problem.

Thanks!