OpenZeppelin
Skip to content

Linea Blob Submission Audit

OpenZeppelin Security | March 21, 2024

Table of Contents

Summary

Type
L2
Timeline
From 2024-03-04
To 2024-03-08
Languages
Solidity
Total Issues
6 (3 resolved, 1 partially resolved)
Critical Severity Issues
0 (0 resolved)
High Severity Issues
0 (0 resolved)
Medium Severity Issues
0 (0 resolved)
Low Severity Issues
4 (2 resolved)
Notes & Additional Information
2 (1 resolved, 1 partially resolved)

Scope

We audited the Consensys/linea-contracts-audit repository at commit 29e6798. All the resolutions mentioned in this report are contained at commit 2816a34, making it the final version reviewed during this audit. The commit be602ab on linea-contracts includes an exact copy/replica of the audited code at commit 2816a34.

In scope were the changes made to the following files in that commit:

 contracts
├── LineaRollup.sol
├── ZkEvmV2.sol
├── interfaces
│   ├── l1
│   │   ├── IL1MessageService.sol
│   │   ├── ILineaRollup.sol
│   │   └── IZkEvmV2.sol
│   └── l2
│       └── IL2MessageManager.sol
└── messageService
    ├── l1
    │   ├── L1MessageService.sol
    │   └── v1
    │       └── L1MessageManagerV1.sol
    └── l2
        └── L2MessageManager.sol

System Overview

The system is described in our previous audit report, which also outlines:

  • Modifications made to the codebase in preparation for EIP-4844.
  • New functionality introduced in version 2 (V2).

The code under review completes this transition by removing obsolete version 1 (V1) code and introducing a new function to submit compressed layer 2 (L2) transactions using data blobs. The original submission function can still be used if desired.

Blob Submissions

When EIP-4844 is activated, all Ethereum users will have the ability to publish arbitrary blobs of data to the blockchain. These blobs cannot be referenced from inside the EVM and will expire in approximately 18 days. They will be priced at their own blob gas rate and are expected to be cheaper than using the calldata of an EVM function call. This makes them ideal for rollup transactions which need to be published but not processed on Layer 1 (L1).

To ensure that the published transactions are faithfully reproduced in the L2 circuit:

  • The blob data is interpreted as a polynomial.
  • A corresponding polynomial commitment is derived on L1.
  • A snark-friendly commitment is published with the data.
  • The two commitments are compared using the proof-of-equivalence protocol.
  • The snark-friendly commitment can now be used by the circuit to validate the provided transactions.

In the original submission function, the commitment is a hash of the provided data buffer and the polynomial evaluation in the proof-of-equivalence protocol is computed directly. The new mechanism utilizes the native EIP-4844 opcodes and precompiles to construct the commitment and to validate a claimed point evaluation. This makes it simpler but otherwise does not change any of the existing functionality.

Security Model and Trust Assumptions

The code under review does not meaningfully change the security model. Previously, addresses with the OPERATOR_ROLE were able to call the submitData function (while the proving system was not paused) to publish compressed L2 transaction data. Now, they can also call the submitBlobData function to publish the data in EIP-4844 blobs.

The operator can choose which function to use for each submission. It is expected that the operator will always choose the cheaper option.

 

Low Severity

Incorrect Error

The StateRootHashInvalid error message does not match the error that it is describing.

For instance, it is possible for both parameters to be empty. Even if the _submissionData.parentStateRootHash is non-empty, it would be more natural to treat it as the expected value. However, in practice, this is actually checking the validity of the submitted dataParentHash parameter.

Consider updating the error accordingly.

Update: Acknowledged, not resolved. The Linea team stated:

This is going to be removed with the next gas optimization.

Incomplete Docstrings

Throughout the codebase, the event parameters are not documented.

Consider thoroughly documenting all events and their parameters. When writing docstrings, consider following the Ethereum Natural Specification Format (NatSpec).

Update: Resolved in pull request #39. The Linea team stated:

All events now have better NatSpec. Note that in two of the files, the order has been shuffled to be: Structs, Events, Errors, and then Functions to be consistent with the rest of the codebase.

Inconsistent Polynomial Encoding

The submitData function interprets the compressed data as polynomial coefficients. On the other hand, the submitBlobData function uses EIP-4844 blobs which implicitly interpret the data as polynomial evaluations. The Linea team have indicated that the circuit includes an Eip4844Enabled flag to handle this difference.

However, this flag is not included in the shnarf, which is used to derive the public input, due to which the prover can select the opposite value. By itself, this would cause the circuit to derive an incorrect polynomial from the provided data. However, if the prover modified the provided L2 transaction data so the correct polynomial was derived, it would successfully pass the proof-of-equivalence check with incorrect transactions.

In practice, these transactions will likely be malformed and will not have valid signatures. Whether the proof will succeed depends on the details of the circuit. If the proof does succeed, the prover can use this mechanism to discard valid transactions that were correctly published.

In either case, in the interest of simplicity and reducing the attack surface, consider including the Eip4844Enabled flag in the shnarf and modifying the circuit to retrieve it from the public input.

Update: Acknowledged, will resolve. The Linea team stated:

Acknowledged: Currently being resolved outside of the contract with the circuit, prover, and other components that will be enforced in decentralized scenarios.

Missing or Misleading Documentation

The following code instances are misleading or would benefit from additional documentation:

Consider updating these instances to improve the clarity of the codebase.

Update: Resolved in pull request #36. The Linea team stated:

The _currentDataHash has been corrected, the systemMigrationBlock has had comments added around future use, and dataHashes has been marked as required.

Notes & Additional Information

Unused Errors and Events

Following the deprecation of V1, the following issues and events are now unused and could be removed:

Consider removing these instances to improve the clarity of the codebase.

Update: Partially resolved in pull request #38. The Linea team stated:

Errors were removed along with the initialized event. The two other events (BlockFinalized) and (ServiceVersionMigrated) were left with comments regarding their usage. They were left primarily for existing consumer usage for past events.

Non-Standard Storage Gaps

When using the proxy pattern for upgrades, it is a common practice to include storage gaps in parent contracts to reserve space for potential future variables. The size is typically chosen so that all contracts have the same number of variables (usually 50). In this way, the expected layout can be deduced without knowing the full contract history. However, the codebase uses inconsistent sizes given that all of them declare a gap storage of 50 positions, regardless of how many variables were declared in the contracts. In addition, the code under review does not reduce the LineaRollup contract's gap size despite introducing a new variable. This does not cause inconsistencies because the LineaRollup contract is the last one in the inheritance chain, making the gap unnecessary.

Consider documenting the existing gap sizes in deployed parent contracts to avoid confusion when updating them. Furthermore, consider removing the unnecessary gap in the LineaRollup contract, which can be reintroduced if future upgrades inherit from this contract. Alternatively, consider reducing the gap size so the whole contract uses 50 storage slots.

Update: Resolved in pull request #37. The Linea team stated:

We removed the gap in LineaRollup.sol and documented the specific numbers of the gaps at each location. Some additional gap comments were made for previous ones that we could not alter.

 
 

Conclusion

The audited codebase adds support for blob submissions introduced in EIP-4844 and removes obsolete code from V1. We found the codebase to be well-written and well-documented, and we appreciate the Linea team's cooperation throughout the engagement.

 

Related Posts