feat: lock token transfer and parameter module #3176

piux2 · 2024-11-21T10:28:25Z

Context for Locking Token Transfer

This feature allows us to lock token transfers, except for paying gas fees to add a package or call a contract. The restriction will be unlocked through GovDAO voting on a proposal.

We also want a few whitelisted, unrestricted accounts to vote on the proposal since a separate fee is required to initiate and vote on proposals.

This implementation manages the lock and unlock settings in r/sys/params, where we change the chain’s parameters. Calling lock or unlock will automatically submit a proposal to GovDAO. Once GovDAO votes and approves the proposal, the token
transfer restriction will be removed instantly.

All changes to parameters specified in r/sys/params must go through GovDAO voting.

Here are some implementation details

Set a flag in base account to indicate if the account is restricted for token transfer.
Add a restricted Denom list in the bank module
System contract to handle
Verify realm access from r/sys/params for change chain parameters.
Integration test to simulate the end to end unlock process
Load params from genesis and verify the values

Main Idea Behind the Alternative Approach To implement parameter module ( Discussion)

The parameter module is designed to store chain and Cosmos SDK modules' parameters. It is not an arbitrary key-value storage system for Gno contracts.
Parameters are abstracted within each module's genesis state.
Parameters can only be modified through:
- The genesis state.
- gno.land/r/sys/gov/dao
The parameter module is intended for managing parameters of other modules, not specifically for the GnoVM.
The parameter module and genesis state support structures, not just primitive types, as parameters.
The ParameterKey prefix is defined in the module's prefix key. This must be registered with the parameter module to prevent conflicts in the parameter store's keyspace.

Todo: update other params...

Contributors' checklist...

Added new tests,
Provided an example (e.g. screenshot) to aid review
not needed
No breaking changes were made,
Added references to related issues and PRs
Provided any useful hints for running manual tests

codecov · 2024-11-21T10:29:59Z

Codecov Report

Attention: Patch coverage is 63.81910% with 144 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gno.land/pkg/sdk/vm/params.go	40.00%	21 Missing and 3 partials ⚠️
tm2/pkg/sdk/bank/genesis.go	0.00%	24 Missing ⚠️
tm2/pkg/sdk/bank/keeper.go	71.01%	15 Missing and 5 partials ⚠️
tm2/pkg/sdk/bank/params.go	61.53%	11 Missing and 4 partials ⚠️
tm2/pkg/sdk/params/keeper.go	62.50%	10 Missing and 5 partials ⚠️
tm2/pkg/sdk/auth/genesis.go	0.00%	11 Missing ⚠️
tm2/pkg/std/errors.go	52.63%	9 Missing ⚠️
gno.land/pkg/sdk/vm/genesis.go	55.55%	6 Missing and 2 partials ⚠️
tm2/pkg/sdk/auth/params.go	77.77%	0 Missing and 4 partials ⚠️
tm2/pkg/std/coin.go	71.42%	2 Missing and 2 partials ⚠️
... and 5 more

📢 Thoughts on this report? Let us know!

zivkovicmilos

Thank you for pushing this out 🙏

I think the direction is good, but I'd love to discuss more about some implementation details. I'm mostly worried about us having a temporary implementation detail as a permanent state of a core object (check comments).

Pinging @moul to give a review as well.

Please check the CI 🙏

examples/gno.land/r/sys/params/unlock.gno

zivkovicmilos · 2024-11-25T01:39:44Z

examples/gno.land/r/sys/params/unlock_test.gno

