Linea Contracts Update

1 Executive Summary

This report presents the results of our engagement with Linea to review an update of their smart contracts, in particular the rollup and message service contracts.

The review was conducted primarily by Rai Yang, with some support from Heiko Fisch and George Kobakhidze. It took place between December 11, 2023, and January 12, 2024.

Linea contracts have undergone several audits by Consensys Diligence (Verifier, Message Service, Canonical Token Bridge, Cross-Chain Governance Executor, Custom Bridged Token) and OpenZeppelin (Verifier, Bridge) throughout 2023.

Recently, in preparation for EIP-4844, the Linea team has implemented an interim upgrade for compressed data submission and finalization and made some changes to the message service; these changes are the subject of the current review.

2 Scope

The scope for this audit has been defined in a document provided by the Linea team; it describes the changes in detail, explains the motivation, and lists the contracts that were altered. This document served as a reference for this engagement. A short outline of the changes is given in section 3.

We started our review at the commit hash 0154676f95a510a855622f8ac9b07816f94edf08 of the GitHub repository Consensys/linea-contracts-audit. Early in the engagement, two changes were incorporated into the codebase, which led to the commit hash a4fb9a48dffc2bc2fb5f9161b2dde19c2bafc5e6. After another small change in the last week, the final version of the codebase considered in this audit has the commit hash bb6eb7284d1ac9574dc69e654abe5ccb8d8ded1a. A list of all Solidity files (except tests and mocks) in the repository at the commit hash bb6eb7284d1ac9574dc69e654abe5ccb8d8ded1a, together with their SHA-1 hashes, can be found in Appendix 1.

We have reviewed the issues and fixes for the OpenZeppelin report in commit 075b26e9656afa11197ebc2377f593d2cc1db26b, we agree M01-M11, L1, L2, L4-L8, L11, N1-N7, N9-N12 are valid issues and M01-M10, L1, L2, L4-L8, N1-N7, N9-N12 are fixed or addressed. However for M01,M06 and M08, we believe the current fix by adding checks for block number order in the contract is not that helpful to resolve the issue, since the operator can always submit an incorrect block number and the check complicates the logic, adds gas cost and may introduce errors, ultimately the block number order are proved by the prover and verified in the data finalization, therefore we recommend to remove these checks.

3 Summary of the Changes

The motivation for these contract changes is the highly anticipated EIP-4844 (also known as “proto-danksharding”), which will bring enormous benefits, especially for rollups. Once implemented, this improvement proposal will provide much cheaper data storage in so-called blobs. While blob data is not stored permanently, it is kept for long enough to give everyone a chance to grab it – what is commonly referred to as “data availability.” As rollups need to publish relatively large amounts of data on L1 – which is currently achieved via calldata – blobs will drastically reduce the L1 fees rollups have to pay.

In order to keep the necessary adaptations to utilize blobs to a minimum when proto-danksharding goes live, the Linea team has implemented an interim update that behaves similarly to EIP-4844 but employs compressed calldata instead of blobs. More precisely – and quoting from Linea’s description – the changes that have been implemented and are the subject of this review are:

1. Compressed data submission. This includes validation of the data, securing access to functionality, as well as public input generation for the proof finalization.
2. Access-controlled block finalization, hashing the provided compressed data, as well as other calldata for public input generation for the proof, and then proof verification.
3. Block finalization without proof verification.
4. L1 to L2 message flow, computing a rolling hash (each message added is hashed with the previous) for L1 for message addition, and a mirrored calculation on L2 when anchoring, where the feedback loop sends the latest rolling hash anchored to L1 in finalization to validate no censorship or tampering.
5. L2 to L1 message flow inclusive of L1 anchoring in the finalization using indexed sparse Merkle trees on L2 for message addition and Merkle proofs for message validation on L1.

4 Security Specification

This section describes, from a security perspective, the expected behavior of the system under audit. It is not a substitute for documentation. The purpose of this section is to identify specific security properties that were validated by the audit team.

4.1 Actors

The relevant actors are listed below with their respective abilities:

• User: Use the message service on L1 and L2.
• Coordinator: Moves information between L1 and L2. This includes submitting and finalizing compressed block data and relaying messages between L1 and L2.
• Sequencer: Builds and executes L2 blocks, generates execution trace and conflated block data.
• Prover: Proves correct state transitions and block data execution with the execution trace provided by the sequencer.
• Security Council: A Linea/Consensys-controlled multi-sig wallet that deploys contracts and performs upgrades.
• Postman: Linea’s off-chain message delivery service or third-party service delivering the messages to claim the delivery fee. Each postman is not dependent on the other to function.

