Há anos, quando comecei a trabalhar em projetos que atendiam bilhões de usuários, vi como as escolhas de infraestrutura feitas nos primeiros dias podem remodelar o destino de uma indústria inteira.

Mesmo plataformas lançadas com as melhores intenções de serem abertas, neutras e livres de controle podem deslizar para formas de centralização.

Não é porque alguém se propõe a ser “malvado”; é apenas a atração gravitacional natural da tecnologia e dos mercados quando certas decisões de design são bloqueadas desde o início.

As escolhas de design de infraestrutura importam desde o primeiro dia.

Essas escolhas de design essenciais devem garantir que a própria tecnologia promova a justiça e evite a consolidação do poder em primeiro lugar.

Já vimos este filme antes

“O poder tende a concentrar-se, mesmo que ninguém planeie isso”

É uma verdade sutil mas profunda que aprendi em primeira mão enquanto trabalhava em produtos de internet em grande escala.

Quando a ‘indústria descentralizada’ nasceu, parecia uma segunda chance. Olhávamos para o Bitcoin, Ethereum e outros como formas de escapar das antigas estruturas de poder.

A narrativa foi direta: retomar o controle, cortar intermediários e deixar o código garantir a justiça.

Mas temos que ser honestos, ao longo do tempo, as mesmas pressões que centralizaram a Internet também começaram a agir nesses sistemas ‘descentralizados’.

Mas como é que a Internet se centralizou?

O Internet não foi iniciada como uma rede descentralizada P2P que poderia até resistir a uma guerra nuclear?

Para entender por que esses sistemas descentralizados estão sucumbindo às pressões de centralização, você precisa entender o que aconteceu com a Internet.

Você tem que olhar como ele passou de seus começos idealistas para um ecossistema altamente centralizado.

A Internet Primitiva: Quando Peer-to-Peer Era a Norma

“No começo, ninguém tinha todas as chaves, e nenhum jogador único estava tomando todas as decisões”

A versão mais antiga do que agora chamamos de Internet começou basicamente sob o Departamento de Defesa dos EUA, com coisas como ARPANET no final dos anos 60.

Origem: @DailySwig

A ideia desde o primeiro dia era evitar esse único ponto de falha, garantir que um único local desativado não pudesse levar tudo junto.

Esta rede foi projetada de forma deliberada para ser descentralizada.

A justificativa foi estratégica: um sistema distribuído poderia resistir à falha de qualquer nó único, tornando as comunicações mais resilientes diante de interrupções, como mau funcionamento do equipamento ou mesmo condições de guerra.

Uma rede de comunicação confiável e descentralizada que poderia resistir mesmo a um ataque nuclear.

Cada nó era um “peer” capaz de enviar e receber dados sem depender de uma única autoridade centralizada. Qualquer máquina, independentemente do hardware ou sistema operativo, poderia “falar” TCP/IP e trocar dados.

Nos anos 70 e 80, as universidades e os laboratórios de pesquisa ligaram-se através da NSFNET e da ARPANET, e de repente, você tinha este ambiente onde ninguém detinha todas as chaves e nenhum único interveniente estava a tomar todas as decisões.

Apareceu nos fundamentos:

TCP/IP, FTP, Telnet, Usenet newsgroups e DNS não se tratavam de prender alguém num único local. Havia pouco incentivo para impor controlos rigorosos ou hierarquias.

Por exemplo, o Usenet espalha mensagens de forma totalmente descentralizada P2P. A autoridade de nomeação delegada do DNS em uma hierarquia distribuída, mas cada componente ainda age como cliente e servidor em algum grau.

Tudo isso reforçou o princípio original:

uma rede que não se trata apenas de um grande jogador definindo as regras, mas sim de um sistema onde qualquer um pode se conectar e participar.

Mas nos anos 90, a World Wide Web e os navegadores mudaram todo o jogo.

A página recriada do primeiro site (Imagem: CERN)

A Ascensão do Modelo Cliente/Servidor

Tim Berners-Lee: O Visionário por Trás da World Wide Web

À medida que a base de usuários da Internet aumentou, as suposições originais em torno da participação aberta e da confiança mútua começaram a mostrar rachaduras

