taikoxyz/taiko-client

Taiko's client implementation in Go. 🔧

taiko-client

Taiko protocol's client software implementation in Go. Learn more about Taiko nodes with the docs.

Project structure

Path	Description
bindings/	Go contract bindings for Taiko smart contracts, and few related utility functions
cmd/	Main executable for this project
docs/	Documentation
driver/	Driver sub-command
integration_test/	Scripts to do the integration testing of all client software
metrics/	Metrics related
pkg/	Library code which used by all sub-commands
proposer/	Proposer sub-command
prover/	Prover sub-command
scripts/	Helpful scripts
testutils/	Test utils
version/	Version information

Build the source

Building the taiko-client binary requires a Go compiler. Once installed, run:

make build

Usage

Review all available sub-commands:

bin/taiko-client --help

Review each sub-command's command line flags:

bin/taiko-client <sub-command> --help

Testing

Ensure you have Docker running, and pnpm installed.

Then, run the integration tests:

1. Start Docker locally
2. Perform a pnpm install in taiko-mono/packages/protocol
3. Replace <PATH_TO_TAIKO_MONO_REPO> and execute:

TAIKO_MONO_DIR=<PATH_TO_TAIKO_MONO_REPO> make test

taiko-client's Issues

fix: L2 execution engine is syncing SyncProgress

summary

I am seeing the SyncProgress outputted by the simple-taiko-node-taiko_client_prover_relayer is showing nil.

example log: progress="&{SyncProgress:<nil> CurrentBlockID:+14309 HighestBlockID:+130426}

.env context

DISABLE_P2P_SYNC is set to true. proposer is disabled, only prover is enabled.

Use a reusable `commitSlot` when committing blocks to save gas

• taikoxyz/taiko-mono#321

feat(prover): add `--graffiti` flag

Update:

          Update:

in both transactions prover set to:
prover : 0x0000000000000000000000000000000000000001

Is that legitimate?

Originally posted by @davaymne in #302 (comment)

Yes, 0x00 and 0x000...1 are two special proof addresses that provide oracle and system proofs for the blocks that are not configured to accept real proofs (ie: modulo 10, the current config realProofSkipSize). They are controlled by Taiko.

Add block verified logs in driver

feat(prover): implement PoS in client

Change order of proofs in evidence and rename `finalize` to `verify`

• taikoxyz/taiko-mono#288
• taikoxyz/taiko-mono#298

Contract accepts (Success) 2 x Prove Block tx for the same block from different provers

There are 2 x successful tx with Prove Block which are related to the same block 499890:

https://sepolia.etherscan.io/tx/0xc37145560cd06d532a320ce7f7b23883915747deb725bc1ccf5b7985ec92f0a0
https://sepolia.etherscan.io/tx/0x28c1433271c1577a192288348488c6e63c4a7168cc5b06ba5b2eaeb7e60afb39

The only one MUST be success.

Ethereum A1 test network tap can not receive test coins

Ethereum A1 test network tap can not receive test coins

Move the public input assembly logic from client software into smart contract

Check solidity custom errors in Go client

gaxle pover and proposer quest

Can we create a website for pover and proposer node users to submit their Galxe task addresses? Since most node users are running on newly generated addresses on servers, would you use your main address to run on a centralized server? Obviously, we need a website that allows for custom submissions, and uses wallet signatures to determine the address ownership, so that node users can customize their own Galxe task addresses

Wait random durations before submit dummy proofs

Review driver's reorg handling logic

When we running alpha-2, we observed that sometimes the driver didn't handle the reorg correctly (the L2 chain still had the block which was based on the reorged BlockProposed event), so the reorg handling logic should have some issues.

feat: auto version the version.go file in taiko-client release please

I will take this eventually, but it is also a good first issue for any community member.

There are two approaches to auto-updating the version.go file as part of the release-please-action for automatic changelogs (second is preferred).

1. Use the context of the release-please-action, and extend the action and do a manual sed replace in the version.go file
2. Get official release-please support, follow my conversation here: googleapis/release-please#1112 (comment)
3. Check the comment below which specifies an extra-files param

Implement client side hardfork

For the next protocol upgrade (with tokenmocis), we need to implement a client hardfork to learn necessary lessons about how we handle upgradability as a L2.

feat(prover): integrate new circuits for next L3 network

feat: implement release please on client repo

Add a documentation for client softwares

Also document changes that differ from the original Ethereum protocol

A how-to-use guide for starting a node

• taikoxyz/simple-taiko-node#1

Do research and add prometheus metrics to client softwares

feat(bindings): add `TaikoData.EthDeposit[] depositsProcessed` field to `blockMetadataComponents`

Add TaikoData.EthDeposit[] depositsProcessed field to blockMetadataComponents and add corresponding tests to make sure EncodeBlockMetadata equals to solidity's abi.encode(blockMetadata).

https://github.com/taikoxyz/taiko-client/blob/update-protocol-bindings/bindings/encoding/input.go#LL45C18-L45C99

Ignore the proof generation when the corresponding block is verified

see: #182

Start a RPC service endpoint (reuse the implementation in `zkevm-chain`) to run `zkevm-circuits`, then remove the `zkevm-circuits` binary in `taiko-client`

