change default genesis package creator, and add way to configure it

[thehowl]

#2508's genesis file contains all the packages in examples/ initialized and deployed by the test1 key, g1jg8mtutu9khhfwc4nxmuhcpftf0pajdhfvsqf5. This is probably fine, but the deployer of the genesis package shouldn't be one where the mnemonic is public and well-known; especially since I believe some packages in examples are giving special privileges to the deployer (through a std.PrevRealm().Addr() / GetOrigCaller() in initialization).

Maybe we can have a deployer deployer address like g1sh0uldn0thappen.... :)

We should change the default in gno.land/cmd/gnoland/genesis_txs_add_packages.go, but also add a way to configure it from the command line.

[moul]

Needed:

• Coordinated launches' genesis should not use test1 or known public keys for deployments.
• It's beneficial that most of the contracts are administered by the deployer by default.
• Gnodev should (if not already the case) use the first gnokey list key or the specified one, so that developing on Gnodev by default makes you an admin. Then, you can drop your privileges using more advanced patterns.

This is the recommended course of action.

---

Now, I'm exploring a way to have the equivalent of go build --tags and go build -X path/to/pkg.var=foo so that we can start having files like init_gnodev.gno, init_production.gno, and init.gno as the default. However, I suggest focusing on what we can do without my addition (the first three points).

[zivkovicmilos]

@Villaquiranm

I've thought a lot about this and tried a few different implementations locally, so I finally reached a conclusion:

• You should only support transaction signing with a private key when adding packages (you don't need the address, just the gnokey entry name, ex MainKey).

This means that what you need to add is this functionality:

gnogenesis txs add packages --signer-key MainKey ...

You can change the flag name of course, this is just an example.

Default should be test1, because it's a known private key.

I think it's acceptable to have this coupling, because the genesis is generated once per chain.
We need to figure out how to get the chain ID, account number and account sequence for the given address.

EDIT:
The more I'm thinking about this, the more I think you don't need to verify genesis signatures in genesis, because if the chain hasn't started, how would you know the account number you need to generate the signature itself?

• When adding transactions from tx sheets, you should verify if they are signed, and if they are not reject them.

I think with these 2 things we can safely say the transactions have valid signatures, and it allows for customizability (different key for different tx). It also doesn't need to use any fancy Metadata fields, they're not needed in the end

[zivkovicmilos]

@Villaquiranm @thehowl

#1104 (comment)

[Villaquiranm]

I think it's acceptable to have this coupling, because the genesis is generated once per chain.
We need to figure out how to get the chain ID, account number and account sequence for the given address.

EDIT:
The more I'm thinking about this, the more I think you don't need to verify genesis signatures in genesis, because if the chain hasn't started, how would you know the account number you need to generate the signature itself?

Hello @zivkovicmilos about this, I saw that we already have some sort of 'fix' for this:
This code verifies if a transaction is on genesis and if it does the accountNumber is considered 0, I did the same for the sequence number.
https://github.com/gnolang/gno/pull/2986/files#diff-b9019e160b0344a18489c4d74194d8da800f863a3130ab78e5d24e8d7635193cR438-R451

On my PR I have started working on how to sign and verify the signature ( Issue related to verify signatures: #1104 ) And all the genesis generation was working. Also I was able to launch the chain locally (With sign verification on)

Current PR #2986. Currently I'm using a Mnemonic, because I need a way to sign the TXs but I could also use a keyName some sort of what we do on maketx give a keyName and then ask for the key password ?

Thanks what do you think ?
@zivkovicmilos @thehowl