Account-based EACL targets

[roman-khimov]

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

I'm always frustrated when I see public keys in the protocol used instead of accounts. Account is a very powerful abstraction that is not limited to a single key. Current EACL target requirement to have public keys leads to problems in the service layer like nspcc-dev/neofs-s3-gw#861 and while workarounds are possible the root cause of the issue is the requirement to have public keys in targets, they should not be needed to process EACL.

Describe the solution you'd like

Extend target definition with a list of accounts. Deprecate key usage.

Describe alternatives you've considered

Reusing the same field is technically possible (it's just bytes). Not sure it's any better, but you can try convincing me.

[cthulhu-rider]

but you can try convincing me

how about: LEN=33 => key, otherwise account?

[roman-khimov]

Huh. That'd be similar to CheckWitness accepting keys or accounts. But it can be done.

[cthulhu-rider]

But it can be done

good. My main question is - can account be 33B in theory?

[roman-khimov]

To me they all 20 bytes (unfortunately, 25 in real life). If for whatever reason we need some new kind of account and it's 33 bytes originally, we can just add a prefix to distinguish it.

[cthulhu-rider]

then i think we can just shift existing field to accounts with the ability to use keys of length 33. Same message format, easier implementation