RFC 015 - TEE como Capability (Hardware Attestation)

Status: Ratificado (Standards Track) Pilar: S1 (Segurança) / S3 (Economia)

1. Resumo

A malha PAEBIRU adota um modelo de confiança orgânico. A presença de um Trusted Execution Environment (TEE) não é um requisito de admissão basal. Em vez disso, o TEE é tratado como uma Capability (recurso econômico escasso) dentro do Barter Engine.

2. Motivação

Exigir TEE para todos os nós excluiria dispositivos de borda ultra-restritos (microcontroladores via paebiru-hal) e sistemas de energy harvesting. No entanto, tarefas de Compute-over-Data sensíveis exigem execução confidencial. Tratar o TEE como um recurso negociável resolve esse impasse.

3. Especificação Técnica

3.1. Capability de Hardware

A DSL dos Plasmídeos (TOML) passa a aceitar o requisito hardware_attestation:

[capabilities.requires]
types = ["TrustedExecution"]
min_security_level = "High"

3.2. Regras de Admissão e Escambo

Inclusão na Borda: Nós sem TEE podem ingressar na malha e executar tarefas leves.
Verificação Estrita: Se um contrato (Plasmídeo) exigir TrustedExecution, o BarterEngine só aprovará a transação se o nó ofertante fornecer uma prova criptográfica (atestação) válida da posse de um enclave (SGX, TrustZone, SE).

4. Impacto Arquitetural

Economia: O BarterEngine deve validar provas de atestação durante o match de recursos.
Kernel: Fornece as primitivas criptográficas para validar assinaturas de enclaves de hardware.