Temas en tendencia
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Déjame entrar en detalles.
Aquí tienes una imagen realista de lo que realmente quería decir cuando dije que la **carga** de verificación se ha desplazado.
Contexto: En los protocolos TEE SGX/TDX modernos, el PROVER envía:
+ evidencia de atestación (cita/informe)
+ garantía de verificación necesaria para validarlo
O
Los protocolos dependen de un tercero y NO de Intel como fuente de verdad para su garantía.
Ahora bien, que el propio demostrador envíe los materiales necesarios para la verificación (colateral) al verificador O que algún tercero suministre artefactos críticos para la toma de decisiones NO es tan problemático como parece a simple vista.
Pero tendremos que abrirnos paso por el barro para hacerlo bien. Déjame explicarte por qué.
Esta elección de diseño es en gran medida un compromiso entre practicidad y disponibilidad. Muchos verificadores NO quieren depender de llamadas en tiempo real de la red de Intel en cada apretón de manos.
Justo.
Entonces, ¿qué decisiones de diseño suelen elegir las personas?
1. El verificador obtiene directamente desde Intel PCS para extraer la cadena de certificación PCK, CRLs PCK, TCBInfo, QEIdentity, etc.
Bueno: La frescura es insignificante, el riesgo de retroceso es insignificante
Malo: El verificador necesita red saliente + problemas de disponibilidad/latencia de Intel
2. Verificadores recuperan desde una caché confiable (PCCS)
Aquí tenemos un Servicio de Caché de Certificados de Provisión que se sincroniza con los PCS de Intel y se considera la fuente de verdad para los verificadores (en lugar de Intel)...

Populares
Ranking
Favoritas
