Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
thehowl opened this issue Jul 10, 2024 · 4 comments · May be fixed by #3253
Open

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

thehowl opened this issue Jul 10, 2024 · 4 comments · May be fixed by #3253
Assignees

Comments

@thehowl
Copy link
Member

thehowl commented Jul 10, 2024

#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
Copy link
Member

moul commented Jul 14, 2024

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
Copy link
Member

zivkovicmilos commented Nov 26, 2024

@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
Copy link
Member

@Villaquiranm
Copy link
Contributor

Villaquiranm commented Nov 27, 2024

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

@Villaquiranm Villaquiranm linked a pull request Nov 30, 2024 that will close this issue
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Teritori (confirmed)
Status: In Progress
5 participants