À medida que o ecossistema blockchain está a expandir-se e a amadurecer, está a surgir uma variedade de arquiteturas de rede diferentes. Nos últimos anos, redes de consenso simples com blocos vazios transformaram-se em sistemas complexos que dependem de camadas de infra-estrutura para permitir uma experiência funcional e interoperável tanto para programadores como para utilizadores.

Rumo à Modularidade

Uma tendência para uma arquitetura modular pode ser observada tanto em ecossistemas blockchain específicos de aplicações como o Cosmos, bem como em plataformas de contratos inteligentes de uso geral, como o Ethereum. As aplicações bem-sucedidas no Ethereum estão historicamente a depender de uma variedade de middlewares adicionais para fornecer produtos úteis e uma experiência de utilizador superior.

Exemplos de tais middlewares incluem oráculos (ex. Chainlink), automação (ex. Gelato), redes de indexação (ex. The Graph), bem como protocolos de interoperabilidade (ex. Buraco de minhoca). Essas ferramentas assumem a forma de um protocolo separado com a sua própria rede de confiança: um conjunto de regras, operadores e, na maioria dos casos, economia simbólica - ou mesmo são fornecidas de forma centralizada. Um exemplo de uma aplicação cripto que encontrou adequação ao mercado do produto são os mercados monetários DeFi, como o Aave:

Uma representação de alto nível do fluxo de liquidação do protocolo de empréstimo Aave; uma interação exemplar de diferentes pilhas interagindo umas com as outras.

O Caminho para Repovoamento

Além do middleware, as arquiteturas modulares também podem ajudar a dimensionar o rendimento dos sistemas blockchain dividindo a funcionalidade principal em diferentes camadas ou simplesmente através da escala horizontal (i.e. lançando mais cadeinas/rollups). Esta abordagem contrasta com a visão original do “computador mundial” de uma única máquina de estado composável que lida com tudo. Neste ponto, um design integrado e monolítico está a ser predominantemente perseguido pelo ecossistema Solana, que procura maximizar o dimensionamento através de várias otimizações a nível de hardware e software.

Arquiteturas monolíticas versus arquiteturas modulares.

Um dos problemas centrais num paradigma modular de blockchain é que acaba com muitas redes de confiança separadas com os seus próprios tokens e suposições de segurança. Isto é especialmente um problema, uma vez que para comprometer uma aplicação, um invasor muitas vezes só precisa comprometer a rede com o mínimo de segurança económica.

Além disso, a complexidade de iniciar uma nova rede de confiança e a interoperabilidade entre elas são problemas que impactam a experiência do programador e do utilizador no paradigma modular. Assim, começámos a ver surgirem modelos que procuram permitir que os programadores alavanquem os operadores de outra rede em troca de uma quota de taxa e muitas vezes outros incentivos. O espaço de design desses modelos de segurança partilhada é grande e remonta aos primeiros designs de sharding no Ethereum e ao modelo de leilão de parachain Polkadot. Exemplos mais recentes incluem reconfiguração defendida pelo Eigenlayer , conceitos baseados no Cosmos de Interchain Security e Mesh Security, sub-redes Avalanche, bem como sequenciamento partilhado.

No nível mais profundo, estas abordagens são comparáveis e tentam alcançar um resultado semelhante, que é a redução do custo de operação e o aumento da segurança para os programadores de aplicações, alargando o âmbito do trabalho e adicionando compromissos adicionais exigidos pelos operadores de nós para assinarem. Em termos gerais, existem duas maneiras de como os protocolos podem delegar mão de obra adicional aos operadores:

Forçado

