Contract configuration constraints #128

New issue

Closed

opened 2025-12-28 18:08:37 +00:00 by sami · 4 comments

sami commented

2025-12-28 18:08:37 +00:00

Owner

Originally created by @AnnaShaleva on GitHub (Jan 27, 2023).

The common pattern of storing the contract configuration is to use the set of key-value records. Given the neofs contract as an example, function nspcc-dev/neofs-contract@dc89137484/neofs/neofs_contract.go (L511) restricts the maximum amount of config fields to ~682 (3 stackitems for a single record, 2047 records at max). Although currently we don't have a lot of configuration values, the problem is that this list is append-only (there's no code that allows to remove values from the contract config). If someday we're going to excessively extend our configs then this problem may be solved with returning an iterator from this method.

Ref. #304.

Originally created by @AnnaShaleva on GitHub (Jan 27, 2023). The common pattern of storing the contract configuration is to use the set of [key-value records](https://github.com/nspcc-dev/neofs-contract/blob/dc89137484cd042e79378d4745558cc560b6368a/neofs/neofs_contract.go#L472). Given the neofs contract as an example, function https://github.com/nspcc-dev/neofs-contract/blob/dc89137484cd042e79378d4745558cc560b6368a/neofs/neofs_contract.go#L511 restricts the maximum amount of config fields to ~682 (3 stackitems for a single record, 2047 records at max). Although currently we don't have a lot of configuration values, the problem is that this list is append-only (there's no code that allows to remove values from the contract config). If someday we're going to excessively extend our configs then this problem may be solved with returning an iterator from this method. Ref. #304.

sami

2025-12-28 18:08:37 +00:00

closed this issue
added the
enhancement

S2

I4

U2

config
labels

sami commented

2025-12-28 18:08:37 +00:00

Author

Owner

@roman-khimov commented on GitHub (Jan 27, 2023):

Generic SetConfig/Config/ListConfig things are just a bad interface. Can easily be misused, impossible to track compatibility/migrations at the contract level. Of course you don't have a lot of options at _deploy time, but other than that each value should have a separate get/set function pair and contracts should deal with the storage schemas/migrations/compatibility internally.

@roman-khimov commented on GitHub (Jan 27, 2023): Generic SetConfig/Config/ListConfig things are just a bad interface. Can easily be misused, impossible to track compatibility/migrations at the contract level. Of course you don't have a lot of options at `_deploy` time, but other than that each value should have a separate get/set function pair and contracts should deal with the storage schemas/migrations/compatibility internally.

sami commented

2025-12-28 18:08:37 +00:00

Author

Owner

@roman-khimov commented on GitHub (Feb 4, 2023):

Another side-effect of the current approach, BTW:

$ ./bin/neo-go contract testinvokefunction -r https://rpc3.morph.t5.fs.neo.org:51331 c4576ea5c3081dd765a17aaaa73d9352e74bdc28 config BasicIncomeRate
{
  "state": "HALT",
  "gasconsumed": "136044",
  "script": "DA9CYXNpY0luY29tZVJhdGURwB8MBmNvbmZpZwwUKNxL51KTPaeqeqFl1x0Iw6VuV8RBYn1bUg==",
  "stack": [
    {
      "type": "ByteString",
      "value": "AOH1BQ=="
    }
  ],
  "exception": null,
  "notifications": []
}

It's a number in fact.

@roman-khimov commented on GitHub (Feb 4, 2023): Another side-effect of the current approach, BTW: ``` $ ./bin/neo-go contract testinvokefunction -r https://rpc3.morph.t5.fs.neo.org:51331 c4576ea5c3081dd765a17aaaa73d9352e74bdc28 config BasicIncomeRate { "state": "HALT", "gasconsumed": "136044", "script": "DA9CYXNpY0luY29tZVJhdGURwB8MBmNvbmZpZwwUKNxL51KTPaeqeqFl1x0Iw6VuV8RBYn1bUg==", "stack": [ { "type": "ByteString", "value": "AOH1BQ==" } ], "exception": null, "notifications": [] } ``` It's a number in fact.

sami commented

2025-12-28 18:08:37 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Apr 10, 2023):

Not a solution, but a practical relief: defining global defaults. In many cases, this will reduce the amount of data stored and the burden on the administrator.

@cthulhu-rider commented on GitHub (Apr 10, 2023): Not a solution, but a practical relief: defining global defaults. In many cases, this will reduce the amount of data stored and the burden on the administrator.

sami commented

2025-12-28 18:08:37 +00:00

Author

Owner

@roman-khimov commented on GitHub (Dec 20, 2023):

#372 will solve it. Then ListConfig could be removed in some future versions.

@roman-khimov commented on GitHub (Dec 20, 2023): #372 will solve it. Then `ListConfig` could be removed in some future versions.