# Advisories Understand before becoming a validator reference: # Proof of stake JBC Blockchain uses proof-of-stake to reach a consensus. For this, we need active participants—known as validators—to propose, verify, and vouch for the validity of blocks. In exchange, honest validators receive financial rewards. Importantly, as a validator you'll need to post JBC as collateral—in other words, have some funds at stake. The only way to become a validator is to make a one-way JBC transaction to the deposit contract on the Mainnet execution layer. The Beacon Chain (consensus layer) is used in parallel to keep track of all validator activity. * [x] I understand proof-of-stake and why validators are needed. # The Deposit To become a validator on the Beacon Chain, you need to deposit 32 JBC per validator that you wish to run. Like all JCB transactions, deposits are non-reversible, but the ability to withdraw your funds via a separate process after depositing remains under your control. * [x] I understand that I need to deposit 32 JBC onto the Beacon Chain to become a validator. Withdrawing deposited JBC from the Beacon Chain is accomplished via a separate process. # The Terminal Using the terminal To become a validator, you will need to be able to run commands in the terminal on your computer. Generating your new key pairs and installing the validator software are both done in the terminal. * [x] I am technically capable of setting up and running a validator. # Validator uptime You'll only get your full rewards if your validator is online and up to date. This is your responsibility. If your validator goes offline you'll be penalized. The penalties for being offline are roughly equal to the rewards for actively participating. * [x] I understand that it is important to keep my validator online and updated. # Bad behavior Bad validator behavior If you try to cheat the system or act contrary to the specification, you will be liable to incur a penalty known as slashing\*. Running your validator keys simultaneously on two or more machines will result in slashing. \*Simply being offline with an otherwise healthy network does not result in slashing, but will result in small inactivity penalties. * [x] I understand that if I act contrary to the specification, I am liable to be slashed. # Key management To become a validator you'll need to know about managing keys and protecting a mnemonic. If you are not yet familiar with keys and mnemonics, please do not proceed. We'll help you create a signing key for every validator you want to run. You may choose to provide a withdrawal address for your validator when generating your deposit data, which will permanently set the withdrawal address. This is recommended for most users. If you do not provide a withdrawal address with your initial deposit data, you will need to derive your withdrawal keys from your mnemonic at a later time, so **store your mnemonic safely**—it will be the ONLY way to withdraw your ETH when you choose to activate withdrawals. * [x] I understand that keys are my responsibility and that my mnemonic (seed) will be the **ONLY WAY** to withdraw my funds if I don't provide a withdrawal address with initial deposit data. # Early adopter risks You're joining a network in its early stages. As with any new piece of software, there is the potential for software bugs. While unlikely, potential bugs may result in slashing. * [x] I am an early adopter, and I accept that software and design bugs may result in me being slashed. # Nodes & Validators # Generate Validator Keys How to generate validator keys for JIB Chain #### Build Requirement * [Python **3.8+**](https://www.python.org/about/gettingstarted/) * [pip3](https://pip.pypa.io/en/stable/installing/) #### For Linux or MacOS users **File Permissions** On Unix-based systems, keystores and the `deposit_data*.json` have `440`/`-r--r-----` file permissions (user & group read only). This improves security by limiting which users and processes that have access to these files. If you are getting `permission denied` errors when handling your keystores, consider changing which user/group owns the file (with `chown`) or, if need be, change the file permissions with `chmod` *** #### Get Started to generate validator keys 1. Clone the Deposit-CLI repository from JIBChain-net Github ```sh git clone https://github.com/jibchain-net/deposit-cli.git && cd deposit-cli ``` 2. Install dependencies (Ensure you are using Python version >= Python3.8) ```sh pip3 install -r requirements.txt python3 setup.py install # Or use the helper script ./deposit.sh install ``` 3. Create key and `deposit_data-*.json` ```sh mkdir validator_keys-test ``` ```sh ./deposit.sh new-mnemonic --num_validators= --mnemonic_language=english --chain=jib --eth1_withdrawal_address= --folder=validator_keys-test ``` Example: ```sh ./deposit.sh new-mnemonic --num_validators=1 --mnemonic_language=english --chain=jib --eth1_withdrawal_address= --folder=validator_keys-test ``` 4. Create your password and confirm your password ``` Running deposit-cli... ***Using the tool on an offline and secure device is highly recommended to keep your mnemonic safe.*** Please choose your language ['1. العربية', '2. ελληνικά', '3. English', '4. Français', '5. Bahasa melayu', '6. Italiano', '7. 日本語', '8. 한국어', '9. Português do Brasil', '10. român', '11. Türkçe', '12. 简体中文']: [English]: Create a password that secures your validator keystore(s). You will need to re-enter this to decrypt them when you setup your Ethereum validators.: Repeat your keystore password for confirmation: ``` 5. Remember your mnemonic key ``` This is your mnemonic (seed phrase). Write it down and store it safely. It is the ONLY way to retrieve your deposit. onion margin nuclear expire december wild fever actress educate picnic key urge slow tape fruit quantum dial hero curtain disorder exercise lawsuit fashion dash Press any key when you have written down your mnemonic. ``` 6. Put your mnemonic key to verify that you saved ``` Please type your mnemonic (separated by spaces) to confirm you have written it down. Note: you only need to enter the first 4 letters of each word if you'd prefer. : onion margin nuclear expire december wild fever actress educate picnic key urge slow tape fruit quantum dial hero curtain disorder exercise lawsuit fashion dash ``` 7. Waiting for generate key ``` ##### ##### ## ##### ## ### ## ####### ######################### ## ## ##### ## ## ## ##### ## ## ## ## ## ### ######## ## #### ## ## ### ##### ##### # ## # ##### # # # ##### ## ## ## ## ## ## ## ### ## ## ############### ## ## ### ## ## ############################# ## ## ### ####### ################# ### ## ## ## ## ## ### ############## ############# Creating your keys. Creating your keystores: [####################################] 1/1 Success! Your keys can be found at: validator_keys-test/validator_keys Press any key. ``` 8. Your keys can be found at: `validator_keys-test/validator_keys` ```sh cd validator_keys-test/validator_keys && ls -la ``` example: ``` total 16 drwxr-xr-x 4 user staff 128 Dec 3 15:14 . drwxr-xr-x 3 user staff 96 Dec 3 15:14 .. -r--r----- 1 user staff 702 Dec 3 15:14 deposit_data-1701591267.json -r--r----- 1 user staff 710 Dec 3 15:14 keystore-m_12381_3600_0_0_0-1701591267.json ``` *** > If you input --num\_validators more than 1, the list of files will show keystore-m\_ equal to the number of validators that you input # Deposit JBC How to deposit JBC to your validator keys Visit JBC Staking launchpad:

