Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 0d271f8

Browse files
fnerdmanclaude
andcommittedMay 20, 2025·
docs: improve section transitions and wording
- Enhance System Architecture section to better connect with specification - Add explanatory text to Rationale section to frame the content properly - Update wording in TEE Attestation Mechanism to reflect specification context - Improve section references and transitions throughout the document - Add specification context to various components to fit the new structure 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
1 parent 63b3cf8 commit 0d271f8

File tree

1 file changed

+10
-8
lines changed

1 file changed

+10
-8
lines changed
 

‎specs/flashtestations.md

Lines changed: 10 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -91,7 +91,7 @@ Flashtestations is designed to achieve the following objectives:
9191

9292
### System Architecture
9393

94-
The Flashtestations protocol consists of four key components that work together to provide secure onchain TEE verification:
94+
Within the Flashtestations specification, the protocol architecture consists of four key components that work together to provide secure onchain TEE verification:
9595

9696
```
9797
┌─────────────────────┐ ┌─────────────────────┐
@@ -291,7 +291,7 @@ class TDXMeasurements():
291291

292292
### TEE Attestation Mechanism
293293

294-
Attestation is the process by which a TEE proves its identity and integrity. The protocol uses Intel TDX with DCAP (Data Center Attestation Primitives) attestation.
294+
Attestation is the process by which a TEE proves its identity and integrity. This section of the specification defines how the protocol uses Intel TDX with DCAP (Data Center Attestation Primitives) attestation.
295295

296296
### Intel TDX DCAP Attestation
297297

@@ -360,7 +360,7 @@ The Allowlist Registry is a core component of Flashtestations that acts as a boo
360360

361361
### Core Concepts
362362

363-
At its most abstract level, the Allowlist Registry is responsible for:
363+
At its most abstract level within this specification, the Allowlist Registry is responsible for:
364364

365365
1. **Storing addresses** that have been validated through attestation
366366
2. **Associating addresses** with their specific workload identity
@@ -600,7 +600,7 @@ The transparency log serves several critical functions:
600600

601601
### Logged Information
602602

603-
The transparency log captures raw attestation data along with verification results:
603+
As specified in this protocol, the transparency log captures raw attestation data along with verification results:
604604

605605
1. **Raw Attestation Quotes**: The complete DCAP quotes submitted for verification
606606
2. **Intel Endorsements**: The actual endorsement data (endorsements) used to validate attestations
@@ -647,29 +647,31 @@ While the allowlist registry maintains the current authorized state (which addre
647647
1. **Allowlist**: Optimized for efficient runtime checks and state updates
648648
2. **Transparency Log**: Optimized for auditability and historical verification
649649

650-
This dual approach enables efficient onchain operations while maintaining complete transparency and auditability.
650+
This dual approach specified in the protocol enables efficient onchain operations while maintaining complete transparency and auditability.
651651

652652
## Rationale
653653

654+
The following explains the reasoning behind key design decisions in the Flashtestations protocol:
655+
654656
### Replacement Model
655657

656-
The conceptual model uses a direct replacement approach:
658+
The protocol uses a direct replacement approach for attestations:
657659

658660
- When an address re-attests for a workloadId, its old entry is replaced with the new one
659661
- This keeps the model simpler by ensuring each address has exactly one current endorsement per workloadId
660662
- When endorsements become invalid, all addresses using that specific endorsement are removed completely
661663

662664
### Gas Optimization
663665

664-
The system must optimize for gas efficiency, particularly for the lookup operations:
666+
The rationale for gas optimization in the protocol design is that the system must prioritize efficiency, particularly for the lookup operations:
665667

666668
- Lookups should be O(1) regardless of the number of addresses
667669
- Storage slots should be fully cleared when no longer needed (to receive gas refunds)
668670
- Batch operations should be supported for removing addresses when endorsements become invalid
669671

670672
### Separation of Concerns
671673

672-
The design maintains clear separation between:
674+
A key design rationale is maintaining clear separation between:
673675

674676
1. **Allowlist Registry**: Tracks which addresses have attestations validated by current endorsements
675677
2. **Policy Registry**: Defines which workloads are acceptable for specific onchain operations

0 commit comments

Comments
 (0)
Please sign in to comment.