# About Super World Computer

## About Super World Computer

Ethereum is often referred to as the "[world computer](https://www.youtube.com/watch?v=j23HnORQXvs)." The "world computer" refers to a decentralized network that functions like a global operating system. It allows users to run applications, store data, and execute smart contracts without centralized control. The concept emphasizes a system where computation and data storage are distributed across many nodes, providing transparency, security, availability, and resistance to censorship.

Unfortunately, due to the limited computational power of Ethereum itself (e.g., in terms of transactions per second), the mission of the world computer to serve people around the world is greatly limited. To address the scalability problem, Ethereum is moving towards its layer 2 (L2), a.k.a., the Rollup-centric roadmap. The idea is to submit the off-chain transactions to Ethereum L1 and then validate the correctness of off-chain execution using fault proofs or validity proofs. In this way, the correctness of the execution result is guaranteed by the Ethereum L1, while the capacity of off-chain execution can be greatly increased.

While the Rollup approach has the potential to achieve hundreds or even thousands of TPS (transactions per second), Ethereum and its L2 solutions are still missing some critical components needed to become the world computer that serves global users without centralized control:

* **High validation costs on Ethereum**: The validity proof approach demands powerful and expensive proving devices. Moreover, upgrading Layer 2 with new EVM EIPs incurs additional implementation costs in circuit design, which increases the risk of bugs, leading to what's known as "EVM-upgrade scary." While the fault-proof approach is more friendly to EVM upgrades, it involves long settlement times on Layer 1 (up to 7 days) and can become costly during periods of network congestion.
* **High storage costs even with the current L2 approach**. A single node capacity limits the storage capacity of an L2 network, typically a few terabytes. This constraint means that L2 networks struggle to support internet-scale applications, such as Twitter, which generates approximately 12TB of data daily.
* **EVM performance limits**. The sequential execution model of the EVM imposes a significant cap on the upper bound of L2 TPS. As a result, running internet-scale applications on L2 remains impractical.
* **High user onboarding cost**. The gap between traditional web users and the emerging world of Web3 remains considerable, particularly due to the upfront cost of acquiring a gas token. Although airdrops attempt to alleviate this issue, they must carefully identify genuine users to avoid unnecessary token sell-offs. Bridging this gap is a core challenge for realizing the world computer vision.
* **Centralized frontends**. Most of the frontends of Ethereum applications heavily rely on centralized servers and DNS mapping, which inherits all the drawbacks of centralized applications, such as single point of failure and censorship attacks. Although ENS and IPFS provide some level of censorship resistance, the web content is static and may disappear at any time.

To address all these problems, we are introducing **the super world computer - a highly customized OP Stack rollup** designed to bring the vision of the world computer to life, backed by years of research and development.

|                      | Existing Ethereum L2s                           | Super World Computer                        |
| -------------------- | ----------------------------------------------- | ------------------------------------------- |
| Security             | Fault proof or validity proof                   | Advanced fault proof with fast settlement   |
| Processing           | Sequential execution/IO model with \~200M gas/s | Parallel execution/IO model with > 1G gas/s |
| Storage              | Limited by single node capacity                 | 1000x of single node capacity               |
| User Onboarding Cost | Upfront cost to buy ETH as gas token            | No cost by receiving Soul Gas Token         |
| Frontend             | DNS + http\://                                  | ENS + web3://                               |

## Our Approach

### Advanced Fault Proof Algorithm Supported By OP