JBC Staking Launchpad

1. Click the **"BECOME A VALIDATOR"** Button 2. Upload the deposit data that you generated, Choose `deposit_data-*.json` NOT a `keystore` file.

** Choose deposit_data file **

3. If correct will show the following:

Upload the correct file!

4. Click the "CONTINUE" button 5. Connect a wallet that uses "JBC Network"

Recommended wallet: Metamask

6. Choose a wallet that has a JBC Token

Choose and Connect

7. If correct will show the following:
8. Click the "CONTINUE" button 9. The summary page will be shown, recheck your validator information and understand/accept the risk
10. Click the "CONTINUE" button 11. Confirm deposit
12. Confirm transaction to deposit:
13. Check your transaction from Block Explorer on the JBC deposit contract: Visit: 14. Check your parameters: that is your validator public key!
# Become a Validator # Prerequisites #### Hardware and Software Requirements (Recommended): * CPU >= `1 core` * RAM >= `2 GiB` * Disk Space >= `10GiB (SSD)` * Linux OS `(Ubuntu or Debian)` * Docker * Install for `Ubuntu`: * Install for `Debian`: * Build essential tools: ``` sudo apt update && sudo apt install build-essential ``` * Editor software on the Linux command line * `vim` or `nano` *** #### Software Checklist 1. Make ```sh make -v ``` Example: ``` GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-apple-darwin11.3.0 ``` 2. Docker ```sh docker -v ``` Example: ``` Docker version 23.0.5, build bc4487a ``` 3. Docker compose ```sh docker compose version ``` Example: ``` Docker Compose version v2.17.3 ``` # Running a Validator Visit the JBC Node repository: ## PLEASE USE NORMAL \`USER\` NOT \`ROOT\` #### How to run a validator node 1. Clone JBC Node on your node machine: ```sh cd ~ git clone https://github.com/jibchain-net/node.git jbc-node cd jbc-node ``` 2. Check node file ```sh ls -la ``` Example: ``` total 64 drwxr-xr-x 14 user staff 448 Dec 3 16:37 . drwxr-xr-x 4 user staff 128 Dec 3 16:05 .. -rw-r--r-- 1 user staff 682 Dec 3 16:07 .env.example drwxr-xr-x 14 user staff 448 Dec 3 16:20 .git -rw-r--r-- 1 user staff 9 Dec 3 16:08 .gitignore -rw-r--r-- 1 user staff 581 Dec 3 16:17 Makefile -rw-r--r-- 1 user staff 569 Dec 3 16:05 README.md drwxr-xr-x 11 user staff 352 Dec 3 16:05 config -rw-r--r-- 1 user staff 1518 Dec 3 16:05 docker-compose.yaml -rw-r--r-- 1 user staff 1121 Dec 3 16:05 genesis.json -rwxr-xr-x 1 user staff 216 Dec 3 16:05 init-script.sh drwxr-xr-x 4 user staff 128 Dec 3 16:11 keys -rw-r--r-- 1 user staff 466 Dec 3 16:19 validator.yaml ``` 3. Create an Environment file with: ```sh make env ``` 4. Edit `.env` file * `VALIDATOR NODE`: Edit on the VALIDATOR Configuration section only * `NODE_GRAFFITI`: *use your node's graffiti flag to include a short text in the blocks that your node creates* * `PUBLIC_BEACON_NODE` : If you're running a full node change to your beacon node. * `FEE_RECIPIENT` : Input your JBC address to receive transaction fees * `FULL NODE`: Edit BOOTNODE Configuration too * `NODE_PUBLIC_IP` : your machine's public IP address (IPv4) ``` ## BOOTNODE Configuration NETWORK_ID=8899 EXECUTION_BOOTNODES=enode://74f719d76fbced15a34164de149815cb3dd3404153ca3759dae442f835b570920bdc60759693b466df2be8307d7e30715662605995c2c96c2259bac1d9a31967@65.108.126.254:32324 BOOTNODE_ENR=enr:-MS4QDTd7LbtmtvUhbLWbHZ4o2jWmfMl-5hfgHpCh4Arl1NIWGY3bt8ztKJIV3uTEeWf_xRbRy9ASoK7dCtYGam4yZEQh2F0dG5ldHOIAAAAAAAAAACEZXRoMpAY_TCCQACImf__________gmlkgnY0gmlwhEFsfv6EcXVpY4IjjYlzZWNwMjU2azGhAtJJHhhHUQ_QDG-IIXIH-VeIB5ELxroUrHf8D7s5_CsliHN5bmNuZXRzAIN0Y3CCI4yDdWRwgiOM TARGET_PEERS=1 NODE_PUBLIC_IP=xx.xx.xx.xxx ## VALIDATOR Configuration NODE_GRAFFITI=JBCValidatorClient PUBLIC_BEACON_NODE="http://119.59.123.101:5002/" FEE_RECIPIENT=0x00000000000 ``` 5. Create keystore file From [Generate Validator Keys](/nodes-and-validators/generate-validator-keys) section. You will receive a key pair ``` total 16 drwxr-xr-x 4 user staff 128 Dec 3 15:14 . drwxr-xr-x 3 user staff 96 Dec 3 15:14 .. -r--r----- 1 user staff 702 Dec 3 15:14 deposit_data-1701591267.json -r--r----- 1 user staff 710 Dec 3 15:14 keystore-m_12381_3600_0_0_0-1701591267.json ``` Copy `keystore-m_.json` to folder `keys` Example:

