Each Ethereum account has its storage, excluding EOA which doesn't have any storage.

The storage layout is divided into slots, starting from slot 0 . There are 2^256 available slots in the storage, each slot is 32 bytes of data. Cause there are a limited number of slots, data collision may happens, we will talk about this later.

State variables are stored differently in the storage, based on rules:

Multiple contiguous items that need less than 32 bytes are packed into a single storage slot if possible.

The variables in turn are in slot in the order of lower-order (ie from right to left).

If a value type does not fit the remaining part of a storage slot, it is stored in the next storage slot.

Structs and array data always start a new slot and their items are packed tightly according to these rules.

Items following struct or array data always start a new storage slot.

You may not know

All state variables in the storage are accessible, whether they are defined public or private. It's recommended not to storage any sensitive informations in the contract storage.

When working with variables that are smaller than 32 bytes, your contract's gas usage must be higher. The reason is EVM operations on 32 bytes, so if the element is smaller than that, the EVM must use more operations in order to reduce the size of the element from 32 bytes to the desired size.

It's better to pack variables fit into one slot if the combination of the data size is smaller than 32 bytes. For example, the order uint128, uint128, uint256 is better than uint128, uint256, uint128 cause the former takes two slots while the latter takes three slots.

## Dynamic arrays and mapping

### Dynamic arrays

Dynamic array takes one slot to store the length of the array. Assume the slot p stores the length of the array, the slot location for element index i in the array is calculated equal to uint256(keccak256(p)) + i.

### Mapping

Mapping takes one slot but nothing is stored at that slot. It is needed to ensure that even if there are two mappings next to each other, their content ends up at different storage locations. Assume mapping is located at slot p, so the slot location for value of key k is calculated equal to keccak256(h(k) + p) where h is function applied to key k depending on its type:

For value types, h pads the value to 32 bytes in the same way as when storing the value in memory.

For strings and byte arrays, h(k) is just the unpadded data.

## bytes and string

bytes and string are encoded identically. In general, the encoding is similar to bytes1[], in the sense that there is a slot for the array itself and a data area that is computed using a keccak256 hash of that slot’s position. However, for short values (shorter than 32 bytes) the array elements are stored together with the length in the same slot.

## Example

You can find my example in [this repository Solidity Storage](https://github.com/quangkeu95/learn-evm/blob/main/src/storage/SimpleStorage.sol)

## References

[Solidity documentation](https://docs.soliditylang.org/en/v0.8.20/internals/layout_in_storage.html)

Sharding in blockchain is a method of increasing the number of transactions that a blockchain can process at any given time. The concept involves splitting the entire network into smaller portions, or "shards," each capable of processing its own transactions and smart contracts. In a traditional blockchain, each node stores all states (account balances, contract code, storage, etc.) and processes all transactions. This provides a high degree of security but limits scalability. Sharding allows for a subset of nodes to handle certain transactions, resulting in higher overall capacity without sacrificing decentralization and security. This approach has been proposed and pursued by several projects such as Ethereum 2.0 to increase their network's scalability and transaction speed.

Ethereum Danksharding

Danksharding is the new sharding design proposed for Ethereum, with a focus on the Ethereum rollup-centric roadmap. The main innovation introduced by Danksharding is the merged fee market: unlike regular sharding, in which shards have both different block and block proposers, only one proposer exists that chooses all transactions and all data that go into that slot in Danksharding.

To avoid large hardware requirements for validators and to remain decentralized when implementing Danksharding, a Proposer-builder separation (PBS) [[1]](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) was introduced.

PBS separates the block processing and building workload into a list of block builders, then the block proposer will accept the block body from builders with the highest bid. So the workload for the block proposer here is reduced drastically, and all other validators and users can verify the blocks very efficiently through data availability sampling (DAS). Also, note that the proposers (and everyone else) don't know the contents of any exec block body submitted by builders.

Proto-danksharding (aka EIP-4844)

Proto-danksharding (PDS) is a proposal to implement core changes, particularly transaction format - that would be needed for full Danksharding. EIP-4844 introduces a new transaction type - a blob-carrying transaction. A blob (Binary large objects) is extremely large (~128kB) and can be much cheaper than similar amounts of calldata. However, blob data is not accessible to EVM execution (the execution layer), the EVM can only view a commitment to the blob.

To learn more about commitment scheme: https://en.wikipedia.org/wiki/Commitment_scheme

The data blobs are represented as polynomials and then use a polynomial commitment scheme to commit to the data. Ethereum plans specifically to use KZG as its polynomial commitment scheme. This allows us not only to achieve a commitment to the data, but also to be able to efficiently check certain properties of the data blob without needing to read the entire thing.

## Data Availability Sampling in Danksharding

The goal of DAS is that network participants can verify the data availability without the need to download a large amount of data.

This is a complex term that requires a lot of time to digest, so I will go deeper later.

## References

https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#What-is-Danksharding

https://www.paradigm.xyz/2022/08/das

https://ethereum.org/en/developers/docs/data-availability/

https://scroll.io/blog/kzg

https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#kzg-commitments-vs-fraud-proofs