Hoskinson pode estar errado sobre o futuro da computação descentralizada

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.