if have more than 1 key please copy all keys

6. Import validator key ```sh make import-validator-key ``` Example: ``` docker run -ti --rm -v ./data/lighthouse:/root/lighthouse -v ./data/lighthouse/custom/validators:/root/.lighthouse/custom/validators -v ./config:/config -v ./keys:/keys sigp/lighthouse lighthouse account validator import --directory=/keys --testnet-dir=/config Running account manager for custom (/config) network validator-dir path: "/root/.lighthouse/custom/validators" WARNING: DO NOT USE THE ORIGINAL KEYSTORES TO VALIDATE WITH ANOTHER CLIENT, OR YOU WILL GET SLASHED. Keystore found at "/keys/keystore-m_12381_3600_0_0_0-1701591267.json": - Public key: 0x92d768771c062137e7433fd27072330b14b75d94379432098916ea145d648d2aa84daa448fce166a943315e2644068b6 - UUID: 96bcdd0c-e0ef-48c2-8bff-7930965c86aa If you enter the password it will be stored as plain-text in validator_definitions.yml so that it is not required each time the validator client starts. Enter the keystore password, or press enter to omit it: ``` **INPUT YOUR VALIDATOR KEY PASSWORD** If a password is correct and imported successfully will be shown: ``` Password is correct. Successfully imported keystore. Successfully updated validator_definitions.yml. Successfully imported 1 validators (0 skipped). WARNING: DO NOT USE THE ORIGINAL KEYSTORES TO VALIDATE WITH ANOTHER CLIENT, OR YOU WILL GET SLASHED. ``` > If you have more than 1 key store. you will input a password equal number of Keystore 7. The system will create a folder `data` ```sh ls -la data/lighthouse/custom/validators/ ``` Example: ``` total 64 drwxr-xr-x 5 user staff 160 Dec 3 16:49 . drwxr-xr-x 3 user staff 96 Dec 3 16:48 .. drwxr-xr-x 3 user staff 96 Dec 3 16:49 0x92d768771c062137e7433fd27072330b14b75d94379432098916ea145d648d2aa84daa448fce166a943315e2644068b6 -rw------- 1 user staff 28672 Dec 3 16:49 slashing_protection.sqlite -rw------- 1 user staff 425 Dec 3 16:49 validator_definitions.yml ``` You will see your validator public key that you imported! 8. Run a Validator node ```sh make run-validator ``` Example: ``` docker compose -f validator.yaml up -d [+] Running 2/2 ✔ Network node_default Created ✔ Container jbc-validator Started ``` 9. Check a validator logs ```sh make validator-logs ``` ``` docker compose -f validator.yaml logs jbc-validator | Dec 03 09:55:50.134 INFO Logging to file path: "/root/.lighthouse/custom/validators/logs/validator.log" jbc-validator | Dec 03 09:55:50.134 INFO Lighthouse started version: Lighthouse/v4.5.0-441fc16 jbc-validator | Dec 03 09:55:50.134 INFO Configured for network name: custom (/config) jbc-validator | Dec 03 09:55:50.135 INFO Starting validator client validator_dir: "/root/.lighthouse/custom/validators", beacon_nodes: ["http://119.59.123.101:5002/"] jbc-validator | Dec 03 09:55:50.135 INFO HTTP metrics server is disabled jbc-validator | Dec 03 09:55:50.150 INFO Completed validator discovery new_validators: 0 jbc-validator | Dec 03 09:55:50.739 INFO Enabled validator voting_pubkey: 0x92d768771c062137e7433fd27072330b14b75d94379432098916ea145d648d2aa84daa448fce166a943315e2644068b6, signing_method: local_keystore jbc-validator | Dec 03 09:55:51.352 INFO Modified key_cache saved successfully jbc-validator | Dec 03 09:55:51.353 INFO Initialized validators enabled: 1, disabled: 0 jbc-validator | Dec 03 09:55:51.399 INFO Initialized beacon node connections available: 1, total: 1 jbc-validator | Dec 03 09:55:51.409 INFO Loaded validator keypair store voting_validators: 1 jbc-validator | Dec 03 09:55:51.409 INFO Pruning slashing protection DB msg: pruning may take several minutes the first time it runs, epoch: 1142 jbc-validator | Dec 03 09:55:51.409 INFO Completed pruning of slashing protection DB jbc-validator | Dec 03 09:55:51.418 INFO HTTP API server is disabled jbc-validator | Dec 03 09:55:51.418 INFO Genesis has already occurred seconds_ago: 438700 jbc-validator | Dec 03 09:55:51.418 INFO Block production service started service: block jbc-validator | Dec 03 09:55:51.418 INFO Attestation production service started next_update_millis: 7581, service: attestation jbc-validator | Dec 03 09:55:51.418 INFO Sync committee service started next_update_millis: 7581, service: sync_committee jbc-validator | Dec 03 09:55:51.418 INFO Validator registration service started service: preparation jbc-validator | Dec 03 09:55:51.418 INFO Proposer preparation service started service: preparation jbc-validator | Dec 03 09:55:51.418 INFO Doppelganger protection disabled. jbc-validator | Dec 03 09:56:05.000 INFO Connected to beacon node(s) synced: 1, available: 1, total: 1, service: notifier jbc-validator | Dec 03 09:56:05.000 INFO Awaiting activation slot: 36559, epoch: 1142, validators: 1, service: notifier jbc-validator | Dec 03 09:56:17.003 INFO Connected to beacon node(s) synced: 1, available: 1, total: 1, service: notifier jbc-validator | Dec 03 09:56:17.003 INFO Awaiting activation slot: 36560, epoch: 1142, validators: 1, service: notifier ``` **Await validator activation and have fun!!** 10. Stop validator ```sh make stop-validator ``` # Withdrawal * Set new withdrawal credential for the validator is not set a `--eth1_withdrawal_address` [Set new withdrawal credential](/withdrawal/set-new-withdrawal-credential) * Voluntary validator exit [Voluntary validator exit](/withdrawal/voluntary-validator-exit) # Set new withdrawal credential How to set new withdrawal credential > For a validator key that is not set a `--eth1_withdrawal_address` 1. Open folder `deposit-cli` that used to generate validator keys

