nspcc-dev/neofs-node

Fork 0

mirror of https://github.com/nspcc-dev/neofs-node.git synced 2026-03-01 04:29:10 +00:00

Ersatz-chain for object headers #1227

New issue

Closed

opened 2025-12-28 17:22:15 +00:00 by sami · 9 comments

sami commented

2025-12-28 17:22:15 +00:00

Owner

Originally created by @roman-khimov on GitHub (Jun 10, 2024).

Originally assigned to: @carpawell on GitHub.

For a test purpose create a branch that works this way:

all object headers SN accepts (new objects) are put into transactions that just do PUSHDATA and leave it on the stack, this needs to be done after appropriate replication
these transactions are pushed into the main chain we have
SN waits for transaction acceptance and says OK to user
default chain block time shifted to 100ms, epoch is 10000 blocks

This needs to be a branch that can de deployed for performance testing easily (no additional configurations). We may then add some contract for additional processing, but let's do this test quickly.

Originally created by @roman-khimov on GitHub (Jun 10, 2024). Originally assigned to: @carpawell on GitHub. _For a test purpose_ create a branch that works this way: * all object headers SN accepts (new objects) are put into transactions that just do PUSHDATA and leave it on the stack, this needs to be done _after_ appropriate replication * these transactions are pushed into the main chain we have * SN waits for transaction acceptance and says OK to user * default chain block time shifted to 100ms, epoch is 10000 blocks This needs to be a branch that can de deployed for performance testing easily (no additional configurations). We may then add some contract for additional processing, but let's do this test quickly.

sami

2025-12-28 17:22:15 +00:00

closed this issue
added the
S2

U2

I4

task
labels

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@carpawell commented on GitHub (Jun 11, 2024):

@roman-khimov

just do PUSHDATA and leave it on the stack

Just syntenic here, right? No real storing.

default chain block time shifted to 100ms, epoch is 10000 blocks

Out of this issue's scope (SN does not control block time or epoch duration (ok, IR can hardcode epoch, but is this issue about it?))? Or what did you mean?

@carpawell commented on GitHub (Jun 11, 2024): @roman-khimov > just do PUSHDATA and leave it on the stack Just syntenic here, right? No real storing. > default chain block time shifted to 100ms, epoch is 10000 blocks Out of this issue's scope (SN does not control block time or epoch duration (ok, IR can hardcode epoch, but is this issue about it?))? Or what did you mean?

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@roman-khimov commented on GitHub (Jun 11, 2024):

Just syntenic here, right? No real storing.

At this stage yes.

Out of this issue's scope

Embedded CN has some defaults, I don't remember if we have this configured explicitly during NeoFS setup for performance testing (@EESergey?).

@roman-khimov commented on GitHub (Jun 11, 2024): > Just syntenic here, right? No real storing. At this stage yes. > Out of this issue's scope Embedded CN has some defaults, I don't remember if we have this configured explicitly during NeoFS setup for performance testing (@EESergey?).

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@carpawell commented on GitHub (Jun 11, 2024):

Embedded CN has some defaults

You said "main chain" that was not witnessed as an embedded CN (have i missed something?) so it was where i was confused. Is it required to be changed too? How many services should be started in total?

@carpawell commented on GitHub (Jun 11, 2024): > Embedded CN has some defaults You said "main chain" that was not witnessed as an embedded CN (have i missed something?) so it was where i was confused. Is it required to be changed too? How many services should be started in total?

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@roman-khimov commented on GitHub (Jun 11, 2024):

"main" was not meant to be mainnet (vs FS chain), it was meant to be main FS chain (vs per-container chains!)

@roman-khimov commented on GitHub (Jun 11, 2024): "main" was not meant to be mainnet (vs FS chain), it was meant to be main FS chain (vs per-container chains!)

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@carpawell commented on GitHub (Jun 14, 2024):

@roman-khimov, how about this: https://github.com/nspcc-dev/neofs-node/tree/feat/test-meta-on-chain?

@carpawell commented on GitHub (Jun 14, 2024): @roman-khimov, how about this: https://github.com/nspcc-dev/neofs-node/tree/feat/test-meta-on-chain?

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@roman-khimov commented on GitHub (Jun 14, 2024):

Looks like it for the first test.

@roman-khimov commented on GitHub (Jun 14, 2024): Looks like it for the first test.

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@carpawell commented on GitHub (Aug 20, 2024):

@roman-khimov, can we close it? Should here be a summary?

@carpawell commented on GitHub (Aug 20, 2024): @roman-khimov, can we close it? Should here be a summary?

sami commented

2025-12-28 17:22:15 +00:00

Author

Owner

@roman-khimov commented on GitHub (Aug 20, 2024):

Yes. Yes.

@roman-khimov commented on GitHub (Aug 20, 2024): Yes. Yes.

sami commented

2025-12-28 17:22:16 +00:00

Author

Owner

@carpawell commented on GitHub (Aug 21, 2024):

We have tested it on 4 machines (100ms blocks, epoch duration was 10000 blocks, every initial PUT put object's header on the stack, sent it via RPC, and waited for inclusion to some block). Container policy was REP 3 (mostly, some additional tests were also made on REP 1).

After all, at a 1-byte load, no chain bottleneck was found. Its block time was quite stable (p(95)=120ms), block processing took almost always less than 1ms, and average object PUT took ~100ms (the same as without additional chain modification).

Required 106.3+ neo-go release with some fixes. No changes were necessary on the node side for this type of testing.

@EESergey

@carpawell commented on GitHub (Aug 21, 2024): We have tested it on 4 machines (100ms blocks, epoch duration was 10000 blocks, every _initial_ PUT put object's header on the stack, sent it via RPC, and waited for inclusion to some block). Container policy was `REP 3` (mostly, some additional tests were also made on REP 1). After all, at a 1-byte load, no chain bottleneck was found. Its block time was quite stable (p(95)=120ms), block processing took almost always less than 1ms, and average object PUT took ~100ms (the same as without additional chain modification). Required 106.3+ neo-go release with some fixes. No changes were necessary on the node side for this type of testing. @EESergey