You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- 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>
Copy file name to clipboardExpand all lines: specs/flashtestations.md
+10-8Lines changed: 10 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -91,7 +91,7 @@ Flashtestations is designed to achieve the following objectives:
91
91
92
92
### System Architecture
93
93
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:
95
95
96
96
```
97
97
┌─────────────────────┐ ┌─────────────────────┐
@@ -291,7 +291,7 @@ class TDXMeasurements():
291
291
292
292
### TEE Attestation Mechanism
293
293
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.
295
295
296
296
### Intel TDX DCAP Attestation
297
297
@@ -360,7 +360,7 @@ The Allowlist Registry is a core component of Flashtestations that acts as a boo
360
360
361
361
### Core Concepts
362
362
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:
364
364
365
365
1.**Storing addresses** that have been validated through attestation
366
366
2.**Associating addresses** with their specific workload identity
@@ -600,7 +600,7 @@ The transparency log serves several critical functions:
600
600
601
601
### Logged Information
602
602
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:
604
604
605
605
1.**Raw Attestation Quotes**: The complete DCAP quotes submitted for verification
606
606
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
647
647
1.**Allowlist**: Optimized for efficient runtime checks and state updates
648
648
2.**Transparency Log**: Optimized for auditability and historical verification
649
649
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.
651
651
652
652
## Rationale
653
653
654
+
The following explains the reasoning behind key design decisions in the Flashtestations protocol:
655
+
654
656
### Replacement Model
655
657
656
-
The conceptual model uses a direct replacement approach:
658
+
The protocol uses a direct replacement approach for attestations:
657
659
658
660
- When an address re-attests for a workloadId, its old entry is replaced with the new one
659
661
- This keeps the model simpler by ensuring each address has exactly one current endorsement per workloadId
660
662
- When endorsements become invalid, all addresses using that specific endorsement are removed completely
661
663
662
664
### Gas Optimization
663
665
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:
665
667
666
668
- Lookups should be O(1) regardless of the number of addresses
667
669
- Storage slots should be fully cleared when no longer needed (to receive gas refunds)
668
670
- Batch operations should be supported for removing addresses when endorsements become invalid
669
671
670
672
### Separation of Concerns
671
673
672
-
The design maintains clear separation between:
674
+
A key design rationale is maintaining clear separation between:
673
675
674
676
1.**Allowlist Registry**: Tracks which addresses have attestations validated by current endorsements
675
677
2.**Policy Registry**: Defines which workloads are acceptable for specific onchain operations
0 commit comments