Flashtestions

[avalonche]

📝 Summary

Adds bootstrapping and tee proof verification functionality to the flashtestations workflow.

Workflow:

• On startup of the payload builder, it will spawn the flashtestations service.
• This step involves the bootstrap which includes funding the generated key using the cli builder signer and submitting an attestation quote with the TEE generated key
• On shutdown the TEE key will refund the builder signer whatever funds are left in its account
• End of block tee proofs controlled by the flag --flashtestations.enable-block-proofs

💡 Motivation and Context

Future Work:

• Abstracting the end of block builder transaction as a trait
• Implementing the end of block builder transaction proofs with the verifyBlockBuilderProof function
• Converting the transactions into EIP712 signatures and submit them without funding the TEE key

---

✅ I have completed the following steps:

• Run make lint
• Run make test
• Added tests (if applicable)

[SozinM]

Suggested change

	tdx = { git = "https://github.com/automata-network/tdx-attestation-sdk.git"}
	tdx = { git = "https://github.com/automata-network/tdx-attestation-sdk.git"}

Suggested change

	tdx = { git = "https://github.com/automata-network/tdx-attestation-sdk.git"}
	tdx = { git = "https://github.com/automata-network/tdx-attestation-sdk.git", rev = "d41e1f7791b7964d7b257c28136f253c8bfa390c"}

[avalonche]

why this commit?

[avalonche]

its causing version conflicts: two different versions of the c-kzg crate

[SozinM]

Suggested change

	dcap-rs = { git = "https://github.com/automata-network/dcap-rs.git" }
	dcap-rs = { git = "https://github.com/automata-network/dcap-rs.git" }

Suggested change

	dcap-rs = { git = "https://github.com/automata-network/dcap-rs.git" }
	dcap-rs = { git = "https://github.com/automata-network/dcap-rs.git", rev = "d847b8f75a493640c4881bdf67775250b6baefab" }

[avalonche]

why this commit?

[fnerdman]

I have a couple of thoughts and suggestions based on how the service is currently started and how/when the attestation transaction is submitted:

1. Startup error handling:
   Currently, if spawn_flashtestations_service fails (e.g., attestation tx can't be submitted or confirmed), the builder startup is blocked and fails. For now, since we don't have any critical dependencies on this service, it might be preferable to continue startup and simply log a warning if the service fails to initialize, rather than aborting the whole process. This would make the builder more robust in the face of temporary issues with the attestation mechanism.

2. When to submit the attestation transaction:
   Right now, the attestation tx is submitted and awaited during startup, which is a blocking operation. This creates a potential deadlock in situations where this builder is the only block producer: the service can't start until the tx is confirmed, but the tx can't be confirmed until a block is built. While the sequencer and rollup-boost can eventually step in and include the tx, it might be more robust to decouple registration from startup.
   One idea: store the attestation tx and submit it as part of the first block the builder produces. This guarantees the tx is included at the earliest opportunity, avoids startup deadlocks, and ensures liveness even in single-builder scenarios. The downside is that, until the attestation is included, each candidate block will have to simulate the registration tx, which is some wasted computation, but likely worth the improved robustness.

Summary:

• Consider logging and continuing if spawn_flashtestations_service fails.
• Consider deferring attestation tx submission to the first block built, to avoid startup deadlocks and improve liveness. This does not have to happen in this PR, can be in a follow up. It may also not make sense due to some other factors I'm not aware of.