Skip to content

Commit b02aabe

Browse files
AliceInHunterlandAnnaShaleva
authored andcommitted
proposal: NeoFS block storage format
Signed-off-by: Ekaterina Pavlova <[email protected]>
1 parent f329e87 commit b02aabe

File tree

1 file changed

+97
-0
lines changed

1 file changed

+97
-0
lines changed

neofs-blocks.mediawiki

Lines changed: 97 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,97 @@
1+
<pre>
2+
NEP: TBD
3+
Title: NeoFS block storage format
4+
Author: Ekaterina Pavlova <[email protected]>
5+
Type: Standard
6+
Status: Draft
7+
Created: 2025-04-07
8+
</pre>
9+
10+
==Abstract==
11+
12+
This proposal outlines the specification for storing Neo blockchain blocks within
13+
the NeoFS container.
14+
15+
==Motivation==
16+
17+
Neo node synchronization via P2P requires all headers and blocks (~700 bytes each, over 1 GB per year with
18+
15-second blocks) to remain available, limiting scalability as chains grow. Storing blocks in NeoFS
19+
provides a distributed alternative, reducing local storage, enabling on-demand fetches and allowing to drop
20+
blocks and headers from storage for most nodes.
21+
22+
==Specification==
23+
24+
===Block Storage Schema===
25+
26+
A single NeoFS container is used to store blocks of a single Neo network. Each container includes a fixed
27+
metadata attribute named `Magic` whose value is the network’s magic number in decimal representation. Each
28+
block is stored in a serialized representation following standard Neo block serialization rules as a
29+
separate NeoFS object with a unique OID and the following metadata attributes:
30+
31+
{| class="wikitable"
32+
! Attribute name !! Attribute value
33+
|-
34+
| Block || String representation of the block index in base 10.
35+
|-
36+
| Hash || Hexadecimal string of the block’s hash.
37+
|-
38+
| PrevHash || Hexadecimal string of the previous block’s hash.
39+
|-
40+
| BlockTime || Millisecond-precision timestamp when the block was created.
41+
|-
42+
| Timestamp || Second-precision timestamp when the block was uploaded.
43+
|}
44+
45+
These attributes are stored as NeoFS object metadata; the list of attributes MAY be extended.
46+
The object MAY include additional data after the block.
47+
48+
An example of a [block object]([https://rest.fs.neo.org/v1/objects/3RCdP3ZubyKyo8qFeo7EJPryidTZaGCMdUjqFJaaEKBV/by_id/Fu7yQzspvLJwSGJNK64xeeyMdWXtU5B5b1es6KSxUag1):
49+
<pre>
50+
ID: Fu7yQzspvLJwSGJNK64xeeyMdWXtU5B5b1es6KSxUag1
51+
CID: 3RCdP3ZubyKyo8qFeo7EJPryidTZaGCMdUjqFJaaEKBV
52+
Owner: NVvY1FF67XJ2GTVhy9FqiZGC4jEQtvjmHt
53+
CreatedAt: 28202
54+
Size: 697
55+
HomoHash: 45c98e627910d9b915d58368493789ce49ca194626f16ea5bf6b57bb2cce462921a1d3faf682d252a804b0555ca48905286222ee9209b3ff1ce4677a082ffd4d
56+
Checksum: fa6cedddfec3a61157c4a12e25f81e85c0f92aac70317d6df7fe193f983b4917
57+
Type: REGULAR
58+
Attributes:
59+
Block=1
60+
Primary=0
61+
Hash=5f3fbb43d1e516fe07771e2e873ebc9e2810662401acf603a775aace486220bd
62+
PrevHash=1f4d1defa46faa5e7b9b8d3f79a06bec777d7c26c4aa5f6f5899a291daa87c15
63+
BlockTime=1627894840919
64+
Timestamp=1734362616 (2024-12-16 18:23:36 +0300 MSK)
65+
ID signature:
66+
public key: 02a4920745d86db224c179c936606dc0e4620edad13d568ef036da279352e45f2b
67+
signature: 0443ff20d15952759b5101a7d223d70eb992260fd9ad5aecb404a97448b2ea54bd1ad783b12ccddba0097dd6608b55ccac9215c5715f9589ec6a555542ead6dc00
68+
[Block Binary Data]
69+
</pre>
70+
71+
===Synchronization Algorithm===
72+
73+
Blocks stored in NeoFS and those synchronized via P2P both use the standard Neo block
74+
serialization format, ensuring compatibility across different synchronization methods.
75+
The NeoFS container serves as verified storage for downloading blocks. Blocks should be
76+
searched one by one directly by block attribute.
77+
78+
Downloaded blocks are inserted into the blockchain using the same logic as in the
79+
P2P synchronization protocol.
80+
81+
==Rationale==
82+
83+
Storing each block as a self-contained NeoFS object moves historical data off full nodes
84+
while preserving byte-exact compatibility with the P2P format. Standard metadata makes
85+
blocks easily discoverable without custom indices, and NeoFS gives durability and fast
86+
parallel fetches. The proposed scheme is implemented as an experimental extension of NeoGo
87+
node ([https://github.com/nspcc-dev/neo-go/issues/3496 nspcc-dev/neo-go#3496]) and
88+
proved to be efficient.
89+
90+
== References ==
91+
92+
* [https://github.com/neo-project/neo/issues/3463 Using NeoFS to store blocks and snapshots]
93+
94+
== Implementation ==
95+
96+
* Go: [https://github.com/nspcc-dev/neo-go/blob/965ae2746cd1a01aba3b4114e1ea26ca7349f34b/cli/util/upload_bin.go utility tool that uploads blocks to NeoFS container]
97+
* Go: [https://github.com/nspcc-dev/neo-go/blob/965ae2746cd1a01aba3b4114e1ea26ca7349f34b/pkg/services/blockfetcher/blockfetcher.go node service that fetches blocks from NeoFS container as an alternative to P2P synchronization]

0 commit comments

Comments
 (0)