fix ut

.github/ISSUE_TEMPLATE/bug.md

@@ -1,14 +1,14 @@
 ---
 name: Report a bug
-about: Something with Polygon zkEVM is not working as expected
+about: Something with X1 is not working as expected
 title: ''
 labels: 'type:bug'
 assignees: ''
 ---
 
 #### System information
 
-zkEVM Node version: `v0.0.X-RCXX`
+X1 Node version: `v0.0.X-RCXX`
 OS & Version: `Windows/Linux/OSX`
 Commit hash : (if `develop`)
 Network: `Mainnet/Testnet`

.github/workflows/test-e2e.yml

@@ -17,7 +17,7 @@ jobs:
       matrix:
         go-version: [ 1.21.x ]
         goarch: [ "amd64" ]
-        e2e-group: [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 ]
+        e2e-group: [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, dac-1 ]
     runs-on: ubuntu-latest
     steps:
     - name: Checkout code

.github/workflows/test-from-prover.yml

@@ -1,4 +1,4 @@
-name: Test from zkevm-prover call
+name: Test from x1-prover call
 on:
   workflow_call:
     inputs:
@@ -25,7 +25,7 @@ jobs:
     - name: Checkout code
       uses: actions/checkout@v3
       with:
-        repository: 0xPolygonHermez/zkevm-node
+        repository: okx/x1-node
 
     - name: Install Go
       uses: actions/setup-go@v3

Dockerfile

@@ -13,8 +13,8 @@ RUN cd /src && make build
 
 # CONTAINER FOR RUNNING BINARY
 FROM alpine:3.18.0
-COPY --from=build /src/dist/xgon-node /app/xgon-node
+COPY --from=build /src/dist/x1-node /app/x1-node
 COPY --from=build /src/config/environments/testnet/node.config.toml /app/example.config.toml
 RUN apk update && apk add postgresql15-client
 EXPOSE 8123
-CMD ["/bin/sh", "-c", "/app/xgon-node run"]
+CMD ["/bin/sh", "-c", "/app/x1-node run"]

Makefile

@@ -12,7 +12,7 @@ endif
 GOBASE := $(shell pwd)
 GOBIN := $(GOBASE)/dist
 GOENVVARS := GOBIN=$(GOBIN) CGO_ENABLED=0 GOOS=linux GOARCH=$(ARCH)
-GOBINARY := xgon-node
+GOBINARY := x1-node
 GOCMD := $(GOBASE)/cmd
 
 LDFLAGS += -X 'github.com/0xPolygonHermez/zkevm-node.Version=$(VERSION)'
@@ -80,21 +80,21 @@ build: ## Builds the binary locally into ./dist
 
 .PHONY: build-docker
 build-docker: ## Builds a docker image with the node binary
-	docker build -t xgon-node -f ./Dockerfile .
+	docker build -t x1-node -f ./Dockerfile .
 
 .PHONY: build-docker-nc
 build-docker-nc: ## Builds a docker image with the node binary - but without build cache
-	docker build --no-cache=true -t xgon-node -f ./Dockerfile .
+	docker build --no-cache=true -t x1-node -f ./Dockerfile .
 
 .PHONY: run-rpc
 run-rpc: ## Runs all the services needed to run a local zkEVM RPC node
-	docker-compose up -d xgon-state-db xgon-pool-db
+	docker-compose up -d x1-state-db x1-pool-db
 	sleep 2
-	docker-compose up -d xgon-prover
+	docker-compose up -d x1-prover
 	sleep 5
-	docker-compose up -d xgon-sync
+	docker-compose up -d x1-sync
 	sleep 2
-	docker-compose up -d xgon-rpc
+	docker-compose up -d x1-rpc
 
 .PHONY: stop
 stop: ## Stops all services

README.md

@@ -1,16 +1,16 @@
-# zkEVM Node
+# X1 Node
 
-zkEVM Node is a Go implementation of a node that operates the Polygon zkEVM Network.
+X1 Node is a Go implementation of a node that operates the X1 Network.
 
-## About the Polygon zkEVM network
+## About the X1 network
 
