Define keys to the network config values

[cthulhu-rider]

In current protocol network configuration is represented by list of raw KV pairs. When new net config is added, there is no way to select its value by key. I propose to add constant keys to the existing config values.

[alexvanin]

Used network parameters as for today.

Parameter name (hex encoded string)	Parameter value type
AuditFee	LittleEndian UInt64
BasicIncomeRate	LittleEndian UInt64
ContainerAliasFee	LittleEndian UInt64
ContainerFee	LittleEndian UInt64
EigenTrustAlpha	Hex encoded string of decimal float, e.g. 0.1
EigenTrustIterations	LittleEndian UInt64
EpochDuration	LittleEndian UInt64
InnerRingCandidateFee	LittleEndian UInt64
MaxObjectSize	LittleEndian UInt64
WithdrawFee	LittleEndian UInt64

[carpawell]

Also, HomomorphicHashingDisabled or something like that after nspcc-dev/neofs-node#1300.

[cthulhu-rider]

I propose to structure network configuration. It's inconvenient to work with raw list of byte arrays. With structured message we won't be needed to describe the format of each parameter.

[alexvanin]

I agree, that it will be more explicit to define required network configuration as protobuf message fields.

However, there is one interesting case where it is useful to have raw list that stores all parameters from the smart contract. Network configuration can define values unrelated to NeoFS Core, but relevant for deployment environment. For example, it can store address of DNS server, which can resolve bucket nice names into container IDs. This allows:

• to set DNS server address once and avoid config reconfiguration on all gates,
• avoid connection to RPC node in S3 Gateway and use only NeoFS endpoint.

Encoding / decoding format for this case is negotiated outside of API scope.

[cthulhu-rider]

@alexvanin thx, I got it.

I think it'd be nice to have a way to distinguish NeoFS native data from the full configuration. In most of the usecases client side needs a subset of the config value (almost always exactly one), but it always receives all of them. What if we'll accept some parameter in request body that will limit data to be read?

For example, to begin with, you can specify the need for custom values ​​that are not interpreted by the protocol:

// system value, e.g. max object size
request <- new network_info_request
request.system_only = true

request -> send()

resp <- recv()
maxSize <- resp.max_object_size

// custom uninterpretable value
request <- new network_info_request

request -> send()

resp <- recv()
foreach i in resp.values {
  // process  (resp.values[i].key, resp.values[i].value)
}

We can go further: accept list of keys to be read. This will allow to read less values than needed. System interpreted values can be enumerated and toggled using bitmask.

request <- NetworkInfoRequest
request.SystemMask = 1000_1100_0111_0000

request -> send()

resp <- recv()
// process requested values

// custom uninterpretable value
request <- NetworkInfoRequest
request.key_list.append("custom_config1")
request.key_list.append("custom_config2")

request -> send()

resp <- recv()
// process resp.values[0] which contains custom_config1 value
// process resp.values[1] which contains custom_config2 value

[fyrchik]

After the latest SDK changes, de facto format for integer values is 8-byte uint64. I think we should allow less than 8-byte uint64 too:

1. It is much easier to work from console (e.g. in dev-env and tests)
2. It is backwards compatible
3. It can be interpreted and/or set by contracts.

[cthulhu-rider]

• MaintenanceModeAllowed boolean