#### Trustless TEE Meeting Day 1

### Supply Chain

- Transparency of design

- Verify

### Physical Attack

- Inactive

- ...

### Simple Crypto

building puff -> desinging a chip in which the key is generated, the idea is that in any manufacturing process, no matter how hard the manufacturer tries -> structure the chip to generate a key that's unique to that hardware.

1. Generate the key internal to the chip
2. Defend against attackers

- side channel attacks

#### IRIS
You should be able to inspect the chip

#### Fabric
Rollout a TEE with better trust assumptions, 12nm zk chip, programmable chip with instruction set that can accelerate all of the ZK.

TEE can be made more secure than what we thought previously.

## Today

Have trustless TEE in the next chip: Fabtric.

1. Is it really trustless?
2. What does it mean?
3. What use-cases does it require, part of the focus

* suggested topic: **Economic security level**

1. Protection of integrity of computation
- anything, restaking, or zk,

2. privacy
- how much $ does it take to break it?
- tee provide the first possible form that is not cryptographic

the challenge: the current tee, sgx, tdx, it takes a lot of money to break these

Puff design / physical security of the device, how much is it worth?

## Use Cases

MACI + FHE

- operator or the tee is honest

fhe compitation -> encryptied value

Voting Schemes -> fhe, bored acc or smth more complicated?

Why fhe? you can be -> quadratic voting, various voting mechanisms for example multiple issues at the same time

Why fhe for quadratic voting?

realistic answer: things doing by a human being, writing a program which has to be like a black box

how often do people change voting mechanism?

- theoretical space is big but

community notes is not great

a good compromise could be leveled homomorphic encryption (HE)

- equality checks
- decriptions
- quadratic, degree 2
- community notes stuff, if it could constrain possible

The challenge:

- people can collude undetectably,
- voting scheme, if tee gets broken, the only thing that gets broken is the abstract
- tools to model the difficulty of collusion?
- a bit weird to use tee to use the coercion, resistance,
- how excited we are for it?

Acc Encumbrance
- if this happens, bribing will be unstoppable

use cases: tee based private key sign once, and never again. presumably you need storage.

- store it for a while
- software obfuscation, that uses one time key
- one time program out of one time memory

Is one time memory, where two values, you can choose a and b value, or a generalization of that idea. One out of m transfer.

## Web2 Encumbrance

storing
- web2 credentials like, pw, cookies, fine grained delegation, applying smart contracts to these web2 credentials, imposing self provided filters, encumbering your X acc, you prove you'll not shill your competitors token, playing with llms
- besides pw, off cookies: standardized format
- oauth

they have all in common: it goes over TLS, at minimum manage the TLS that consists a hand-shake with PublicKey encryption.

Interoperability challenge
- more variety
- web2 services of target

#### Computational Characteristics

- TLS has the public key operation, which stands out
- Fractionalizing X accounts

#### Security Model Perspective

- Service provider can enable this through oauth
- do you think users have more use cases than the provider has thought of
- v: bare case of encumbrance, if operators wanted to happen, expose it on chain, and then recycle the api every day
- zkTLS

## Trustless TEE
### Security Models for Hardware and Encryption

- **Invasive Attack Models**
- Involves physical probing of chips using ion beams and microprobes
- Requires precise targeting of specific chip regions
- Can be countered with:
- Activated meshes for detection
- Tripwire sensors that self-destruct
- Multiple design paths (15+ different tile designs)
- Randomized physical designs
- Acceptable chip self-destruction rate: 10-20% for security
- **Non-invasive Attacks**
- Side channel attacks
- No physical chip manipulation required
- Can measure without decapsulation
- Generally less destructive approach

### Voting Systems and Privacy

- **Basic Macy Implementation**
- Components:
- Pre-registered users with keys
- Operator with key pair
- Encrypted votes published on chain
- Nullifier system to prevent double voting
- Features:
- Coercion resistance
- Privacy protection
- Anti-bribery mechanisms
- Multiple vote capability with last/first vote counting rules
- **FHE Enhancement**
- Enables more complex voting schemes:
- Quadratic voting
- Sortition
- Multi-issue voting
- Challenges:
- High computational overhead
- Complex implementation requirements
- Server-side processing demands

### Trusted Execution Environment (TEE) Applications

- **Simple Use Cases**
- Counter-based signing
- Anti-slashing for staking providers
- One-time signatures
- Quantum money implementations
- Single-use credentials
- **Web2 Integration**
- Password and credential management
- OAuth implementations
- TLS operations
- API key management
- Account encumbrance for social media

