Tópicos em alta
#
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 está uma imagem realista do que eu realmente quis dizer quando disse que o **ônus** da verificação foi transferido.
Contexto: Nos protocolos TEE SGX/TDX modernos, o PROVER envia:
+ evidência de atestação (citação/relatório)
+ garantia de verificação necessária para validá-la
OU
Os protocolos dependem de terceiros e NÃO de Intel como fonte de verdade para suas garantias.
Agora, o próprio provador enviando os materiais necessários para verificação (colateral) ao verificador OU algum terceiro fornecendo artefatos críticos de tomada de decisão NÃO é tão problemático quanto parece à primeira vista.
Mas vamos ter que atravessar um pouco de lama para acertar. Deixe-me te contar o porquê.
Essa escolha de design é, em grande parte, uma questão de praticidade e disponibilidade. Muitos verificadores NÃO querem depender de chamadas de rede Intel ao vivo em cada aperto de mão.
Justo.
Então, quais escolhas de design as pessoas normalmente focam:
1. Verificador busca diretamente do Intel PCS para puxar a cadeia de certificados PCK, CRLs PCK, TCBInfo, QEIdentity, etc.
Bom: Frescura ruim, risco de retrocesso é insignificante
Ruim: Verificador precisa de rede de saída + problemas de disponibilidade/latência de Intel
2. Buscas verificadoras de um cache confiável (PCCS)
Aqui temos um Serviço de Cache de Certificados de Provisão que sincroniza com o Intel PCS e é considerado a fonte de verdade para verificadores (em vez da Intel)...

Melhores
Classificação
Favoritos
