mirror of
https://github.com/nspcc-dev/neofs-node.git
synced 2026-03-01 04:29:10 +00:00
Smart IR -> SN GAS transfers #345
Labels
No labels
I1
I2
I3
I4
S0
S1
S2
S3
S4
U0
U1
U2
U3
U4
blocked
bug
config
dependencies
discussion
documentation
enhancement
enhancement
epic
feature
go
good first issue
help wanted
neofs-adm
neofs-cli
neofs-cli
neofs-cli
neofs-ir
neofs-lens
neofs-storage
neofs-storage
performance
question
security
task
test
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
nspcc-dev/neofs-node#345
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @carpawell on GitHub (Oct 12, 2021).
After #873 there is rude notary deposit logic:
SNchecks its notary and GAS balances and tries to keep 1:3 GAS to Notary balance proportion withGAS/2OR1deposits.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
IRsends GAS toSNonly once in 300 blocks(it does not depends on epoch duration), soSNruns out of GAS(not notary balance) with the time.Questions
IRsend GAS toSN?netmapsize/SN's balances?SNchange its deposit logic?@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.
@carpawell commented on GitHub (May 16, 2022):
Current implementation: IR has
NEOFS_IR_TIMERS_EMITenv which means how often (in blocks) Alphabet should sendNEOFS_IR_EMIT_STORAGE_AMOUNT/len(netmap)GAS to every SN.So I think that the algorithm has some drawbacks:
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+).
Directions in which I think we need to think about in that issue:
I do not think that it should be a network parameter: I think flexibility should be achieved automatically, not via setting config values.
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
AddPeerTX that is also used as a health check. All the other expenses are on the Proxy contract.