Background

The constraints API was initially built with the primary assumption being non-delegation, i.e., the proposer issues commitments to L1/L2 users and creates constraints for the builders. This way they can outsource block construction to builders but still verify that their constraints are followed. Importantly this can be done trustlessly because the proposer has complete knowledge of the commitments and constraints that were made.

How block building works with today’s specs

image.png

  1. L1 Proposer calls POST /delegate which sets the delegate BLS pubkey and a committer address. Note that self-delegation is possible by assigning to keys you own.
  2. committer address (ECDSA key) signs off on commitments via commitments API (e.g., “I will include your L1 transaction”)
  3. delegate key signs off on constraints which are posted to POST /constraints endpoint
  4. builder gets constraints via GET /constraints and builds the L1 block. They make sure to include transactions such that they satisfy the constraints while also including a proof. Everything is posted to POST /blocks_with_proofs
  5. The L1 Proposer calls GET /header_with_proofs and can verify the proofs against the block header before accepting it

Note that in steps 2 and 3, the entity performing this is intentionally unspecified to support delegation and non-delegation.

Shift towards delegation

A motivating design question was asking how individual proposers are expected to scale to support multiple based rollups in the future - in terms of hardware to run many L2 nodes + build competitively + have DDOS protection etc. The result adds sophistication back to proposers that PBS was designed to shield them from.

So to minimize proposer sophistication, more teams have shifted towards the delegation model that relies on a trusted gateway to issue commitments and constraints.

How delegation affects the specs

Since the specs were originally designed assuming non-delegation, there some leftover baggage that should be addressed. When delegating, there is a data availability problem that negates any security guarantees that proofs originally gave us. It is easier to explain this via a simple attack:

  1. L1 Proposer calls POST /delegate to delegate to a gateway
  2. gateway signs of two L1 inclusion preconfs: $TX_{inc1}$ and $TX_{inc2}$
  3. gateway posts a single constraint $C_{inc1}$ for $TX_{inc1}$ to the relay but omits a constraint for $TX_{inc2}$
  4. builder builds a block that includes $TX_{inc1}$ and generates a valid Merkle inclusion proof
  5. L1 Proposer calls GET /header_with_proofs and the proof is valid because they are only aware of $C_{inc1}$