Tópicos populares
#
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.
Deixe-me entrar nos detalhes aqui.
Aqui está uma imagem realista do que realmente quis dizer quando disse que o **ônus** da verificação foi transferido.
Contexto: Nos protocolos modernos de SGX/TDX TEE, o PROVEDOR envia:
+ evidência de atestação (citação/relatório)
+ colateral de verificação necessário para validá-la
OU
Os protocolos dependem de um 3º partido e NÃO da Intel como fonte de verdade para seu colateral.
Agora, o provedor em si enviando os materiais necessários para verificação (colateral) ao verificador OU algum 3º partido fornecendo artefatos críticos para a tomada de decisão NÃO é tão problemático quanto parece à primeira vista.
Mas teremos que atravessar um pouco de lama para acertar isso. Deixe-me explicar por quê.
Essa escolha de design é em grande parte um compromisso de praticidade e disponibilidade. Muitos verificadores NÃO querem depender de chamadas de rede da Intel ao vivo em cada handshake.
Justo.
Então, quais escolhas de design as pessoas normalmente focam:
1. O verificador busca diretamente da Intel PCS para puxar a cadeia de certificados PCK, CRLs PCK, TCBInfo, QEIdentity, etc.
Bom: Frescor, risco de retrocesso é negligenciável
Ruim: O verificador precisa de rede de saída + problemas de disponibilidade/latência da Intel
2. O verificador busca de um cache confiável (PCCS)
Aqui temos um Serviço de Cache de Certificado de Provisionamento que se sincroniza com a Intel PCS e é considerado a fonte de verdade para os verificadores (em vez da Intel)...

Top
Classificação
Favoritos