A World Wide Web, introduzida em 1989-1991, foi construída com base em padrões abertos (HTTP, HTML) deliberadamente colocados no domínio público. Em sua forma mais inicial, a Web tornou trivial para indivíduos, pequenas organizações ou qualquer pessoa com um modem e hospedagem criar um site.

A infraestrutura ainda era em grande parte ‘plana’ e descentralizada, com inúmeras páginas da web independentes ligadas entre si em uma federação solta.

Mas nos anos 90 algo se tornou realmente popular.

Foi quando ‘Web Browsing’ se tornou a ‘aplicação matadora’.

Os websites tornaram-se vitrines, órgãos de informação e centros de entretenimento. A pessoa comum não estava a executar o seu próprio servidor nem a alojar as suas próprias páginas.

A página inicial da Netscape em 1994, apresentando sua mascote Mozilla, como visto no NCSA Mosaic 3.0

[Screenshot: Alex Pasternack /OldWeb.today]

Eles executaram navegadores da web (clientes), primeiro com aqueles modems lentos, depois banda larga, para buscar conteúdo de grandes servidores web conhecidos. De repente, hospedar grandes quantidades de dados e configurar sites de comércio eletrônico ou mecanismos de pesquisa se tornou algo grandioso.

Os primeiros motores de busca, como AltaVista, Yahoo! e, mais tarde, o Google, surgiram para ajudar as pessoas a navegar pelo mundo online em rápida expansão.

O efeito de rede tornou-se pronunciado: quanto mais pessoas usavam um motor de busca, melhor ele podia refinar seus modelos de indexação e publicidade, reforçando sua dominância.

O algoritmo PageRank do Google transformou-o numa porta única para a vastidão da web.

Isso impulsionou dinheiro e atenção para grandes centros de dados, e aqueles que poderiam expandir e lidar com essas cargas massivas saíram na frente.

À medida que os Provedores de Serviços de Internet surgiram para atender a milhões de novos usuários, a infraestrutura naturalmente se otimizou para a entrega downstream.

As velocidades de download são mais rápidas do que as velocidades de upload (conexões de banda larga assimétricas como ADSL ou cabo) fazem sentido econômico porque a maioria dos usuários consome mais do que produz. A rede ‘aprendeu’ que a maioria dos pontos finais era apenas clientes.

E à medida que a base de usuários da Internet cresceu, as suposições originais do design em torno da participação aberta e da confiança mútua começaram a mostrar falhas.

Segurança, Firewalls e portões fechados

“Liberdade e abertura sem salvaguardas podem convidar abusos que nos obrigam a construir muros mais altos.”

Os protocolos originais não foram construídos para lidar com uma multidão massiva e diversificada, muitos com interesses comerciais ou motivações que testaram a abertura do sistema.

Sem salvaguardas reais, o spam tornou-se um grande problema, explorando esse ambiente aberto.

O design original e aberto tornava cada anfitrião acessível a partir de qualquer outro anfitrião, o que era bom quando a Internet era uma comunidade pequena e confiável.

Mas à medida que crescia, os ataques, as tentativas de hacking e as atividades maliciosas dispararam.

Origem:emailtray.com

Da mesma forma, sem uma maneira de manter o uso de largura de banda justo, algumas aplicações aprenderam a ultrapassar os limites e obter vantagem à custa de outros.

Essas lacunas de design empurraram a Internet para uma maior regulamentação e controle.

Para proteger as redes internas, as organizações implementaram firewalls para bloquear conexões de entrada. A tradução de Endereço de Rede (NAT) isolou ainda mais as máquinas internas atrás de um único endereço IP compartilhado.

Isso limitou a natureza peer-to-peer das comunicações.

Os hosts por trás de NATs e firewalls foram efetivamente forçados a desempenhar apenas o papel de cliente, não sendo mais diretamente acessíveis do mundo externo.

Com o tempo, essas decisões de infraestrutura reforçaram umas às outras.

A Emergência dos gatekeepers

“Um punhado de empresas percebeu que controlar centros de dados e possuir infraestruturas de servidores maciças lhes conferia enormes vantagens competitivas.”

A complexidade e o custo de executar o próprio servidor em casa, juntamente com barreiras técnicas como NAT e firewalls, significavam que menos indivíduos participavam como verdadeiros pares.

