NOMOS-DATA-AVAILABILITY: New Raw RFC #41
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nomos/data-availability-layer.md
Outdated
Comment on lines
36
to
43
| Decentralized blockchains require full nodes to verify network transactions by downloading all the data of the network. | ||
| This becomes a problem as the blockchain data grows, full nodes will need more resources to download and | ||
| store the data while maintaining connection to the network. | ||
| Light nodes on the other hand do not download the entire network data because of it's resource limiting nature. | ||
| This retricts the network from scaling as the network is reliant on full nodes to process transactions. | ||
| and requires light nodes to rely on centralized parties. | ||
| A blockchain can have light nodes prove the validity of transaction data, | ||
| without the light node to downloading all the blockchain data. |
There was a problem hiding this comment.
This is not really the focus. Focus is bandwidth reduction. Splitting data into chunks and knowing who to send what really makes an impact as the network grows.
There was a problem hiding this comment.
@danielSanchezQ Do you mean not the focus for the network or for the role of a DA node in the BL layer for Nomos? Is focus on bandwidth reduction for light nodes, full nodes or both?
nomos/data-availability-layer.md
Outdated
|
|
||
| The data availability service of the Nomos base layer consist of different node roles, dispersal clients, | ||
| data availibity sampling nodes, and data availability provider nodes. | ||
| All network partipants have a choice in which node role they choose to run. |
There was a problem hiding this comment.
They do not. All nodes within the base layer do sample and verification. Dispersal is triggered by executor in zones, then by all of the base layer nodes participating in the different DA subnetworks (internal protocol yet to be decided).
nomos/data-availability-layer.md
Outdated
Comment on lines
57
to
58
| Nodes MAY decide to provide resources to the data availibilty service of the Nomos base-layer or | ||
| join a Data Availibility Committee within a zone. |
There was a problem hiding this comment.
No such thing as committees here.
nomos/data-availability-layer.md
Outdated
Comment on lines
70
to
72
| Zones act as [Data Availability Committees](#) for their own blockchain state. | ||
| Zones SHOULD provide data availability for their blockchain in the event that light nodes can not access data, | ||
| light nodess MAY utilize the data avilability of the Nomos base layer. |
There was a problem hiding this comment.
I think this is incorrect. Or it did change. We do not have committees.
There was a problem hiding this comment.
Correct I believe there is no committees. I assumed a committee would be a DA implementation within a zone not connected to the main Nomos chain, and the term committees has been used in other articles. Removing this term from the spec.
nomos/data-availability-layer.md
Outdated
| All light node are considered to be Nomos base layer nodes. | ||
| Base-layer nodes MUST NOT process data, | ||
| but only provide data availability guarantees for a limit amount of time. | ||
| The role of a provider node is to store polynomial commitment schemes for Nomos zones. |
There was a problem hiding this comment.
They store the commitments, and a chunk of the original (or extended) data.
nomos/data-availability-layer.md
Outdated
|
|
||
| #### Sending Data | ||
|
|
||
| Zones are responisble for creating data chunks that need to be stored on the blockchain. |
There was a problem hiding this comment.
They are responsible for the encoding (reference to the encoding section maybe?).
nomos/data-availability-layer.md
Outdated
| #### Sending Data | ||
|
|
||
| Zones are responisble for creating data chunks that need to be stored on the blockchain. | ||
| The data SHOULD be sent to provider nodes. |
nomos/data-availability-layer.md
Outdated
|
|
||
| Once encoded, | ||
| the data is dispersed to different Nomos data availibilty provider nodes that have joined a subnet on the base layer. | ||
| It is RECCOMENDED that the dispersal client sends a column to 4096 provider nodes for better bandwidth optimization. |
There was a problem hiding this comment.
They should send a single column to each of the 4096 da subnetworks.
nomos/data-availability-layer.md
Outdated
Comment on lines
255
to
286
| ### VID Certificate | ||
|
|
||
| A verifiable information dispersal certificate, VID certificate, | ||
| is a list of attestation from data availibility nodes. | ||
| It is used to verify that the data chucks have been dispersed properly amongst nodes in the base layer. | ||
| The provider node signs an attestation that contain the hash value of the `row_commitment` and | ||
| of the `aggregated_column_commitment`. | ||
| Signitures are verified by dispersal clients and | ||
| valid signitures SHOULD be added to the VID certificate | ||
|
|
||
| For every provider node $j$, assuming $sk_j$ is the private key, a signature is generated as follows: | ||
|
|
||
| ${ \Large \sigma_j=Sign(sk_j, hash(C_{agg}, r_1,r_2,\dots,r_{\ell})) }$ | ||
|
|
||
| The provider node sends the signed attestation back to the zone dispersal clients confirming the data has been received and | ||
| verified. | ||
| Once a dispersal client verifies data chucks have been hashed and signed by the base layer, | ||
| the VID certificate SHOULD be created. | ||
|
|
||
| The attesstation is created with the following values: | ||
|
|
||
|
|
||
| ```rs | ||
| // Provider node SHOULD hash using Blake2 algorithm | ||
| // blob_hash : Hash of row_commitment and column_commitiment | ||
| fn sendAsstation () { | ||
| attestation_hash = hash(blob_hash, DAnode); | ||
| } | ||
| ``` | ||
|
|
||
| The VID certificate is then sent to block builder to be accepted through concensus, | ||
| as desirbed in [Cryptarchia](#). |
nomos/data-availability-layer.md
Outdated
Comment on lines
290
to
321
| Light nodes MAY choose to be a data availability sampling node. | ||
| This node can participate in any other NOMOS service while providing verification of data dispersal services. | ||
| For example, a dispersal client can send data to be available through the base layer and | ||
| decide to perform data availability sampling to have a great assurance that the data is available. | ||
| This would reduce the potential threats from malicious or | ||
| faulty nodes not replicating data in their subnets. | ||
|
|
||
| The following steps are REQUIRED by a data availability sampling node to verify data dispersal: | ||
|
|
||
| 1. Choose a random column value and row value from base layer provider nodes. | ||
| Light node wants to opening of $C_t$ and $r_{t'}$. | ||
|
|
||
| 2. Assuming provider node $node_t$, it calculates the $eval$ value for the `column_commitment`. | ||
| Also calculates the `row_commitment` value $r_{t'}$ and the proof of it. | ||
| Then sends these values to the sampling node. | ||
|
|
||
| ${ \Large eval(\Phi,w^{t-1})\to C_t,\pi_{C_t} }$ | ||
|
|
||
| 3. Sampling nodes verifies the `row_commitment` and the `column_commitment` as follows: | ||
|
|
||
| ${ \Large verify(C_{agg},C_{r},\pi_{C_r}) \to true/false }$ | ||
|
|
||
| ${ \Large verify(C_{agg},C_r, \pi_{C_r})\to true/false}$ | ||
|
|
||
| 4. If this proof is true, then light nodes wants to opening of the column commitment. | ||
| $node_r$ calculates the $eval$ value and sends it to the light node to be verified. | ||
|
|
||
| ${ \Large eval(\theta_t,w^{t'-1})\to data_{t'}^{t},\pi_{data_{t'}^{t}} }$ | ||
|
|
||
| ${ \Large verify(C_t, data_{t'}^t, \pi_{data_{t'}^t})\to true/false }$ | ||
|
|
||
| If this is true, then this proves that the data chuck has been encoded correctly. |
There was a problem hiding this comment.
All this is WIP as we do not have anything decided yet.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Open discussion for a Nomos data availability layer raw RFC. Should include all components of the data availability service provided by the Nomos blockchain as well as how they are utilized within the network.