deposit-cli that consist of validator_keys-test folder

2. Use command to generate bls to change execution change ```sh ./deposit.sh generate-bls-to-execution-change ```
* Enter for select English language * Enter the network * Enter: `jib` * Enter your mnemonic separated by spaces (" ") * Example: `worry uncover treat tonight input soon worth code benefit hotel hungry stamp subway neck join trap flat music argue air menu quantum volcano connect` * Enter the index position for the keys to start generating withdrawal credentials * Enter: `0` * Enter a list of the **validator index** number(s) of your validator(s) as identified on the beacon chain. Split multiple items with whitespaces or commas. * Check your validator index from: * Example: `500` (1 Validator). * If you have more than 1 validator use commas to split. Example: `500, 501, 502` (3 Validators) * Enter a list of the old BLS withdrawal credentials of your validator(s) * Open `deposit-data.json` file. and copy the old withdrawal credential

Old withdrawal credentials should be start with 00

* Example: `0098b66b3d28ae0694d1c25e58d0636c3e2a0fe306e57d067aae98de2171820f` * Enter the 20-byte execution address for the new withdrawal credentials. (Your wallet) * Example: `0x53D1644eExxxxxxxxxxxxxxx3f99B90bf34b93` * **Note that you CANNOT change it once you have set it on the chain.** * Repeat your execution address for confirmation and Ensure that you have control over this address. * Example: `0x53D1644eExxxxxxxxxxxxxxx3f99B90bf34b93` * Success! Your SignedBLSToExecutionChange JSON file can be found at: `deposit-cli/bls_to_execution_changes` * Check your bls\_to\_execution\_changes files ``` ls ./bls_to_execution_changes ```
* Broadcast BLS signature to consensus client using Docker ```sh docker run -ti -v ./bls_to_execution_changes:/bls_dir gcr.io/prysmaticlabs/prysm/cmd/prysmctl:latest validator withdraw -beacon-node-host=https://metrabyte-cl.jibchain.net/ --path=/bls_dir --accept-terms-of-use --confirm ``` * Done! # Voluntary validator exit How to Voluntary validator exit with lighthouse 1. Download the lighthouse binary from

