Eco balance in auto-deploy procedure #150

New issue

Open

opened 2025-12-28 18:08:41 +00:00 by sami · 3 comments

sami commented

2025-12-28 18:08:41 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Jul 5, 2023).

TBD ✍️

Originally created by @cthulhu-rider on GitHub (Jul 5, 2023). TBD :writing_hand:

sami added the

enhancement

labels

2025-12-28 18:08:41 +00:00

sami commented

2025-12-28 18:08:42 +00:00

Author

Owner

@AnnaShaleva commented on GitHub (Jul 5, 2023):

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. https://github.com/nspcc-dev/neofs-contract/issues/496.

@AnnaShaleva commented on GitHub (Jul 5, 2023): 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. https://github.com/nspcc-dev/neofs-contract/issues/496.

sami commented

2025-12-28 18:08:42 +00:00

Author

Owner

@AnnaShaleva commented on GitHub (Jul 5, 2023):

Ref. https://github.com/nspcc-dev/neofs-node/pull/2408.

@AnnaShaleva commented on GitHub (Jul 5, 2023): Ref. https://github.com/nspcc-dev/neofs-node/pull/2408.

sami commented

2025-12-28 18:08:42 +00:00

Author

Owner

@roman-khimov commented on GitHub (Aug 10, 2023):

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

Yep.

@roman-khimov commented on GitHub (Aug 10, 2023): > Proxy contract usage as signer and definite height-dependant round-robin algorithm of choosing the node that should start the update notary process. Yep.