Anos atrás, 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 toda uma indústria.

Mesmo plataformas lançadas com as melhores intenções de serem abertas, neutras e livres de controle podem se transformar em 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 definidas desde o início.

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

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

Já vimos esse filme antes

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

É uma verdade sutil, porém 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. Olhamos para o Bitcoin, Ethereum e outros como formas de escapar das estruturas de poder antigas.

A narrativa foi direta: retomar o controle, cortar os 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 atuar sobre esses sistemas ‘descentralizados’.

Mas como a Internet se tornou centralizada?

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

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

Você precisa observar como ele passou de seus começos idealistas para um ecossistema altamente centralizado.

A Internet Inicial: Quando o Peer-to-Peer Era a Norma

No início, 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 basicamente começou 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 nenhum local que caísse pudesse levar tudo o mais com ele.

Esta rede foi projetada deliberadamente para ser descentralizada.

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

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

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

Nos anos 70 e 80, as universidades e os laboratórios de pesquisa se conectaram por meio do NSFNET e do ARPANET, e de repente você tinha esse ambiente em que ninguém detinha todas as chaves e nenhum jogador único estava ditando todas as regras.

Apareceu nos fundamentos:

TCP/IP, FTP, Telnet, grupos de discussão Usenet e DNS não se tratavam de prender alguém em um único local. Havia pouco incentivo para impor controles ou hierarquias rígidas.

Usenet, por exemplo, espalhava mensagens de forma totalmente descentralizada P2P. O DNS delegava a autoridade de nomeação em uma hierarquia distribuída, mas cada componente ainda atuava como cliente e servidor em algum grau.

Isso tudo reforçou aquele princípio original:

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

Mas no início dos anos 90, a World Wide Web e os navegadores mudaram todo o jogo.

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

O Surgimento 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 cresceu, pressupostos originais em torno da participação aberta e da confiança mútua começaram a mostrar falhas”

A World Wide Web, introduzida em 1989-1991, foi construída sobre padrões abertos (HTTP, HTML) deliberadamente colocados em 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 em uma federação solta.

Mas nos anos 90 algo se tornou muito popular.

Foi quando ‘Navegação na web’ se tornou o ‘aplicativo matador’.

Websites tornaram-se vitrines, veículos de notícias e centros de entretenimento. A pessoa média não estava executando seu próprio servidor ou hospedando suas próprias páginas.

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

[Captura de tela: Alex Pasternack /OldWeb.today]

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

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

O efeito de rede tornou-se pronunciado: quanto mais pessoas usavam um mecanismo de busca, melhor ele podia refinar seus modelos de indexação e publicidade, reforçando seu domínio.

O algoritmo PageRank do Google transformou-o em um único gateway para a vastidão da web.

Isso impulsionou dinheiro e atenção para grandes centros de dados, e aqueles que conseguiam escalar 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 otimizou a entrega downstream.

Velocidades de download mais rápidas do que de upload (conexões assimétricas de banda larga como ADSL ou cabo) faziam sentido econômico porque a maioria dos usuários consumia mais do que produzia. A rede ‘aprendeu’ que a maioria dos pontos finais eram apenas clientes.

E à medida que a base de usuários da Internet aumentou, as suposições do design original sobre participação aberta e confiança mútua começaram a mostrar rachaduras.

Segurança, Firewalls e portões fechados

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

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

Sem proteções reais, o spam se tornou um grande problema, explorando esse ambiente aberto.

O design original e aberto permitia que cada host fosse alcançável a partir de qualquer outro host, o que era bom quando a Internet era uma comunidade pequena e confiável.

Mas à medida que cresceu, aumentaram os ataques, tentativas de hacking e atividades maliciosas.

Fonte:emailtray.com

Da mesma forma, sem alguma maneira de manter o uso da largura de banda justo, algumas aplicações aprenderam a empurrar os limites e obter uma vantagem às custas 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 as conexões de entrada. A Tradução de Endereços de Rede (NAT) isolou ainda mais as máquinas internas por trás de um único endereço IP compartilhado.

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

Hosts behind NATs and firewalls were effectively forced into a client-only role, no longer directly addressable from the outside world.

Com o tempo, essas decisões de infraestrutura se reforçaram mutuamente.

A Emergência dos gatekeepers

“Um punhado de empresas percebeu que controlar centros de dados e possuir infraestruturas de servidores massivas lhes deu enormes vantagens competitivas.”

A complexidade e o custo de executar o próprio servidor em casa, aliados a barreiras técnicas como NAT e firewalls, significavam que menos pessoas participavam como verdadeiros pares.

Em outras palavras, o ambiente praticamente 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 maciças lhes conferia enormes vantagens competitivas.

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

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

Origem:datareportal.com

