Eco balance in auto-deploy procedure

[cthulhu-rider]

TBD ✍️

[AnnaShaleva]

Contracts update during auto-deploy procedure is based on the following scenario in the worst case of simultaneouse alphabet nodes restart with fresh contract binaries:

• All N alphabet nodes wake up and start to try to update contracts (let it be a single NNS contract for certainty)
• Each node sends her own notary request with unique main transaction (main transactions differ in the first signer which is singlesignature account of the alphabet node), overall N unique main transactions
• Each node receives notary request from its neighbours and answers with yet another notary request, overall amount of notary requests in this procedure is N*N
• Notary service collects signatures for all N unique main transactions and sends all N main transactions (each of them updates single NNS contract) to the network
• All N transactions are accepted into block. First of them is HALTed, the rest of them will FAULT, because NNS contract (as far as the rest of the contracts) requires version upgrade on each update.

The problem here is that each alphabet node pays for its main transaction (even if the transaction is FAULTed). As a result all N nodes will pay for all update transactions emitted for all contracts. It costs a lot and we have to wait until committee nodes will earn enough gas to start this update procedure. This scheme is very unoptimal. It would be nice if only single node could pay for a single updating transaction. It can be achieved via Proxy contract usage as signer and definite height-dependant round-robin algorithm of choosing the node that should start the update notary process.

Ref. nspcc-dev/neofs-node#2416.

[AnnaShaleva]

Ref. nspcc-dev/neofs-node#2408.

[roman-khimov]

Proxy contract usage as signer and definite height-dependant round-robin algorithm of choosing the node that should start the update notary process.

Yep.