berachain/beacon-kit v1.1.3

BeaconKit v1.1.3

on GitHub

Summary

v1.1.3 fixes syncing issues in a couple of ways:

• v1.1.3 restructures Consensus Layer and Execution Layer communication to keep them in lock-step. Now every RPC communication issue among them will result in a BeaconKit termination BUT being their states in sync you can easily restart any time and keep going.
• v1.1.3 adds a scripts/rollback_cl.sh utility to restore synchrony among Consensus Layer and Execution Layer, in case e.g. you start from a misaligned state (CL tip is ahead of EL tip)

Context on Syncing Issues

BeaconKit 101: there are two processes, BeaconKit itself, acting as Consensus Layer and any EL (mostly unforked Geth and Reth) acting as Execution layer. These two processes can fall out of sync in a way that makes syncing a node a pretty frustrating procedure. Some findings and recommendations for operators running Geth and Reth ELs are below.

Syncing Geth

Make sure to specify --syncmode=full among your flags. This will inform your EL that no snap sync is available so that it won’t waste time with it (snap is default in Geth).

Syncing Reth

We recommend that, while syncing a node, you add the following configs:

--engine.persistence-threshold 0
--engine.memory-block-buffer-target 0

You don’t need to keep the once the node has completed sync, but they make resuming syncing, or syncing from genesis more robust. If you are curious about these flags, here is a deeper explanation:

• Reth does not immediately store on disk every block it received from its consensus layer: by default, only block up to tip’s grandparent (tip - 2 blocks) are persisted. This is fine in Ethereum, since usually blocks are finalised way later than they are marked as latest (aka tip) by the Consensus layer, and it definitely offers some performance. However this is risky with Berachain, where you enjoy the single block finality offered by CometBFT. The default config guarantees that Reth will forget the tip’s parent, a finalized block, in case of shutdown, even if graceful. This is not acceptable in BeaconKit v1.1.3, so we use the flags above to make sure blocks are duly stored.
• Strictly speaking you don’t need those flags under normal operations. However your Consensus Layer and Execution Layer will fall out of sync even in case of a graceful shutdown. You can now use the scripts/rollback_cl.sh utility to recover synchrony and restart the system!

Update Priority

This table provides priorities for which classes of users should update particular components.

All Changes

• fix(node-api): Fix param in validator endpoint (#2539)
• fix(API): fix slot selection in validator API (#2538)
• chore(testing): modified start-reth to enforce persistence (#2536)
• Add new script for rollbacking CL to EL height (#2498)
• chore(testing): modified start-geth to enforce syncmode full (#2535)
• chore(networks): add bepolia testnet (#2532)
• Ask to delete EL data dir on make start-[client] (#2479)
• Improvements to signal handling (#2379)
• add a mainnet launch target to vscode (#2386)
• fix(testnet): Activate Deneb1 for EVM inflation (#2528)
• chore(config): activate bera minting on testnet since block 1 (#2527)
• chore(ci): Set go version to 1.23.5 in release workflow (#2525)
• fix(engine api): [2/3] Add force head in FinalizeBlock (#2488)
• fix(engine api): [1/3] error on engine API errors (revive #2485) (#2508)
• fix(node-api): Implement validators endpoint filtering properly (#2467)
• fix(blobs): cleanup logging and node-api handling of blobs (#2486)
• fix(errors): Ignore requests Txs + RPC Error Handlings Fixes (#2517)
• chore(state-transition): cleaned up state in state-transition UTs (#2518)
• chore(engine): splitted up NotifyAndVerifyNewPayload (#2495)
• chore(types): Fix error type and clean up interface definition (#2515)
• fix(state-processor): stricter timestamp enforcement on execution-payload (#2512)
• fix(types): avoid panic on unmarshalling of empty inputs (#2511)
• Revert "fix(engine api): [1/3] error on engine API errors (#2485)" (#2507)
• do not reject PRs based on missing period in a comment (#2504)
• chore: Cleanup devtools.mk make targets (#2421)
• Fix broken CI due to using newest go version which is not supported b… (#2505)
• Merge pull request #2470 from berachain/02-04-explicitly_set_bash_shell_in_kurtosis_makefile
• Merge branch 'main' into 02-04-explicitly_set_bash_shell_in_kurtosis_makefile
• fix(engine api): [1/3] error on engine API errors (#2485)
• chore(generics): Remove Generics from Node Builder (#2500)
• fix(cli): unlocking rollback (#2478)
• chore(e2e): Initialize finalBlockNum before wait loop in WaitForFinalizedBlockNumber (#2494)
• refactor(depinject): Replace Concrete CometBFT implementation with Interface (#2487)
• fix(ci): Update Test Configs to work with new Geth version (#2489)
• chore(networks): 80094 network configs (#2484)
• refactor(cli): Refactor CollectGenesisDeposits to be callable from runtime (#2464)
• chore(state-transition): flipped transaction context attributes logic (#2451)
• Build Process - Fix Linux arm64 (#2475)
• Explicitly set bash shell in Kurtosis Makefile

Binaries

System	Architecture	Binary	PGP Signature
	amd64	beacond-v1.1.3-linux-amd64	Signature
	arm64	beacond-v1.1.3-linux-arm64	Signature
	arm64	beacond-v1.1.3-darwin-arm64	Signature
System	Option	-	Resource
	Docker		berachain/beacon-kit

Verifying signatures

Use gpg to verify the signature on these binary archives. This is important to make sure that the content you've downloaded is legitimate. gpg can be installed with most package managers. For example:

• brew install gpg on mac
• apt install gpg on Ubuntu/Debian

Once gpg is installed, import our public key into its database and verify:

• Download signing public key from here.
• Run gpg --import berachain_release.asc
• Verify with gpg --verify {signature}.sig {binary}.tar.gz
• This message is expected: WARNING: This key is not certified with a trusted signature!
• To resolve the warning, trust the key by signing with your own keypair. gpg --lsign-key <keyid>