Choose for your architechture.

* How to download with the command line: * Copy link address
* Open `deposit-cli` folder and run this command ``` wget https://github.com/sigp/lighthouse/releases/download/v4.5.0/lighthouse-v4.5.0-x86_64-apple-darwin-portable.tar.gz ```
* Extract zip file ``` tar -zxvf ```
* Test binary file ```sh ./lighthouse ```
* Clone chain config ``` git clone https://github.com/jibchain-net/node.git -b config config ```
* Run to exit validator ``` ./lighthouse --testnet-dir=./config account validator exit --keystore=./validator_keys-test/validator_keys/keystore-m_12381_3600_0_0_0-1701319485.json --beacon-node https://metrabyte-cl.jibchain.net/ ``` > The --keystore flag is used to specify the path to the EIP-2335 voting keystore for the validator. The path should point directly to the validator key .json file, not the folder containing the .json file. * Enter password * Type "`Exit my validator`"
* Done ``` Successfully validated and published voluntary exit for validator 0x8debdde83a995937ec83ba8cd9b653c9e28e5405b90d9503389032234201e61fe451900f5b95bab3789556f46568348b Voluntary exit has been accepted into the beacon chain, but not yet finalized. Finalization may take several minutes or longer. Before finalization there is a low probability that the exit may be reverted. Current epoch: 4152, Exit epoch: 4157, Withdrawable epoch: 4413 Please keep your validator running till exit epoch Exit epoch in approximately 1920 secs ``` * Your JBC will be withdrawn to your withdrawal address on `epoch: 4413` * Check validator status on:

