Smart IR -> SN GAS transfers #345

Open
opened 2025-12-28 17:19:10 +00:00 by sami · 2 comments
Owner

Originally created by @carpawell on GitHub (Oct 12, 2021).

After #873 there is rude notary deposit logic: SN checks its notary and GAS balances and tries to keep 1:3 GAS to Notary balance proportion with GAS/2 OR 1 deposits.

But it could not be always good, e.g. for tests, it is common practice to set epoch to 20 blocks in dev-env, but IR sends GAS to SN only once in 300 blocks(it does not depends on epoch duration), so SN runs out of GAS(not notary balance) with the time.

Questions

  1. How often/much should IR send GAS to SN?
  2. Should it depend on netmap size/SN's balances?
  3. Should SN change its deposit logic?
Originally created by @carpawell on GitHub (Oct 12, 2021). After #873 there is rude notary deposit logic: `SN` checks its notary and GAS balances and tries to keep 1:3 GAS to Notary balance proportion with `GAS/2` OR `1` deposits. But it could not be always good, e.g. for tests, it is common practice to set epoch to 20 blocks in dev-env, but `IR` sends GAS to `SN` only once in 300 blocks(it does not depends on epoch duration), so `SN` runs out of GAS(not notary balance) with the time. ### Questions 1. How often/much should `IR` send GAS to `SN`? 2. Should it depend on `netmap` size/`SN`'s balances? 3. Should `SN` change its deposit logic?
Author
Owner

@cthulhu-rider commented on GitHub (May 12, 2022):

Mb related #830

How to fill SN with GAS based on SN's needs?

Fund spending depends on notary flag.

We don't want to bind this events to NeoFS epochs. Send once per 300 epochs, we have a fee per TX, more TXs => more extra funds. Network config parameter?

We need to briefly describe the process: needs, amounts and current implementation.

@cthulhu-rider commented on GitHub (May 12, 2022): Mb related #830 How to fill SN with GAS based on SN's needs? Fund spending depends on notary flag. We don't want to bind this events to NeoFS epochs. Send once per 300 epochs, we have a fee per TX, more TXs => more extra funds. Network config parameter? We need to briefly describe the process: needs, amounts and current implementation.
Author
Owner

@carpawell commented on GitHub (May 16, 2022):

Current implementation: IR has NEOFS_IR_TIMERS_EMIT env which means how often (in blocks) Alphabet should send NEOFS_IR_EMIT_STORAGE_AMOUNT/len(netmap) GAS to every SN.

So I think that the algorithm has some drawbacks:

  1. it is not connected to the epoch duration while almost all processes in NeoFS are done once per epoch;
  2. the more SNs we have the less every node receives;
  3. it does not take into account node's balance but not every node spends an equal amount of GAS;
  4. SN becomes real rich unstoppably. Not sure but maybe that may lead to some potential opportunities for external attackers (have their own SN => will have a huge amount of GAS soon).

On the other hand, we can see that the current rule allows having a stable mainnet and testnet (except for the fact that we have GAS transfers that SNs do not need at all: their balances are 20K+).

How to fill SN with GAS based on SN's needs?

Directions in which I think we need to think about in that issue:

  1. Do not send GAS at all if SN spends GAS more times less than it receives. Maybe add some practical threshold that every SN should have on its balance.
  2. Change trigger period.
  3. Find out the difference between notary/non-notary SN's spending and decide if we need to take into account NeoFS contract side signature collecting.

Network config parameter?

I do not think that it should be a network parameter: I think flexibility should be achieved automatically, not via setting config values.

Fund spending depends on notary flag.

General rule: in notary-enabled env SN spends GAS only on TX that must be modified by the Alphabet and, therefore, must be formed from scratch. I think that it is only AddPeer TX that is also used as a health check. All the other expenses are on the Proxy contract.

@carpawell commented on GitHub (May 16, 2022): Current implementation: IR has `NEOFS_IR_TIMERS_EMIT` env which means how often (in blocks) Alphabet should send `NEOFS_IR_EMIT_STORAGE_AMOUNT`/`len(netmap)` GAS to every SN. So I think that the algorithm has some drawbacks: 1. it is not connected to the epoch duration while almost all processes in NeoFS are done once per epoch; 2. the more SNs we have the less every node receives; 3. it does not take into account node's balance but not every node spends an equal amount of GAS; 4. SN becomes *real rich* unstoppably. Not sure but maybe that may lead to some potential opportunities for external attackers (have their own SN => will have a huge amount of GAS soon). On the other hand, we can see that the current rule allows having a stable mainnet and testnet (except for the fact that we have GAS transfers that SNs do not need at all: their balances are 20K+). > How to fill SN with GAS based on SN's needs? Directions in which I think we need to think about in that issue: 1. Do not send GAS at all if SN spends GAS more times less than it receives. Maybe add some practical threshold that every SN should have on its balance. 2. Change trigger period. 3. Find out the difference between notary/non-notary SN's spending and decide if we need to take into account NeoFS contract side signature collecting. > Network config parameter? I do not think that it should be a network parameter: I think flexibility should be achieved automatically, not via setting config values. > Fund spending depends on notary flag. General rule: in notary-enabled env SN spends GAS only on TX that must be modified by the Alphabet and, therefore, must be formed from scratch. I think that it is only `AddPeer` TX that is also [used as a health check](https://github.com/nspcc-dev/neofs-node/issues/830). All the other expenses are on the Proxy contract.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nspcc-dev/neofs-node#345
No description provided.