Em outras palavras, o ambiente basicamente empurrou a Net para um punhado de gigantes centralizados.

No início dos anos 2000, algumas empresas perceberam que controlar centros de dados e possuir infraestruturas de servidores massivas lhes conferia enormes vantagens competitivas.

Eles poderiam fornecer serviços mais rápidos, confiáveis e convenientes do que um peer aleatório na rede.

Esta tendência estava em esteroides no final dos anos 2000.

Origem:datareportal.com

Motores de busca como o Google, grandes plataformas como a Amazon, gigantes das redes sociais como o Facebook e redes de distribuição de conteúdos construíram infraestruturas massivas que forneceram conteúdos e aplicações a uma velocidade e escala sem precedentes.

Essas grandes empresas também se aproveitaram do “ciclo virtuoso” de dados e algoritmos.

Quanto mais usuários eles atraíam, mais dados eles coletavam, o que lhes permitia refinar seus produtos, personalizar experiências e direcionar anúncios de forma mais precisa. Isso tornou seus serviços ainda mais atrativos, atraindo mais usuários e mais receitas.

Em seguida, o modelo de receita da Internet mudou bastante para a publicidade direcionada.

Com o tempo, esse ciclo de feedback concentrou ainda mais o poder, já que os concorrentes menores lutavam para igualar o investimento em infraestrutura e as vantagens de dados dos grandes players.

Infraestrutura que antes poderia ser executada a partir de um servidor pessoal ou de um centro de dados local, está cada vez mais migrando para a nuvem.

Gigantes como a Amazon (AWS), a Microsoft (Azure) e o Google Cloud agora hospedam a espinha dorsal de grande parte da Internet. Esta mudança ocorreu porque executar infraestruturas de grande escala, seguras e confiáveis tornou-se tão complexo e intensivo em capital que apenas algumas empresas podiam fazê-lo de forma eficiente.

Startups e até empresas estabelecidas acharam mais barato e simples confiar nesses grandes fornecedores de nuvem.

Serviços como CDNs (como Cloudflare ou Akamai) e resolutores de DNS também gravitaram em direção a alguns grandes players.

A complexidade e as vantagens de custo dessas soluções gerenciadas significaram menos motivos para as organizações “implantarem sua própria” infraestrutura.

Gradualmente, os alicerces descentralizados, como pequenos ISPs, hospedagem independente e roteamento localizado, deram lugar a um modelo em que a maioria do tráfego e dos serviços depende de um número reduzido de intermediários principais.

O Resultado: Poder Concentrado em Poucas Mãos

“Os grandes jogadores não começaram como malvados; eles apenas otimizaram para conveniência, desempenho e lucro.

Foi o resultado natural das escolhas de design arquitetônico iniciais na rede subjacente.

Com escala e centralização veio mais poder e controle.

Grandes plataformas estabelecem seus próprios termos de serviço, determinando que conteúdo os usuários podem ver ou postar e como seus dados serão coletados ou vendidos. Os usuários tinham menos alternativas se não gostassem dessas políticas.

Com o tempo, os algoritmos de recomendação dessas plataformas e as políticas de conteúdo tornaram-se árbitros de facto do discurso público.

Paradoxalmente, o que começou como uma rede aberta e descentralizada que permitia a livre troca de ideias e conteúdo agora muitas vezes encaminha informações por alguns portais corporativos.

Agora, em alguns aspectos, essas empresas exercem um poder comparável ao dos governos: elas podem moldar o discurso público, influenciar o comércio e controlar ecossistemas inteiros de desenvolvedores de terceiros.

Uma rede originalmente projetada para interconexão livre e de igual para igual agora orbita em torno de centros corporativos poderosos que podem moldar e controlar grande parte da experiência online.

Este não foi algum grande esquema para concentrar poder. Nem essa situação resultou de uma única “virada errada”.

Os grandes jogadores não começaram sendo maus; eles apenas otimizaram a conveniência, o desempenho e o lucro. Foi o resultado natural das primeiras escolhas de design arquitetônico na rede subjacente.

Essas escolhas não anteciparam como um público muito mais amplo e comercialmente orientado usaria o sistema e o levaria além de seus parâmetros de design iniciais.