4.2 Trust Model

In any system, it’s important to identify what trust is expected/required between various actors. For this audit, we established the following trust model:

• The single coordinator relays messages between L1 and L2 correctly and timely and does not censor L1 → L2 or L2 → L1 messages.
• The single sequencer sequences the L2 transaction correctly, timely and does not censor L2 messages.
• The single prover proves the execution correctly, sets chainID correctly in the circuit for the corresponding chain, generates Merkle roots correctly, and does not censor L2 → L1 messages.
• Postman delivers the messages to the destination layer correctly and rationally based on the fee and gas cost of delivering the message.
• Security Council performs the service administration properly and upgrades the contracts correctly and securely.

4.3 Security Properties

The following is a non-exhaustive list of security properties that were considered in this audit:

• Storage layout is not broken.
• Reentrancy issues have not been introduced.
• Previous issues have not been reintroduced.
• Access control is still in place and has been used correctly.
• Attack vectors have not been introduced.
• Backwards compatibility remains.
• Duplicate claiming is not possible.
• If external contracts are used, security and lack of exploitability is maintained.
• Compressed data item submission is validated correctly.
• Messaging system is sound.
• Proof verification is sound (includes rollup mechanism and public input generation).
• The algorithm (proof of equivalence) to check compressed data submitted to L1 is the same data used in the prover is correctly implemented.
• New (if used) messaging mechanism is sound and has no attack/manipulation vectors.
• Merkle root proving is valid.
• If submitted data is incorrect in finalization, operator can resubmit and finalize data.
• L1 contract migration/update is sound once EIP-4844 is implemented on L1.
• L1 → L2 message claiming refund subsdize(REFUND_OVERHEAD_IN_GAS) is correctly set that prevents user gas price manipulation.
• L1 → L2 messages are not tampered by the coordinator.
• Linea chain can fork when L1 forks.
• L1 contract can distinguish data submitted from different Linea forks.

5 Findings

Each issue has an assigned severity:

• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Critical issues are directly exploitable security vulnerabilities that need to be fixed.

currentL2BlockNumber = _finalizationData.finalBlockNumber;

if (stateRootHashes[currentL2BlockNumber] != _finalizationData.parentStateRootHash) {
  revert StartingRootHashDoesNotMatch();
}

if (startingParentFinalStateRootHash != _finalizationData.parentStateRootHash) {
          revert FinalStateRootHashDoesNotMatch(
            startingParentFinalStateRootHash,
            _finalizationData.parentStateRootHash
          );
 }

if (stateRootHashes[currentL2BlockNumber] != _finalizationData.parentStateRootHash) {
  revert StartingRootHashDoesNotMatch();
}

