feat: remove traces of account number from the account object

[zivkovicmilos]

Description

This PR removes the Account Number from the account object.

⚠️ BREAKING PR, PLEASE UPDATE ALL SIGNING CLIENTS. ⚠️

The account number is a sequential number generated from the internal chain state, to initialize accounts.
It serves no security benefits, given that the account object already has a Sequence for replay protection, and accounts are never deleted in TM2.

Having it introduces a large overhead on maintaining it, and not being able to return "empty" accounts. It also introduces friction when generating transaction signatures, as the client would need to go to the chain to fetch the active account number.

Starts the process of closing #661.

Related:

• Reminder: need to set VerifyGenesisSignatures to true on mainnet,  #1104
• change default genesis package creator, and add way to configure it #2573

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests

[codecov]

Codecov Report

Attention: Patch coverage is 80.55556% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
tm2/pkg/std/tx.go	0.00%	6 Missing ⚠️
tm2/pkg/std/account.go	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[moul]

There is a minor security benefit that may seem negligible. For example, similar to chainid, a faulty copy-paste of the gnokey command will fail if you attempt to run a transaction on the wrong network using the same key.

Having different chainid values should be enough to protect against cryptographic replay attacks. However, it also offers additional protection against operating on the incorrect network.

I need a bit more time to consider the impact.

Edit: I remember considering a similar approach. My idea was not to remove it but to make it optional, allowing you to choose between explicitness and implicitness. I wanted to extend this option to both the account number and the sequence number. However, the sequence number has a greater impact on security.

[moul]

should be kept.

[zivkovicmilos]

This replace was originally removed, not sure when it was added back in 🙁

The gnofaucet cannot have a replace, because gnolang/faucet (imported by gnofaucet) imports gnolang/gno, and it's going to cause a build error since the API changed in this version of gnolang/gno -- we want gnofaucet to use an old version of gnolang/gno

[thehowl]

thinking gnolang/faucet should be moved into the monorepo or gnofaucet out of it; in any case fine.

[moul]

Move it in the monorepo.

[zivkovicmilos]

There is a minor security benefit that may seem negligible. For example, similar to chainid, a faulty copy-paste of the gnokey command will fail if you attempt to run a transaction on the wrong network using the same key.

Having different chainid values should be enough to protect against cryptographic replay attacks. However, it also offers additional protection against operating on the incorrect network.

I need a bit more time to consider the impact.

Edit: I remember considering a similar approach. My idea was not to remove it but to make it optional, allowing you to choose between explicitness and implicitness. I wanted to extend this option to both the account number and the sequence number. However, the sequence number has a greater impact on security.

@moul

The only reasoning I can think of for keeping the Account Number is that at some point accounts would've been "deleted", and having a global account counter would prevent any funny business in the future. I can't see any limitation that sequence (changed on a per-tx basis on the account), and chain-id don't already provide as a combination (this is the case on Ethereum, this is the only replay protection).

The benefits of dropping it are we can minimize the amount of chain queries we do for regular transaction signing (ex. in Adena, or any signing client), and that we can now return values for uninitialized accounts (zero balance, zero sequence). It makes the signing logic cleaner and simpler

[moul]

I'm considering whether it makes sense to replace AccountNumber with the pubkey here. However, since we're signing with the corresponding privkey and appending the pubkey to the tx, it may be unnecessary.

cc @aeddi @kristovatlas

[moul]

Added several reviewers.

Blocking progress until Jae has a chance to review it. However, we shouldn't wait for Jae to continue the review.

[tbruyelle]

@zivkovicmilos As mentioned in the issue #661, why not return an error if the account doesn't exist ? This is what the auth module of the SDK does.

[thehowl]

overall lgtm and agree to remove it

[zivkovicmilos]

@zivkovicmilos As mentioned in the issue #661, why not return an error if the account doesn't exist ? This is what the auth module of the SDK does.

@tbruyelle
It's not just about the uninitialized account response, the bigger issue is we drag around the account number like we did the zero timestamp for no apparent reason or security benefit 🙁

I am actually totally fine with the uninitialized accounts erroring out like they do now, we handle this in all of our clients

[tbruyelle]

@tbruyelle It's not just about the uninitialized account response, the bigger issue is we drag around the account number like we did the zero timestamp for no apparent reason or security benefit 🙁

I am actually totally fine with the uninitialized accounts erroring out like they do now, we handle this in all of our clients

I see OK.

It is likely that the presence of the account number in gno is a simple port from the SDK codebase, and interestingly I was able to find the origin of the account number : cosmos/cosmos-sdk#1077

As noted in the PR, the account number was added as a security measure, actually a replay protection, but in the context of account pruning (account removed from state when balance is 0). However, I don't know much about state pruning so I can't say if this is still relevant. Maybe someone else can jump in and explain if this is still relevant.