Com o tempo, essas escolhas se acumularam em um sistema onde algumas empresas dominam.

A mesma coisa está acontecendo diante dos nossos olhos na indústria descentralizada.

O caminho para a centralização é pavimentado com soluções “temporárias”

“A atração pela centralização nem sempre é resultado de intenção maliciosa; muitas vezes, é uma tentativa de resolver problemas de um sistema que nunca foi projetado para se manter descentralizado em grande escala.”

Assim como a Internet primitiva se afastou de seus ideais ponto a ponto e caiu nas mãos de alguns grandes jogadores, as tecnologias de blockchain e “descentralizadas” de hoje correm o risco de seguir o mesmo caminho.

Isto é mais fácil de ver com as tentativas da Ethereum de escalar.

Taxas elevadas e baixa capacidade de processamento levaram os desenvolvedores a adotar soluções de Camada 2 (L2): rollups que agrupam transações fora da cadeia e depois as liquidam no Ethereum. Em teoria, esses L2s devem manter a natureza confiável do Ethereum.

Na prática, muitos dependem de um único “sequenciador” (um servidor central que ordena transações) administrado por uma empresa.

Neste momento, uma solução L2 em particular tem a maior atividade e valor total bloqueado, mas também é a mais centralizada,

A ideia é que a descentralização virá um dia, mas já ouvimos isso antes.

Com o tempo, essas soluções “temporárias” têm o hábito de se tornarem permanentes. O mesmo padrão pode surgir com abordagens em camadas futuras; algumas nem sequer se preocupam em prometer qualquer caminho para a descentralização.

Os “logins sociais” podem parecer úteis: eles tornam fácil para as pessoas começarem a usar um serviço sem precisar lidar com chaves privadas ou interfaces complicadas. Mas se esses logins dependem de um componente centralizado, você está confiando novamente em uma empresa para fazer a coisa certa.

É por isso que, quando construímos o zkLogin, o construímos e o integramos de forma confiável. Foi difícil, mas não podemos comprometer e introduzir centralização para conveniência.

Um padrão semelhante surgiu no ecossistema NFT.

Um único mercado dominante tornou-se o local principal para vendas secundárias, capturando a maior parte do volume de negociação e efetivamente se tornando a plataforma de facto.

Há pouco tempo, este mercado decidiu parar de aplicar pagamentos de royalties em vendas secundárias.

Sim, aumentou o volume de negociação, mas prejudica os criadores que dependiam desses royalties como uma fonte chave de renda.

Este é um claro exemplo das consequências quando plataformas centralizadas podem modificar as regras sempre que desejam.

O domínio deles também se estendeu além da negociação, já que muitos projetos também dependiam de suas APIs e infraestrutura.

Quando essa plataforma centralizada teve falhas, todo o ecossistema sentiu o impacto, expondo a profunda dependência que havia se formado.

Mas por que isso continua acontecendo?

Porque os usuários desejam experiências rápidas, baratas e fáceis. Os desenvolvedores, sob pressão, muitas vezes recorrem a soluções familiares e confiáveis. Essas escolhas são mais simples e rápidas, mas podem introduzir pontos de controle que minam a descentralização.

Nenhum desses passos começa como grandes planos de monopolizar. São apenas respostas práticas a desafios técnicos e de mercado difíceis.

Mas com o tempo, esses “curativos” se tornam incorporados no DNA do sistema, criando uma estrutura onde alguns jogadores detêm as chaves.

É por isso que esses sistemas devem ser projetados desde o início para os construtores, não apenas para os consumidores.

Construindo para Construtores, Não Apenas Consumidores

“Se eu tivesse perguntado às pessoas o que elas queriam, elas teriam dito cavalos mais rápidos.” - Henry Ford

A maioria dos consumidores apenas deseja uma versão melhor do que já têm.

Mas quando apenas perseguimos essas melhorias de curto prazo, corremos o risco de acabar com sistemas que parecem descentralizados na superfície, mas ainda têm alguns atores-chave controlando tudo.

Se realmente quisermos evitar repetir os erros que levaram aos gatekeepers digitais de hoje, precisamos nos concentrar nos criadores do futuro, nos construtores, não apenas nos consumidores.

