Constraints API First Pass Comments

Terminology

• a preconfirmation is not defined but is immediately used in the "preconfer" defintion
• a builder is responsible for providing a proof that constraints are followed, not "proving constraints are followed". slightly different and a small semantic nit pick
• "Relay: A trusted party", it feels quite arbitrary to add trust into this components definition when there is trust involved in each component to be honest.
• I have no idea what "an abstracted EVM RPC API" is. What is abstracted about it? it abstracts across many chains? that means its multichain. it supports preconf json RPC? well thats not abstracted, thats a new RPC API.

API Notes

• why is /constraints/v0/builder/delegate seperate from the register validtor API? it feels like you should abstract that instead
• why are we adding a new path /constraints/v0/builder/header_with_proofs instead of adding an optional proof field to the existing get header api https://github.com/ethereum/builder-specs/blob/main/apis/builder/header.yaml
• you mention "delegations" which should be in the terminology section because it's not totally clear what a "delegation" is

Diagram Notes

• why is the proposer on the left

General Comments

• I'd appreciate an "Honest Gateway" spec like https://github.com/ethereum/builder-specs/blob/main/specs/bellatrix/validator.md
• this whole thing generally makes no sense without understanding what a "constraint" is and there is not really any clear definition or schema. I would personally abstract away the cosntraints message from this API entirely and create a new spec which defintions a constraints defintion