feat: get type of node (node/proposer/prover)

Any possibility to fetch from the taiko node which type it is (node/proposer/prover)? I don't think we can right now but maybe this could be useful? Feel free to close this issue if you think otherwise :)

feat(proposer): check if transaction's `nonce` is ready to be included before proposing

Right now i believe we only sort the nonces of pending transactions before proposing, but in current implementation, if the latest nonce of an address is 100, but the smallest nonce in mempool is 102, we will still keep proposing it. And maybe we should only update the taiko_txPoolContent API in taiko-geth instead of client.

When proposing a transactions list, submit the block information at the same time

Bug: Failed to start Taiko client

Taiko-client failed to start, the error message is belowing.

CRIT [05-06|20:10:17.557] Failed to start Taiko client             error="abi: improperly encoded uint64 value"

After I searched for a while, I found that this error is caused by autogenerated code, which interacts with l1 contract.

Implement EIP-4844 Proto-Danksharding on client side

Implement protocol's new EIP-1559 fee

taikoxyz/taiko-mono#13468

“Block prove” tx fails while following tx for the same block prove was successfull

There are 2 x “Block prove” txs regarding block 515570:

• https://sepolia.etherscan.io/tx/0x54327bc7a27c41d9b983390a710cb0cc06141fb0f3deaec9f76a3590f616e150
  Sent in block: 3812149 with status: “failed” execution reverted
• https://sepolia.etherscan.io/tx/0x5304bfca9e4dfb8bf38877d6acd631030160478c20cab9896f69456ba2b25b2b
  Sent in block: 3812153 with status: “success”

Could you pls clarify the reason the 2nd TX got success while it was submitted after the 1st one which failed.

Deploy an internal devnet using the current "dummy verification contract"

https://console.cloud.google.com/kubernetes/workload/overview?project=evmchain&pageState=(%22savedViews%22:(%22i%22:%2237d28b54406745a1ba4a2e8504f3692e%22,%22c%22:%5B%22gke%2Fus-central1%2Finternal-devnet-autopilot-cluster%22%5D,%22n%22:%5B%5D))

feat(prover): only submit an oracle proof when there is a new invalid normal proof

feat(prover): implement auction in client

Comment HIVE integration test results in client's PRs

Failed to using P2P sync where lastSyncedVerifiedBlockID==1 or LatestVerifiedHeight == 1

This happened when there was only one block to be verified on L1

Generate PoW proofs and verify them in contract

Deploy a grafana dashboard in K8S to monitory our own nodes and services

Introduce randomness when building the `txList` to propose

Client makes taiko-geth lag to last verified block

I updated to the latest taiko-client on git, commit 949f376 on branch grimsvotn

My node was then stuck on the "Last Verified Block" and didn't sync to the latest block on L2

Constant state of 30 minute lag. I reset the node and re-synced 4 times and it was consistent.

The logs from the execution engine (taiko-geth)

INFO [06-16|19:50:32.473] Imported new potential chain segment     number=195,809 hash=632700..400460 blocks=1    txs=1     mgas=0.128    elapsed="530.507µs" mgasps=240.986  age=30m8s     dirty=56.22MiB
INFO [06-16|19:50:32.473] Recovered head state                     number=195,809 hash=632700..400460
INFO [06-16|19:50:32.473] Extend chain                             add=10 number=195,809 hash=632700..400460
INFO [06-16|19:50:32.474] Chain head was updated                   number=195,809 hash=632700..400460
WARN [06-16|19:50:44.597] Ignoring already known beacon payload    number=195,809 hash=632700..400460 age=30m20s
WARN [06-16|19:50:56.718] Ignoring already known beacon payload    number=195,809 hash=632700..400460 age=30m32s

Meanwhile, the taiko-client had a lot of this in the logs

unexpected ForkchoiceUpdate response status: VALID

I rolled back to commit cb4dada and then it synced right and everything worked.

Trigger hive tests by PR branch

A normal prover should at least wait `protocolConfig.targetProofTime` seconds before submitting proofs

For hive result comment, update existing instead of adding one

Prover still running for already proven block

I'm running the prover, and it attempted to prove block 35917.

I see the following log:

simple-taiko-node-taiko_client_driver-1          | INFO [03-26|20:39:14.544] ✅ Valid block proven                     blockID=35917 hash=1fb0ee..b04435 prover=0x6798639591530FbBAfd12c2826422B58bD2c5219

Then I still constantly see the following log:

simple-taiko-node-taiko_client_prover_relayer-1  | INFO [03-26|20:47:44.022] Request proof                            height=35917 output=<nil>

Shouldn't the proving process be stopped when someone else has already generated a proof?

feat(all): optimize gas estimation

eth_estimateGas doesn't work well when there are lots of blocks to be verified in protocol.

feat(proposer): check current proposer's Taiko token balance && block fee before each proposing operation

Merge all client binaries as one and support sub-commands

Merge all client binary as one and support sub-commands, output one single Docker images.

Change client code accordingly after protocol tokenomics v1 PR merged

• https://github.com/taikoxyz/taiko-mono/pull/243/files

Estimate `tx.gasUsed` before proposing

Update client softwares based on the new protocol upgrade

taikoxyz/taiko-mono#13389