gnolang / gno

Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source
https://gno.land/
Other
842 stars 343 forks source link

Accounts should be locked and unlockable #1837

Open deelawn opened 3 months ago

deelawn commented 3 months ago

This has to do with GNOT distribution. Accounts should be locked by default -- any transactions submitted should fail while in this locked state, with the exception of a new type of transaction that can be submitted to unlock the account. The new type of transaction should be submitted to indicate that the account owner agrees with the terms of a legal waiver authored by us. Alternately, we could have a special realm the account can call to agree to the waiver and unlock the account.

As for the implementation details, we can add a new method of the keys.Info type that returns a boolean indicating whether the account has submitted a transaction agreeing to the waiver, then update all interface implementations accordingly. https://github.com/gnolang/gno/blob/master/tm2/pkg/crypto/keys/types.go#L87-L98

Another issue will follow that makes some accounts (exchanges, ICF, IBC) unlockable only by passing a governance proposal.

@moul @jaekwon -- please edit or add any details Ii have missed.

moul commented 3 months ago

To enhance performance, we should handle locking filters by adding new fields in tm2's user store. The mempool should efficiently filter transactions with minimal lookups.

For updating fields and managing logic, we can apply the same approach planned for PoC (r/sys/valset), and the namespace system (r/sys/names). This involves having gnoland listen to specific std.Event (#575) triggered by r/sys/acctlock.


For the three types of locking, consider the following: