Depositing to additional validators in a local Ethereum testnet

[tomknig]

I'd like to use the kurtosis ethereum-package as a testbed for validator lifecycle operations, but deposits fail to create new validators:

I am running the ethereum-package with basic parameters, especially with deposit_contract_address: "0x4242424242424242424242424242424242424242". I am successfully calling the deposit function of the deposit contract, which I assume is the actual contract used in the environment here. Invalid data, such as altered withdrawal_credentials successfully fail with errors like:

ContractFunctionRevertedError: The contract function "deposit" reverted with the following reason: DepositContract: reconstructed DepositData does not match supplied deposit_data_root

When called with correct depositdata created using ethdo validator depositdata¹, the transaction looks fine. An excerpt from blockscout is attached in ³, ⁴, and ⁵. However, lookups of the validator created fail. Neither ethdo validtor info² nor dora^6,7 seem to be able to get any data about this validator. I'd use that as a proxy that the network doesn't know anything about this new validator.

Am I operating under wrong assumptions or doing something wrong here? Can I use such local testnet somehow to run and test my deposits and validator operations?

Additional Notes

In the process of debugging, I discovered the assertoor validator lifecycle test which apparently does seem to be testing validator lifecycle related things such as deposits.

Footnotes

1. Full ethdo command

   ethdo validator depositdata \
     --withdrawaladdress "0x8943545177806ED17B9F23F0a21ee5948eCaa776" \
     --validatoraccount "validators/1" \
     --forkversion "0x50000038" \
     --depositvalue "32 Ether"
   

2. Full ethdo command for getting info about a validator

    ethdo --json validator info --validator=0x838ceb6da14cb87f54d4074791aff5cf3a9ad27e97c2bb41ebb07756d848e8cedfe9d4f2b3da09e96812a031f4c6edf4
   Failed to obtain validator: unknown validator
   

3. The deposit transaction
   
4. The 0x4242424242424242424242424242424242424242' contracts perspective
   
5. Not much can be learned from the deposit contract logs, but it does entail the correct public key, i.e., the one we've had in our depositdata
   
6. Dora not knowing about our validator
   
7. And dora not knowing about any pending validators
   

[tomknig]

It's still unclear to me why my deposits were not listed at all, but I did find that I was using the incorrect forkversion for creating depositdata. The genesis fork version is not 0x50000038 but 0x10000038... Fixing this yields valid deposits and patience leads to those deposits being included.