+	id := ProposeUnlockSend()
+	urequire.PanicsWithMessage(
+		t,
+		simpledao.ErrProposalNotAccepted.Error(),


Do you think we should standardize errors like these, to avoid having to import simpledao?
It would mean that the dao package would need to know about specific implementation details like errors, so I'm not sure if this is the way to go

cc @moul

Currently, GovDAO is a wrapper around the SimpleDAO. All voting and proposal functionality are implemented in SimpleDAO. I'm not sure if using the proposal errors defined in SimpleDAO will cause any issues down the line unless we decide to flatten the GovDAO implementation and stop wrapping the SimpleDAO package entirely.

On the other hand, whether GovDAO should be implemented as a SimpleDAO wrapper or not can be a separate topic.

zivkovicmilos · 2024-11-25T01:47:30Z

gno.land/cmd/gnoland/testdata/transfer_unlock.txtar

+stdout '(0 uint64)'
+
+
+## vote unlock proposal with unrestricted account test1


Which accounts are going to be unrestricted in the initial version of the chain?

For now, all GovDAO accounts that need to vote must be unrestricted from token transfer locking, as voting on a proposal requires sending fees to the contract.

gno.land/pkg/gnoland/app.go

zivkovicmilos · 2024-11-25T01:48:59Z

gno.land/pkg/gnoland/app_test.go

-				{key: "foo", kind: "bool", value: true},
-				{key: "foo", kind: "bytes", value: []byte{0x48, 0x69, 0x21}},
-			},
+			/*


This is commented out since it conflicts with the alternative approach for the Params module in this PR. I believe we should avoid setting arbitrary parameter values in the genesis file without going through module validation.

We need to discuss it and agree on the approach.

zivkovicmilos · 2024-11-26T00:46:08Z

tm2/pkg/sdk/auth/genesis.go

+	// Otherwise, we cannot verify the unrestricted address in the genesis state.
+
+	for _, addr := range data.Params.UnrestrictedAddrs {
+		acc := ak.GetAccount(ctx, addr)


There is tight coupling here. The account keeper must have a previously initialized account in order for us to modify it in another func

Can't we keep the store of unrestricted accounts somewhere, instead of keeping the Unrestricted information on the account itself?

My biggest concern is that we're coupling temporary logic (account balance transfer locks) into a structure that will be encoded and saved permanently to disk. Every time we use the account, even in 10 years, we will have to keep track of its "restricted state".

This is why I'm suggesting we go with an approach that isn't so coupled

There are two reasons for implementing it this way:

There was a previous requirement to track and unlock token transfers on an individual account basis, not just for whitelisted accounts. That is the reason the restricted state is on the account level. We can revisit the requirement, otherwise, we will need to track the restricted state for a long time.

The whitelisted unrestricted accounts need to be validated to ensure they exist when we load the genesis state.

tm2/pkg/sdk/auth/params.go

zivkovicmilos · 2024-11-26T00:47:37Z

tm2/pkg/sdk/auth/params.go

+	ok, err := ak.paramk.GetParams(ctx, ModuleName, "p", params)
+
+	if !ok {
+		panic("params key " + ModuleName + " does not exist")


zivkovicmilos · 2024-11-26T00:48:40Z

tm2/pkg/sdk/auth/params.go

+	TxSizeCostPerByte      int64            `json:"tx_size_cost_per_byte" yaml:"tx_size_cost_per_byte"`
+	SigVerifyCostED25519   int64            `json:"sig_verify_cost_ed25519" yaml:"sig_verify_cost_ed25519"`
+	SigVerifyCostSecp256k1 int64            `json:"sig_verify_cost_secp256k1" yaml:"sig_verify_cost_secp256k1"`
+	UnrestrictedAddrs      []crypto.Address `json:"unrestricted_addrs" yaml:"unrestricted_addrs"`


Just a note we don't initialize this new field in DefaultParams

By default, there are no unrestricted accounts since token transfer locking is off. Unrestricted accounts should be added to the genesis file when token locking is set to true. These accounts can be added manually or through a separate genesis command later in the production deployment.

tm2/pkg/sdk/auth/params.go

Gno2D2 · 2024-12-09T04:59:58Z

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

IGNORE the bot requirements for this PR (force green CI check)

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

Fix any issues flagged by automated checks.
Follow the Contributor Checklist to ensure your PR is ready for review.
- Add new tests, or document why they are unnecessary.
- Provide clear examples/screenshots, if necessary.
- Update documentation, if required.
- Ensure no breaking changes, or include BREAKING CHANGE notes.
- Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

Debug

Automated Checks
Maintainers must be able to edit this pull request (more info)
If
🟢 Condition met
└── 🟢 The pull request was created from a fork (head branch repo: piux2/gno)
Then
🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request
Manual Checks
**IGNORE** the bot requirements for this PR (force green CI check)
If
🟢 Condition met
└── 🟢 On every pull request
Can be checked by

Any user with comment edit permission

thehowl · 2024-12-20T18:14:54Z

I was asked by Manfred to provide some feedback on the two different approaches. I don't have strong opinions one way or the other, here's what I consider:

I think having the possibility for the on-chain code to specify params for things that don't exist yet will allow us to configure parameters via the GovDAO for features that are yet to be added with a chain upgrade, while with the struct-based approach the chain upgrade would need to also set the defaults for any new parameter.
The struct-based approach makes it so that param-setting is more intentional; on this regard, one thing that I think we could do if we were to keep the "generic" approach is to enforce keys to only use lowercase ASCII symbols, so we avoid any potential "misleading" upgrades that take advantage of weird unicode symbols or ambiguous characters.
The struct based approach, though, makes it easier to statically analyse and inspect all chain parameters, and how exactly they're used.

If I was forced to choose, the "generic" approach seems to me simple to understand and to build on top of, and like I would shoot myself less frequently in the foot. But I'm not heavily swinging either way.

piux2 · 2024-12-27T19:12:19Z

@thehowl @moul The issue is not limited to key name and type validation. Allowing the creation and update of arbitrary chain parameters is unsafe and could lead to undetectable mistakes, potentially leaving the chain vulnerable to exploitation later.

It's like using a map when we should be using a struct to pass parameters to the critical sections of a program.

Here are some specifics:

Hard to Verify Proposals

In practice, proposals like this are difficult to verify in terms of their behavior and consequences because the behavior is implemented in the code itself.

gno/examples/gno.land/r/gov/dao/v2/prop4_filetest.gno

Line 11 in 3fd5571

mExec := params.NewStringPropExecutor("prop1.string", "value1")

Configuration-Implementation Mismatch

Configurations can easily become out of sync with the code implementation without being noticed. This makes it challenging to track how these settings are linked in the code and how they impact chain behavior. This issue is especially problematic when we need to support backward-compatible features.

Example

This constant does not match the genesis configuration, meaning changes in the genesis will never update the value of chainDomainParamPath as intended.

gno/gno.land/genesis/genesis_params.toml

Line 10 in 3fd5571

["gno.land/r/sys/params.vm"]

gno/gno.land/pkg/sdk/vm/params.go

Line 7 in 3fd5571

chainDomainParamPath = "gno.land/r/sys/params.chain_domain.string"

It could get worse. Imagine if this property were created by GovDao instead of the genesis. All these small mistakes would be extremely difficult to detect. The old key could remain in the chain even after creating a new key chainDomainParamPath = "gno.land/r/sys/params.vm.chain_domain.string" to correct it. Because old keys can persist unnoticed on the chain, they could lead to unexpected results if we accidentally use an outdated on-chain key in the code.

feat: lock token transfer and parameter module

2279644

github-actions bot assigned piux2 Nov 21, 2024

github-actions bot added 🧾 package/realm Tag used for new Realms or Packages. 📦 🤖 gnovm Issues or PRs gnovm related 📦 🌐 tendermint v2 Issues or PRs tm2 related 📦 ⛰️ gno.land Issues or PRs gno.land package related labels Nov 21, 2024

chores: ufmt

c293926

zivkovicmilos requested review from zivkovicmilos and moul November 21, 2024 10:48

Kouteki added the in focus Core team is prioritizing this work label Nov 21, 2024

zivkovicmilos added this to the 🚀 Mainnet launch milestone Nov 21, 2024

Kouteki linked an issue Nov 25, 2024 that may be closed by this pull request

Global GNOT lock #2980

Open

zivkovicmilos requested changes Nov 26, 2024

View reviewed changes

addressed comments

3591b39

piux2 requested a review from zivkovicmilos December 19, 2024 03:35

piux2 added 5 commits December 27, 2024 00:47

merge master

c84c819

merge master

5cecf36

fmt

599e64a

fix test

b7f317a

lint

41d1633

piux2 added 2 commits December 27, 2024 11:31

fix test

9fd24d5

gno tidy

9f05d03

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: lock token transfer and parameter module #3176

feat: lock token transfer and parameter module #3176

piux2 commented Nov 21, 2024

codecov bot commented Nov 21, 2024 •

edited

Loading

zivkovicmilos left a comment

zivkovicmilos Nov 25, 2024

piux2 Dec 8, 2024

zivkovicmilos Nov 25, 2024

piux2 Dec 8, 2024 •

edited

Loading

zivkovicmilos Nov 25, 2024

piux2 Dec 8, 2024

zivkovicmilos Nov 26, 2024

piux2 Dec 9, 2024

zivkovicmilos Nov 26, 2024

zivkovicmilos Nov 26, 2024

piux2 Dec 8, 2024 •

edited

Loading

Gno2D2 commented Dec 9, 2024 •

edited

Loading

✅ Automated Checks (for Contributors):

☑️ Contributor Actions:

☑️ Reviewer Actions:

📚 Resources:

If

Then

If

Can be checked by

thehowl commented Dec 20, 2024

piux2 commented Dec 27, 2024 •

edited

Loading

		stdout '(0 uint64)'


		## vote unlock proposal with unrestricted account test1

feat: lock token transfer and parameter module #3176

Are you sure you want to change the base?

feat: lock token transfer and parameter module #3176

Conversation

piux2 commented Nov 21, 2024

Context for Locking Token Transfer

Here are some implementation details

Main Idea Behind the Alternative Approach To implement parameter module ( Discussion)

codecov bot commented Nov 21, 2024 • edited Loading

Codecov Report

zivkovicmilos left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piux2 Dec 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

piux2 Dec 8, 2024 • edited Loading

Choose a reason for hiding this comment

Gno2D2 commented Dec 9, 2024 • edited Loading

🛠 PR Checks Summary

Manual Checks (for Reviewers):

✅ Automated Checks (for Contributors):

☑️ Contributor Actions:

☑️ Reviewer Actions:

📚 Resources:

If

Then

If

Can be checked by

thehowl commented Dec 20, 2024

piux2 commented Dec 27, 2024 • edited Loading

codecov bot commented Nov 21, 2024 •

edited

Loading

piux2 Dec 8, 2024 •

edited

Loading

piux2 Dec 8, 2024 •

edited

Loading

Gno2D2 commented Dec 9, 2024 •

edited

Loading

piux2 commented Dec 27, 2024 •

edited

Loading