Mecanismos de busca como o Google, plataformas grandes como a Amazon, gigantes das redes sociais como o Facebook e redes de distribuição de conteúdo construíram infraestruturas massivas que entregaram conteúdo e aplicativos em velocidade e escala sem precedentes.

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

Quanto mais usuários eles atraíram, mais dados eles reuniram, o que lhes permitiu refinar seus produtos, personalizar experiências e direcionar anúncios com mais precisão. Isso tornou seus serviços ainda mais atraentes, atraindo mais usuários e mais receita.

Então, o modelo de receita da Internet mudou drasticamente para a publicidade direcionada.

Com o tempo, esse ciclo de retroalimentação concentrou ainda mais poder, já que os concorrentes menores lutaram para acompanhar o investimento em infraestrutura e as vantagens de dados dos grandes jogadores.

Infraestrutura que antes podia ser executada a partir de um servidor pessoal ou de um centro de dados local, cada vez mais se mudou para a nuvem.

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

Startups e até mesmo empresas estabelecidas acharam mais barato e mais simples depender desses grandes provedores de nuvem.

Serviços como CDNs (como Cloudflare ou Akamai) e resolução de DNS também se concentraram em alguns grandes jogadores.

As vantagens de complexidade e custo dessas soluções gerenciadas significavam menos motivos para as organizações “construírem sua própria” infraestrutura.

Gradualmente, os fundamentos descentralizados como pequenos provedores de internet, hospedagem independente e roteamento localizado cederam lugar a um modelo em que a maioria do tráfego e dos serviços depende de um número muito pequeno de intermediários principais.

As consequências: poder concentrado em poucas mãos

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

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

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

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

Ao longo do tempo, os algoritmos de recomendação e políticas de conteúdo dessas plataformas se tornaram árbitros de fato do discurso público.

Paradoxalmente, o que começou como uma rede aberta e descentralizada que capacitava a livre troca de ideias e conteúdo agora frequentemente direcionava informações através de alguns gateways corporativos.

Agora essas empresas, em alguns aspectos, possuem 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 em nível de pares agora orbita em torno de centros corporativos poderosos que podem moldar e controlar grande parte da experiência online.

Isso não foi algum grande esquema para concentrar poder. Nem essa situação decorreu de uma única “volta errada”.

Os grandes players não começaram como malévolos; eles apenas otimizaram para conveniência, desempenho e 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 mais 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 um punhado de empresas domina.

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ções maliciosas; muitas vezes, é uma tentativa de corrigir problemas de um sistema que nunca foi construído para se manter descentralizado em grande escala.”

Assim como a internet inicial se afastou de seus ideais de peer-to-peer e caiu nas mãos de alguns grandes players, as tecnologias de blockchain e “descentralizadas” de hoje correm o risco de seguir o mesmo caminho.

Isso é mais fácil de ver com as tentativas do Ethereum de escalar.

Altas taxas 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 sem confiança do Ethereum.

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

No 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 um jeito de se tornarem permanentes. O mesmo padrão pode surgir com abordagens em camadas futuras; alguns nem se incomodam em prometer qualquer caminho para a descentralização.

“Logins sociais” podem parecer úteis: eles facilitam 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 única empresa para fazer a coisa certa.

Por isso, 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 se tornou o principal local para vendas secundárias, capturando a maior parte do volume de negociação e efetivamente se tornando a plataforma de facto.

Não faz muito tempo, este mercado decidiu parar de exigir pagamentos de royalties nas vendas secundárias.

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

Este é um claro exemplo das consequências quando plataformas centralizadas podem modificar as regras a qualquer momento que desejarem.

Seu domínio também se estendeu além das negociações, pois muitos projetos também dependiam de suas APIs e infraestrutura.

Quando esta plataforma centralizada teve interrupções, 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, frequentemente 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. Eles 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 quer apenas uma versão melhor do que eles já têm.

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

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

É por isso que sempre digo à minha equipe que os consumidores sempre pedirão 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 à centralização em prol da conveniência. Eles podem criar sistemas nos quais nenhuma entidade única pode 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 ser dimensionados para um nível de internet.

Dívida técnica vs Dívida de design

A dívida técnica pode ser corrigida com refatoração; a dívida de design muitas vezes exige uma reinicialização total.

Desde os meus primeiros anos trabalhando em sistemas que escalavam para bilhões de usuários, uma lição ficou comigo: uma vez que um sistema se torna crucial para a missão, você não pode simplesmente derrubá-lo e reconstruir sem causar uma interrupção massiva.

O momento em que milhões de usuários dependem dos comportamentos e pressupostos arraigados do seu sistema, até mesmo propor mudanças arquiteturais 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” em sua forma mais severa.

Isso não é apenas sobre limpeza de código; trata-se de escolhas arquiteturais fundamentais que ditam como a confiança, o poder e o valor fluem pela rede.