É por isso que sempre digo à minha equipa que os consumidores vão sempre pedir um cavalo mais rápido; são os construtores que imaginam o carro.

0:00 / 0:38

Com os blocos de construção certos, os desenvolvedores podem lançar plataformas que não são forçadas a se centralizar por uma questão de conveniência. Eles podem criar sistemas onde nenhuma entidade única possa dominar ou prender os usuários, garantindo que os benefícios fluam de forma mais equitativa para todos os participantes.

É por isso que esses sistemas devem ser projetados desde o início para reforçar a descentralização, mesmo quando precisam escalar para um nível de internet.

Dívida Técnica vs Dívida de Design

A dívida técnica pode ser resolvida com refatoração; a dívida de design muitas vezes exige um reset total.

Desde os meus primeiros anos a trabalhar em sistemas que escalam para bilhões de utilizadores, uma lição ficou comigo: uma vez que um sistema se torna crucial para a missão, não se pode simplesmente desmantelar tudo e reconstruir sem causar uma perturbação massiva.

O momento em que milhões de usuários dependem dos comportamentos e pressupostos arraigados do seu sistema, mesmo a proposta de mudanças arquitetônicas radicais se torna inviável.

Isso quebraria aplicativos, modelos de negócios e a confiança de comunidades inteiras construídas por cima.

Este é o conceito de “dívida de design” no seu estado mais severo.

Não se trata apenas da limpeza do código; trata-se de escolhas arquitetônicas fundamentais que ditam como a confiança, o poder e o valor fluem através da rede.

Nos primeiros dias desta indústria, o chamado “trilema de blockchain ou escalabilidade,” a ideia de que não se pode ter descentralização, segurança e escalabilidade ao mesmo tempo, era tratada como uma lei da natureza.

As pessoas construíram em cima dessa suposição, acreditando que era tão imutável quanto a gravidade. Mas não era.

Originou-se de arquiteturas iniciais com falhas: estados globais compartilhados maciços, modelos de dados limitados que tornavam impossível o paralelismo e a escalabilidade modular.

A única maneira de avançar é agrupar todas as transações juntas, forçando todos os participantes a lutarem pelos mesmos recursos limitados, independentemente do que estão fazendo. O resultado? Leilões ineficientes para espaço de bloco que aumentam os custos durante picos de demanda e não isolam a congestão onde ela realmente ocorre.

Nestas condições, adicionar camadas (como L2s que dependem de sequenciadores centralizados ou ativos comprimidos que dependem de armazenamento centralizado) apenas tapou os buracos.

Cada correção destinada a resolver questões de curto prazo muitas vezes adiciona mais complexidade e mais pontos de controle centralizado, afastando-se ainda mais da visão original.

É assim que a dívida de design se acumula em uma forma de “gravidade técnica” que puxa tudo em direção à centralização.

Mesmo sistemas que nunca tiveram a intenção de serem porteiros acabam reforçando estruturas hierárquicas porque sua arquitetura fundamental exige isso. Uma vez que isso acontece, o caminho de volta para um estado verdadeiramente descentralizado e sem confiança é bloqueado por interesses arraigados e inércia infraestrutural.

A lição é clara: tens de acertar na arquitetura desde o início.

Isso significa escolher modelos de dados que não agrupem tudo em um único estado global, usando soluções de armazenamento que sejam verificáveis sem confiar em um intermediário, e escolhendo uma camada de rede que não dependa de um punhado de intermediários poderosos.

Trata-se de reimaginar toda a pilha de tecnologia desde o primeiro dia.

Começar com o Fundamental Certo Desde o Primeiro Dia

A única verdadeira cura para a dívida de design é não acumulá-la em primeiro lugar.

Quando falamos sobre construir infraestrutura que não pode ser malévola, estamos realmente falando sobre fazer as escolhas arquitetônicas corretas desde o primeiro dia.

Por isso, quando projetamos Sui, quisemos incorporar esses princípios fundamentais desde o primeiro dia.

Isto permite aos desenvolvedores construir aplicações escaláveis, seguras e amigáveis sem se curvarem para trás ou dependerem de muletas centralizadas.

Considere o próprio modelo de programação:

A abordagem centrada no objeto da Sui é uma saída deliberada dos paradigmas baseados em contas que têm dominado muitas blockchains.

