Skip to content

Commit 182e53a

Browse files
author
fnerdman
committed
feat: add Block Builder TEE Proofs section
1 parent 65e99e5 commit 182e53a

File tree

1 file changed

+93
-0
lines changed

1 file changed

+93
-0
lines changed

specs/flashtestations.md

Lines changed: 93 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -670,3 +670,96 @@ To establish trust in expected measurements, the TEE block builder must be built
670670
4. **Verification**: Independent parties can follow the build process and verify that it produces the same measurements
671671

672672
This allows anyone to verify that the expected measurements correspond to the published source code.
673+
674+
## Block Builder TEE Proofs
675+
676+
The Flashtestations protocol can be extended to provide cryptographic guarantees that blocks were constructed by an authorized TEE-based block builder. This section describes how block builders running in a TEE can prove block authenticity through an on-chain verification mechanism.
677+
678+
### Core Mechanism
679+
680+
The block builder TEE proof system works through a final transaction appended to each block. This transaction:
681+
682+
1. Calls a designated smart contract method that accepts a block content hash
683+
2. Verifies the caller's authorization using `isAllowedPolicy(block_builder_policy_id, msg.sender)`
684+
3. Provides cryptographic evidence that the block was constructed by a valid TEE-based block builder
685+
686+
The key insight is that the required private key to sign this transaction is protected within the TEE environment. Thus, only a genuine TEE-based block builder with the proper attestation can successfully execute this transaction.
687+
688+
### Block Building Process
689+
690+
When building a block, the TEE block builder:
691+
692+
1. Produces a block according to the L2 protocol rules
693+
2. Computes the block content hash using the `ComputeBlockContentHash` function:
694+
695+
```solidity
696+
function ComputeBlockContentHash(block, transactions) {
697+
// Create ordered list of all transaction hashes
698+
transactionHashes = []
699+
for each tx in transactions:
700+
txHash = keccak256(rlp_encode(tx))
701+
transactionHashes.append(txHash)
702+
703+
// Compute a single hash over block data and transaction hashes
704+
// This ensures the hash covers the exact transaction set and order
705+
return keccak256(abi.encode(
706+
block.parentHash,
707+
block.number,
708+
block.timestamp,
709+
transactionHashes
710+
))
711+
}
712+
```
713+
714+
3. Computes `blockContentHash = ComputeBlockContentHash(block, block.transactions)`
715+
716+
This block content hash formulation provides a balance between rollup compatibility and verification strength:
717+
- Contains the minimal set of elements needed to uniquely identify a block's contents
718+
- Compatible with data available on L1 for most optimistic and ZK rollup implementations
719+
- Enables signature verification without requiring state root dependencies
720+
- Supports future L1 verification of block authenticity across different rollup designs
721+
722+
### Verification Contract
723+
724+
The smart contract that verifies block builder TEE proofs would implement:
725+
726+
```solidity
727+
// Block builder verification contract
728+
function verifyBlockBuilderProof(bytes32 blockContentHash) external {
729+
// Check if the caller is an authorized TEE block builder
730+
require(
731+
IAllowlist(ALLOWLIST_CONTRACT).isAllowedPolicy(BLOCK_BUILDER_POLICY_ID, msg.sender),
732+
"Unauthorized block builder"
733+
);
734+
735+
// At this point, we know:
736+
// 1. The caller is a registered address from an attested TEE
737+
// 2. The TEE is running an approved block builder workload (via policy)
738+
739+
// Additional validation can be performed on the blockContentHash
740+
741+
emit BlockBuilderProofVerified(
742+
msg.sender,
743+
block.number,
744+
blockContentHash
745+
);
746+
}
747+
```
748+
749+
### Security Properties
750+
751+
This mechanism provides several important security guarantees:
752+
753+
1. **Block Authenticity**: Each block contains cryptographic proof that it was produced by an authorized TEE block builder
754+
2. **Non-Transferability**: The proof cannot be stolen or reused by unauthorized parties due to TEE protection of signing keys
755+
3. **Policy Flexibility**: The system can adapt to new block builder implementations by updating the policy without contract changes
756+
4. **Auditability**: All proofs are recorded on-chain for transparency and verification
757+
758+
### Integration with Rollup Systems
759+
760+
For rollup systems, this proof mechanism:
761+
762+
1. Can be included as the final transaction in each block
763+
2. Enables L1 contracts to verify that blocks were built by authorized TEEs
764+
3. Provides a foundation for stronger security guarantees in optimistic rollups
765+
4. Supports cross-chain verification of block authenticity

0 commit comments

Comments
 (0)