Gnosis Core Devs Call Notes February 22, 2023

February 22, 2023
Armagan Ercan

Greetings everyone, and welcome to the weekly Gnosis Core Devs Call. Just a quick reminder that this meeting takes place every Wednesday.

Participants: Erigon, Gateway, Nethermind, Geth, Gnosis DevOps, Gnosis Core Devs, Gnosis DevRels, Gnosis Comms team and the contributors.

The main topic of discussion during the meeting was the withdrawals contract. The team is currently making preparations for the forthcoming Shapella upgrade. Furthermore, updates were given on Devnet, the Client team, Chain infrastructure, and POSDAO.

Watch on Gnosis Chain YouTube channel


  • Withdrawals Contract
  • Shapella Upgrade
  • Core Dev Team updates
  • Client Team Update
  • Chain Infrastructure Updates
  • Devnet

Withdrawals contract

  • Should be finalized
  • Being audited by Adam
  • If the transfers can’t occur (insolvency case), they will be queued and cleared when new GNO is supplied
  • Dapplion is asking for help from Nethermind to pick a safe value of the number of failed transactions to execute per block
  • Might be useful to test on mainnet because on devnets the entire state can be cached
  • Ruben suggests a default of 16 for both, so 32 in the worst case scenario
  • If we have one day worth of failed amounts, then clearing the queue would take a day as well
  • In any case, this would be an unlikely scenario
  • Would require a massive exit
  • Lukasz: is there an estimation of gas usage for those transactions?
  • Dapplion: we don’t have those numbers but we should compute them
  • Based on this, we could choose a number for the failed transactions per block
  • Dapplion: will ask Ihor to get some numbers
  • Need to assign tokens to Deposit Contract
  • Should have some 0x01 addresses
  • Method 1: Jorge’s “Merge” method of just overwriting storage slots
  • Nethermind and Erigon have support for storage allocations
  • Makes it possible to give tokens to users in contracts
  • Method 2: Assign code as constructor bytecode (?)


  • Are there blockers?
  • Actual withdrawals contract (currently using mocks)
  • Can we start spinning one up?
  • Status


  • Started an internal devnet using a mock contract a few days ago
  • So far, everything seems to be good
  • Starts with AuRa blocks, then Merges (Bellatrix) and then enables Withdrawals


  • Lighthouse might not be compatible with TTD = 0
  • Devnet is simple to set up because it’s mostly automated

Current state

  • A dozen of validators
  • Went through Shanghai without any issues
  • Withdrawals have not been tested yet
  • Figuring BLS addresses out
  • The nodes are public, so an RPC can be shared
  • Erigon can also join this devnet, but the mock contract is still used, so that needs to be configured


  • Not implemented yet
  • Can be done this week


  • We can spin up a devnet with both clients end of next week (March 2nd)
  • Gnosis DevOps
  • Will run Nethermind first?

Client team updates

Execution Layer


  • Running devnet for withdrawals
  • Issues regarding 1.17
  • Attestations down
  • We’ll investigate and contact Nethermind on Telegram


  • Chiado now works
  • Linked to dead peers on Nethermind
  • Enabled snapshots
  • Light client works for Gnosis and Chiado
  • DevOps is working on spinning up more Nimbus peers


  • Trying to run latest Prysm on mainnet
  • Will be working on geth sync for the rest of the month

Consensus Layer


  • Will be working on geth sync for the rest of the month
  • How to configure the Gnosis preset?
    `--chain-config-file=/configs/mainnet/config.yaml` refers to `PRESET_BASE: gnosis`


  • Publishing on Gnosis repo

Chain Infra


  • Half of the traffic on Chiado
  • 25% traffic on mainnet
  • Everything’s good and planning to increase traffic
  • Gnosis Bridge Validator
  • 1-of-7
  • Work can be slow during EthDenver


  • Not ready till T+1 after Ethereum Shanghai/Capella
  • For the 0x00 -> 0x01 address conversion


  • When is a realistic time for Withdrawals?
  • Need to prep community
  • We should not overpromise


  • We should not overpromise
  • Next steps (can be done without Erigon)
  • Deploy a new one with the actual smart contract
  • With upgrade from mainnet bytecode if possible, but not essential
  • Can be put in the genesis bytecode
  • The contract should be pre-funded to simulate the current state on mainnet
  • Would be great to test the insolvency case
  • Test the deposit contract update
  • Start with the bytecode of the current deposit contract
  • Go through the upgrade
  • Can probably be done this week
  • Shadow forks


  • Deposit contract for Genesis
  • Start testing tooling
  • Dappnode
  • Withdrawal credentials in general


  • Deposit contract needs to be updated
  • Requires testing
  • On devnet
  • On chiado
  • Emulate it as close to mainnet as possible

Additional Workstreams

  • Mainnet
  • Shutterized Beacon Chain
  • Account Abstraction


  • Hive
    Dapplion: Should be the option in the long term
    Marek agrees because Ethereum also supports Hive tests
    However, the initial effort will be more important as we have nothing yet
    Currently: Truffle test suites
    Really annoying to work with
    Deprecated, but still necessary for nodes being synced from Genesis:
    Pre-merge testing of POSDAO - rotation of validator set, voting etc
    Test that we can still go thru the Merge without going thru forks or nodes getting start
    Still relevant:
    xDai Block Rewards
    Has prevented really bad problems from happening
    Syncing from Genesis
    None of them are being worked on
    Would anyone have capacity to do either?
    Nethermind: Hive tests are written in Go
    Nethermind has devs, but not sure anyone is available
    Erigon: Andrew will ask around, but probably no capacity
    Would be great to have long term ownership of Gnosis tests
    Especially for shutterized beacon chain etc in the future
    We wouldn’t need a suite as extensive as Ethereum’s for now
    The withdrawal tests are relatively succinct


  • The xDai team did an attempt at implementing withdrawals
    They had a way to pause withdrawals
    Sounds really bad, we don’t want to be able to stop the network
  • There will be no trace (logs) of withdrawals on explorers
    We need to work with explorers to display them
    Ideally they add a new tab, similar to “internal” / “ERC-20” for withdrawals
    We can probably piggy-back from the mainnet implementation
    Caveat: insolvency case, might require some specific logic
    Lukasz: should withdrawals be shown in traces somewhere?
    Lukasz: mixed feelings
    We should maybe ask block explorers / users what they want?
    Dapplion: let’s keep it simple

Read original article on mirror.xyzRead original article on substack