O trilema blockchain surgiu mais uma vez em Consenso em Hong Kong em fevereiro, até certo ponto, colocando Charles Hoskinson, o fundador da Cardano, no pé de trás – ter que garantir aos participantes que hiperescaladores como Google Cloud e Microsoft Azure estão não um risco para a descentralização.
Foi dito que os principais projetos de blockchain precisar hiperescaladores, e não se deve se preocupar com um único ponto de falha porque:
- A criptografia avançada neutraliza o risco
- A computação multipartidária distribui material chave
- A computação confidencial protege os dados em uso
O argumento baseava-se na ideia de que “se a nuvem não consegue ver os dados, a nuvem não consegue controlar o sistema”, e foi deixado lá devido a limitações de tempo.
Mas há uma alternativa ao argumento de Hoskinson a favor dos hiperescaladores que merece mais atenção.
MPC e computação confidencial reduzem a exposição
Este foi um bastião estratégico no argumento de Charles – que tecnologias como computação multipartidária (MPC) e a computação confidencial garantem que os fornecedores de hardware não tenham acesso aos dados subjacentes.
São ferramentas poderosas. Mas eles não dissolver o risco subjacente.
O MPC distribui material chave entre várias partes para que nenhum participante possa reconstruir um segredo. Isso reduz significativamente o risco de um único nó comprometido. Contudo, a superfície de segurança se expande em outras direções. A camada de coordenação, os canais de comunicação e a governação dos nós participantes tornam-se críticos.
Em vez de confiar num único detentor de chave, o sistema depende agora de um conjunto distribuído de intervenientes que se comportem corretamente e que o protocolo seja implementado corretamente. O único ponto de falha não desaparece. Na verdade, torna-se simplesmente uma superfície de confiança distribuída.
A computação confidencial, especialmente ambientes de execução confiáveis, apresenta uma compensação diferente. Os dados são criptografados durante a execução, o que limita a exposição ao provedor de hospedagem.
Mas ambientes de execução confiáveis (ETEs) dependem de suposições de hardware. Eles dependem do isolamento da microarquitetura, da integridade do firmware e da implementação correta. A literatura acadêmica, por exemplo, aqui e aquidemonstrou repetidamente que vulnerabilidades arquitetônicas e de canal lateral continuam a surgir em tecnologias enclave. O limite de segurança é mais estreito do que o da nuvem tradicional, mas não é absoluto.
Mais importante ainda, tanto o MPC quanto os TEEs geralmente operam sobre infraestrutura hiperescaladora. O hardware físico, a camada de virtualização e a cadeia de fornecimento permanecem concentrados. Se um fornecedor de infraestrutura controlar o acesso a máquinas, largura de banda ou regiões geográficas, ele mantém a alavancagem operacional. A criptografia pode impedir a inspeção de dados, mas não impede restrições de rendimento, desligamentos ou intervenções políticas.
Ferramentas criptográficas avançadas dificultam ataques específicos, mas ainda não eliminam o risco de falha no nível da infraestrutura. Eles simplesmente substituem uma concentração visível por uma mais complexa.
O argumento 'Nenhum L1 pode lidar com a computação global'
Hoskinson destacou que os hiperescaladores são necessários porque nenhuma Camada 1 pode lidar com as demandas computacionais dos sistemas globais, referindo-se aos trilhões de dólares que ajudaram a construir esses centros de dados.
Claro, Redes de camada 1 não foram desenvolvidos para executar ciclos de treinamento de IA, mecanismos de negociação de alta frequência ou pipelines de análise empresarial. Eles existem para manter o consenso, verificar transições de estado e fornecer disponibilidade durável de dados.
Ele está correto sobre para que serve a Camada 1. Mas os sistemas globais necessitam principalmente de resultados que qualquer pessoa possa verificar, mesmo que a computação ocorra noutro local.
Na infraestrutura criptográfica moderna, a computação pesada ocorre cada vez mais fora da cadeia. O que importa é que os resultados podem ser comprovados e verificados onchain. Esta é a base de rollups, sistemas de conhecimento zero e redes de computação verificáveis.
Concentrar-se em saber se um L1 pode executar computação global ignora a questão central de quem controla a infraestrutura de execução e armazenamento por trás da verificação.
Se a computação ocorrer fora da cadeia, mas depender de uma infraestrutura centralizada, o sistema herdará modos de falha centralizados. A liquidação permanece descentralizada em teoria, mas o caminho para produzir transições estatais válidas está concentrado na prática.
A questão deveria ser sobre a dependência na camada de infraestrutura, e não sobre a capacidade computacional dentro da Camada 1.
Neutralidade criptográfica não é o mesmo que neutralidade de participação
A neutralidade criptográfica é uma ideia poderosa e algo que Hoskinson usou em seu argumento. Isso significa que as regras não podem ser alteradas arbitrariamente, backdoors ocultos não podem ser introduzidos e o protocolo permanece justo.
Mas a criptografia continua hardware.
Essa camada física determina quem pode participar, quem pode pagar para fazê-lo e quem acaba excluído, porque o rendimento e a latência são, em última análise, limitados por máquinas reais e pela infraestrutura em que são executadas. Se a produção, distribuição e hospedagem de hardware permanecerem centralizadas, a participação torna-se economicamente limitada, mesmo quando o protocolo em si é matematicamente neutro.
Em sistemas de alta computação, o hardware é o divisor de águas. Determina a estrutura de custos, quem pode escalar e a resiliência sob pressão da censura. Um protocolo neutro executado em infraestrutura concentrada é neutro na teoria, mas restrito na prática.
A prioridade deve mudar para a criptografia combinada com diversificado propriedade de hardware.
Sem diversidade de infra-estruturas, a neutralidade torna-se frágil sob pressão. Se um pequeno conjunto de provedores puder limitar as cargas de trabalho, restringir regiões ou impor barreiras de conformidade, o sistema herdará sua vantagem. A justiça das regras por si só não garante a justiça da participação.
A especialização supera a generalização nos mercados de computação
Competir com a AWS costuma ser considerado uma questão de escala, mas isso também é enganoso.
Os hiperescaladores otimizam a flexibilidade. Sua infraestrutura foi projetada para atender milhares de cargas de trabalho simultaneamente. Camadas de virtualização, sistemas de orquestração, ferramentas de conformidade empresarial e garantias de elasticidade – esses recursos são pontos fortes para a computação de uso geral, mas também são camadas de custos.
Prova de conhecimento zero e a computação verificável é determinística, densa em computação, com restrição de largura de banda de memória e sensível ao pipeline. Em outras palavras, eles recompensam a especialização.
Uma rede de prova desenvolvida especificamente compete em prova por dólar, prova por watt e prova por latência. Quando o hardware, o software do provador, o projeto do circuito e a lógica de agregação são integrados verticalmente, a eficiência aumenta. A remoção de camadas de abstração desnecessárias reduz a sobrecarga. A taxa de transferência sustentada em clusters persistentes supera o dimensionamento elástico para cargas de trabalho estreitas e constantes.
Nos mercados de computação, a especialização supera consistentemente a generalização para tarefas constantes e de alto volume. AWS otimiza para opcionalidade. Uma rede de testes dedicada otimiza para uma classe de trabalho.
A estrutura económica também difere. Preço dos hiperscaladores para margens empresariais e ampla variabilidade de demanda. Uma rede alinhada em torno de incentivos de protocolo pode amortizar o hardware de maneira diferente e ajustar o desempenho em torno da utilização sustentada, em vez de modelos de aluguel de curto prazo.
A competição gira em torno da eficiência estrutural para uma carga de trabalho definida.
Use hiperescaladores, mas não dependa deles
Os hiperscaladores não são o inimigo. Eles são fornecedores de infraestrutura eficientes, confiáveis e distribuídos globalmente. O problema é a dependência.
Uma arquitetura resiliente utiliza grandes fornecedores para capacidade de expansão, redundância geográfica e distribuição de borda, mas não ancora funções essenciais a um único provedor ou a um pequeno cluster de provedores.
A liquidação, a verificação final e a disponibilidade de artefatos críticos devem permanecer intactas mesmo se uma região de nuvem falhar, um fornecedor sair do mercado ou se as restrições políticas aumentarem.
É aqui que o armazenamento descentralizado e a infraestrutura de computação se tornam uma alternativa viável. Artefatos de prova, registros históricos e entradas de verificação não devem ser retirados a critério do fornecedor. Em vez disso, deveriam viver em infraestruturas economicamente alinhadas com o protocolo e estruturalmente difíceis de desligar.
Hypescalers devem ser usados como um opcional acelerador em vez de algo fundamental para o produto. A nuvem ainda pode ser útil para alcance e rajadas, mas a capacidade do sistema de produzir provas e persistir do que depende a verificação não é restrita a um único fornecedor.
Em tal sistema, se um hyperscaler desaparecer amanhãa rede apenas desaceleraria, porque as partes mais importantes pertencem e são operadas por uma rede mais ampla, em vez de serem alugadas de um ponto de estrangulamento de grandes marcas.
É assim que se fortalece o espírito de descentralização da criptografia.
