client: Optimize message encoding for signing #260

New issue

Open

opened 2025-12-28 18:07:36 +00:00 by sami · 0 comments

sami commented

2025-12-28 18:07:36 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Dec 11, 2024).

currently, to sign any request, Client encodes its parts and passes to the signing func. Any encoding result is a protobuf message. There are 3 supported crypto schemes at the moment, and each of them hashes the signed payload. After signatures are calculated, Client attaches it to the request, encodes it into protobuf and passes into gRPC transport

with this, client takes up a lot of memory. More lightweight approach is desired

Describe the solution you'd like

calculate the signed checksum immediately w/o an intermediate buffer. The message can provide corresponding interface for this. https://pkg.go.dev/io#WriterTo is the closes std one (but there is no need for (int64, error) return)

Describe alternatives you've considered

continue current encoding, but use resulting protobuf messages not just for signing but for gRPC transport too

this is harder to implement, but will go more efficiently

Additional context

i block this for now. https://github.com/nspcc-dev/neofs-api/issues/305 is about to come, and may make all these irrelevant

Originally created by @cthulhu-rider on GitHub (Dec 11, 2024). ## Is your feature request related to a problem? Please describe. currently, to sign any request, `Client` encodes its parts and passes to the signing func. Any encoding result is a protobuf message. There are 3 supported crypto schemes at the moment, and each of them hashes the signed payload. After signatures are calculated, Client attaches it to the request, encodes it into protobuf and passes into gRPC transport with this, client takes up a lot of memory. More lightweight approach is desired ## Describe the solution you'd like calculate the signed checksum immediately w/o an intermediate buffer. The message can provide corresponding interface for this. https://pkg.go.dev/io#WriterTo is the closes std one (but there is no need for `(int64, error)` return) ## Describe alternatives you've considered continue current encoding, but use resulting protobuf messages not just for signing but for gRPC transport too this is harder to implement, but will go more efficiently ## Additional context i block this for now. https://github.com/nspcc-dev/neofs-api/issues/305 is about to come, and may make all these irrelevant