### Future Considerations and Trade-offs

- **FHE vs TEE Trade-offs**
- TEEs provide better latency for specific operations
- FHE offers broader security guarantees but higher overhead
- Hybrid approaches may be optimal for certain applications
- **Security Considerations**
- Need for threshold decryption in FHE implementations
- Balance between security and performance
- Economic considerations for different security levels
- Importance of hardware security for key storage
- Trade-offs between centralized and decentralized approaches

## zkTLS

### Scraping Challenges & LLM Solutions

- Current challenge: Websites frequently change UI/HTML structure, breaking scraping
- Two main approaches to handle changes:
- Community-maintained providers that update scraping rules
- LLM-based automatic adaptation when patterns break
- Privacy concern: Sending HTML/JSON to external LLMs could expose PII
- Considering running smaller LLMs inside TEEs to protect privacy
- University websites identified as frequently changing targets
- System uses previous working patterns to help LLM identify new structure

### Legal Framework for Web Scraping

- Key case studies from Facebook litigation against browser extensions
- Computer Fraud and Abuse Act (CFAA) often used as catch-all legal challenge
- Legal assessment for ZK proofs:
- Public data scraping likely legally defensible
- Non-custodial, user-generated proofs reduce legal risk
- Authenticated systems (e.g., ZK Venmo) present more legal complexity
- Terms of Service violations remain a potential risk

### Business Applications & Cost Benefits

- Primary use case: Background verification (employment, education)
- Traditional background checks costs per verification
- ZKTLS reduces cost to under x per verification
- Major platforms of interest:
- TikTok showing interest
- Microsoft identified as potential collaborator

### Future Opportunities & Use Cases

- Identity verification and selective disclosure
- Targeted airdrops based on historical behavior
- Example: ETH early adopters with variable vesting schedules
- Social graph portability (though vampire attacks noted as historically unsuccessful)
- Community-driven privacy innovations within existing platforms
- Integration with privacy-focused TEE projects like Keystone 2

### FHE

- Current state: Japanese group achieved 1Hz for RISC-5 processor under FHE
- uint64 operations run at ~3Hz - surprisingly close to full processor speed
- Key optimization opportunity: Implementing ALU operations in single ciphertext
- Can achieve significant improvements through:
- Packing/unpacking operations (32 bits into single ciphertext)
- Infrequent bootstrapping (once per cycle or several cycles)
- Using relaxed functional bootstrapping for binary numbers
- Estimated requirements: ~100 multiplications for 1 RV32 cycle
- Target: 1 MHz encrypted RISC-5 operations achievable on 7nm process

#### Hardware Implementation Considerations

- Die area calculations:
- 4096 x 12 = ~24k operations per multiplication
- One 32-bit multiplier uses ~0.4mm² in 7nm process
- 600mm² die could support ~30k multipliers
- Can achieve ~100 teraops at 2.5GHz
- Architecture decisions:
- Chiplets vs monolithic design (trade-off between flexibility and complexity)
- HBM memory integration
- UCI/PCIe implementation
- Patent costs

#### Cost Structure for Chip Development

- Base startup costs
- Key expenses:
- RISC-V license
- EDA tools: Annual subscription model
- IP blocks: Multiple millions per component
- Process node costs:
- 130nm
- 7nm
- 5nm
- Testing equipment: Multiple shifts required
- FPGA emulation: Enterprise pricing for multiple units

#### AI/ML Applications

- Recent breakthrough: Fast LLM processing through FHE
- Logarithmic overhead with O(d) ciphertexts
- Matrix multiplication optimization potential
- Performance comparison:
- Overhead reduced to ~7x over plaintext operations
- Competitive with NVIDIA’s pricing margin on AI hardware
- Potential throughput: Equivalent to one A100 card on 7nm process

#### Security Trade-offs

- TEE (Trusted Execution Environment) vs FHE approach
- Concerns about hardware security:
- Physical defense mesh design
- Fault injection protection
- PUF (Physical Unclonable Function) implementation
- Security vs Performance balance:
- Full security requires significant resources
- Market may accept “good enough” security with better performance
- Need for verifiable manufacturing process

#### Market & Applications

- Primary target: B2B applications
- Key potential customers:
- Cloud providers (AWS-like services)
- Blockchain/rollup operators
- Financial institutions
- Independent validators
- Timeline expectations:
- 1.5-3 years to market
- Need to demonstrate demand to fabs
- Potential partnerships with established manufacturers