Skip to content

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

AliceInHunterland
Copy link
Contributor

No description provided.

Copy link
Contributor

@roman-khimov roman-khimov left a 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?

Its structure is described further below.

<pre>
block_binary
Copy link
Contributor

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.


==Abstract==

This proposal outlines the methodology and specifications for storing Neo blockchain blocks within
Copy link
Contributor

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.


==Motivation==

Neo node synchronization via P2P requires all block headers (~700 bytes each, over 1 GB per year with
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

headers and blocks

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
Copy link
Contributor

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.

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).
Copy link
Contributor

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).

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`)
Copy link
Contributor

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).

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`)
Copy link
Contributor

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.

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`)
Copy link
Contributor

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"


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.
Copy link
Contributor

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>

Copy link
Contributor

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.

@Jim8y
Copy link
Contributor

Jim8y commented Apr 11, 2025

@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

Signed-off-by: Ekaterina Pavlova <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants