You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: public/content/developers/docs/data-availability/blockchain-data-storage-strategies/index.md
+24-31Lines changed: 24 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,12 +28,11 @@ You should have a good understanding of [blockchain fundamentals](/developers/do
28
28
29
29
There are three attributes we'd like to have for data.
30
30
31
-
-*Confidentiality*, unauthorized entities are not allowed to read the information. This is useful in many cases, but *there are no secrets on the blockchain*. Blockchains work because everybody can verify the state transitions, so it is impossible to use them to store secrets directly. There are ways to store confidential information on the blockchain, but they all rely on some offchain component to store at least a key.
31
+
-_Confidentiality_, unauthorized entities are not allowed to read the information. This is useful in many cases, but _there are no secrets on the blockchain_. Blockchains work because everybody can verify the state transitions, so it is impossible to use them to store secrets directly. There are ways to store confidential information on the blockchain, but they all rely on some offchain component to store at least a key.
32
32
33
-
-*Integrity*, the information is correct, it cannot be changed by unauthorized entities, or in unauthorized ways (for example, transferring [ERC-20 tokens](https://eips.ethereum.org/EIPS/eip-20#events) without a `Transfer` event). On the blockchain, every node verifies every state change, which ensures integrity.
34
-
35
-
-*Availability*, the information is available to any authorized entity. On the blockchain, this is usually achieved by having the information available on every [full node](https://ethereum.org/developers/docs/nodes-and-clients#full-node).
33
+
-_Integrity_, the information is correct, it cannot be changed by unauthorized entities, or in unauthorized ways (for example, transferring [ERC-20 tokens](https://eips.ethereum.org/EIPS/eip-20#events) without a `Transfer` event). On the blockchain, every node verifies every state change, which ensures integrity.
36
34
35
+
-_Availability_, the information is available to any authorized entity. On the blockchain, this is usually achieved by having the information available on every [full node](https://ethereum.org/developers/docs/nodes-and-clients#full-node).
37
36
38
37
## EIP-4844 blobs {#eip-4844-blobs}
39
38
@@ -49,11 +48,11 @@ At writing posting on EIP-4844 costs one wei (10<sup>-18</sup> ETH) per byte, wh
49
48
50
49
Here are the addresses to see the blobs posted by some famous rollups.
## Offchain with L1 mechanisms {#offchain-with-l1-mechs}
76
74
77
75
Depending on your security tradeoffs, it might be acceptable to put the information elsewhere and use a mechanism that ensures the data is available when needed. There are two requirements for this to work:
78
76
79
-
1. Post a [hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function) of the data on the blockchain, called an *input commitment*. This can be a single 32-byte word, so it is not expensive. As long as the input commitment is available, integrity is assured because it's not feasible to find any other data that would hash to the same value. So if incorrect data is provided, it can be detected.
77
+
1. Post a [hash](https://en.wikipedia.org/wiki/Cryptographic_hash_function) of the data on the blockchain, called an _input commitment_. This can be a single 32-byte word, so it is not expensive. As long as the input commitment is available, integrity is assured because it's not feasible to find any other data that would hash to the same value. So if incorrect data is provided, it can be detected.
80
78
81
79
2. Have a mechanism that ensures availability. For example, in [Redstone](https://redstone.xyz/docs/what-is-redstone) any node can submit an availability challenge. If the sequencer does not respond onchain by the deadline, the input commitment is discarded, so the information is considered never to have been posted.
82
80
83
81
This is acceptable for an optimistic rollup because we are already relying on having at least one honest verifier for the state root. Such an honest verifier will also make sure it has the data to process blocks, and issue an availability challenge if the information is not available offchain. This type of optimistic rollup is called [plasma](/developers/docs/scaling/plasma/).
84
82
85
-
86
83
## Contract code {#contract-code}
87
84
88
-
Information that only needs to be written once, never gets overwritten, and needs to be available onchain can be stored as contract code. This means that we create a "smart contract" with the data and then use [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) to read the information. The advantage is that copying code is relatively cheap.
85
+
Information that only needs to be written once, never gets overwritten, and needs to be available onchain can be stored as contract code. This means that we create a "smart contract" with the data and then use [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) to read the information. The advantage is that copying code is relatively cheap.
89
86
90
87
Other than the cost of memory expansion, `EXTCODECOPY` costs 2600 gas for the first access to a contract (when it is "cold") and 100 gas for subsequent copies from the same contract plus 3 gas per 32 byte word. Compared with calldata, which costs 15.95 per byte, this is cheaper starting at about 200 bytes. Based on [the formula for memory expansion costs](https://www.evm.codes/about#memoryexpansion), at long as you don't need more than 4MB of memory, the memory expansion cost is smaller than the cost of adding calldata.
91
88
92
-
Of course, this is just the cost to *read* the data. To create the contract costs approximately 32,000 gas + 200 gas/byte. This method is only economical when the same information needs to be read many times in different transactions.
93
-
94
-
Contract code can be nonsensical, as long as it doesn't start with `0xEF`. Contracts that start with `0xEF` are interpreted as [ethereum object format](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), which has much stricter requirements.
89
+
Of course, this is just the cost to _read_ the data. To create the contract costs approximately 32,000 gas + 200 gas/byte. This method is only economical when the same information needs to be read many times in different transactions.
95
90
91
+
Contract code can be nonsensical, as long as it doesn't start with `0xEF`. Contracts that start with `0xEF` are interpreted as [ethereum object format](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), which has much stricter requirements.
96
92
97
93
## Events {#events}
98
94
99
95
[Events](https://docs.alchemy.com/docs/solidity-events) are emitted by smart contracts, and read by offchain software.
100
96
Their advantage is that offchain code can listen for events. The cost is [gas](https://www.evm.codes/#a0?fork=cancun), 375 plus 8 gas per byte of data. At 12 gwei/gas and 2300 $/ETH, this translates to one cent plus 22 cents per kilobyte.
101
97
102
-
103
98
## Storage {#storage}
104
99
105
100
Smart contracts have access to [persistent storage](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). However, it is very expensive. Writing a 32 byte word to a previously empty storage slot can [cost 22,100 gas](https://www.evm.codes/#55?fork=cancun). At 12 gwei/gas and 2300 $/ETH, this is about 61 cents per write operation, or $19.5 per kilobyte.
106
101
107
102
This is the most expensive form of storage in Ethereum.
108
103
109
-
110
-
111
104
## Summary {#summary}
112
105
113
106
This table summarizes the difference options, their advantages and disadvantages.
114
107
115
-
| Storage type | Source of data | Availability guarantee | Onchain availability | Additional limitations
116
-
| - | - | - | - | - |
117
-
| EIP-4844 blobs | Offchain | Ethereum guarantee for [~18 days](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)| Only hash is available ||
118
-
| Calldata | Offchain | Ethereum guarantee forever (part of the blockchain) | Only available if written to a contract, and at that transaction |
119
-
| Offchain with L1 mechanisms | Offchain | "One honest verifier" guarantee during the challenge period | Hash only | Guaranteed by the challenge mechanism, only during the challenge period
120
-
| Contract code | Onchain or offchain | Ethereum guarantee forever (part of the blockchain) | Yes | Written to a "random" address, cannot start with `0xEF`
121
-
| Events | Onchain | Ethereum guarantee forever (part of the blockchain) | No |
122
-
| Storage | Onchain | Ethereum guarantee forever (part of the blockchain and the present state until overwritten) | Yes |
108
+
| Storage type | Source of data | Availability guarantee | Onchain availability | Additional limitations|
| EIP-4844 blobs | Offchain | Ethereum guarantee for [~18 days](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)| Only hash is available ||
111
+
| Calldata | Offchain | Ethereum guarantee forever (part of the blockchain)| Only available if written to a contract, and at that transaction |
112
+
| Offchain with L1 mechanisms | Offchain | "One honest verifier" guarantee during the challenge period | Hash only | Guaranteed by the challenge mechanism, only during the challenge period|
113
+
| Contract code | Onchain or offchain | Ethereum guarantee forever (part of the blockchain) | Yes | Written to a "random" address, cannot start with `0xEF`|
114
+
| Events | Onchain | Ethereum guarantee forever (part of the blockchain) | No|
115
+
| Storage | Onchain | Ethereum guarantee forever (part of the blockchain and the present state until overwritten) | Yes|
0 commit comments