Nos primeiros dias desta indústria, o chamado “trilema blockchain ou escalabilidade”, a ideia de que você não 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 falhas: estados globais compartilhados massivos, modelos de dados limitantes 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 lutar 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 conseguem isolar a congestão onde ela realmente ocorre.

Sob essas condições, adicionar camadas (como L2s que dependem de sequenciadores centralizados ou ativos comprimidos que dependem de armazenamento centralizado) apenas disfarçou as rachaduras.

Cada patch destinado a corrigir problemas 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 atrai tudo para a centralização.

Até mesmo sistemas que nunca pretendiam ser 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: você tem que acertar a arquitetura desde o início.

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

Trata-se de reimaginar todo o stack de tecnologia desde o primeiro dia.

Acertando os Fundamentos Desde o Primeiro Dia

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

Quando falamos em construir infraestrutura que não pode ser maléfica, estamos realmente falando em 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.

Isso permite aos desenvolvedores construir aplicações escaláveis, seguras e amigáveis ao usuário sem se curvar para trás ou depender de muletas centralizadas.

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

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

Modelo de programação centrado em objetos

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

Em um mundo em que os desenvolvedores do 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 força os desenvolvedores a padrões de pensamento não naturais. Isso introduz complexidade propícia a erros.

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

Os objetos servem como cidadãos de primeira classe, tornando simples representar ativos, definir regras e evitar armadilhas comuns, como bugs de recursividade, sem código complicado.

Esse modelo familiar reduz drasticamente a sobrecarga conceitual e armadilhas comuns como a reentrância. Em vez de escrever verificações de rotina ou barreiras complexas para evitar exploits, os desenvolvedores contam com o Move VM para garantir a segurança no nível 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 do Web2 para o ambiente sem confiança do Web3, possibilitada ao começar com as suposições corretas desde o início.

Escalando por Design, Não por Durex

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

Desde o início, Sui foi construído para lidar com cargas do mundo real. Foi projetado para escalar horizontalmente enquanto mantém a composabilidade atômica síncrona.

O modelo de objeto do sistema dá a Sui um entendimento detalhado 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 travar o estado global inteiro. Isso desacelera tudo 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 poder 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 interligação de vários domínios ou a criação de infraestrutura para alcançar escalabilidade.

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

Se um ativo popular ou um dApp domina o mercado de 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 precifique os recursos em um nível mais fino de granularidade.

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

Tudo está incorporado no design fundamental da plataforma, garantindo que, mesmo à medida que a demanda cresce, o sistema não volte aos velhos padrões cansativos de guardiões e jardins murados.

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

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

Armazenamento Verificável sem hosts centralizados

Um aplicativo verdadeiramente descentralizado não pode depender de um único provedor de nuvem ou de um banco de dados centralizado.

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

Com a verificabilidade do Walrus, os dados não sã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 construir aplicativos totalmente descentralizados sem voltar aos padrões centralizados que buscamos evitar.

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

Agora, projetar para a descentralização também significa que não deve parar na camada de consenso ou execução; deve se estender à 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 ISPs, o que introduz 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, de vários caminhos, interdomínio que pode ser executada lado a lado com a internet atual. É uma reimaginação completa de como os dados se movem pelas redes, construída com segurança, controle e desempenho incorporados ao seu núcleo.

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

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

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

Você não está adicionando a descentralização como um recurso tardio; você está incorporando-a na fundação.

Esta simplicidade reduz a complexidade e mantém a porta fechada para soluções de trabalho “convenientes”, mas centralizadoras. Mais importante ainda, acertar nos 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 a concentração de poder em um único lugar.”

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

Se você começar com suposições erradas, não importa a quantidade de código extra ou truques inteligentes, você não será salvo.

Uma arquitetura que recompensa gatekeepers. Um modelo de dados que força 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 importam tanto.

A descentralização não é apenas uma questão de contar quantos nós você tem. A verdadeira descentralização significa projetar no nível raiz para que a confiança, a justiça e a verificabilidade sejam impossíveis de contornar.

Significa construir sistemas onde nem um punhado de baleias nem uma empresa bem financiada podem 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 desenfreada.

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 incorporação do usuário até a disponibilidade de dados e a camada de rede, reforça a abertura e neutralidade, você cria um ambiente onde os construtores e usuários florescem em termos iguais.

Ao começar pelos primeiros princípios e aplicar a descentralização em cada camada, é possível criar uma infraestrutura que permaneça fiel à sua ética, não importa o quão grande ela cresça.

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

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

Aviso legal:

1. Este artigo foi republicado de [ Erro: O texto de origem está vazio.]. Todos os direitos autorais pertencem ao autor original [@EvanWeb3]. Se houver objeções a esta reedição, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipe Gate Learn faz traduções do artigo em outros idiomas. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.