-
Notifications
You must be signed in to change notification settings - Fork 116
proposal: NeoFS block storage format #194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
proposal: NeoFS block storage format #194
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Index files? Synchronization algorithm?
neofs-blocks.mediawiki
Outdated
Its structure is described further below. | ||
|
||
<pre> | ||
block_binary |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can just refer to "standard Neo block serialization", that's what it is in its essence.
neofs-blocks.mediawiki
Outdated
|
||
==Abstract== | ||
|
||
This proposal outlines the methodology and specifications for storing Neo blockchain blocks within |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
methodology
is too strong word for this.
neofs-blocks.mediawiki
Outdated
|
||
==Motivation== | ||
|
||
Neo node synchronization via P2P requires all block headers (~700 bytes each, over 1 GB per year with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
headers and blocks
neofs-blocks.mediawiki
Outdated
Neo node synchronization via P2P requires all block headers (~700 bytes each, over 1 GB per year with | ||
15-second blocks) to remain available, limiting scalability as chains grow. Storing blocks in NeoFS | ||
provides a distributed alternative, reducing local storage, enabling on-demand fetches, and speeding | ||
up sync with snapshots or checkpoints. This proposal defines a NeoFS storage schema, building on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
snapshots and checkpoints are for a different proposal.
neofs-blocks.mediawiki
Outdated
15-second blocks) to remain available, limiting scalability as chains grow. Storing blocks in NeoFS | ||
provides a distributed alternative, reducing local storage, enabling on-demand fetches, and speeding | ||
up sync with snapshots or checkpoints. This proposal defines a NeoFS storage schema, building on | ||
experiments (e.g., nspcc-dev/neo-go#3496) and future enhancements (#1526). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Experiments are for a different proposal section (rationale).
neofs-blocks.mediawiki
Outdated
has network magic attribute (`Magic:56753`). Each block is stored in a binary | ||
form as a separate object with a unique OID and a set of attributes: | ||
- block object identifier with block index value (`Block:1`) | ||
- primary node index (`Primary:0`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have it now, but I'm still thinking if its useful. I can imagine searches for block hashes/timestamps, but primary index is not so obvious (especially without a verification script hash).
neofs-blocks.mediawiki
Outdated
A single NeoFS container is used to store blocks. Each container | ||
has network magic attribute (`Magic:56753`). Each block is stored in a binary | ||
form as a separate object with a unique OID and a set of attributes: | ||
- block object identifier with block index value (`Block:1`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Define field names first, then describe them. Examples are for a different section.
neofs-blocks.mediawiki
Outdated
form as a separate object with a unique OID and a set of attributes: | ||
- block object identifier with block index value (`Block:1`) | ||
- primary node index (`Primary:0`) | ||
- block hash in the LE form (`Hash:5412a781caf278c0736556c0e544c7cfdbb6e3c62ae221ef53646be89364566b`) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LE/BE are a bit different in C#, we can say "in hex hash representation"
neofs-blocks.mediawiki
Outdated
|
||
These attributes are stored as NeoFS object metadata alongside the binary block data. | ||
Multibyte data items are always stored in little-endian order, where the low bytes come first. | ||
Its structure is described further below. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a not that the object MAY have additional data after the block, it can be useful for future extensions.
var-byte transactions[]; // Array of serialized transactions | ||
} | ||
</pre> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need an example of object.
@AliceInHunterland please update accordingly, this is not likely can be reviewed with any useful suggestions from other coredevs since we know little about neofs, please just follow roman's suggestion |
1c6106c
to
674a1c2
Compare
674a1c2
to
1231891
Compare
Signed-off-by: Ekaterina Pavlova <[email protected]>
1231891
to
6c12fbe
Compare
No description provided.