mirror of
https://github.com/0glabs/0g-storage-node.git
synced 2025-04-04 15:35:18 +00:00
Compare commits
3 Commits
fd9435dcc3
...
f0a363903c
Author | SHA1 | Date | |
---|---|---|---|
![]() |
f0a363903c | ||
![]() |
898350e271 | ||
![]() |
915cb016f5 |
@ -11,7 +11,7 @@ pub fn unused_tcp_port() -> Result<u16, String> {
|
||||
unused_port(Transport::Tcp)
|
||||
}
|
||||
|
||||
/// A convenience function for `unused_port(Transport::Tcp)`.
|
||||
/// A convenience function for `unused_port(Transport::Udp)`.
|
||||
pub fn unused_udp_port() -> Result<u16, String> {
|
||||
unused_port(Transport::Udp)
|
||||
}
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
ZeroGravity system consists of a data availability layer (0G DA) on top of a decentralized storage system (0G Storage). There is a separate consensus network that is part of both the 0G DA and the 0G Storage. For 0G Storage, the consensus is responsible for determining the ordering of the uploaded data blocks, realizing the storage mining verification and the corresponding incentive mechanism through smart contracts.
|
||||
|
||||
Figure 1 illustrates the architecture of the 0G system. When a data block enters the 0G DA, it is first erasure coded and organized into multiple consecutive chunks through erasure coding. The merkle root as a commitment of the encoded data block is then submitted to the consensus layer to keep the order of the data entering the system. The chunks are then dispersed to different storage nodes in 0G Storage where the data may be further replicated to other nodes depending on the storage fee that the user pays. The storage nodes periodically participate the mining process by interacting with the consensus network to accrue rewards from the system.
|
||||
Figure 1 illustrates the architecture of the 0G system. When a data block enters the 0G DA, it is first erasure coded and organized into multiple consecutive chunks through erasure coding. The merkle root as a commitment of the encoded data block is then submitted to the consensus layer to keep the order of the data entering the system. The chunks are then dispersed to different storage nodes in 0G Storage where the data may be further replicated to other nodes depending on the storage fee that the user pays. The storage nodes periodically participate in the mining process by interacting with the consensus network to accrue rewards from the system.
|
||||
|
||||
<figure><img src="../.gitbook/assets/zg-storage-architecture.png" alt=""><figcaption><p>Figure 1. The Architecture of 0G System</p></figcaption></figure>
|
||||
|
||||
|
@ -1,6 +1,6 @@
|
||||
# Mining Reward
|
||||
|
||||
0G Storage creates pricing segments every 8 GB of data chunks over the data flow. Each pricing segment is associated with an Endowment Pool and a Reward Pool. The Endowment Pool collects the storage endowments of all the data chunks belongs to this pricing segment and releases a fixed ratio of balance to the Reward Pool every second. The rate of reward release is set to 4% per year.
|
||||
0G Storage creates pricing segments every 8 GB of data chunks over the data flow. Each pricing segment is associated with an Endowment Pool and a Reward Pool. The Endowment Pool collects the storage endowments of all the data chunks belong to this pricing segment and releases a fixed ratio of balance to the Reward Pool every second. The rate of reward release is set to 4% per year.
|
||||
|
||||
The mining reward is paid to miners for providing data service. Miners receive mining reward when submit the first legitimate PoRA for a mining epoch to 0G Storage contract.
|
||||
|
||||
|
@ -13,7 +13,7 @@ enum SlotStatus {
|
||||
}
|
||||
|
||||
/// Sliding window is used to control the concurrent uploading process of a file.
|
||||
/// Bounded window allows segments to be uploaded concurrenly, while having a capacity
|
||||
/// Bounded window allows segments to be uploaded concurrently, while having a capacity
|
||||
/// limit on writing threads per file. Meanwhile, the left_boundary field records
|
||||
/// how many segments have been uploaded.
|
||||
struct CtrlWindow {
|
||||
@ -165,7 +165,7 @@ impl ChunkPoolWriteCtrl {
|
||||
|
||||
if file_ctrl.total_segments != total_segments {
|
||||
bail!(
|
||||
"file size in segment doesn't match with file size declared in previous segment. Previous total segments:{}, current total segments:{}s",
|
||||
"file size in segment doesn't match with file size declared in previous segment. Previous total segments:{}, current total segments:{}",
|
||||
file_ctrl.total_segments,
|
||||
total_segments
|
||||
);
|
||||
|
Loading…
Reference in New Issue
Block a user