From 3d9aa8c940b9c2d4ecd951300fd6bc5156406b5b Mon Sep 17 00:00:00 2001 From: SamiAlHassan <150172180+SamiAlHassan@users.noreply.github.com> Date: Tue, 18 Feb 2025 01:10:51 +0000 Subject: [PATCH] docs: fix broken figure image paths across docs (#335) * patch figure links on proof-of-random-access.md * patch figure links on transaction-processing.md * patch figure links on k-v-store.md * patch figure links on architecture.md --- docs/architecture.md | 4 ++-- docs/incentive-mechanism/proof-of-random-access.md | 2 +- docs/k-v-store.md | 2 +- docs/transaction-processing.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/architecture.md b/docs/architecture.md index b988e58..63d86e0 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -6,13 +6,13 @@ ZeroGravity system consists of a data availability layer (0G DA) on top of a dec 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. The Architecture of 0G System

+

Figure 1. The Architecture of 0G System

## 0G Storage 0G Storage employs layered design targeting to support different types of decentralized applications. Figure 2 shows the overview of the full stack layers of 0G Storage. -

Figure 2. Full Stack Solution of 0G Storage

+

Figure 2. Full Stack Solution of 0G Storage

The lowest is a log layer which is a decentralized system. It consists of multiple storage nodes to form a storage network. The network has built-in incentive mechanism to reward the data storage. The ordering of the uploaded data is guaranteed by a sequencing mechanism to provide a log-based semantics and abstraction. This layer is used to store unstructured raw data for permanent persistency. diff --git a/docs/incentive-mechanism/proof-of-random-access.md b/docs/incentive-mechanism/proof-of-random-access.md index 2fb4861..6ff2016 100644 --- a/docs/incentive-mechanism/proof-of-random-access.md +++ b/docs/incentive-mechanism/proof-of-random-access.md @@ -30,4 +30,4 @@ Precisely, the mining process has the following steps: 6. For each piece $$\overrightarrow{v}$$, compute the Blake2b hash of the tuple ($$\mathsf{miner\_id}$$, $$\mathsf{nonce}$$, $$\mathsf{context\_digest}$$, $$\mathsf{start\_position}$$, $$\mathsf{mine\_length}$$, $$\overrightarrow{v}$$). 7. If one of Blake2b hash output is smaller than a target value, the miner finds a legitimate PoRA solution. -

Figure 1. Recall Position and Scratchpad Computation

+

Figure 1. Recall Position and Scratchpad Computation

diff --git a/docs/k-v-store.md b/docs/k-v-store.md index 482d862..09f7aa0 100644 --- a/docs/k-v-store.md +++ b/docs/k-v-store.md @@ -6,4 +6,4 @@ A user-defined function will be used to deserialize the raw content in the log e When a new key-value node just joins the network, it connects to the log layer and plays the log entries from head to tail to construct the latest state of the key-value store. During the log entry playing, an application-specific key-value node can skip irrelevant log entries which do not contain stream IDs that it cares. -

Figure 1. Decentralized K-V Store

+

Figure 1. Decentralized K-V Store

diff --git a/docs/transaction-processing.md b/docs/transaction-processing.md index 6f4ce0c..3cec368 100644 --- a/docs/transaction-processing.md +++ b/docs/transaction-processing.md @@ -8,7 +8,7 @@ When an application server linking with the 0G Storage key-value runtime starts When an application server with the key-value runtime encounters the commit record during playing the log, it identifies a conflict window consisting of all the log entries between the start log position of the transaction and the position of the commit record. The log entries in the conflict window therefore contain the key-value operations concurrent with the transaction submitting the commit record. The runtime further detects whether these concurrent operations contain the updates on the keys belonging to the read set of the transaction. If yes, the transaction is aborted, otherwise committed successfully. -

Figure 1. Transaction Processing on 0G K-V Store

+

Figure 1. Transaction Processing on 0G K-V Store

## Concurrent Assumption