Skip to content

Commit

Permalink
chore(docs): protocol-specs typos (#8706)
Browse files Browse the repository at this point in the history
  • Loading branch information
ludamad committed Sep 23, 2024
1 parent 02cff0b commit 48de163
Showing 1 changed file with 5 additions and 5 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -94,9 +94,9 @@ You could say that the transactions are pre-confirmed until they convince the va
### No-consensus

If there is no explicit consensus for the Rollup, staking can still be utilized for leader selection, picking a distinct sequencer which will have a period to propose a block and convince the validating light-client.
The user can as earlier define his own confirmation rules and could decide that if the sequencer acknowledge his transaction, then he sees it as confirmed.
This have a weaker guarantees than the consensus based as the sequencer could be malicious and not uphold his part of the deal.
Nevertheless, the user could always do an out of protocol agreement with the sequencer, where the sequencer guarantees that he will include the transaction or the user will be able to slash him and get compensated.
The user can as earlier define his own confirmation rules and could decide that if the sequencer acknowledges his transaction, then he sees it as confirmed.
This has weaker guarantees than the consensus-based approach as the sequencer could be malicious and not uphold his part of the deal.
Nevertheless, the user could always do an out-of-protocol agreement with the sequencer, where the sequencer guarantees that he will include the transaction or the user will be able to slash him and get compensated.

:::info Fernet
Fernet lives in this category if you have a single sequencer active from the proposal to proof inclusion stage.
Expand All @@ -107,7 +107,7 @@ If the user is not satisfied with the guarantee provided by the sequencer, he ca

## Data Availability and Publication

As alluded to earlier, we belong to the school of thought that Data Availability and Publication is different things.
As alluded to earlier, we belong to the school of thought that Data Availability and Publication are different things.
Generally, what is often referred to as Data Availability is merely Data Publication, e.g., whether or not the data have been published somewhere.
For data published on Ethereum you will currently have no issues getting a hold of the data because there are many full nodes and they behave nicely, but they are not guaranteed to continue doing so.
New nodes are essentially bootstrapped by other friendly nodes.
Expand All @@ -125,7 +125,7 @@ The latency is based on using Ethereum L1 as the home of the validating light no
|Method | Publication | Availability | Quantity | Latency | Description |
| ------- | :----------: | :----------: | :----------: | :-------: | :-------: |
|calldata| Eth L1 | Eth L1 | $78,125~\dfrac{byte}{s}$ | None | Part of the transaction payload required to execute history, if you can sync an Ethereum node from zero, this is available. Essentially, if Ethereum lives this is available. Have to compete against everything on Ethereum for blockspace. |
|blobs| Eth L1 | benevolent Eth L1 super full-nodes | x | None | New blob data, will be published but only commitments available from the execution environment. Content can be discarded later and don't have to be stored forever. Practically a "committee" of whoever wants can keep it, and you rely on someone from this set providing the data to you. |
|blobs| Eth L1 | benevolent Eth L1 super full-nodes | x | None | New blob data, will be published but only commitments available from the execution environment. Content can be discarded later and doesn't have to be stored forever. Practically a "committee" of whoever wants can keep it, and you rely on someone from this set providing the data to you. |
^^| | | $31,744 \dfrac{byte}{s}$ | None | target of `3` blobs of size `4096` fields (`380,928` bytes per block) |
^^| | | $677,205 \dfrac{byte}{s}$ | None | target of `64` blobs of size `4096` fields (`8,126,464` bytes per block) |
|Celestia| Celestia + Blobstream bridge | Celestia Full Storage Nodes | $161,319~\dfrac{byte}{s}$ | ~100 mins | 2MB blocks. Can be used in proof after relay happens, with latency improvements expected.|
Expand Down

0 comments on commit 48de163

Please sign in to comment.