Verifiable attributes #2280

roman-khimov · 2023-03-15T18:57:18Z

Is your feature request related to a problem? Please describe.

Any node operator can set any attribute for their node on the network. We can't have some controlled group that uses an attribute no one else can use, while this might be useful.

Describe the solution you'd like

One simple approach is just to have a public group key and some signature derived from the corresponding private key, similar to the way NEP-15 groups are designed (https://github.com/neo-project/proposals/blob/master/nep-15.mediawiki#user-content-Group). It may be not the most convenient one at the same time.

Describe alternatives you've considered

Another approach could be reusing NNS with some special key/address entries for nodes. Maybe there are some other ones.

Private node attribute are coming. The term private means that the system controls access to the declaration of certain attributes by storage nodes. This feature will allow you to prevent unauthorized installation of attributes that semantically require confirmation. Until now, storage nodes were free to set format-valid attributes. Therefore, to prepare for the feature arrival, a new attribute validator (`netmap.NodeValidator`) is introduced: it fakes the real validation and allows all nodes to access all attributes. In the future, verification will be tightened. Refs #2280. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>

Previously, storage nodes could declare (almost) any key-value attributes while entering the network map. Sometimes there is a need to restrict access to a specific attribute value. To do this, the concept of a private node attribute is introduced. Access lists with public key are stored in the NeoFS NNS: for each private attribute there is a domain, and only nodes recorded in this domain are able to use this attribute. From now, the Inner Ring checks any incoming node for permission to use private attributes (if any). Closes #2280. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>

Add command to get and set list of public keys for the storage nodes allowed to use private attribute. Refs #2280. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>

Previously, storage nodes could declare (almost) any key-value attributes while entering the network map. Sometimes there is a need to restrict access to a specific attribute value. To do this, the concept of a private node attribute is introduced. Access lists with public key are stored in the NeoFS NNS: for each private attribute there is a domain, and only nodes recorded in this domain are able to use this attribute. From now, the Inner Ring checks any incoming node for permission to use private attributes (if any). Closes #2280. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>

Add command to get and set list of public keys for the storage nodes allowed to use private attribute. Refs #2280. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>

From now, the Inner Ring checks any incoming node for permission to associate itself with optional private node group (kind of subnet). Access lists are stored in the NeoFS NNS. Closes #2280. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>