Modelo de programação centrado em objetos

No centro da filosofia de design da Sui está o modelo de programação centrado em objetos.

Num mundo onde os desenvolvedores de Web2 naturalmente pensam em termos de objetos, como arquivos, registros e ativos, não faz sentido reduzir tudo a um modelo de conta monolítico.

Fazer isso obriga os desenvolvedores a adotar padrões de pensamento não naturais. Isso introduz complexidade propensa a erros.

O modelo de programação centrado em objetos alinha-se naturalmente com a forma como os engenheiros do Web2 já raciocinam sobre o software.

Os objetos funcionam como cidadãos de primeira classe, tornando simples representar ativos, definir regras e evitar armadilhas comuns, como bugs de reentrância, sem código complicado e sem sentido.

Este modelo familiar reduz drasticamente a sobrecarga conceptual e armadilhas comuns como a reentrância. Em vez de escrever verificações de rotina ou barreiras de proteção complexas para evitar exploits, os desenvolvedores dependem do Move VM para garantir a segurança ao nível de tempo de execução.

Como resultado, o código é mais legível, seguro e mais fácil de entender.

É uma ponte direta da mentalidade orientada a objetos da Web2 para o ambiente sem confiança da Web3, tornada possível ao começar com as suposições corretas desde o início.

Escalando por Design, Não com Fita Adesiva

Mas um grande modelo de programação não significa nada se ele desmorona sob carga.

Desde o início, Sui foi construído para lidar com carga do mundo real. Foi projetado para escalar horizontalmente mantendo a composabilidade atômica síncrona.

O modelo de objeto do sistema dá ao Sui uma compreensão detalhada de quais partes do estado cada transação toca, permitindo a execução paralela em escala. Isso contrasta fortemente com os sistemas baseados em EVM, que precisam bloquear o estado global inteiro. Isso torna tudo mais lento e incentiva soluções centralizadas para descarregar o volume de transações.

Com Sui, cada objeto é efetivamente sua própria shard. Precisa de mais capacidade? Adicione mais potência computacional para lidar com a carga.

O Protótipo Pilotfish:https://blog.sui.io/pilotfish-execution-scalability-blockchain/

Os desenvolvedores não precisam se preocupar com a lógica de fragmentação, a conexão de vários domínios ou a montagem de infraestrutura para alcançar escala.

Portanto, o sistema pode lidar com mais tráfego à medida que a rede cresce, mas como garantir uma alocação justa de recursos?

Se um ativo popular ou um dApp monopolizar as atualizações de estado, pode aumentar os custos e degradar a experiência para todos os outros.

Em vez de depender de um único leilão global para o espaço de bloco, onde um aplicativo popular pode aumentar os preços para todos, os mercados locais de taxas permitem que o sistema defina o preço dos recursos a um nível mais fino de granularidade.

Cada “objeto” ou fragmento pode ter sua própria taxa de mercado, garantindo que a congestão em uma área não se espalhe e penalize partes não relacionadas da rede.

Tudo isso está incorporado ao design fundamental da plataforma, garantindo que, mesmo com o aumento da demanda, o sistema não volte aos velhos padrões cansados de porteiros e jardins murados.

Projetar para a descentralização também significa construir a verificabilidade diretamente nas camadas de armazenamento e comunicação.

Se o armazenamento de dados depende de uma única parte confiável, você volta ao ponto de partida. Você precisa de soluções de armazenamento que permitam que qualquer pessoa verifique a integridade dos dados sem depender de um intermediário.

Armazenamento Verificável Sem Hospedeiros Centralizados

Uma aplicação verdadeiramente descentralizada não pode depender de um único fornecedor de nuvem ou de uma base de dados centralizada.

Walrus fornece uma camada de armazenamento descentralizada e verificável comparável em poder e escala a ofertas centralizadas como AWS ou Google Cloud.

Com o Walrus, a verificabilidade dos dados não é uma reflexão tardia, mas uma propriedade intrínseca.

Ao integrar uma camada de armazenamento que é inerentemente verificável e à prova de adulteração, o Walrus garante que os desenvolvedores possam executar sites, hospedar dados e criar aplicativos totalmente descentralizados sem voltar aos padrões centralizados que procuramos evitar.

