Hi @82y31. Great questions!
Let me try to briefly go through them one by one:
- All nodes/operators run the same block-building logic with the default algorithms.
- Every transaction is shared across all builder nodes. The orderflow-proxy service receives transactions and shares them with orderflow-proxy on all other instances, as well as with rbuilder. See also Operating system, services and reproducible builds | BuilderNet
- BuilderNet does compute the optimal block after removing each transaction. For this, the transactions are stored in the redistribution archive (see also Architecture overview | BuilderNet)
- Builder nodes don’t compete with each other, but they collaborate. They do not try to outbid each other, rather they are aware of each other’s bids, as well as of those of competitors.
Your last two questions are about verifying the TEE proof, and how a sender can be sure about it. This is documented in more detail here: Orderflow encryption and attestation | BuilderNet
In short:
- Users can reproducibly build the BuilderNet node VM images, and arrive at exactly the same TDX measurements as published on https://measurements.builder.flashbots.net/
- Every builder node creates a local TLS certificate, of which the private key reside exclusively inside the TEE instance (and never leaves it).
- Every builder node exposes a server to validate it’s TEE proof with aTLS. During TLS setup on this port, the TEE proof validation (attestation) is performed, which establishes a secure channel into a verified TEE instance. Over this secure verified channel, users receive the TLS certificate.
- Users can use this TLS certificate which they received after the TEE proof validation to send orderflow to the instance (they can require the server to possess the private key for this certificate).
See also Orderflow encryption and attestation | BuilderNet for more details.
Hope that helps, and happy to dive deeper and answer more questions!