Contract configuration constraints

[AnnaShaleva]

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

neofs-contract/neofs/neofs_contract.go

Line 511 in dc89137

func ListConfig() []record {

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.

[roman-khimov]

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]

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.

[cthulhu-rider]

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.

[roman-khimov]

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