Em outras palavras, Walrus estende a filosofia de “correção por construção” da execução para o armazenamento, garantindo a integridade de sua aplicação em todas as camadas.

Agora, o design para a descentralização também significa que não deve parar no consenso ou na camada de execução; deve se estender para a própria rede.

As camadas de rede não devem depender de um punhado de ISPs poderosos ou serviços de roteamento. Isso também é centralização.

Uma Camada de Rede Construída para a Descentralização

Networking is another piece of the puzzle often overlooked in Web3.

A roteamento tradicional da Internet é controlado por alguns provedores de serviços de Internet, introduzindo potenciais pontos de estrangulamento e vulnerabilidades.

SCION é um protocolo de rede de próxima geração que desafia esse status quo, tornando o roteamento mais seguro, confiável e resistente ao controle centralizado.

É uma arquitetura de roteamento segura, multipath e interdomínio que pode ser executada lado a lado com a internet atual. É uma reimaginação completa de como os dados se movem entre redes, construída com segurança, controle e desempenho incorporados ao seu núcleo.

Ao integrar SCION ao Sui, estamos garantindo que a rede subjacente não seja um único ponto de falha ou controle.

Nenhuma entidade única consegue ditar o fluxo de dados, e os utilizadores podem confiar que as rotas subjacentes não serão manipuladas ou monopolizadas.

Ao integrar verificabilidade e sem permissão em cada camada, incluindo o modelo de dados, armazenamento e rede, você reduz a área de superfície onde os pontos centrais de controle podem ter influência.

Não está a adicionar a descentralização como uma reflexão posterior; está a incorporá-la na fundação.

Esta simplicidade reduz a complexidade e mantém a porta fechada para soluções alternativas “convenientes”, mas centralizadoras. Mais importante ainda, acertar os fundamentos significa nunca apostar em uma mentalidade de “vamos consertar depois”.

Todos os caminhos levam de volta ao design de som

A descentralização não é uma contagem de validadores. A verdadeira descentralização diz respeito à arquitetura que impede que o poder se concentre num único local.

O ponto de tudo o que exploramos é simples: se quiseres um sistema que não possa ser malévolo, tens de começar com a arquitetura certa.

Se você começar com suposições erradas, nenhuma quantidade de código extra ou truques inteligentes irá te salvar.

Uma arquitetura que recompensa os guardiões. Um modelo de dados que obriga cada ator a competir pelo mesmo recurso escasso. Uma camada de rede projetada em torno de hubs centralizados. Eventualmente, você cairá nos mesmos padrões antigos de controle e hierarquia.

É por isso que os fundamentos arquitetônicos são tão importantes.

A descentralização não se trata apenas de contar quantos nós você tem. A verdadeira descentralização significa projetar no nível fundamental de forma que a confiança, a imparcialidade e a verificabilidade sejam impossíveis de contornar.

Significa construir sistemas onde nem um punhado de baleias nem uma empresa bem financiada possam inclinar silenciosamente o campo de jogo. Trata-se de garantir que cada participante tenha uma chance justa e que nenhum ponto de estrangulamento, nenhuma decisão de design sutil, possa se transformar em centralização descontrolada.

Sui é um exemplo do que acontece quando você projeta com esses princípios em mente desde o primeiro dia, em vez de tentar adaptá-los posteriormente.

Quando toda a pilha, desde o modelo de programação até a camada de consenso, e desde a integração do usuário até a disponibilidade de dados e a camada de rede, reforça a abertura e a neutralidade, você cria um ambiente onde construtores e usuários prosperam em termos iguais.

Ao começar pelos princípios fundamentais e aplicar a descentralização em cada camada, é possível criar uma infraestrutura que se mantém fiel à sua ética, independentemente do seu crescimento.

Construa corretamente desde o início, e não precisará prometer correções futuras ou medidas paliativas.

Você terá uma rede que é inerentemente justa, resiliente e pronta para servir de base para a próxima geração de experiências digitais.

Aviso legal:

1. Este artigo é reeditado a partir de [X]. Todos os direitos autorais pertencem ao autor original [@EvanWeb3]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles tratarão disso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipa de tradução do Gate Learn faz traduções do artigo para outras línguas. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.