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 70.44776% with 198 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
gnovm/stdlibs/sys/params/params.go	0.00%	30 Missing ⚠️
gnovm/stdlibs/std/params.go	50.84%	23 Missing and 6 partials ⚠️
tm2/pkg/sdk/bank/params.go	37.77%	25 Missing and 3 partials ⚠️
tm2/pkg/sdk/bank/keeper.go	71.62%	16 Missing and 5 partials ⚠️
tm2/pkg/sdk/bank/genesis.go	0.00%	15 Missing ⚠️
gno.land/pkg/gnoland/types.go	52.17%	9 Missing and 2 partials ⚠️
gno.land/pkg/sdk/vm/genesis.go	41.17%	7 Missing and 3 partials ⚠️
tm2/pkg/sdk/params/handler.go	71.87%	6 Missing and 3 partials ⚠️
tm2/pkg/sdk/params/keeper.go	86.15%	6 Missing and 3 partials ⚠️
tm2/pkg/std/errors.go	52.63%	9 Missing ⚠️
... and 7 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

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

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

gno.land/pkg/gnoland/app.go

gno.land/pkg/gnoland/app_test.go

tm2/pkg/sdk/auth/genesis.go

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
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 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.

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

tm2/pkg/sdk/bank/keeper.go

zivkovicmilos · 2025-01-08T15:18:43Z

@piux2 @moul

I'll try to sum up my primary concerns with this PR, and we just need to agree if we're okay with this at this point in the chain's lifecycle:
I honestly believe this PR introduces more coupling, and tech debt that will need to be paid at some point (with interest). I've tried to note in the comments on my first review pass the critical areas. This is the first thing we all need to swallow, before we even start discussing the implementation details.

Things that keep me worried about the implementation:

Unrestricted in BaseAccount, whose place there has far-reaching implications, long after we enable token transfers (this generally concerns use-case specific code we're introducing now, to live on forever in core types)
amino.Marshal for custom params structs -- at this point I don't have a better proposal, but something is holding me back from saying "okay" to this. Launching a v2 of a struct is going to be a nightmare to maintain, and track. It's also going to require a lot of handler code, to ensure backwards compatibility between protocol upgrades
We introduced InitGenesis and SetParams for keepers, but these are not called in a standard way by the app bootstrap process -- they're custom calls. On the surface they enforce structure, but nothing is stopping us from changing the signature of SetParams for the banker module for example, while keeping the rest unchanged (no interface call is enforced).

What I like about the PR:

It moves the responsibility of "params" from a single central keeper, to individual modules, that define what they need and what "params" look like. I think this is the scalable way to go, and easier to understand in code

In terms of which approach to go with, maybe we can opt for a fusion of the two ideas?

keep "params" as individual fields, as opposed to structs
keep the ownership / management of "params" on the modules (a version introduced in this PR)

I'm more inclined to opt for the field approach Manfred initially advocated for, because it seems more durable and future-proof. We already support most field types, so I can't foresee an issue when we need to change values or update structs (completely revamp what "params" are). We also don't encounter the amino.Marshal moment, which opens up a pandora box of its own, that I'd prefer to keep closed and sealed shut 🙂

piux2 · 2025-01-09T00:50:20Z

@zivkovicmilos

This PR supports both individual field parameters and struct types.

The most important gap we aim to resolve between this PR and the existing params implementation is the following:

a) The current implementation treats the Param module as a native store, allowing arbitrary chain parameter key-value pairs to be added from both genesis and GovDao.

b) This PR predefines chain parameters in the code, allowing only their values to be modified from genesis and GovDao.

gnovm/stdlibs/std/params.go

…o feat_lock_transfer

zivkovicmilos

Went through the PR again from scratch because of the changes, and it took me a minute 🙏

I think the PR applies most of the changes we've left in the comments. Apart from what @moul is discussing on the format, I think it looks alright, given what we want to accomplish now ahead of the launch.

Unblocking the PR 🙏

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

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

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

tm2/pkg/sdk/params/keeper.go

tm2/pkg/sdk/params/params_test.go

tm2/pkg/sdk/params/test_common.go

tm2/pkg/std/account.go

…o feat_lock_transfer

jaekwon · 2025-02-20T03:48:45Z

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