Um protocolo pode exigir que os operadores operem infraestruturas adicionais (ex. camadas de execução adicionais ou middlewares) para poder participar. Este artigo refere-se a infraestruturas adicionais como “sub-redes”. Um dos primeiros exemplos práticos deste padrão no espaço cripto foi a rede Terra, onde os validadores tinham de executar binários de middleware oracle adicionais aos binários de consenso já existentes. Esta é também a abordagem adotada pela implementação inicial do Interchain (Replicated) Security, onde - após uma votação de governação bem-sucedida - todo o conjunto validador de uma cadeia Cosmos (com algumas ressalvas) tem de correr e optar por penalidades adicionais de corte relativas a uma chamada cadeia de consumidores separada. As abordagens forçadas diminuem a flexibilidade e aumentam o custo da infraestrutura e a pressão sobre os operadores de nós. Também proporcionam benefícios para a interoperabilidade entre sub-redes, bem como servem como um mecanismo de acumulação de valor para o token de rede principal, razão pela qual são um design popular.

Opção de adesão

O protocolo pode permitir que os operadores de nós optem por sub-redes específicas ou definam funções específicas nas quais podem optar. Com este método, a flexibilidade para os operadores de nós é mantida, permitindo assim melhorias na eficiência e permitindo uma participação mais ampla aumentando a descentralização. Por outro lado, existem implicações para a interoperabilidade da sub-rede e os pressupostos de segurança em geral. O restaking de camada interna é o principal exemplo de um design opt-in que procura expandir a funcionalidade fornecida pelos operadores de nós Ethereum.

Visualização das diferentes abordagens de agregação laboral. Nos modelos forçados, todos os 3 operadores precisam de operar infraestruturas para as redes A e B para receberem recompensas. Num design opt-in como reconfiguração, os operadores escolhem as redes/funções que suportam, neste exemplo o operador 1 opta pela rede B & C, enquanto o operador 2 opta pela rede A & B (AVS na terminologia de Camada Própria).

A Perspectiva do Operador

Como vimos, o ecossistema modular emergente permitiu uma inovação em ritmo acelerado e trouxe aplicações poderosas para o espaço criptográfico. Este ecossistema em expansão leva a topologias de rede complexas que apresentam várias compensações aos fornecedores de infraestruturas que precisam de tomar decisões sobre as redes que suportam com base nos seus recursos disponíveis e cálculos de custo e risco/recompensa específicos da rede.

A seguir, estarei a explorar as compensações inerentes aos modelos de segurança partilhada na perspetiva de dois tipos de operadores de infraestrutura: stakers individuais e empresas fornecedoras de staking profissional.

A vista do Solo Staker

Os stakers individuais são definidos como indivíduos que querem participar na segurança das redes que suportam executando a infraestrutura na sua própria configuração e predominantemente com os seus próprios tokens.

A visão individual dos modelos de segurança partilhados.

The Sking Provider View

Os fornecedores de staking profissionais são entidades incorporadas com fins lucrativos que operam infraestruturas para uma variedade de redes de prova de participação e dependem de delegações de detentores de tokens, como fundações, investidores institucionais e detentores de tokens de retalho, bem como agregadores como protocolos de liquidez de staking.

A visão do fornecedor de staking sobre modelos de segurança partilhados.

Conclusão

Para evitar a fragmentação da segurança, o ecossistema cripto conceituou diferentes modelos de partilha de segurança entre redes blockchain. Os modelos opt-in como o restaking fornecem flexibilidade ao permitir que os operadores se especializem e tomem decisões económicas mais granulares, enquanto nos modelos forçados a rede em geral está a fazer escolhas para todos os seus operadores subjacentes.

Esta flexibilidade pode ajudar a criar um ecossistema mais diversificado e descentralizado, por um lado, porque se torna viável para operadores mais pequenos participarem e, por outro lado, operadores maiores são capazes de fornecer produtos de staking diferenciados com base na sua curadoria de sub-rede.

Finalmente, os protocolos de (re) staking líquido e outros agregadores poderão no futuro desempenhar um papel coordenador na atribuição de mão-de-obra a operadores que procuram fornecer a melhor experiência do utilizador e retornos ajustados ao risco aos detentores de tokens, abstraindo a complexidade da sub-rede e da escolha do operador.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [espelho]. Todos os direitos de autor pertencem ao autor original [Felix Lutsch]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.