OP Stack has recently launched an on-chain fault-proof algorithm, officially promoting Optimism to stage 1. However, a key concern with fault proofs is that resolving a dispute requires about 73 interactions between the defender and the challenger. To address this, we propose a multi-section fault dispute game that incorporates multiple intermediate claim hashes for each interaction. This approach is expected to reduce the number of interactions and associated gas costs by up to 90%. We are pleased to have received an OP [grant](https://app.charmverse.io/op-grants/page-29596258544520615) to develop this solution further.

|                        | Moves | Per move gas cost | Total gas cost | Savings |
| ---------------------- | ----- | ----------------- | -------------- | ------- |
| Current (N = 2)        | 73    | \~250,000         | \~18,250,000   | 0%      |
| N = 16 with calldata   | 19    | \~258,192         | \~4,905,648    | 73%     |
| N = 256 with calldata  | 10    | \~381,072         | \~3,810,720    | 79%     |
| N = 4096 with EIP-4844 | 8     | \~250,000         | \~2,000,000    | 89%     |

(caption: The estimated on-chain interactions and gas cost of current and proposed methods)

### Pushing EVM Performance Limits with Parallelization

Parallel EVM emerges as a standout solution for enhancing EVM execution speeds. By leveraging parallel program execution and data read/write operations, it taps into the concurrency capabilities of modern computers, which are typically equipped with 4-8 CPU cores and boast high-bandwidth I/O.

Our exploration in this area focuses on the performance limits of the EVM through parallel optimistic execution, also known as Block STM, and parallel I/O—a strategy designed to reduce latency and boost performance by parallelizing EVM data reads. Key areas of exploration include:

* **EIP-7650: Programmable Access Lists**, which enables contracts to define multiple data locations for parallel preloading. This method can sustainably reduce the latency of reading multiple data and thus lower gas costs beyond what EIP-2930 offers.
* **Intelligent I/O Preloading**: By designing an EVM capable of learning the common read locations (via SLOAD and CALL) within a contract method, it can preload data in parallel during contract method invocation, thus leveraging I/O parallelization benefits even without explicit access lists.

### Programmable Large Storage with EthStorage as L3

Ethereum’s data availability roadmap allows for the publication of large amounts of data on-chain. However, to limit validator storage requirements, Ethereum discards the DA data (namely binary large objects, BLOBs) older than 18 days. EthStorage, a storage L2, offers a solution for long-term BLOB storage by maintaining a key-to-BLOB-hash mapping on-chain while proving the storage off-chain. This approach reduces storage costs by a factor of 1,000, with 1,000x the capacity, enabling storage of massive datasets far beyond the limitations of sequencers or validators. Additionally, EthStorage’s key-to-BLOB interface enables **programmable large storage**—a critical infrastructure for supporting Web2 applications.

However, programming storage on Ethereum L1 is prohibitively expensive; the gas cost of maintaining on-chain metadata can exceed the storage cost itself. To mitigate these costs, SWC L2 will **integrate EthStorage as L3**, reducing the cost of storing a BLOB to approximately 1/10,000th of the mainnet cost. This dramatically reduced storage cost on the SWC L2 opens up new possibilities for applications on Ethereum, such as fully on-chain AI with all models and training data stored in EthStorage.

### Soul Gas Token

To bridge the gap between traditional web users and the growing world of Web3, SWC will adopt a **non-transferable gas token** named Soul Gas Token, where the SWC token (ERC20) is the native gas token of the SWC Rollup, thanks to the recent custom gas token feature of OP Stack.

The concept of Soul Gas Token revolves around facilitating Web2 users' entry into Web3 by airdropping them with a **non-transferable** gas token. This token will enable users to pay for transaction gas fees without the immediate selling pressure. Additionally, this feature does not require support from new wallets—existing EOA wallets will automatically prioritize using the Soul Gas Token for payment before drawing from the user's account balance. This initiative is particularly aimed at those new billions to Web3, providing a seamless transition without the upfront cost of acquiring a gas token.

### web3:// - Transforming EVM into the Unstoppable Web Server

As the Ethereum scalability initiatives, including our super world computer plan, advance, they set the stage for widespread adoption of fully on-chain applications. However, an essential component remains absent in Ethereum's evolution: a decentralized protocol facilitating direct access to on-chain resources like NFT images and dynamic on-chain websites.

To address this, we proposed a new standard that defines HTTP-style web3:// links in ERC-4804/6860 for navigating dynamic on-chain resources maintained by smart contracts. As a result, it effectively transforms the Ethereum virtual machine (EVM) into an unstoppable decentralized HTTP server. Combined with the programmable large storage enabled by EthStorage, we are bringing to life **the fully decentralized web**, or web3, a re-architected internet where all centralized entities are replaced by permissionless protocols.


# Soul Gas Token

### **Motivation**

To bridge the gap between traditional web users and the growing world of Web3, we propose a **non-transferable gas token** named Soul Gas Token (SGT), where the gas token is the native token of a Rollup. The concept revolves around facilitating Web2 users' entry into Web3 by airdropping them with SGT. This token will enable users to pay for transaction gas fees without the immediate selling pressure of the airdropped token. This initiative is particularly aimed at those new to Web3, providing a seamless transition without the upfront cost of acquiring a gas token.

### **How It Works (Using OP Stack as a Case Study)**

* **Technical Implementation**: **SGT is managed through an ERC20 contract deployed on the L2 with a twist**: the chain operator or governance can **`mint`** new tokens by deposit SGT. To maintain its non-transferable nature, all attempts to use ERC20's **`transfer`**, **`transferFrom`**, or **`approve`** methods will result in failure.
* **Wallet Compatibility**: The transaction format remains consistent with existing Rollup ones. Users can transact using ETH wallets without the need for additional ones (e.g., AA wallets), ensuring a smooth user experience.
* **Gas Fee Process**: For an L2 transaction, the fee will first be deducted from the user's SGT balance in the ERC20 contract. If the balance is insufficient, the system will then draw from the user's balance. To account for the additional processing cost of SGT, the base gas cost may be slightly higher than traditional transactions, likely from 21,000 to 21,000+2,100+5,000=28,100 gas. Note that the token transferred in `msg.value` will be always from the user balance, preventing transferability of SGT token.

### **Potential Challenges**

* **Sequencer Incentives**: The sequencer will receive the gas fee in SGT as `used_price * gas_price`.
* **Risk of DoS Attacks**: The introduction of a "free" transaction token like SoulETH could potentially incur denial-of-service (DoS) type attacks. Mitigation strategies include limiting the initial airdrop quantity to support a finite number of transactions, coupled with a mechanism to replenish SGT for users with verified on-chain behaviors.
* **Sybil Attack Prevention**: Airdrops are susceptible to exploitation through Sybil attacks. We will implement established best practices of airdrops to identify and mitigate such threats effectively.

This article outlines a novel approach to lowering the entry barrier into Web3, leveraging SoulETH as a transitional gas token for Web2 users. By addressing the outlined challenges and focusing on user onboarding experience, we believe SoulETH can significantly contribute to the wider adoption of Web3.

### Comparison with [SoulETH](https://www.notion.so/acbc11492bc145849c470a8ce5114128?pvs=21)

|                  | SoulETH        | SoulGT                                                                     |
| ---------------- | -------------- | -------------------------------------------------------------------------- |
| Mint             | Only sequencer | Anyone by depositing SGT (e.g., the foundation airdrops SGT by depositing) |
| Sequencer reward | None           | used\_price \* gas\_price                                                  |
| Transferability  | None           | None                                                                       |

### Concluding Remarks

This article outlines a novel approach to lowering the entry barrier into Web3, leveraging SGT as a transitional gas token for Web2 users. By addressing the outlined challenges and focusing on user onboarding experience, we believe SGT can signifiQcantly contribute to the wider adoption of Web3.


# Inbox Contract

### Motivation

The batch inbox is currently an Externally Owned Account (EOA), which has both advantages and disadvantages:

Advantages:

* Low submission gas cost due to the absence of onchain execution.
* Verification logic is moved offchain to the derivation part, protected by a fault dispute game with a correct absolute prestate.

Disadvantage:

* Onchain verification is not possible.

This specification aims to allow the batch inbox to be a contract, enabling customized batch submission conditions such as:

* Requiring the batch transaction to be signed by a quorum of sequencers in a decentralized sequencing network; or
* Mandating that the batch transaction call a BLOB storage contract (e.g., EthStorage) with a long-term storage fee, which is then distributed to data nodes that prove BLOB storage over time.

### How It Works

The integration process consists of three primary components:

1. The [`BatchInboxAddress`](https://github.com/ethereum-optimism/optimism/blob/db107794c0b755bc38a8c62f11c49320c95c73db/op-chain-ops/genesis/config.go#L77) can now be set to either an Externally Owned Account (EOA) or a smart contract. When a contract is used, it assumes responsibility for verifying and enforcing batch submission conditions.
2. Modification of the `op-node` derivation process: The `op-node` will be updated to exclude failed batch transactions during the derivation process. This change ensures that only successfully executed batch transactions are processed and included in the derived state.
3. Modification of the op-batcher submission process: The op-batcher will be updated to [call `recordFailedTx`](https://github.com/blockchaindevsh/optimism/blob/02e3b7248f1b590a2adf1f81488829760fa2ba03/op-batcher/batcher/driver.go#L537) for failed batch transactions. This modification ensures that the data contained in failed transactions will be resubmitted automatically.
   1. Most failures will be detected during the [`EstimateGas`](https://github.com/ethereum-optimism/optimism/blob/8f516faf42da416c02355f9981add3137a3db190/op-service/txmgr/txmgr.go#L266) call. However, under certain race conditions, failures may occur after the transaction has been included in a block.

These modifications aim to enhance the security and efficiency of the batch submission and processing pipeline, allowing for more flexible and customizable conditions while maintaining the integrity of the derived state.


# L2 Blob

### Motivation

The Ethereum Cancun upgrade has significantly reduced Layer 2 (L2) data uploading costs by introducing BLOB transactions to Layer 1 (L1). This innovation has also enabled a variety of additional applications based on the BLOBs due to their low cost, such as [blob.fm](https://blob.fm/), [EthStorage](https://ethstorage.io), and [Ethscriptions](https://ethscriptions.com/). However, while the data upload costs have decreased, the execution costs on L1 remain high compared to L2, leading to high costs for L2 state proposals and non-financial applications that rely on BLOBs.

To address these challenges, the L2 BLOB feature introduces support for BLOB transactions on L2. enabling L3 solutions that settle on L2 to use an enshrined 4844-compatible DA layer without needing to integrate third-party DA providers or deal with the security risks associated with DA bridges. Additionally, the applications mentioned above could migrate to L2 with minimal costs.

Furthermore, the L2 BLOB feature uses [Alt-DA](https://github.com/ethereum-optimism/specs/blob/main/specs/experimental/alt-da.md) to upload L2 BLOBs while still using L1 DA for L2 calldata. This approach, referred to as a “hybrid DA L2”, combines the best features of different DA solutions. This allows users and applications of an L2 to choose between L1 DA and alt-DA for different types of transaction data within the same network, without the need to maintain multiple L2s. Specifically, users can upload and store non-financial data at a very low cost using L2 BLOBs and Alt-DA, while still conducting critical financial data using L2 calldata and L1 DA. In some cases, these two types of data may even occur within the same transaction. Here are a few potential scenarios:

* While the L2 continues to use L1 DA for uploading calldata, multiple app-specific or game-focused L3s settled on it can directly use the enshrined 4844-compatible L2 DA layer, benefiting from easy integration, robust security, and lower costs.
* Users might use a platform like Decentralized Twitter primarily for social networking (non-financial), while also sending payments (financial) to other users within the same application.

### How It Works

The following diagram illustrates the transaction data flow for a hybrid DA L2:

<img src="/files/4Ni98uuNA9Lw2dlzxldy" alt="Alt Text" width="600">

This hybrid approach provides a versatile, cost-effective solution for data availability across diverse applications on L2, supporting Ethereum’s ongoing scalability efforts.


# web3://

### Motivation

With the advancements in Ethereum scalability, including our “Super World Computer” initiative, the ecosystem is progressing toward broad adoption of fully on-chain applications. However, a critical component remains underdeveloped: a decentralized protocol that enables direct access to on-chain resources, such as NFT images and dynamic websites hosted within smart contracts.

To address this need, we have introduced a new standard for defining HTTP-style web3:// links through ERC-4804 and ERC-6860. This protocol allows seamless navigation to dynamic on-chain resources governed by smart contracts, effectively transforming the Ethereum Virtual Machine (EVM) into a decentralized, unstoppable HTTP server.

When combined with the programmable storage provided by EthStorage, this approach lays the groundwork for **a fully decentralized web** (Web3), a reimagined internet that replaces centralized entities with permissionless protocols. Our aim is to establish a resilient, censorship-resistant infrastructure that inherently provides direct access to decentralized resources.

### How It Works

#### URL structure

```
web3://<contract>[:<chainId>]/<path>
```

The URLs are following a structure close to traditional HTTP URLs:

* `<contract>` can either be a contract address such as `0x5ad14e8439b9619e165db27545faf6df13e2b947` or a domain name such as `web3url.eth`. Learn more about [domain name resolution](https://docs.web3url.io/web3-url-structure/domain-name).
* `chainId` is optional and indicates the chain id of the blockchain where to query the smart contract. `web3://0x5a985f13345e820aa9618826b85f74c3986e1463:5/tokenHTML/2` will for example query on the goerli blockchain (chain id = 5).
* `path` follows a similar structure than traditional HTTP URLs, in the form of `/path/path2?query1=xx&query2=xx`. To know how to build a path, we first need to know the [**resolve mode** of the called smart contract](https://docs.web3url.io/web3-url-structure/resolve-mode)

#### Standards

The `web3://` protocol is made of various Ethereum ERCs, some of which are still in draft status. We will flag on this documentation what is definitive and what could change.

Here is the list of ERCs :

* [ERC-4804](https://eips.ethereum.org/EIPS/eip-4804): The base ERC from which everything is based on. This ERC is final and cannot be edited anymore.
* [ERC-6860](https://eips.ethereum.org/EIPS/eip-6860): (Draft) This ERC updates the base [ERC-4804](https://eips.ethereum.org/EIPS/eip-4804) with clarifications, minor fixes and changes. Still in draft status.
* [ERC-6821](https://eips.ethereum.org/EIPS/eip-6821): (Draft) ENS resolution : support for the `contentcontract` TXT field to point to a contract in another chain. Still in draft status.
* [ERC-6944](https://eips.ethereum.org/EIPS/eip-6944): (Draft) New resolve mode offloading some parsing processing on the browser side, based on [ERC-5219](https://eips.ethereum.org/EIPS/eip-5219). Still in draft status.
* [ERC-7087](https://eips.ethereum.org/EIPS/eip-7087) : (Draft) Auto mode : Add MIME type support. Still in draft status.
* [ERC-7617](https://eips.ethereum.org/EIPS/eip-7617) : (Draft) Add chunk support in ERC-6944 resource request mode. Still in pending merge status.
* [ERC-7618](https://eips.ethereum.org/EIPS/eip-7618) : (Draft) Add Content-encoding handling in ERC-6944 resource request mode. Still in pending merge status.

#### Examples

**Access an on-chain website**

```
web3://web3url.eth
```

This on-chain website is located in the `0x5ad14e8439b9619e165db27545faf6df13e2b947` smart contract in the QuarkChain L2 testnet blockchain.

> ⏩ Try now with a [web3:// gateway](https://web3url.w3eth.io), or with the others `web3://` clients

**Get a NFT**

```
web3://0x4e1f41613c9084fdb9e34e11fae9412427480e56/tokenHTML/9352
```

This URL will fetch the HTML of the NFT number 9352 of the Terraforms NFT collection located at [`0x4e1f41613c9084fdb9e34e11fae9412427480e56`](https://etherscan.io/address/0x4e1f41613c9084fdb9e34e11fae9412427480e56) on the Ethereum mainnet blockchain.

> ⏩ Try now with a [web3:// gateway](https://0x4e1f41613c9084fdb9e34e11fae9412427480e56.w3eth.io/tokenHTML/9352), or with the others `web3://` clients

**Fetch an USDC balance**

```
web3://0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48/balanceOf/nemorino.eth?returns=(uint256)
```

This URL will fetch the balance of USDC of the account `nemorino.eth`.

> ⏩ Try now with a [web3:// gateway](https://0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48.w3eth.io/balanceOf/nemorino.eth?returns=\(uint256\)), or with the others `web3://` clients

### Additional Resources

* [Official Website](https://web3url.io)
* [Full Documentation](https://docs.web3url.io)


# L1 Header Hash History

### Motivation

The "L1 Header Hash History" feature allows direct access to recent L1 header hash on L2.

It is useful for two primary applications:

1. Random number generator.
2. Verification of L1 state on L2.

This feature is similar to the recent [EIP-2935](https://eips.ethereum.org/EIPS/eip-2935), which finally lands after 5 years.

### How It Works

We implemented it by extending the L1Block a bit [here](https://github.com/QuarkChain/optimism/blob/48d461b7ba7b3f1aa599f52b7b8a17d25e6d12d1/packages/contracts-bedrock/src/L2/L1Block.sol#L175-L198), which is used by OP Stack to store information about L1 block.

When L1 block information is saved, it is now also stored in one slot of the 8192-window buffer.

The slot for block `N` can be computed as:

```
N % HISTORY_SIZE
```

The stored block hash can be retrieved by calling the [`blockHash(uint256 _historyNumber)`](https://github.com/QuarkChain/optimism/blob/48d461b7ba7b3f1aa599f52b7b8a17d25e6d12d1/packages/contracts-bedrock/src/L2/L1Block.sol#L182) method.


# App Developers


# Receive test tokens

## Get Test QKC for Delta Testnet On L1

Steps:

1. Ensure you have some sepolia gas, otherwise go [here](https://www.alchemy.com/faucets/ethereum-sepolia) for faucet.
2. Invoke the `mint` function on etherscan [here](https://sepolia.etherscan.io/address/0xC359FCF9328143f798C197B86856e656411aBC48#writeContract).

Or simply run this:

```bash
export L1_RPC_URL='https://65.108.230.142:8545'
export PRIVATE_KEY=''# input your own pk

cast send 0xC359FCF9328143f798C197B86856e656411aBC48 'mint()' --private-key $PRIVATE_KEY -r $L1_RPC_URL
```

After that you can cross the claimed `Test QKC` to L2 via [the migration page](https://migration.delta.testnet.l2.quarkchain.io).

## Get Delta Testnet Soul Gas Token On L2

```bash
export SOUL_GAS_TOKEN=0x4200000000000000000000000000000000000800
export L2_RPC_URL='https://rpc.delta.testnet.l2.quarkchain.io:8545'
export PRIVATE_KEY=''# input your own pk

cast send --value <amount, e.g., 10ether> $SOUL_GAS_TOKEN 'deposit()' --private-key $PRIVATE_KEY -r $L2_RPC_URL
```

Then if you import `0x4200000000000000000000000000000000000800` into metamask, you'll see your balance of `Soul Gas Token`.

## Faucet

> Go to <https://qkc-l2-delta-faucet.eth.sep.web3gateway.dev>.


# Bridge tokens

### Mainnet

* <https://migration.mainnet.l2.quarkchain.io>

### Delta Testnet

* <https://migration.delta.testnet.l2.quarkchain.io>


# Node Operators


# Run an Ethereum node

Follow the tutorial [here](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/) to run an Ethereum node.


# Run a Super World Computer node

This guide will help you get SWC node up and running.

## Hardware requirements

Hardware requirements for SWC nodes can vary depending on the type of node you plan to run. Archive nodes generally require significantly more resources than full nodes. Below are suggested minimum hardware requirements for each type of node.

* 16 GB RAM
* 300 GB SSD (full node) or 500 GB SSD (archive node)
* Reasonably modern CPU

## Sync modes

For full nodes, the following configurations are available ([explanation](https://docs.optimism.io/operators/node-operators/management/snap-sync#enable-snap-sync-for-your-node)):

|                         | `op-node`(CL)                              | `op-geth`(EL)                   |
| ----------------------- | ------------------------------------------ | ------------------------------- |
| Full nodes EL snap sync | `--syncmode=execution-layer (not default)` | `--syncmode=snap (default)`     |
| Full nodes EL full sync | `--syncmode=execution-layer (not default)` | `--syncmode=full (not default)` |
| Full nodes CL sync      | `--syncmode=consensus-layer (default)`     | `--syncmode=full (not default)` |

For archive nodes, please add `--gcmode=archive` to `op-geth`.

## Mainnet

### Steps

1. Follow the following steps to download the executable binaries.

* 1.1 Download `op-geth`

  ```bash
  export VERSION=v1.0.2
  curl -L "https://github.com/QuarkChain/op-geth/releases/download/${VERSION}/op-geth.${VERSION}.linux-amd64.tar.gz" \
    | tar -xz && mv "op-geth.${VERSION}" op-geth
  ```
* 1.2 Download `op-node`

  ```bash
  export VERSION=v1.0.2
  curl -L "https://github.com/QuarkChain/optimism/releases/download/op-node%2F${VERSION}/op-node.${VERSION}.linux-amd64.tar.gz" \
    | tar -xz --strip-components=1 && mv "${VERSION}" op-node
  ```

2. Setup `op-geth`:

   > The default settings are for full nodes with snap sync. For configurations related to full sync or archive nodes, please refer to the [Sync modes](#sync-modes) section.

   ```bash
       # assume op-node and op-geth are located at ./op-node and ./op-geth

       cd op-geth
       # prepare mainnet_genesis.json
       curl -LO https://raw.githubusercontent.com/QuarkChain/pm/refs/heads/main/L2/assets/mainnet_genesis.json
       ./build/bin/geth init --datadir=datadir --state.scheme hash mainnet_genesis.json
       openssl rand -hex 32 > jwt.txt

       export PUBLIC_IP=<YOUR_PUBLIC_IP>

       # The rpc port is the default one: 8545.
       ./build/bin/geth --datadir ./datadir   \
           --http \
           --http.corsdomain="*" \
           --http.vhosts="*" \
           --http.addr=0.0.0.0 \
           --http.api=web3,eth,txpool,net \
           --ws \
           --ws.addr=0.0.0.0 \
           --ws.port=8546 \
           --ws.origins="*" \
           --ws.api=eth,txpool,net \
           --nat="extip:${PUBLIC_IP}" \
           --networkid=100011 \
           --authrpc.vhosts="*" \
           --authrpc.port=8551 \
           --authrpc.jwtsecret=./jwt.txt \
           --rollup.disabletxpoolgossip \
           --rollup.sequencerhttp=https://rpc.mainnet.l2.quarkchain.io:8545 \
           --rollup.enabletxpooladmission 2>&1 | tee -a geth.log -i
   ```
3. Setup `op-node`:

   > ⚠️ The `op-node` admin RPC should not be exposed publicly. If left exposed, it could accidentally expose admin controls to the public internet.

   > Sync mode is set to `--syncmode=execution-layer` to enable snap sync.

   ```bash
       # assume op-node and op-geth are located at ./op-node and ./op-geth
       # copy jwt.txt from the op-geth directory above to ./op-node
       cp ./op-geth/jwt.txt ./op-node 
       cd ./op-node

       export L1_RPC_KIND=basic
       export L1_RPC_URL=<YOUR_RPC_URL>
       export L1_BEACON_URL=<YOUR_BEACON_URL>
       # prepare delta_testnet_rollup.json
       curl -LO https://raw.githubusercontent.com/QuarkChain/pm/refs/heads/main/L2/assets/mainnet_rollup.json
       mkdir safedb

       export PUBLIC_IP=<YOUR_PUBLIC_IP>

       ./build/bin/op-node --l2=http://localhost:8551 \
           --l2.jwt-secret=./jwt.txt \
           --verifier.l1-confs=4 \
           --rollup.config=./mainnet_rollup.json \
           --rpc.port=8547 \
           --p2p.listen.ip=0.0.0.0 \
           --p2p.listen.tcp=9003 \
           --p2p.listen.udp=9003 \
           --p2p.advertise.ip=$PUBLIC_IP \
           --l1=$L1_RPC_URL \
           --l1.rpckind=$L1_RPC_KIND \
           --l1.beacon=$L1_BEACON_URL \
           --l1.beacon-archiver=https://archive.mainnet.ethstorage.io:9645 \
           --l1.cache-size=0 \
           --safedb.path=safedb \
           --syncmode=execution-layer | tee -a node.log -i
   ```

## Delta Testnet

### Software dependencies

| Dependency                                        | Version | Version Check Command |
| ------------------------------------------------- | ------- | --------------------- |
| [git](https://git-scm.com/)                       | `^2`    | `git --version`       |
| [go](https://go.dev/)                             | `^1.21` | `go version`          |
| [make](https://linux.die.net/man/1/make)          | `^3`    | `make --version`      |
| [just](https://just.systems/man/en/packages.html) | `^1.34` | `just --version`      |

### Steps

1. Follow the following steps to build a node. The steps are basically the same as in [Optimism's documentation](https://docs.optimism.io/builders/node-operators/tutorials/node-from-source), the only difference is that here we use the `delta_testnet` branch of both [our optimism fork](https://github.com/QuarkChain/optimism/tree/delta_testnet) and [our op-geth fork](https://github.com/QuarkChain/op-geth/tree/delta_testnet) instead.

* 1.1 Build `op-geth`

  ```bash
  git clone -b delta_testnet https://github.com/QuarkChain/op-geth.git
  pushd op-geth && make geth && popd
  ```
* 1.2 Build `op-node`

  ```bash
  git clone -b delta_testnet https://github.com/QuarkChain/optimism.git
  pushd optimism && make op-node && popd
  ```

2. Setup `op-geth`:

   > The default settings are for full nodes with snap sync. For configurations related to full sync or archive nodes, please refer to the [Sync modes](#sync-modes) section.

   ```bash
       # assume optimism and op-geth repo are located at ./optimism and ./op-geth

       cd op-geth
       # prepare gamma_testnet_genesis.json
       curl -LO https://raw.githubusercontent.com/QuarkChain/pm/main/L2/assets/delta_testnet_genesis.json
       ./build/bin/geth init --datadir=datadir --state.scheme hash delta_testnet_genesis.json
       openssl rand -hex 32 > jwt.txt

       export PUBLIC_IP=<YOUR_PUBLIC_IP>

       # The rpc port is the default one: 8545.
       ./build/bin/geth --datadir ./datadir   \
           --http \
           --http.corsdomain="*" \
           --http.vhosts="*" \
           --http.addr=0.0.0.0 \
           --http.api=web3,eth,txpool,net \
           --ws \
           --ws.addr=0.0.0.0 \
           --ws.port=8546 \
           --ws.origins="*" \
           --ws.api=eth,txpool,net \
           --nat="extip:${PUBLIC_IP}" \
           --networkid=110011 \
           --authrpc.vhosts="*" \
           --authrpc.port=8551 \
           --authrpc.jwtsecret=./jwt.txt \
           --rollup.disabletxpoolgossip \
           --rollup.sequencerhttp=http://65.109.110.98:8545 \
           --rollup.enabletxpooladmission 2>&1 | tee -a geth.log -i
   ```
3. Setup `op-node`:

   > ⚠️ The `op-node` admin RPC should not be exposed publicly. If left exposed, it could accidentally expose admin controls to the public internet.

   > Sync mode is set to `--syncmode=execution-layer` to enable snap sync.

   ```bash
       # assume optimism and op-geth repo are located at ./optimism and ./op-geth
       # copy jwt.txt from the op-geth directory above to optimism/op-node
       cp op-geth/jwt.txt optimism/op-node 
       cd optimism/op-node

       export L1_RPC_KIND=basic
       export L1_RPC_URL=http://65.108.230.142:8545
       export L1_BEACON_URL=http://65.108.230.142:3500
       # prepare delta_testnet_rollup.json
       curl -LO https://raw.githubusercontent.com/QuarkChain/pm/main/L2/assets/delta_testnet_rollup.json

       export PUBLIC_IP=<YOUR_PUBLIC_IP>
       mkdir safedb
       # Ensure to replace --p2p.static with the sequencer's address.
       # Note: p2p is enabled for unsafe block.
       ./bin/op-node --l2=http://localhost:8551 \
           --l2.jwt-secret=./jwt.txt \
           --verifier.l1-confs=4 \
           --rollup.config=./delta_testnet_rollup.json \
           --rpc.port=8547 \
           --p2p.listen.ip=0.0.0.0 \
           --p2p.listen.tcp=9003 \
           --p2p.listen.udp=9003 \
           --p2p.advertise.ip=$PUBLIC_IP \
           --l1=$L1_RPC_URL \
           --l1.rpckind=$L1_RPC_KIND \
           --l1.beacon=$L1_BEACON_URL \
           --l1.beacon-archiver=https://archive.testnet.ethstorage.io:9635 \
           --l1.cache-size=0 \
           --safedb.path=safedb \
           --syncmode=execution-layer | tee -a node.log -i
   ```


# Contract addresses

### Mainnet

#### Mainnet L1 address

```json
{
    "SuperchainProxyAdminImpl": "0x39f6ef46f0c1fb978298ef9fdb7a600610f65875",
    "SuperchainConfigProxy": "0x6b97e18104389b63779396e91073ec9b4388d7c6",
    "SuperchainConfigImpl": "0xce28685eb204186b557133766eca00334eb441e4",
    "ProtocolVersionsProxy": "0xa838dfa10d304f5b67db5041ce29ddf49d9a847f",
    "ProtocolVersionsImpl": "0x37e15e4d6dffa9e5e320ee1ec036922e563cb76c",
    "OpcmImpl": "0xcbf13801164dddc86d0895805b36769b70361c41",
    "OpcmContractsContainerImpl": "0x0000000000000000000000000000000000000000",
    "OpcmGameTypeAdderImpl": "0x1805e56a77e927495dd4ed9ca4cc5c04ee7b2910",
    "OpcmDeployerImpl": "0xde7158538e03a0bd22530a512562a16feb218760",
    "OpcmUpgraderImpl": "0x2b4a81b83ce461a4fcf9a3c1768a1a974a3fea2d",
    "OpcmInteropMigratorImpl": "0x881f2542fe1bda0ffddba2e79f83f2472bd2824d",
    "OpcmStandardValidatorImpl": "0xdb3a0eba8d936e8d994dd7851609b2cc4213b7df",
    "DelayedWethImpl": "0x33dadc2d1aa9bb613a7ae6b28425ea00d44c6998",
    "OptimismPortalImpl": "0x9ef630d9d41adac7ab6d67d6e2f6afbdc20d43e0",
    "OptimismPortalInteropImpl": "0xb0eb854fd842e0e564d49d2fe6b2ac25d035523c",
    "EthLockboxImpl": "0x784d2f03593a42a6e4676a012762f18775ecbbe6",
    "PreimageOracleImpl": "0x1fb8cdfc6831fc866ed9c51af8817da5c287add3",
    "MipsImpl": "0x07babe08ee4d07dba236530183b24055535a7011",
    "SystemConfigImpl": "0x2bfe4a5bd5a41e9d848d843ebcdfa15954e9a557",
    "L1CrossDomainMessengerImpl": "0x22d12e0faebd62d429514a65ebae32dd316c12d6",
    "L1Erc721BridgeImpl": "0x7f1d12fb2911eb095278085f721e644c1f675696",
    "L1StandardBridgeImpl": "0xe32b192fb1dca88fcb1c56b3acb429e32238adcb",
    "OptimismMintableErc20FactoryImpl": "0x5493f4677a186f64805fe7317d6993ba4863988f",
    "DisputeGameFactoryImpl": "0x33d1e8571a85a538ed3d5a4d88f46c112383439d",
    "AnchorStateRegistryImpl": "0x0875282c0ba2958094312eec447d0d8186033838",
    "OpChainProxyAdminImpl": "0x75025088b628aa01e52a5d770f7cec62cbd7add4",
    "OptimismPortalProxy": "0xf9ea3f50acbacb122bfb9ceb6cf79c6cfcf35c7a",
    "AddressManagerImpl": "0xcda65dcad63986b991fcf80e9c6293e82bc8f33e",
    "L1Erc721BridgeProxy": "0x6415832dfb88d8e02237a6aa691a3b79a12c8f27",
    "SystemConfigProxy": "0xbb8bed33614599947d5ca1844de546e59ea50e7a",
    "OptimismMintableErc20FactoryProxy": "0xcccb929fdcaa6e15f40aef3b78d8a006228501c4",
    "L1StandardBridgeProxy": "0x326798c62fc0d7281f3840e08226a671aa949e98",
    "L1CrossDomainMessengerProxy": "0x3137f7b40e58d9babb62f63924314ef037c400cb",
    "EthLockboxProxy": "0x961395673c7273cac77852a4c010c060fd75b0f7",
    "DisputeGameFactoryProxy": "0x61870a40eaa988515060e91e39da9c4a690b5c9b",
    "AnchorStateRegistryProxy": "0xe3f46bd5f116b3878bc5bbd95d306f876e907889",
    "FaultDisputeGameImpl": "0x0000000000000000000000000000000000000000",
    "PermissionedDisputeGameImpl": "0xfb8a8c7ec1a3bf0ab19e7734d9aaf3964ab165de",
    "DelayedWethPermissionedGameProxy": "0xc2b857d7cc34b546c2f050dfc73bda1028224eab",
    "DelayedWethPermissionlessGameProxy": "0x0000000000000000000000000000000000000000",
    "AltDAChallengeProxy": "0x0000000000000000000000000000000000000000",
    "AltDAChallengeImpl": "0x0000000000000000000000000000000000000000",
    "L2OutputOracleProxy": "0x0000000000000000000000000000000000000000"
}
```

#### Mainnet L2 addresses

```json
{
  "SoulGasToken": "0x4200000000000000000000000000000000000800"
}
```

### Delta Testnet

#### Delta Testnet L1 address

```json
{
  "SuperchainProxyAdminImpl": "0x16119bea134b18c255998583989caabcf36845c8",
  "SuperchainConfigProxy": "0x45c491ac0188cae26e0378b9e409e9795666b533",
  "SuperchainConfigImpl": "0xce28685eb204186b557133766eca00334eb441e4",
  "ProtocolVersionsProxy": "0x78ae0788d3af65e8c8c012e2258d17739ff6b89f",
  "ProtocolVersionsImpl": "0x37e15e4d6dffa9e5e320ee1ec036922e563cb76c",
  "OpcmImpl": "0x4631b0cebbbd711862cda4797d09309cd70e7fb8",
  "OpcmContractsContainerImpl": "0x0000000000000000000000000000000000000000",
  "OpcmGameTypeAdderImpl": "0xcd75b2c1a1a25c410a45fd25441f4be0df1febee",
  "OpcmDeployerImpl": "0x15226d5107e617e6c9667be8c0ff163377c643ef",
  "OpcmUpgraderImpl": "0x8cda26cb1281b56c0f8cf6868f5d2f80ef27c0f4",
  "OpcmInteropMigratorImpl": "0xd5a467252409dd9445effd2940ce8f8b2320abc7",
  "OpcmStandardValidatorImpl": "0x0fb660356cf16d41ad3106664278192b51177153",
  "DelayedWethImpl": "0x33dadc2d1aa9bb613a7ae6b28425ea00d44c6998",
  "OptimismPortalImpl": "0x9ef630d9d41adac7ab6d67d6e2f6afbdc20d43e0",
  "OptimismPortalInteropImpl": "0xb0eb854fd842e0e564d49d2fe6b2ac25d035523c",
  "EthLockboxImpl": "0x784d2f03593a42a6e4676a012762f18775ecbbe6",
  "PreimageOracleImpl": "0x1fb8cdfc6831fc866ed9c51af8817da5c287add3",
  "MipsImpl": "0x07babe08ee4d07dba236530183b24055535a7011",
  "SystemConfigImpl": "0x2bfe4a5bd5a41e9d848d843ebcdfa15954e9a557",
  "L1CrossDomainMessengerImpl": "0x22d12e0faebd62d429514a65ebae32dd316c12d6",
  "L1Erc721BridgeImpl": "0x7f1d12fb2911eb095278085f721e644c1f675696",
  "L1StandardBridgeImpl": "0xe32b192fb1dca88fcb1c56b3acb429e32238adcb",
  "OptimismMintableErc20FactoryImpl": "0x5493f4677a186f64805fe7317d6993ba4863988f",
  "DisputeGameFactoryImpl": "0x33d1e8571a85a538ed3d5a4d88f46c112383439d",
  "AnchorStateRegistryImpl": "0xeb69cc681e8d4a557b30dffbad85affd47a2cf2e",
  "OpChainProxyAdminImpl": "0xba4230fcc692838ed1c2866438cb7b6d95d5553d",
  "OptimismPortalProxy": "0x7f59517cd129c29da65768fd028990bcb436b02e",
  "AddressManagerImpl": "0x901b8de454ccde7cedd283e1aa389eadb97bda50",
  "L1Erc721BridgeProxy": "0xd9af04742b2ffff8e66e6a0345478725316995c0",
  "SystemConfigProxy": "0x41d0e63bdb755cc6492df78981ce3bf45e451636",
  "OptimismMintableErc20FactoryProxy": "0x1810789d7960cc1d810686d48328a4aff57b3229",
  "L1StandardBridgeProxy": "0x2a3e379c6689d4b37efe00843c2bcf6b4574187b",
  "L1CrossDomainMessengerProxy": "0x47a112d15e7ab56f06d0666aff9256ede18d8caf",
  "EthLockboxProxy": "0xd15aaa6dc056af7707d1605594dba7a37a9b93ba",
  "DisputeGameFactoryProxy": "0x10ffc150ebad96e483d0af6bbe8b48803b7f65d4",
  "AnchorStateRegistryProxy": "0x955e1dd1731e61f854be9d9ff86db9a870f8e7dd",
  "FaultDisputeGameImpl": "0x0000000000000000000000000000000000000000",
  "PermissionedDisputeGameImpl": "0x92698aebd4ec8e835b1d851a8df071d8d2a3f1c8",
  "DelayedWethPermissionedGameProxy": "0x51f4c67552e6159429f7c7643828ad26c12178c3",
  "DelayedWethPermissionlessGameProxy": "0x0000000000000000000000000000000000000000",
  "AltDAChallengeProxy": "0x0000000000000000000000000000000000000000",
  "AltDAChallengeImpl": "0x0000000000000000000000000000000000000000",
  "L2OutputOracleProxy": "0x0000000000000000000000000000000000000000"
}
```

#### Delta Testnet L2 addresses

```json
{
  "SoulGasToken": "0x4200000000000000000000000000000000000800"
}
```


# RPC configurations

### Mainnet

```
Bridge: https://migration.mainnet.l2.quarkchain.io
Explorer：https://explorer.mainnet.l2.quarkchain.io
RPC: https://rpc.mainnet.l2.quarkchain.io:8545
```

### Delta Testnet

```
Bridge: https://migration.delta.testnet.l2.quarkchain.io
Faucet: https://qkc-l2-delta-faucet.eth.sep.web3gateway.dev
Explorer：https://explorer.delta.testnet.l2.quarkchain.io
RPC: https://rpc.delta.testnet.l2.quarkchain.io:8545
```


# Links

* 📢 **Discord**: <https://discord.com/invite/GbkGhY3qkh>
* 💬 **Telegram**: <https://t.me/quarkchainio>
* 🐦 **Twitter**: <https://x.com/quark_chain>


# Whitepaper