Inquiry on Validator Smart Contract Configuration and Node Information Retrieval in QBFT

[KimH4nKyul]

I have asked a question here, but I believe I can get additional information from this place.

Firstly, does a QBFT node need to have the Validator Smart Contract defined in the genesis.json file to have one?
Or is it automatically generated even if it is not defined?

Is it only possible to obtain validator node information on a QBFT node through the Validator Smart Contract? I couldn't find a related RPC API. Am I missing something?

[frank-lim-partior]

2. Could this give you what you're looking for?
   https://docs.goquorum.consensys.io/reference/api-methods#istanbul_getvalidators

[KimH4nKyul]

2. Could this give you what you're looking for?
   https://docs.goquorum.consensys.io/reference/api-methods#istanbul_getvalidators

Oh, I see. I thought this method only worked with IBFT consensus, but when I tested it with the istanbul option while running a QBFT node in Geth, it worked correctly.

Thank you @frank-lim-partior so much for your answer! The problem has been resolved :)

[yohanelly95]

hey @KimH4nKyul I added the example ValidatorAllowlist contract and deployed to an existing chain, I updated the genesis.json like so

  "nonce": "0x0",
  "timestamp": "0x58ee40ba",
  "extraData": "0xf88fa00000000000000000000000000000000000000000000000000000000000000000f869940d638cdc26d8ae3325bf4eba49992e28b0f4af9b94fdd781c436c2fb360f7458af64aceaf5ee13e6e594c16e2a9092e92210ce55f05023d1c45d01689037946f1013a68bcfc9da74fb83408ca7db32e7731d7594da06eca6f65f05b573820bf781819dc4d41f6a3dc080c0",
  "gasLimit": "0x1C9C380",
  "gasUsed": "0x0",
  "number": "0x0",
  "difficulty": "0x1",
  "coinbase": "0x0000000000000000000000000000000000000000",
  "mixHash": "0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "config": {
    "chainId": 22111337,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip150Hash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "muirglacierblock": 0,
    "berlinBlock": 0,
    "londonBlock": 0,
    "isQuorum": true,
    "maxCodeSizeConfig": [
      {
        "block": 0,
        "size": 64
      }
    ],
    "txnSizeLimit": 64,
    "enableGasPriceBlock": 10,
    "transitions": [{
         "block": 10,
         "blockReward": "100000",
         "beneficiaryMode": "validators"
       },
         {
            "block": 160,
            "validatorselectionmode": "contract",
            "validatorcontractaddress": "0xFEb70E7Ad36b425b698184B3d5b1F856c8122a42"
        }],
    "qbft": {
      "policy": 0,
      "epoch": 30000,
      "ceil2Nby3Block": 0,
      "testQBFTBlock": 0,
      "blockperiodseconds": 5,
      "emptyblockperiodseconds": 60,
      "requesttimeoutseconds": 10
    }
  },
  "alloc": {
    "0x6f110618b32034086ed866b9a947c36431efbfa2": {
      "balance": "1000000000000000000000000000"
    }
  }
}

but when I try to run geth init data/genesis.json I get the error that

INFO [08-09|09:27:24.350] Running with private transaction manager disabled - quorum private transactions will not be supported
INFO [08-09|09:27:24.352] Maximum peer count                       ETH=50 LES=0 total=50
INFO [08-09|09:27:24.352] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
INFO [08-09|09:27:24.353] Enabling recording of key preimages since archive mode is used
INFO [08-09|09:27:24.353] Set global gas cap                       cap=25,000,000
INFO [08-09|09:27:24.353] Allocated cache and file handles         database=/root/.ethereum/geth/chaindata cache=16.00MiB handles=16
INFO [08-09|09:27:24.366] Persisted trie from memory database      nodes=6 size=961.00B time="27.241µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
Fatal: Failed to write genesis block: database contains incompatible genesis (have c32d9c5005ff49d1a690d83e1827c4ac7d8b4800bcc4018c58d925e4efee886f, new 03b8378757ee624b2dcbc9e61be84378f9252878d47c2471f3c8feae107f81a5)

not sure why this is happening! Now even without that transition defined (switching validator methods to contract) I get the same error. Where did I go wrong? cc @frank-lim-partior

[yohanelly95]

Note: the transition to enable gas worked successfully, but that was included before starting the chain.

[KimH4nKyul]

@yohanelly95
Could you try specifying genesis.json with a command to run geth instead of geth init? If necessary, try deleting chaindata and running it.

[yohanelly95]

@KimH4nKyul tried deleting the chaindata but this is sort of a regenesis of the chain itself. Can't we add new transitions to future blocks. Stop the nodes -> Update the genesis.json -> geth init nodes -> restart the nodes. So the transition will apply to all nodes on the future block? When I try this I get this for eg,

Fatal: Failed to write genesis block: database contains incompatible genesis (have c32d9c5005ff49d1a690d83e1827c4ac7d8b4800bcc4018c58d925e4efee886f, new 03b8378757ee624b2dcbc9e61be84378f9252878d47c2471f3c8feae107f81a5)

So I cannot add block transitions once the chain is live already. And if I do not geth init the nodes again before restarting the genesis transitions updates are not applied!

[KimH4nKyul]

@yohanelly95
I apologize, but at the moment, I believe the issue you're facing can only be resolved by deleting the existing blockchain data and reinitializing the genesis block with the modified genesis.json. It might be a good idea to share the problem with others as well. cc @rodion-lim-partior

[frank-lim-partior]

@yohanelly95 have you tried running just geth instead of geth init like Kim mentioned? geth init will attempt to initialize the Blockchain and write a new Genesis block. Whereas you're trying to start geth on an existing blockchain. I've successfully tried changing configs via transition blocks after a chain has been live.

[rodion-lim-partior]

@yohanelly95, to update transitions, you do need to make a call to geth init. If geth init has been called before, there are strict checks to ensure that a subset of genesis parameters remain unchanged. In your case, the hash of the restricted parameters should lead to the value of c32d9c5005ff49d1a690d83e1827c4ac7d8b4800bcc4018c58d925e4efee886f.

One of these values has changed since the previous successful invocation of geth init. Transitions on the other hand are not one of the checked configurations, and are allowed to be amended across runs. It will probably be a good idea to look through your VCS to see which are the changes that have been made to your Genesis files over history, and try to derive the one that leads back to the hash above.

If your use case is to update transitions only, we have a previous PR that might be helpful: https://github.com/partior-3p/quorum/pull/22/files. W

[yohanelly95]

@yohanelly95, to update transitions, you do need to make a call to geth init. If geth init has been called before, there are strict checks to ensure that a subset of genesis parameters remain unchanged. In your case, the hash of the restricted parameters should lead to the value of c32d9c5005ff49d1a690d83e1827c4ac7d8b4800bcc4018c58d925e4efee886f.

One of these values has changed since the previous successful invocation of geth init. Transitions on the other hand are not one of the checked configurations, and are allowed to be amended across runs. It will probably be a good idea to look through your VCS to see which are the changes that have been made to your Genesis files over history, and try to derive the one that leads back to the hash above.

If your use case is to update transitions only, we have a previous PR that might be helpful: https://github.com/partior-3p/quorum/pull/22/files. W

I figured it out, yes I needed to run geth init again specifying the data directory and updating transitions did seem to work! Although most forge/cast commands seem to fail or return errors. For eg running forge script, the txn is successful but I never receive a txn receipt so it gets stuck waiting for it. How do I resolve this?

[yohanelly95]

@rodion-lim-partior @frank-lim-partior created this issue for the foundry issues I am facing. #1726