Done !

# Cancun Upgrade The JIB Chain Cancun-Deneb (Dencun) Upgrade **Summary**: The JIB Chain Cancun-Deneb (Dencun) Upgrade, set to launch on March 12, 2024, heralds a transformative chapter for the JBC network. It's not merely a hard fork; it's a symphony of innovation orchestrated to elevate JBC's scalability, security, and user-friendliness to unparalleled heights. Central to this upgrade are Ethereum Improvement Proposals (EIPs), with EIP-4844 shining as the beacon of progress with its groundbreaking proto-danksharding. Through these meticulously crafted changes, the upgrade promises a landscape of enhanced network efficiency and diminished transaction fees, setting the stage for a flourishing ecosystem on JBC. Drawing from the triumphs of predecessors like the Shanghai upgrade, this evolution is poised to deliver a resilient foundation for decentralized applications, promising a delightful user journey through the beatific realm of JBC's potential.

Image from: https://www.datawallet.com/crypto/ethereum-cancun-upgrade-explained

*** ### genesis.json 
{
  "config": {
    "chainId": 8899,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "muirGlacierBlock": 0,
    "berlinBlock": 0,
    "londonBlock": 0,
    "arrowGlacierBlock": 0,
    "grayGlacierBlock": 0,
    "mergeForkBlock": 2200641,
    "terminalTotalDifficulty": 512048629250937967,
    "terminalTotalDifficultyPassed": true,
    "shanghaiTime": 1701158251,
    "cancunTime": 1710220283,
    "ethash": {}
  },
  "nonce": "0x0",
  "gasLimit": "8000000",
  "difficulty": "0x40000",
  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "coinbase": "0x0000000000000000000000000000000000000000",
  "alloc": {
    "4Fbd49c841c2f891b8e04B887B9C5035BE7c7209": {
      "balance": "1000000000000000000000000001"
    }
  },
  "number": "0x0",
  "gasUsed": "0x0",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "baseFeePergas": "0x2540BE400"
}
On genesis.json file add line 22 to schedule upgrade time for execution layer. ``` "cancunTime": 1710220283 ``` Tue Mar 12 2024 12:11:23 GMT+0700 (Indochina Time) *** ### Config.yml {% code title="" lineNumbers="true" %} ```yaml # Extends the mainnet preset PRESET_BASE: 'mainnet' CONFIG_NAME: 'jibchain' # needs to exist because of Prysm. Otherwise it conflicts with mainnet genesis # Genesis # --------------------------------------------------------------- # `2**14` (= 16,384) MIN_GENESIS_ACTIVE_VALIDATOR_COUNT: 1 # Friday, April 22, 2022 9:00:00 AM +UTC MIN_GENESIS_TIME: 1701158551 GENESIS_FORK_VERSION: 0x10008899 GENESIS_DELAY: 100 # Forking # --------------------------------------------------------------- # Some forks are disabled for now: # - These may be re-assigned to another fork-version later # - Temporarily set to max uint64 value: 2**64 - 1 # Altair ALTAIR_FORK_VERSION: 0x20008899 ALTAIR_FORK_EPOCH: 1 # Merge BELLATRIX_FORK_VERSION: 0x30008899 BELLATRIX_FORK_EPOCH: 1 TERMINAL_TOTAL_DIFFICULTY: 512048629250937967 TERMINAL_BLOCK_HASH: 0x0000000000000000000000000000000000000000000000000000000000000000 TERMINAL_BLOCK_HASH_ACTIVATION_EPOCH: 18446744073709551615 # Capella CAPELLA_FORK_VERSION: 0x40008899 CAPELLA_FORK_EPOCH: 1 # Sharding SHARDING_FORK_VERSION: 0x70008899 SHARDING_FORK_EPOCH: 18446744073709551615 # Deneb DENEB_FORK_VERSION: 0x08008899 DENEB_FORK_EPOCH: 23598 # Time parameters # --------------------------------------------------------------- # 12 seconds SECONDS_PER_SLOT: 12 # 14 (estimate from Eth1 mainnet) SECONDS_PER_ETH1_BLOCK: 14 # 2**8 (= 256) epochs ~27 hours MIN_VALIDATOR_WITHDRAWABILITY_DELAY: 256 # 2**8 (= 256) epochs ~27 hours SHARD_COMMITTEE_PERIOD: 256 # 2**11 (= 2,048) Eth1 blocks ~8 hours ETH1_FOLLOW_DISTANCE: 2048 # Validator cycle # --------------------------------------------------------------- # 2**2 (= 4) INACTIVITY_SCORE_BIAS: 4 # 2**4 (= 16) INACTIVITY_SCORE_RECOVERY_RATE: 16 # 2**4 * 10**9 (= 16,000,000,000) Gwei EJECTION_BALANCE: 16000000000 # 2**2 (= 4) MIN_PER_EPOCH_CHURN_LIMIT: 4 # 2**16 (= 65,536) CHURN_LIMIT_QUOTIENT: 65536 # [New in Deneb:EIP7514] 2**3 (= 8) MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT: 8 # Fork choice # --------------------------------------------------------------- # 40% PROPOSER_SCORE_BOOST: 40 # Deposit contract # --------------------------------------------------------------- DEPOSIT_CHAIN_ID: 8899 DEPOSIT_NETWORK_ID: 8899 DEPOSIT_CONTRACT_ADDRESS: 0xe9364471539cD35D1911f844914c7DaBf7aeE92D # Networking # --------------------------------------------------------------- # `10 * 2**20` (= 10485760, 10 MiB) GOSSIP_MAX_SIZE: 10485760 # `2**10` (= 1024) MAX_REQUEST_BLOCKS: 1024 # `2**8` (= 256) EPOCHS_PER_SUBNET_SUBSCRIPTION: 256 # `MIN_VALIDATOR_WITHDRAWABILITY_DELAY + CHURN_LIMIT_QUOTIENT // 2` (= 33024, ~5 months) MIN_EPOCHS_FOR_BLOCK_REQUESTS: 33024 # `10 * 2**20` (=10485760, 10 MiB) MAX_CHUNK_SIZE: 10485760 # 5s TTFB_TIMEOUT: 5 # 10s RESP_TIMEOUT: 10 ATTESTATION_PROPAGATION_SLOT_RANGE: 32 # 500ms MAXIMUM_GOSSIP_CLOCK_DISPARITY: 500 MESSAGE_DOMAIN_INVALID_SNAPPY: 0x00000000 MESSAGE_DOMAIN_VALID_SNAPPY: 0x01000000 # 2 subnets per node SUBNETS_PER_NODE: 2 # 2**8 (= 64) ATTESTATION_SUBNET_COUNT: 64 ATTESTATION_SUBNET_EXTRA_BITS: 0 # ceillog2(ATTESTATION_SUBNET_COUNT) + ATTESTATION_SUBNET_EXTRA_BITS ATTESTATION_SUBNET_PREFIX_BITS: 6 # Deneb # `2**7` (=128) MAX_REQUEST_BLOCKS_DENEB: 128 # MAX_REQUEST_BLOCKS_DENEB * MAX_BLOBS_PER_BLOCK MAX_REQUEST_BLOB_SIDECARS: 768 # `2**12` (= 4096 epochs, ~18 days) MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS: 4096 # `6` BLOB_SIDECAR_SUBNET_COUNT: 6 ``` {% endcode %} Add DENEB FORK ``` DENEB_FORK_VERSION: 0x08008899 DENEB_FORK_EPOCH: 23598 ``` Add Validator cycle and PROPOSER\_SCORE\_BOOST config ``` # [New in Deneb:EIP7514] 2**3 (= 8) MAX_PER_EPOCH_ACTIVATION_CHURN_LIMIT: 8 # Fork choice # --------------------------------------------------------------- # 40% PROPOSER_SCORE_BOOST: 40 ``` Add networking config ``` # Networking # --------------------------------------------------------------- # `10 * 2**20` (= 10485760, 10 MiB) GOSSIP_MAX_SIZE: 10485760 # `2**10` (= 1024) MAX_REQUEST_BLOCKS: 1024 # `2**8` (= 256) EPOCHS_PER_SUBNET_SUBSCRIPTION: 256 # `MIN_VALIDATOR_WITHDRAWABILITY_DELAY + CHURN_LIMIT_QUOTIENT // 2` (= 33024, ~5 months) MIN_EPOCHS_FOR_BLOCK_REQUESTS: 33024 # `10 * 2**20` (=10485760, 10 MiB) MAX_CHUNK_SIZE: 10485760 # 5s TTFB_TIMEOUT: 5 # 10s RESP_TIMEOUT: 10 ATTESTATION_PROPAGATION_SLOT_RANGE: 32 # 500ms MAXIMUM_GOSSIP_CLOCK_DISPARITY: 500 MESSAGE_DOMAIN_INVALID_SNAPPY: 0x00000000 MESSAGE_DOMAIN_VALID_SNAPPY: 0x01000000 # 2 subnets per node SUBNETS_PER_NODE: 2 # 2**8 (= 64) ATTESTATION_SUBNET_COUNT: 64 ATTESTATION_SUBNET_EXTRA_BITS: 0 # ceillog2(ATTESTATION_SUBNET_COUNT) + ATTESTATION_SUBNET_EXTRA_BITS ATTESTATION_SUBNET_PREFIX_BITS: 6 # Deneb # `2**7` (=128) MAX_REQUEST_BLOCKS_DENEB: 128 # MAX_REQUEST_BLOCKS_DENEB * MAX_BLOBS_PER_BLOCK MAX_REQUEST_BLOB_SIDECARS: 768 # `2**12` (= 4096 epochs, ~18 days) MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS: 4096 # `6` BLOB_SIDECAR_SUBNET_COUNT: 6 ``` [^1]: Schedule cancunTime for upgrade # How to upgrade Use node repository from jibchain-net GitHub 1. Clone node repository ```sh git clone https://github.com/jibchain-net/node.git && cd node ``` 2. create env or update your env ```sh make env ``` 3. run a node ```sh docker compose up -d ``` 4. check node logs ```sh docker compose logs -f ```

execution logs

execution logs should to have Cancun Time @1710220283 on Post-merge section

consesus logs

consensus logs should to have Ready for Deneb