Data availability on zkSync is maintained through a combination of techniques that ensure the entire Layer 2 (L2) state can be reconstructed from the data submitted to the Ethereum Layer 1 (L1) blockchain. Here’s a detailed explanation of the process:

1. State Diffs:

   • Instead of submitting the data of each transaction, zkSync submits how the state of the blockchain changes, known as the state diff. This approach allows transactions that change the same storage slots to be very cheap, as these transactions don't incur additional data costs[1].

2. Additional Data:

   • Besides state diffs, zkSync also posts additional data to L1, such as L2-to-L1 messages, L2-to-L1 logs, and the bytecodes of deployed smart contracts. All this data is compressed before being sent to L1 to reduce costs[1].

3. Reconstruction of L2 State:

   • By posting all the necessary data to L1, zkSync ensures that the state of the L2 chain can be fully reconstructed from the data on L1. This is a critical security property of the rollup, as it allows anyone to verify the correctness of the L2 state[1].

1. Filtering Transactions:

   • The process begins by filtering all transactions to the L1 zkSync contract to identify only the commitBlocks transactions where the proposed block has been referenced by a corresponding executeBlocks call. This is important because a committed or even proven block can be reverted, but an executed one cannot[1].

2. Extracting Pubdata:

   • Once the relevant committed blocks that have been executed are identified, the system pulls the transaction input and relevant fields. The main types of pubdata extracted include:

     • L2 to L1 Logs

     • L2 to L1 Messages

     • Published Bytecodes

     • Compressed State Diffs[1]

3. State Diffs:

   • State diffs are key-value pairs representing the 32-byte value stored at a particular storage slot for a particular address. The actual data structure used is more efficient:

     • Derived Key: A hash of the storage slot and address.

     • Compressed Value: The value is compressed to reduce data size.

     • Enumeration Index: A shorthand ID that can be substituted for the derived key after its first write[1].

4. Contract Bytecodes:

   • Contract bytecode is chunked into opcodes (8 bytes each), assigned a 2-byte index, and the newly formed byte sequence (indexes) is verified and sent to L1. This process involves:

     • Server-side operator handling the compression.

     • System contract verifying the compression before sending to L1.

   • The compressed bytecode is sent through factoryDeps, and the hash of the uncompressed bytecode is stored on the AccountStorage contract, making it part of the state diffs[1].

• zkSync also introduces a hybrid model called zkPorter, which combines the benefits of rollups and validiums. In zkPorter, some storage slots post data to L1 (like a rollup), while others do not (like a validium). This allows for cheaper transactions while maintaining a balance between security and cost[1].

Data availability on zkSync is maintained by submitting compressed state diffs and additional necessary data to the Ethereum L1. This ensures that the entire L2 state can be reconstructed from the data on L1, providing a robust security mechanism. The use of zkPorter further enhances this by allowing a mix of rollup and validium features, optimizing for both cost and security.

Citations:

[1] https://docs.zksync.io/zk-stack/concepts/data-availability/overview.html

Data availability on zkSync is maintained through a combination of techniques that ensure the entire Layer 2 (L2) state can be reconstructed from the data submitted to the Ethereum Layer 1 (L1) blockchain. Here’s a detailed explanation of the process:

1. State Diffs:

   • Instead of submitting the data of each transaction, zkSync submits how the state of the blockchain changes, known as the state diff. This approach allows transactions that change the same storage slots to be very cheap, as these transactions don't incur additional data costs[1].

2. Additional Data:

   • Besides state diffs, zkSync also posts additional data to L1, such as L2-to-L1 messages, L2-to-L1 logs, and the bytecodes of deployed smart contracts. All this data is compressed before being sent to L1 to reduce costs[1].

3. Reconstruction of L2 State:

   • By posting all the necessary data to L1, zkSync ensures that the state of the L2 chain can be fully reconstructed from the data on L1. This is a critical security property of the rollup, as it allows anyone to verify the correctness of the L2 state[1].

1. Filtering Transactions:

   • The process begins by filtering all transactions to the L1 zkSync contract to identify only the commitBlocks transactions where the proposed block has been referenced by a corresponding executeBlocks call. This is important because a committed or even proven block can be reverted, but an executed one cannot[1].

2. Extracting Pubdata:

   • Once the relevant committed blocks that have been executed are identified, the system pulls the transaction input and relevant fields. The main types of pubdata extracted include:

     • L2 to L1 Logs

     • L2 to L1 Messages

     • Published Bytecodes

     • Compressed State Diffs[1]

3. State Diffs:

   • State diffs are key-value pairs representing the 32-byte value stored at a particular storage slot for a particular address. The actual data structure used is more efficient:

     • Derived Key: A hash of the storage slot and address.

     • Compressed Value: The value is compressed to reduce data size.

     • Enumeration Index: A shorthand ID that can be substituted for the derived key after its first write[1].

4. Contract Bytecodes:

   • Contract bytecode is chunked into opcodes (8 bytes each), assigned a 2-byte index, and the newly formed byte sequence (indexes) is verified and sent to L1. This process involves:

     • Server-side operator handling the compression.

     • System contract verifying the compression before sending to L1.

   • The compressed bytecode is sent through factoryDeps, and the hash of the uncompressed bytecode is stored on the AccountStorage contract, making it part of the state diffs[1].

• zkSync also introduces a hybrid model called zkPorter, which combines the benefits of rollups and validiums. In zkPorter, some storage slots post data to L1 (like a rollup), while others do not (like a validium). This allows for cheaper transactions while maintaining a balance between security and cost[1].

Data availability on zkSync is maintained by submitting compressed state diffs and additional necessary data to the Ethereum L1. This ensures that the entire L2 state can be reconstructed from the data on L1, providing a robust security mechanism. The use of zkPorter further enhances this by allowing a mix of rollup and validium features, optimizing for both cost and security.

Citations:

[1] https://docs.zksync.io/zk-stack/concepts/data-availability/overview.html