Skip to content

Scoru,Proto: limit the size of a wrapped proof

Context

Closes #3062 (closed)

  (* This encoding uses unbounded sub-encodings. To avoid attacks through too
     large proofs and long decoding times on public nodes, we put another layer
     of security by restricting the maximum_size to [30Kb].

     Even if the operation size limit is currentxly [32Kb] (see
     {!Constants_repr.max_operation_data_length}) the node's mempool can still
     be spammed with larger proofs before detecting that the operations are
     indeed larger than the limit.

     By design, the proofs should be created and verified for a single tick
     which should limit the number of read/writes in the Merkle tree, and thefore,
     limit the total size of a proof. Thus, [30Kb] can be lowered once we
     have empirically observed that a valid proof can not be that large.

     Note that an encoded proof that is [30Kb] might still be not included
     in a valid L1 operation. The refutation operation also contains other
     information such as an inbox proof. We only put here an upper bound
     for the size.
  *)

Having a much lower upper-bound might cause a failure in the encoding of a valid proof regarding the refutation game. By putting the upper-bound slightly below the L1 operation size limitn we guarantee that it can be at least included in a valid L1 operation regarding the size, and without being directly linked to the {!Constants_repr.max_operation_data_length} which could be updated in the future.

Manually testing the MR

Checklist

  • Document the interface of any function added or modified (see the coding guidelines)
  • Document any change to the user interface, including configuration parameters (see node configuration)
  • Provide automatic testing (see the testing guide).
  • For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
  • Select suitable reviewers using the Reviewers field below.
  • Select as Assignee the next person who should take action on that MR
Edited by Valentin Chaboche

Merge request reports