if (finalizationDataDataHashesLength != 0) {
  bytes32 startingDataParentHash = dataParents[_finalizationData.dataHashes[0]];

  if (startingDataParentHash != _finalizationData.dataParentHash) {
    revert ParentHashesDoesNotMatch(startingDataParentHash, _finalizationData.dataParentHash);
  }

  bytes32 startingParentFinalStateRootHash = dataFinalStateRootHashes[startingDataParentHash];

  if (startingParentFinalStateRootHash != _finalizationData.parentStateRootHash) {
    revert FinalStateRootHashDoesNotMatch(startingParentFinalStateRootHash, _finalizationData.parentStateRootHash);
  }

_addL2MerkleRoots(_finalizationData.l2MerkleRoots, _finalizationData.l2MerkleTreesDepth);
_anchorL2MessagingBlocks(_finalizationData.l2MessagingBlocksOffsets, lastFinalizedBlock);

uint256 publicInput = uint256(
  keccak256(
    abi.encode(
      shnarf,
      _finalizationData.parentStateRootHash,
      _finalizationData.lastFinalizedTimestamp,
      _finalizationData.finalBlockNumber,
      _finalizationData.finalTimestamp,
      _finalizationData.l1RollingHash,
      _finalizationData.l1RollingHashMessageNumber,
      keccak256(abi.encodePacked(_finalizationData.l2MerkleRoots))
    )

_addL2MerkleRoots(_finalizationData.l2MerkleRoots, _finalizationData.l2MerkleTreesDepth);

shnarf = keccak256(
      abi.encode(
        shnarf,
        _submissionData.snarkHash,
        _submissionData.finalStateRootHash,
        compressedDataComputedX,
        _calculateY(_submissionData.compressedData, compressedDataComputedX)
      )
 );     

function _submitData(SubmissionData calldata _submissionData) internal returns (bytes32 shnarf) {
  shnarf = dataShnarfHashes[_submissionData.dataParentHash];

  bytes32 parentFinalStateRootHash = dataFinalStateRootHashes[_submissionData.dataParentHash];
  uint256 lastFinalizedBlock = currentL2BlockNumber;

  if (_submissionData.firstBlockInData <= lastFinalizedBlock) {
    revert FirstBlockLessThanOrEqualToLastFinalizedBlock(_submissionData.firstBlockInData, lastFinalizedBlock);
  }

  if (_submissionData.firstBlockInData > _submissionData.finalBlockInData) {
    revert FirstBlockGreaterThanFinalBlock(_submissionData.firstBlockInData, _submissionData.finalBlockInData);
  }

  if (_submissionData.parentStateRootHash != parentFinalStateRootHash) {
    revert StateRootHashInvalid(parentFinalStateRootHash, _submissionData.parentStateRootHash);
  }

  bytes32 currentDataHash = keccak256(_submissionData.compressedData);

  if (dataFinalStateRootHashes[currentDataHash] != EMPTY_HASH) {
    revert DataAlreadySubmitted(currentDataHash);
  }

  dataParents[currentDataHash] = _submissionData.dataParentHash;
  dataFinalStateRootHashes[currentDataHash] = _submissionData.finalStateRootHash;

  bytes32 compressedDataComputedX = keccak256(abi.encode(_submissionData.snarkHash, currentDataHash));

  shnarf = keccak256(
    abi.encode(
      shnarf,
      _submissionData.snarkHash,
      _submissionData.finalStateRootHash,
      compressedDataComputedX,
      _calculateY(_submissionData.compressedData, compressedDataComputedX)
    )
  );

  dataShnarfHashes[currentDataHash] = shnarf;

  emit DataSubmitted(currentDataHash, _submissionData.firstBlockInData, _submissionData.finalBlockInData);
}

function _calculateY(
  bytes calldata _data,
  bytes32 _compressedDataComputedX
) internal pure returns (bytes32 compressedDataComputedY) {
  if (_data.length % 0x20 != 0) {
    revert BytesLengthNotMultipleOf32();
  }

  bytes4 errorSelector = ILineaRollup.FirstByteIsNotZero.selector;
  assembly {
    for {
      let i := _data.length
    } gt(i, 0) {

    } {
      i := sub(i, 0x20)
      let chunk := calldataload(add(_data.offset, i))
      if iszero(iszero(and(chunk, 0xFF00000000000000000000000000000000000000000000000000000000000000))) {
        let ptr := mload(0x40)
        mstore(ptr, errorSelector)
        revert(ptr, 0x4)
      }
      compressedDataComputedY := addmod(
        mulmod(compressedDataComputedY, _compressedDataComputedX, Y_MODULUS),
        chunk,
        Y_MODULUS
      )
    }
  }
}

function submitData(
  SubmissionData calldata _submissionData
)
  external
  whenTypeNotPaused(PROVING_SYSTEM_PAUSE_TYPE)
  whenTypeNotPaused(GENERAL_PAUSE_TYPE)
  onlyRole(OPERATOR_ROLE)
{
  _submitData(_submissionData);
}

Appendix 1 - Solidity files with their SHA-1 hashes

The following table contains all Solidity files (with the exception of tests and mocks) in the client’s repository with their corresponding SHA-1 hash; the repository is viewed at bb6eb7284d1ac9574dc69e654abe5ccb8d8ded1a – which is the final version of the codebase considered for this audit. Not all these files have changed since earlier audits, and we have only reviewed the changes that the client outlined in the audit companion document.

Appendix 2 - Disclosure

Consensys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via Consensys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any third party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any third party by virtue of publishing these Reports.

A.2.1 Purpose of Reports

The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of code and only the code we note as being within the scope of our review within this report. Any Solidity code itself presents unique and unquantifiable risks as the Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond specified code that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. In some instances, we may perform penetration testing or infrastructure assessments depending on the scope of the particular engagement.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

A.2.2 Links to Other Web Sites from This Web Site

You may, through hypertext or other computer links, gain access to web sites operated by persons other than Consensys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that Consensys and CD are not responsible for the content or operation of such Web sites, and that Consensys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that Consensys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. Consensys and CD assumes no responsibility for the use of third-party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

A.2.3 Timeliness of Content

The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice unless indicated otherwise, by Consensys and CD.