search

nspcc-dev / neofs-node

NeoFS is a decentralized distributed object storage integrated with the Neo blockchain
https://fs.neo.org
GNU General Public License v3.0
32 stars 38 forks source link

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

Open cthulhu-rider opened 1 year ago

cthulhu-rider commented 1 year ago

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.

AnnaShaleva commented 1 year ago

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 1 year ago

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.

roman-khimov commented 1 year ago

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

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