Change Notary request senders and try to deduplicate main transactions in auto-deploy procedure #148

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).

based on nspcc-dev/neofs-node#2408
see @AnnaShaleva https://github.com/nspcc-dev/neofs-node/pull/2408#discussion_r1252066039

Overview

according to introduced changes, all committee members do all committee actions (such as updating the NNS contract) on their own and independently of each other. This approach was chosen to comply with the overall decentralization of the network (no one knows what state the other participant is in). In particular, this approach will be useful when committee nodes are run non-simultaneously.

if we consider (approximately) synchronous execution of a procedure on all nodes, N nodes will send N requests in total. Lets consider all transactions are semantically correct. Then only first "lucky" one will enter the blockchain while N-1 others will fail.
@AnnaShaleva mentioned pretty important disadvantage of this approach: all nodes will pay for their transaction regardless of success.

Possible solution

We can make Proxy contract to pay for such transactions. Since these will be similar main transactions, only one request will be proceeded by the Notary service.

Pros:

no duplicated transactions => less GAS wasted
???

Cons:

how to make main transactions exactly the same (vub/nonce)?
???

P.S. we can share dynamic transaction's parts in NNS like is done for Notary role designation, but this seems pretty complex and fragile.

Originally created by @cthulhu-rider on GitHub (Jul 5, 2023). * based on nspcc-dev/neofs-node#2408 * see @AnnaShaleva https://github.com/nspcc-dev/neofs-node/pull/2408#discussion_r1252066039 ## Overview according to introduced changes, all committee members do all committee actions (such as updating the NNS contract) on their own and independently of each other. This approach was chosen to comply with the overall decentralization of the network (no one knows what state the other participant is in). In particular, this approach will be useful when committee nodes are run non-simultaneously. if we consider (approximately) synchronous execution of a procedure on all nodes, N nodes will send N requests in total. Lets consider all transactions are semantically correct. Then only first "lucky" one will enter the blockchain while N-1 others will fail. @AnnaShaleva mentioned pretty important disadvantage of this approach: all nodes will pay for their transaction regardless of success. ## Possible solution We can make Proxy contract to pay for such transactions. Since these will be similar main transactions, only one request will be proceeded by the Notary service. Pros: 1. no duplicated transactions => less GAS wasted 2. ??? Cons: 1. how to make main transactions exactly the same (vub/nonce)? 2. ??? P.S. we can share dynamic transaction's parts in NNS like is done for Notary role designation, but this seems pretty complex and fragile.

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):

To clarify things a bit, this issue is mostly related to the currently implemented update procedure.

N nodes will send N requests in total

It's not exactly true. In simultaneous setup scenario current code works in the following way: N nodes will send N*N notary requests in total with N unique main transactions. This happens because we use single signature account (alphabet's one) as the first signer to construct main transaction.

I've firstly suggested to use Proxy contract instead of a single alphabet account as the first signer to reduce the number of unique main transactions (up to one unique main transaction per contract update), but as Leo mentioned, we have a problem with the rest hashable fields synchronisation between the nodes.

From the other side, if we choose some single node to start the update procedure and send initial notary request with update call (the rest of the nodes will track the incoming notary requests and sign them), then the following problem occurs: we don't know how to definitely and reliably choose this single node who will send the first request so that we're 100% sure that exactly one node will init the update process for the subsequent contract.

@AnnaShaleva commented on GitHub (Jul 5, 2023): To clarify things a bit, this issue is mostly related to the currently implemented *update* procedure. > N nodes will send N requests in total It's not exactly true. In simultaneous setup scenario current code works in the following way: N nodes will send N*N notary requests in total with N unique main transactions. This happens because we use single signature account (alphabet's one) as the first signer to construct main transaction. I've firstly suggested to use Proxy contract instead of a single alphabet account as the first signer to reduce the number of unique main transactions (up to one unique main transaction per contract update), but as Leo mentioned, we have a problem with the rest hashable fields synchronisation between the nodes. From the other side, if we choose some single node to start the update procedure and send initial notary request with `update` call (the rest of the nodes will track the incoming notary requests and sign them), then the following problem occurs: we don't know how to definitely and reliably choose this single node who will send the first request so that we're 100% sure that exactly one node will init the update process for the subsequent contract.

sami commented

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

Author

Owner

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

Another problem that occurs within the scope of this issue is that the usage of Proxy contract as the first signer isn't possible for deployment procedure, because there's no Proxy contract at this stage.

@AnnaShaleva commented on GitHub (Jul 5, 2023): Another problem that occurs within the scope of this issue is that the usage of Proxy contract as the first signer isn't possible for *deployment* procedure, because there's no Proxy contract at this stage.

sami commented

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

Author

Owner

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

how to make main transactions exactly the same (vub/nonce)?

VUB = last_epoch_update_block + something (likely it'll fit into MVUBI)
nonce = epoch

@roman-khimov commented on GitHub (Aug 10, 2023): > how to make main transactions exactly the same (vub/nonce)? VUB = last_epoch_update_block + something (likely it'll fit into MVUBI) nonce = epoch