-Since this is an implementation of a protocol it's fundamental to understand it, [here](https://zkevm.polygon.technology/docs/zknode/zknode-overview) you can find the specification of the protocol.
+Since this is an implementation of a protocol it's fundamental to understand it, [here]() you can find the specification of the protocol.
 
 Glossary:
 
 - L1: Base blockchain where the rollup smart contracts are deployed. It's Ethereum or a testnet of Ethereum, but it could be any EVM compatible blockchain.
-- L2: the rollup network aka the Polygon zkEVM network.
-- Batch: a group of transactions that are executed/proved, using the [zkEVM prover](https://github.com/0xPolygonHermez/zkevm-prover) and sent to / synchronized from L1
+- L2: the rollup network aka the X1 network.
+- Batch: a group of transactions that are executed/proved, using the [X1 prover]() and sent to / synchronized from L1
 - Sequencer: the actor that is responsible for selecting transactions, putting them in a specific order, and sending them in batches to L1
 - Trusted sequencer: sequencer that has special privileges, there can only be one trusted sequencer. The privileges granted to the trusted sequencer allow it to forecast the batches that will be applied to L1. This way it can commit to a specific sequence before interacting with L1. This is done to achieve fast finality and reduce costs associated with using the network (lower gas fees)
 - Permissionless sequencer: sequencer role that can be performed by anyone. It has competitive disadvantages compared to the trusted sequencer (slow finality, MEV attacks). Its main purpose is to provide censorship resistance and unstoppability features to the network.
@@ -20,7 +20,7 @@ Glossary:
 - Trusted state: state reached through processing transactions that have been shared by the trusted sequencer. This state is considered trusted as the trusted sequencer could commit to a certain sequence, and then send a different one to L1
 - Virtual state: state reached through processing transactions that have already been submitted to L1. These transactions are sent in batches by either trusted or permissionless sequencers. Those batches are also called virtual batches. Note that this state is trustless as it relies on L1 security assumptions
 - Consolidated state: state that is proven on-chain by submitting a ZKP (Zero Knowledge Proof) that proves the execution of a sequence of the last virtual batch.
-- Invalid transaction: a transaction that can't be processed and doesn't affect the state. Note that such a transaction could be included in a virtual batch. The reason for a transaction to be invalid could be related to the Ethereum protocol (invalid nonce, not enough balance, ...) or due to limitations introduced by the zkEVM (each batch can make use of a limited amount of resources such as the total amount of keccak hashes that can be computed)
+- Invalid transaction: a transaction that can't be processed and doesn't affect the state. Note that such a transaction could be included in a virtual batch. The reason for a transaction to be invalid could be related to the Ethereum protocol (invalid nonce, not enough balance, ...) or due to limitations introduced by the X1 (each batch can make use of a limited amount of resources such as the total amount of keccak hashes that can be computed)
 - Reverted transaction: a transaction that is executed, but is reverted (because of smart contract logic). The main difference with *invalid transaction* is that this transaction modifies the state, at least to increment nonce of the sender.
 
 ## Architecture
@@ -31,7 +31,7 @@ Glossary:
 
 The diagram represents the main components of the software and how they interact between them. Note that this reflects a single entity running a node, in particular a node that acts as the trusted sequencer. But there are many entities running nodes in the network, and each of these entities can perform different roles. More on this later.
 
-- (JSON) RPC: an HTTP interface that allows users (dApps, metamask, etherscan, ...) to interact with the node. Fully compatible with Ethereum RPC + some extra [custom endpoints](./docs/zkEVM-custom-endpoints.md) specifics of the network. It interacts with the `state` (to get data and process transactions) as well as the `pool` (to store transactions).
+- (JSON) RPC: an HTTP interface that allows users (dApps, metamask, etherscan, ...) to interact with the node. Fully compatible with Ethereum RPC + some extra [custom endpoints]() specifics of the network. It interacts with the `state` (to get data and process transactions) as well as the `pool` (to store transactions).
 - L2GasPricer: it fetches the L1 gas price and applies some formula to calculate the gas price that will be suggested for the users to use for paying fees on L2. The suggestions are stored on the `pool`, and will be consumed by the `rpc`
 - Pool: DB that stores transactions by the `RPC` to be selected/discarded by the `sequencer` later on
 - Sequencer: responsible for building the trusted state. To do so, it gets transactions from the pool and puts them in a specific order. It needs to take care of opening and closing batches while trying to make them as full as possible. To achieve this it needs to use the executor to actually process the transaction not only to execute the state transition (and update the hashDB) but also to check the consumed resources by the transactions and the remaining resources of the batch. After executing a transaction that fits into a batch, it gets stored on the `state`. Once transactions are added into the state, they are immediately available through the `rpc`.
@@ -42,7 +42,7 @@ The diagram represents the main components of the software and how they interact
 - State: Responsible for managing the state data (batches, blocks, transactions, ...) that is stored on the `state SB`. It also handles the integration with the `executor` and the `Merkletree` service
 - State DB: persistence layer for the state data (except the Merkletree that is handled by the `HashDB` service), it stores informationrelated to L1 (blocks, global exit root updates, ...) and L2 (batches, L2 blocks, transactions, ...)
 - Aggregator: consolidates batches by generating ZKPs (Zero Knowledge proofs). To do so it gathers the necessary data that the `prover` needs as input through the `state` and sends a request to it. Once the proof is generated it sends a request to send an L1 tx to verify the proof and move the state from virtual to verified to the `ethtxmanager`. Note that provers connect to the aggregator and not the other way arround. The aggregator can handle multiple connected provers at once and make them work concurrently in the generation of different proofs
-- Prover/Executor/hashDB: service that generates ZK proofs. Note that this component is not implemented in this repository, and it's treated as a "black box" from the perspective of the node. The prover/executor has two implementations: [JS reference implementation](https://github.com/0xPolygonHermez/zkevm-proverjs) and [C production-ready implementation](https://github.com/0xPolygonHermez/zkevm-prover). Although it's the same software/binary, it implements three services:
+- Prover/Executor/hashDB: service that generates ZK proofs. Note that this component is not implemented in this repository, and it's treated as a "black box" from the perspective of the node. The prover/executor has two implementations: [JS reference implementation](https://github.com/okx/x1-proverjs) and [C production-ready implementation](https://github.com/okx/x1-prover). Although it's the same software/binary, it implements three services:
   - Executor: Provides an EVM implementation that allows processing batches as well as getting metadata (state root, transaction receipts, logs, ...) of all the needed results.
   - Prover: Generates ZKPs for batches, batches aggregation, and final proofs.
   - HashDB: service that stores the Merkletree, containing all the account information (balances, nonces, smart contract code, and smart contract storage)
@@ -64,8 +64,8 @@ Required services and components:
 
 There must be only one synchronizer, and it's recommended that it has exclusive access to an executor instance, although it's not necessary. This role can perfectly be run in a single instance, however, the JSON RPC and executor services can benefit from running in multiple instances, if the performance decreases due to the number of requests received
 
-- [`zkEVM RPC endpoints`](./docs/json-rpc-endpoints.md)
-- [`zkEVM RPC Custom endpoints documentation`](./docs/zkEVM-custom-endpoints.md)
+- [`X1 RPC endpoints`](./docs/json-rpc-endpoints.md)
+- [`X1 RPC Custom endpoints documentation`]()
 
 ### Trusted sequencer
 

ci/e2e-group-dac-1/datacommittee_test.go

@@ -0,0 +1 @@
+../../test/e2e/datacommittee_test.go

cmd/run.go

@@ -5,6 +5,14 @@ import (
 	"crypto/ecdsa"
 	"errors"
 	"fmt"
+	"net"
+	"net/http"
+	"net/http/pprof"
+	"os"
+	"os/signal"
+	"runtime"
+	"time"
+
 	dataCommitteeClient "github.com/0xPolygon/cdk-data-availability/client"
 	datastreamerlog "github.com/0xPolygonHermez/zkevm-data-streamer/log"
 	"github.com/0xPolygonHermez/zkevm-node"
@@ -34,13 +42,6 @@ import (
 	"github.com/jackc/pgx/v4/pgxpool"
 	"github.com/prometheus/client_golang/prometheus/promhttp"
 	"github.com/urfave/cli/v2"
-	"net"
-	"net/http"
-	"net/http/pprof"
-	"os"
-	"os/signal"
-	"runtime"
-	"time"
 )
 
 func start(cliCtx *cli.Context) error {

config/config_test.go

@@ -145,8 +145,8 @@ func Test_Defaults(t *testing.T) {
 			expectedValue: types.NewDuration(5 * time.Second),
 		},
 		{
-			path:          "SequenceSender.MaxTxSizeForL1",
-			expectedValue: uint64(131072),
+			path:          "SequenceSender.MaxBatchesForL1",
+			expectedValue: uint64(10),
 		},
 		{
 			path:          "SequenceSender.GasOffset",
@@ -210,7 +210,7 @@ func Test_Defaults(t *testing.T) {
 		},
 		{
 			path:          "MTClient.URI",
-			expectedValue: "zkevm-prover:50061",
+			expectedValue: "x1-prover:50061",
 		},
 		{
 			path:          "State.DB.User",
@@ -226,7 +226,7 @@ func Test_Defaults(t *testing.T) {
 		},
 		{
 			path:          "State.DB.Host",
-			expectedValue: "zkevm-state-db",
+			expectedValue: "x1-state-db",
 		},
 		{
 			path:          "State.DB.Port",
@@ -315,7 +315,7 @@ func Test_Defaults(t *testing.T) {
 		},
 		{
 			path:          "Pool.DB.Host",
-			expectedValue: "zkevm-pool-db",
+			expectedValue: "x1-pool-db",
 		},
 		{
 			path:          "Pool.DB.Port",
@@ -399,7 +399,7 @@ func Test_Defaults(t *testing.T) {
 		},
 		{
 			path:          "Executor.URI",
-			expectedValue: "zkevm-prover:50071",
+			expectedValue: "x1-prover:50071",
 		},
 		{
 			path:          "Executor.MaxResourceExhaustedAttempts",

config/default.go

@@ -16,7 +16,7 @@ Outputs = ["stderr"]
 	User = "state_user"
 	Password = "state_password"
 	Name = "state_db"
-	Host = "xgon-state-db"
+	Host = "x1-state-db"
 	Port = "5432"
 	EnableLog = false	
 	MaxConns = 200
@@ -58,7 +58,7 @@ FreeGasAddress = "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"
 	User = "pool_user"
 	Password = "pool_password"
 	Name = "pool_db"
-	Host = "xgon-pool-db"
+	Host = "x1-pool-db"
 	Port = "5432"
 	EnableLog = false
 	MaxConns = 200
@@ -146,7 +146,7 @@ MaxTxLifetime = "3h"
 [SequenceSender]
 WaitPeriodSendSequence = "5s"
 LastBatchVirtualizationTimeMaxWaitPeriod = "5s"
-MaxTxSizeForL1 = 1000
+MaxBatchesForL1 = 10
 L2Coinbase = "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266"
 PrivateKey = {Path = "/pk/sequencer.keystore", Password = "testonly"}
 UseValidium = true
@@ -174,10 +174,10 @@ CleanHistoryPeriod = "1h"
 CleanHistoryTimeRetention = "5m"
 
 [MTClient]
-URI = "xgon-prover:50061"
+URI = "x1-prover:50061"
 
 [Executor]
-URI = "xgon-prover:50071"
+URI = "x1-prover:50071"
 MaxResourceExhaustedAttempts = 3
 WaitOnResourceExhaustion = "1s"
 MaxGRPCMessageSize = 100000000
@@ -191,7 +191,7 @@ Enabled = false
 User = "prover_user"
 Password = "prover_pass"
 Name = "prover_db"
-Host = "xgon-state-db"
+Host = "x1-state-db"
 Port = "5432"
 EnableLog = false
 MaxConns = 200