add data availability docs #1995
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Jason-W123
requested review from
mahsamoosavi,
pete-vielhaber and
TucksonDev
and removed request for
mahsamoosavi and
pete-vielhaber
|
|
||
| **Rollup Mode:** In this mode, all transaction data is included in either the calldata of transactions submitted to the Ethereum mainnet (the parent chain) or the blobs submitted by the transaction. This inclusion ensures that all data is readily available on-chain for anyone to download and verify. | ||
|
|
||
| **Anytrust Mode:** In Anytrust mode, transaction data initially gets submitted to a group of nodes known as the Data Availability Servers (DAS). The DAS stores and distributes the data. Instead of including the entire dataset on-chain, only a cryptographic proof (Data Availability Certificate, or DACert) is submitted to the parent chain. This proof significantly reduces the amount of data stored on-chain, reducing costs. |
There was a problem hiding this comment.
Does it make sense to say Data Availability Committee (DAC) instead? It involves the committee as a whole, instead of the individual servers.
There was a problem hiding this comment.
Also, I'd say "only a cryptographic proof that the data has been stored by the DAC (Data Availability Certificate...)", so it is not confused with other types of proof.
There was a problem hiding this comment.
Sorry, kind confused here, do you here mean DACert or DAC?
There was a problem hiding this comment.
Oh, my comment is a bit confusing, you're right. I meant that the data is stored by the DAC, and the cryptographic proof is the Data Availability Certificate. So the text would read "only a cryptographic proof that the data has been stored by the DAC (Data Availability Certificate, or DACert)...". I think we've introduced the DAC before, so in this case we are just saying that the data is stored by the DAC, and they return the DACert, which is posted to the parent chain.
Let me know if it's clearer now. If not, maybe we can try to find a different way to describe the process 🙏
|
|
||
| Because of those data availability mechanisms, Arbitrum Nitro nodes synchronize their data differently than Ethereum nodes or other layer-one network nodes. While Go-Ethereum nodes utilize a sophisticated P2P network to synchronize with the Ethereum blockchain by discovering other nodes, exchanging data, and participating in the consensus mechanism, Arbitrum nodes diverge from this traditional approach. | ||
|
|
||
| However, Arbitrum nodes do **not** primarily rely on a traditional peer-to-peer (P2P) mechanism for syncing their state as many other blockchains do. |
There was a problem hiding this comment.
I'd remove this paragraph. It doesn't add value to what has already been said, and it says that it somehow relies on a P2P mechanism (not primarily, but still...)
There was a problem hiding this comment.
I add this paragraph is because I want to say arbitrum sync and process the data by a much more trustless way, but ya, I forget to add this word in, how do you think if we add trustless in this paragraph?
There was a problem hiding this comment.
Maybe in the paragraph above that compares Ethereum to Arbitrum: "However, Arbitrum nodes do not primarily rely on a traditional peer-to-peer (P2P) mechanism for syncing their state as many other blockchains do."
What do you think?
There was a problem hiding this comment.
This is a great page to have, thanks very much @Jason-W123 !!
I did a thorough review and requested some changes. Happy to discuss any of them! 🙏
Co-authored-by: José FP <[email protected]>
|
|
||
| Here's how Arbitrum data flow works: | ||
|
|
||
| 1. Batching and submission: |
There was a problem hiding this comment.
For these lists below, I would change to:
- asdf
a. asdf
i.
No description provided.