Reminder: need to set VerifyGenesisSignatures to true on mainnet,

[piux2]

We need to verifying the signatures of txs in genesis file upon mainnet launch. We might want to set default to true before the release. This could be a backdoor for production

gno/gno.land/pkg/gnoland/app.go

Line 54 in 4bd1789

VerifyGenesisSignatures: false, // for development

[moul]

I'm considering changing gnoland start to gnoland dev to facilitate users in crafting custom genesis files for experimentation. Meanwhile, gnoland start will be tailored for production use, having fixed parameters and incorporating VerifyGenesisSignatures.

See #1050 and #1102 for more details.

[moul]

This is a simple fix, but we actually want to revert it to continue development.

I suggest making this either a configuration file option that can be changed without patching the codebase or a fuse variable that can be set with a transaction. This way, we can expect a chain to start as false and then, from a specific transaction, change to true, without the ability to revert.

[zivkovicmilos]

@moul @piux2

Thinking about this issue a bit, I don't think having VerifyGenesisSignatures makes any sense actually.

You need a few things to generate a transaction signature in the genesis.json:

gno/tm2/pkg/std/tx.go

Lines 112 to 117 in 2093d8a

	ChainID: chainID,
	AccountNumber: accountNumber,
	Sequence: sequence,
	Fee: tx.Fee,
	Msgs: tx.Msgs,
	Memo: tx.Memo,

Notice that you can specify all params, apart from the account number, which is dependent on internal chain state (which doesn't exist!). This means we can't actually generate transaction signatures without the chain having state (> block 1), and us knowing what the account number actually is, which is impossible before we start the chain :)

I suggest 2 options:

• we drop this issue entirely, genesis txs don't have signatures -> this is a valid option and doesn't introduce any security risk, since you need a 2/3+ valid majority to run the chain from the generated genesis anyways
• we drop account number from the account state. It's a pretty radical idea, but I don't actually see what benefits having the account number gives us -> feat: remove traces of account number from the account object #3213