TrueCloudLab/frostfs-node

Fork 27

Inconsistent `morph init` behavior before and after `height ≈ 100` #1391

New issue

Closed

opened 2024-09-23 14:31:01 +00:00 by potyarkin · 2 comments

potyarkin commented

2024-09-23 14:31:01 +00:00

Member

Expected Behavior

frostfs-adm morph init should work the same regardless of current blockchain height.

Current Behavior

Given a 7-node NEO network (all 7 nodes are members of committee) morph init works differently depending on current blockchain height:

If current block height is below 100, morph init works as expected. It transfers a lot of GAS and some NEO tokens to committee account in alphabet wallets prior to proceeding with Stage 2 where these tokens will be used to cover transaction fees.

If current block height is above 100, committee accounts in alphabet wallets remain empty and Stage 2 fails with an error:

Stage 2: set notary and alphabet nodes in designate contract.                                                                                                                                                  
Error: Insufficient funds (-511) - insufficient funds

Threshold value of 100 is a rough estimate based on multiple manual tests (i.e. morph init works when started around height = 39, but does not work with height = 249, height = 135, height = 100)

Possible Solution

No fix can be suggested by reporter. Further solutions shall be up to developers.

Steps to Reproduce (for bugs)

Generate a 7-letter alphabet: frostfs-adm morph generate-alphabet --size 7
Start 7-node neo-go privnet using alphabet keys for consensus nodes
bin/frostfs-adm-v0.42.9 morph init --contracts data/contracts --rpc-endpoint http://neo-go-endpoint --alphabet-wallets wallet

Context

Private chat (one, two)
This issue did not come up with 1-node and 4-node alphabets. Probably because multisig accounts for committee and consensus are the same in those scenarios but are distinct with 7-node alphabet.

Regression

Your Environment

Version used:
- frostfs-adm v0.42.9
- frostfs-contracts v0.19.4
- neo-go v0.106.3
Server setup and configuration: custom exploratory environment (protocol.privnet.yml)
Operating System and version (uname -a): Linux hostname 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux

## Expected Behavior `frostfs-adm morph init` should work the same regardless of current blockchain height. ## Current Behavior Given a 7-node NEO network (all 7 nodes are members of committee) `morph init` works differently depending on current blockchain height: - If current block height is below 100, `morph init` works as expected. It transfers a lot of GAS and some NEO tokens to `committee` account in alphabet wallets prior to proceeding with `Stage 2` where these tokens will be used to cover transaction fees. - If current block height is above 100, `committee` accounts in alphabet wallets remain empty and `Stage 2` fails with an error: ``` Stage 2: set notary and alphabet nodes in designate contract. Error: Insufficient funds (-511) - insufficient funds ``` Threshold value of 100 is a rough estimate based on multiple manual tests (i.e. `morph init` works when started around height = 39, but does not work with height = 249, height = 135, height = 100) ## Possible Solution No fix can be suggested by reporter. Further solutions shall be up to developers. ## Steps to Reproduce (for bugs) - Generate a 7-letter alphabet: `frostfs-adm morph generate-alphabet --size 7` - Start 7-node neo-go privnet using alphabet keys for consensus nodes - `bin/frostfs-adm-v0.42.9 morph init --contracts data/contracts --rpc-endpoint http://neo-go-endpoint --alphabet-wallets wallet` ## Context - Private chat ([one](https://chat.yadro.com/yadro/pl/wcit3x8zijr5bfbbbfb3fjmgno), [two](https://chat.yadro.com/yadro/pl/nj7ubzasftf3zcxoguxkdrnxso)) - This issue did not come up with 1-node and 4-node alphabets. Probably because multisig accounts for `committee` and `consensus` are the same in those scenarios but are distinct with 7-node alphabet. ## Regression No ## Your Environment * Version used: * frostfs-adm v0.42.9 * frostfs-contracts v0.19.4 * neo-go v0.106.3 * Server setup and configuration: custom exploratory environment ([protocol.privnet.yml](https://git.frostfs.info/potyarkin/bringup/src/branch/bug/morph-init-at-100-blocks/morph/protocol.privnet.yml)) * Operating System and version (`uname -a`): `Linux hostname 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux `

potyarkin added the

bug

frostfs-adm

triage

labels 2024-09-23 14:31:01 +00:00

fyrchik added

and removed

labels 2024-10-01 12:23:35 +00:00

fyrchik removed the

triage

label 2024-10-02 06:22:32 +00:00

fyrchik added this to the vNext milestone 2024-10-02 06:22:45 +00:00

fyrchik modified the milestone from vNext to v0.44.0

2024-10-02 07:58:00 +00:00

fyrchik commented

2024-10-02 07:59:53 +00:00

Owner

In frostfs-adm we try to be idempotent and not to do things twice.
For transfers we first check the balance of some account we have performed transfer to.

acc := c.Accounts[0]

The problem is that this account is the one of consensus node, which receives rewards for block processing.
I guess 100 blocks is enough to make the linked condition false.
The solution: check the balance of the committee account, it should be greater than 0.

In `frostfs-adm` we try to be idempotent and not to do things twice. For transfers we first check the balance of _some_ account we have performed transfer to. https://git.frostfs.info/TrueCloudLab/frostfs-node/src/commit/57c31e9802ad19b8d64388315cd53a05515e353e/cmd/frostfs-adm/internal/modules/morph/initialize/initialize_transfer.go#L84 The problem is that this account is the one of consensus node, which receives rewards for block processing. I guess 100 blocks is enough to make the linked condition false. The solution: check the balance of the committee account, it should be greater than 0.

🚀 1

fyrchik self-assigned this 2024-10-02 08:00:00 +00:00

fyrchik referenced this issue from a pull request that will close it,

2024-10-02 08:42:05 +00:00

adm: Properly check whether transfers were made #1409

fyrchik closed this issue

2024-10-02 09:08:46 +00:00

fyrchik referenced this issue from a commit

2024-10-02 09:08:47 +00:00

[#1391] adm: Properly check whether transfers were made

potyarkin commented

2024-10-02 11:39:30 +00:00