+}
+
+func (prm *SDKParams) assertRealmAccess(key gstd.ParamKey) {
+	realm := gno.ReRealmPath.FindString(key.Realm)


MathString? realm isn't used so more efficient.

I think we should replace with gno.IsRealm. It's got a bit more logic.

jaekwon · 2025-02-20T04:01:05Z

gnovm/stdlibs/std/params.go

+func (pk ParamKey) String() string {
+	pks := ""
+	if pk.Prefix == "" {
+		pks = fmt.Sprintf("vm:%s.%s", pk.Realm, pk.Key)


it should be fmt.Sprintf("%s:%s.%s", pk.Module, pk.Realm, pk.Key).
"vm:" should not be hard coded here so different modules can have "realms" too.

type ParamKey struct {
Module string // NOTE comes first
Realm string
Key string
Type string
}

If 'auth:gno.land/r/sys/params.tx_size_cost_per_byte.string' is considered a valid key, how can we validate a user's intention to modify either a predefined module parameter (such as 'auth:max_memo_bytes' or 'auth:tx_size_cost_per_byte') or 'gno.land/r/sys/params.tx_size_cost_per_byte.string', which is not valid in the auth module?

gno/tm2/pkg/sdk/auth/params.go

Line 26 in 955e1ca

type Params struct {

Does it also conflict with an earlier defined rule that everything modified from the contract must start with "vm:" ?

jaekwon · 2025-02-20T04:15:17Z

tm2/pkg/sdk/bank/keeper.go

+	if amt.ContainOneOfDenom(toSet(rds)) {
+		acc := bank.acck.GetAccount(ctx, addr)
+		accr := acc.(std.AccountRestricter)
+		if acc != nil && accr.IsRestricted() {


!accr.IsUnrestricted() and accr.IsRestricted() are NOT the same thing.

Please replace this with !accr.IsUnrestricted() and remove all references of code of "IsRestricted()", because that should really be a separate flag, perhaps with a different name to avoid confusion.

Example: Normally you might have Alice, Bob, Carl, David, and say only Alice is Unrestricted.

With the transfer lock, only Alice can send, Bob, Carl, David cannot. After the transfer lock is released, everyone can send. Bob, Carl, and David are not restricted, and never were individually, and yet accr.IsRestricted() would still return true. Semantically wrong.

And if David were a bad actor, his account might be "Frozen". So accr.IsFrozen() might be true, but it's not the same flag (nor the inversion of) IsUnrestricted.

agree, done.

jaekwon · 2025-02-20T04:22:14Z

tm2/pkg/sdk/bank/params.go

+		if value != "" { // lock sending denoms
+			bank.AddRestrictedDenoms(ctx, value.(string))
+		} else { // unlock sending ugnot
+			bank.DelAllRestrictedDenoms(ctx)


It is weird to make setting a parameter be stateful like this.

We don't need "AddRestrictedDenoms" and "DelAllRestrictedDenoms", there is one parameter named "RestrictedDenoms", and there only need be one function named "bank.SetRestrictedDenoms(ctx, string)".

Then if value != "" { should also disappear.

This is because the RestrictedDenom string allows multiple values. However, when we vote to add a RestrictedDenom from the contract, people do not necessarily know or need to know what has been added previously. That is why I used 'Add' instead of directly calling SetRestrictedDenoms to set entire restricted demons list from the GNO contract.

jaekwon · 2025-02-20T04:23:10Z

tm2/pkg/sdk/bank/keeper.go

 	}
 }

+func (bank BankKeeper) AddRestrictedDenoms(ctx sdk.Context, restrictedDenoms ...string) {


Replace AddRestrictedDenoms/DelRestrictedDenoms/DelAllRestrictedDenoms with simply. "SetRestrictedDenoms".

https://github.com/gnolang/gno/pull/3176/files#r1962837296

jaekwon · 2025-02-20T05:04:37Z

tm2/pkg/sdk/params/keeper.go

+		}
+	}
+
+	bz, err := amino.MarshalJSON(param)


Rather than storing the whole thing under "key" as a single object {...},
every field in param should be broken up, and stored either as "module:_.key" or "module.key".
This requires reflection, like reflect.ValueOf(param).Field(i).Tag and .Name, and whatever logic amino uses to derive the json key name.

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 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

zivkovicmilos reviewed Jan 8, 2025

View reviewed changes

examples/gno.land/r/gov/dao/v2/prop4_filetest.gno Outdated Show resolved Hide resolved

tm2/pkg/sdk/bank/keeper.go Show resolved Hide resolved

jaekwon reviewed Jan 9, 2025

View reviewed changes

gnovm/stdlibs/std/params.go Outdated Show resolved Hide resolved

piux2 added 10 commits February 13, 2025 11:43

updated prefix, validation and tests

fb627fa

merge the Master in this branch

76fb5ee

Merge branch 'feat_lock_transfer' of https://github.com/piux2/gno int…

cf36f63

…o feat_lock_transfer

fix test

3002f65

fix the test

cf9fe49

lint

bfe737f

fix test

d98a5d2

more testing coverage

8f6b1a8

fix

1c653cc

Merge remote-tracking branch 'origin/master' into feat_lock_transfer

b3ee19f

zivkovicmilos approved these changes Feb 17, 2025

View reviewed changes

Kouteki mentioned this pull request Feb 17, 2025

Test6 launch #3142

Open

piux2 and others added 11 commits February 17, 2025 14:46

Minor fixes and code cleanup.

3fd67eb

fix lower case const

8c598e2

Merge remote-tracking branch 'origin/master' into feat_lock_transfer

1c84000

updated the CI workflows go version to 1.23.xx

9889ece

Merge branch 'master' into feat_lock_transfer

98af87b

more tests and clean up

02d1a61

merged master in this branch

d3a24d9

Merge branch 'feat_lock_transfer' of https://github.com/piux2/gno int…

1edd921

…o feat_lock_transfer

fix test

228a273

fix test

3ceaadf

fix test

12b6f19

jaekwon reviewed Feb 20, 2025

View reviewed changes

remove account.IsRestrict() and use account.IsUnrestricted() instead

6e07d28

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

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

zivkovicmilos commented Jan 8, 2025

piux2 commented Jan 9, 2025

zivkovicmilos left a comment

jaekwon Feb 20, 2025

jaekwon Feb 20, 2025

jaekwon Feb 20, 2025

piux2 Feb 20, 2025 •

edited

Loading

jaekwon Feb 20, 2025

piux2 Feb 20, 2025

jaekwon Feb 20, 2025

piux2 Feb 20, 2025 •

edited

Loading

jaekwon Feb 20, 2025

jaekwon Feb 20, 2025

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

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

zivkovicmilos commented Jan 8, 2025

piux2 commented Jan 9, 2025

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 Feb 20, 2025 • 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

piux2 Feb 20, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented Nov 21, 2024 •

edited

Loading

Gno2D2 commented Dec 9, 2024 •

edited

Loading

piux2 commented Dec 27, 2024 •

edited

Loading

piux2 Feb 20, 2025 •

edited

Loading

piux2 Feb 20, 2025 •

edited

Loading