Camada de segurança compartilhada

O que é uma camada de segurança compartilhada?

Uma camada de segurança compartilhada é um modelo de segurança de blockchain no qual várias chains, serviços, aplicativos ou módulos dependem de um conjunto comum de validadores, staking agrupado ou garantia em restaking, em vez de criarem sua própria segurança do zero.

No mercado cripto, uma camada de segurança compartilhada ajuda novas redes a utilizar ou acessar segurança econômica de um sistema maior que já possui validadores, participantes de staking, governança e infraestrutura de segurança.

A documentação oficial da relay chain da Polkadot descreve a segurança compartilhada como um modelo no qual chains conectadas se beneficiam do Nominated Proof of Stake sem precisar iniciar sua própria segurança.

A documentação oficial do Cosmos Hub Interchain Security descreve a Interchain Security como uma plataforma para lançar chains Cosmos-SDK que podem utilizar o conjunto de validadores, o staking e a comunidade do Cosmos Hub.

A visão geral oficial do EigenLayer descreve o restaking como um sistema que permite aos participantes de staking fornecer segurança a serviços no ecossistema EigenLayer.

Uma camada de segurança compartilhada pode oferecer suporte a appchains, parachains, consumer chains, serviços de disponibilidade de dados, sistemas de oráculos, bridges, infraestrutura de rollups e outras redes cripto que precisam de segurança confiável.

O principal objetivo é reduzir o custo e a dificuldade de lançar uma infraestrutura segura.

Em vez de cada nova chain recrutar seus próprios validadores e criar sua própria economia de tokens para staking, ela pode se conectar a uma base de segurança maior.

Em termos simples, uma camada de segurança compartilhada é uma base de segurança que muitos sistemas cripto podem usar ao mesmo tempo.

Por que as camadas de segurança compartilhada são importantes

As camadas de segurança compartilhada são importantes porque é difícil proteger novas blockchains e serviços de forma independente.

Uma rede pequena com um conjunto de validadores fraco pode ser mais fácil de atacar, censurar, interromper ou manipular.

Uma nova chain pode ter uma tecnologia robusta, mas ainda não conseguir atrair validadores, delegadores, staking, monitoramento, liquidez e participação em governança suficientes.

A segurança compartilhada pode facilitar isso ao permitir que novos sistemas acessem um pool existente de segurança econômica.

Isso pode reduzir os custos iniciais para desenvolvedores e melhorar a segurança dos usuários.

Também pode melhorar a interoperabilidade, pois sistemas protegidos pela mesma camada podem compartilhar regras de mensagens, premissas sobre validadores ou relações de liquidação.

A documentação oficial das parachains da Polkadot afirma que as parachains se beneficiam de segurança compartilhada, interoperabilidade e escalabilidade enquanto se concentram na lógica específica de aplicativos.

A segurança compartilhada é especialmente importante no design modular de blockchains, pois execução, liquidação, consenso, disponibilidade de dados e verificação podem ocorrer em locais diferentes.

Quando essas partes são separadas, as premissas de segurança se tornam mais difíceis de entender para os usuários.

Uma camada de segurança compartilhada oferece a desenvolvedores e usuários uma base mais clara para avaliar quem protege o sistema e o que acontece se os validadores se comportarem de forma inadequada.

Como funciona uma camada de segurança compartilhada

Uma camada de segurança compartilhada funciona conectando vários sistemas a uma única fonte de segurança.

Essa fonte pode ser uma provider chain, relay chain, protocolo de restaking, marketplace de validadores, sistema de staking agrupado ou rede de segurança criptoeconômica.

O sistema conectado geralmente recebe validação, atestação, produção de blocos, disponibilidade de dados, finalidade, verificação de mensagens ou outros serviços de segurança da camada compartilhada.

Validadores ou operadores podem executar software adicional para cada chain ou serviço conectado.

Participantes de staking podem delegar ativos a validadores ou operadores que optam por proteger sistemas adicionais.

O sistema conectado pode pagar recompensas, taxas, inflação ou outros incentivos aos validadores e participantes de staking que o protegem.

Se validadores ou operadores não cumprirem suas obrigações, o modelo de segurança compartilhada poderá aplicar penalidades, slashing, remoção, perda de recompensas ou ação de governança, dependendo do protocolo.

O design exato depende do ecossistema.

Alguns sistemas replicam o conjunto de validadores da provider chain nas consumer chains.

Outros sistemas permitem que apenas um subconjunto de validadores opte por proteger um serviço específico.

Portanto, a camada de segurança compartilhada não é uma tecnologia única, mas uma família de designs que agrupam confiança e segurança econômica.

Provider chain

Uma provider chain é uma blockchain que fornece segurança a outras chains ou serviços.

Na segurança compartilhada no estilo Cosmos, a provider chain pode compartilhar seu conjunto de validadores e staking com consumer chains.

A documentação do Cosmos Hub Interchain Security afirma que o Hub pode permitir que chains utilizem seus validadores, staking e comunidade.

A provider chain geralmente possui um token estabelecido, conjunto de validadores, sistema de governança, economia de staking e reputação.

As consumer chains se beneficiam porque não precisam criar sozinhas uma economia de segurança completa.

A provider chain pode se beneficiar porque as consumer chains podem criar nova demanda, taxas, recompensas e valor para o ecossistema.

Essa relação deve ser projetada cuidadosamente porque os validadores da provider chain assumem deveres adicionais.

Se as consumer chains forem exigentes demais, os validadores poderão enfrentar sobrecarga operacional ou desempenho reduzido.

Se as recompensas forem muito baixas, os validadores poderão não querer participar.

Uma provider chain só é útil quando sua segurança pode ser compartilhada sem enfraquecer o sistema-base.

Consumer chain

Uma consumer chain é uma blockchain que recebe segurança de uma provider chain ou camada de segurança compartilhada.

Uma consumer chain ainda pode ter sua própria lógica de aplicativo, configurações de governança, taxas, modelo de token e experiência do usuário.

O que ela utiliza é parte da estrutura de segurança que valida ou protege seu estado.

Isso pode ajudar uma nova chain a ser lançada mais rapidamente e com uma segurança mais robusta do que conseguiria criar sozinha.

No entanto, uma consumer chain não é livre de riscos apenas por usar segurança compartilhada.

Ela ainda pode apresentar bugs em contratos inteligentes, erros na lógica do aplicativo, risco de oráculo, risco de bridge, risco de governança, baixa liquidez e risco de interface do usuário.

Os usuários também devem verificar quanto da segurança da provider chain realmente se aplica à consumer chain.

Alguns designs exigem que todo o conjunto de validadores valide a consumer chain.

Outros designs permitem apenas um conjunto parcial ou grupo opt-in.

A robustez de uma consumer chain depende dos detalhes do acordo de segurança compartilhada.

Conjunto de validadores

Um conjunto de validadores é o grupo de validadores responsável por produzir, verificar, finalizar ou atestar a atividade da blockchain.

Em uma camada de segurança compartilhada, o conjunto de validadores pode proteger mais de uma chain ou serviço.

Isso pode melhorar a segurança porque uma nova chain pode depender de validadores que já estão economicamente comprometidos e têm experiência operacional.

Também pode criar complexidade operacional, pois os validadores podem precisar executar vários softwares diferentes.

Se os validadores estiverem sobrecarregados, a qualidade da validação poderá cair.

Se muitos sistemas dependerem do mesmo conjunto de validadores, as falhas poderão se tornar correlacionadas.

A diversidade de validadores importa porque a segurança é mais fraca quando muitos validadores são controlados pelo mesmo operador, hospedados na mesma infraestrutura ou expostos ao mesmo bug de software.

A documentação da relay chain da Polkadot observa que a segurança depende não apenas do staking, mas também da quantidade de validadores e de fatores de centralização social ou física.

Um conjunto de validadores compartilhado pode ser poderoso, mas deve permanecer descentralizado, monitorado e devidamente incentivado.

Os usuários devem perguntar quem realmente está validando os sistemas conectados.

Segurança agrupada

Segurança agrupada significa que vários participantes combinam seu staking, trabalho de validação ou garantias econômicas para proteger um sistema.

Em designs de segurança compartilhada, a segurança agrupada pode tornar um novo serviço mais difícil de atacar, pois um invasor precisa superar uma base de segurança maior.

A documentação oficial de termos-chave do EigenLayer descreve a segurança agrupada por meio de restaking como um modelo em que várias partes combinam recursos para fornecer maior segurança a um sistema.

A segurança agrupada pode ser eficiente porque o mesmo capital de segurança pode dar suporte a mais de um serviço útil.

Ela também pode se tornar arriscada se o mesmo capital ficar exposto a condições de slashing demais ou a muitas falhas correlacionadas.

Por isso, a segurança agrupada deve ser avaliada considerando tanto o benefício quanto o ônus.

O benefício é uma proteção compartilhada mais forte.

O ônus é que validadores e participantes de staking podem aceitar mais responsabilidades e mais formas de perder fundos.

A segurança agrupada é atraente, mas não é segurança gratuita.

Cada serviço adicional altera o perfil de risco e recompensa do pool compartilhado.

Restaking e segurança compartilhada

O restaking é um dos mais importantes modelos modernos de segurança compartilhada.

O restaking permite que ativos em staking ou tokens de staking líquido sejam usados para proteger serviços adicionais além da chain-base original.

A visão geral do EigenLayer afirma que o restaking permite aos participantes de staking fazer restaking de ETH nativo ou tokens de staking líquido para fornecer segurança a Autonomous Verifiable Services.

Esses serviços podem incluir disponibilidade de dados, verificação, tarefas semelhantes a oráculos, bridges, coprocessadores e outra infraestrutura que precisa de garantias criptoeconômicas.

Os operadores executam o software necessário para dar suporte a esses serviços.

Participantes de staking podem delegar a operadores ou executar eles mesmos a infraestrutura de operador.

A promessa é eficiência de capital, pois um pool de ativos em staking pode dar suporte a mais de um serviço cripto.

O risco é que serviços adicionais possam acrescentar exposição adicional a slashing, riscos operacionais, de contratos inteligentes e de governança.

O restaking transforma o capital em staking em um recurso de segurança compartilhado.

Os usuários devem entender exatamente quais serviços seus ativos em restaking estão ajudando a proteger.

Autonomous Verifiable Services

Autonomous Verifiable Services, frequentemente chamados de AVSs no ecossistema EigenLayer, são serviços que usam segurança em restaking por meio do EigenLayer.

A visão geral do EigenLayer descreve os AVSs como serviços criados no protocolo que utilizam a segurança compartilhada da Ethereum.

Um AVS pode definir tarefas que os operadores devem executar.

Essas tarefas podem envolver validação, disponibilidade de dados, computação, atestação, mensagens ou outro trabalho verificável.

Os operadores optam por fornecer serviços para AVSs.

Participantes de staking delegam ativos a operadores e aceitam o perfil de risco associado aos serviços selecionados pelo operador.

Um AVS deve definir claramente seus requisitos, recompensas, condições de slashing, regras de monitoramento e lógica de verificação.

Se o design do AVS for fraco, a segurança compartilhada poderá não proteger os usuários como esperado.

Os usuários não devem presumir que todos os AVSs têm o mesmo nível de segurança apenas por usarem um protocolo de segurança compartilhada.

A qualidade do design do serviço ainda importa.

Interchain Security

Interchain Security é uma abordagem de segurança compartilhada do ecossistema Cosmos.

Ela permite que uma consumer chain use a segurança de uma provider chain em vez de começar com um conjunto isolado de validadores.

A documentação do Cosmos Interchain Security a descreve como uma plataforma para lançar chains Cosmos-SDK.

A documentação oficial do Partial Set Security explica que as consumer chains podem usar apenas um subconjunto de validadores da provider chain para obter mais flexibilidade do que no modelo replicado anterior.

Isso significa que a segurança compartilhada pode ser personalizada conforme as necessidades de uma consumer chain.

Uma chain que precisa de mais segurança pode exigir uma participação maior de validadores.

Uma chain menor ou experimental pode escolher um modelo opt-in com menor segurança garantida.

A contrapartida é clara: mais segurança geralmente exige maior comprometimento dos validadores e recompensas mais robustas.

A Interchain Security mostra como a segurança compartilhada pode se tornar uma relação de governança e econômica entre chains.

Também mostra que os usuários precisam verificar quanta segurança da provider chain uma consumer chain realmente recebe.

Segurança compartilhada da Polkadot

A Polkadot é um dos exemplos mais estabelecidos de camada de segurança compartilhada.

A Polkadot usa uma arquitetura de relay chain e parachains, na qual as chains conectadas podem se beneficiar da segurança e interoperabilidade da relay chain.

A documentação da relay chain da Polkadot afirma que as chains Layer 1 conectadas se beneficiam da segurança do Nominated Proof of Stake sem precisar iniciar seu próprio conjunto de validadores.

A documentação das parachains da Polkadot afirma que as parachains herdam a segurança do conjunto de validadores da Polkadot e podem se comunicar por Cross-Consensus Messaging.

Esse modelo ajuda chains específicas para aplicativos a se concentrarem em sua própria lógica, enquanto a relay chain coordena a segurança.

Ele também cria um ambiente de interoperabilidade compartilhada, pois as parachains podem se comunicar com base em premissas comuns.

O modelo da Polkadot não é igual ao restaking ou à Cosmos Interchain Security.

Trata-se de uma arquitetura Layer 0 em que a segurança compartilhada e as mensagens cross-chain são objetivos centrais do design.

Antes de avaliar aplicativos nesse ecossistema, os usuários devem entender a relay chain, os validadores, o coretime, as parachains, a governança e o modelo de mensagens.

A segurança compartilhada é mais forte quando os usuários entendem tanto a base de segurança comum quanto a lógica da chain específica do aplicativo.

Camada de segurança compartilhada vs. blockchain independente

Uma blockchain independente é responsável por sua própria segurança.

Ela deve atrair validadores, participantes de staking, miners, delegadores, operadores de nós, participantes de governança e infraestrutura de monitoramento.

Uma chain com segurança compartilhada pode depender de uma camada de segurança existente para algumas dessas responsabilidades.

Isso pode facilitar o lançamento e a escalabilidade.

No entanto, uma chain independente pode ter mais autonomia e menos dependências externas.

Uma chain com segurança compartilhada pode depender da governança da provider chain, da participação de validadores, de regras de slashing compartilhadas ou de atualizações da camada de segurança.

A contrapartida está entre independência e o início da segurança.

Uma chain independente controla seu próprio destino, mas deve se proteger.

Uma chain com segurança compartilhada recebe ajuda, mas aceita as regras e premissas de outra camada.

Nenhum dos modelos é automaticamente melhor, pois o modelo adequado depende dos objetivos do aplicativo, da tolerância ao risco e das expectativas dos usuários.

Camada de segurança compartilhada vs. sidechain

Uma sidechain é uma blockchain separada conectada a outra chain por uma bridge ou peg.

Uma sidechain frequentemente possui seu próprio conjunto de validadores e suas próprias premissas de segurança.

Uma chain com segurança compartilhada depende mais diretamente de uma camada de segurança comum ou do conjunto de validadores de uma provider chain.

Essa diferença importa porque os usuários frequentemente confundem chains conectadas com chains de segurança compartilhada.

Uma chain pode ser conectada por uma bridge sem compartilhar a segurança dos validadores.

Uma chain pode usar a mesma máquina virtual de outra chain sem compartilhar segurança.

Uma chain pode ter taxas baixas e carteiras conhecidas, mas ainda ser protegida por um conjunto independente menor de validadores.

Segurança compartilhada diz respeito a quem valida e protege o sistema, e não apenas a como os ativos se movem entre sistemas.

Os usuários devem perguntar se a chain herda segurança, aluga segurança, faz restaking de segurança ou apenas transfere ativos por bridge.

A resposta altera o modelo de risco.

Camada de segurança compartilhada vs. rollup

Um rollup é um sistema de escalabilidade que executa transações fora de uma chain-base, enquanto depende da chain-base para liquidação, provas ou publicação de dados, conforme o tipo de rollup.

Uma camada de segurança compartilhada é mais ampla, pois pode proteger vários tipos de serviços, chains e módulos, não apenas a execução de rollups.

Algumas infraestruturas relacionadas a rollups podem usar segurança compartilhada para disponibilidade de dados, sequenciamento, verificação ou mensagens entre rollups.

Outros rollups dependem principalmente de sua chain de liquidação e sistema de provas.

A diferença é importante porque a segurança de um rollup depende da disponibilidade de dados, da validade das provas ou de desafios de fraude, de chaves de atualização, sequenciadores e premissas de liquidação.

A segurança compartilhada pode adicionar outra camada de operadores, participantes de staking, recompensas e condições de slashing.

Um rollup pode usar segurança compartilhada para um componente específico sem que todo o seu modelo de segurança se torne idêntico ao da camada compartilhada.

Os usuários devem verificar qual parte da stack é protegida pela segurança compartilhada.

Desenvolvedores devem evitar alegações vagas de que um rollup é totalmente protegido por uma camada compartilhada se apenas um módulo a utilizar.

Alegações precisas de segurança são essenciais em sistemas cripto modulares.

Camada de segurança compartilhada vs. bridge

Uma bridge move ativos ou mensagens entre chains.

Uma camada de segurança compartilhada protege chains ou serviços por meio de validadores comuns, staking ou garantia em restaking.

Algumas bridges podem usar segurança compartilhada para verificação, mas uma bridge não é automaticamente uma camada de segurança compartilhada.

O risco de bridge inclui bugs em contratos inteligentes, comprometimento de signatários, repetição de mensagens, falha de liquidez e controle de governança.

O risco de segurança compartilhada inclui falha de validadores, design de slashing, concentração de operadores, risco de governança e exposição entre serviços.

Uma bridge pode conectar duas chains que não compartilham segurança alguma.

Uma camada de segurança compartilhada pode apoiar a interoperabilidade, mas sua função principal não é apenas mover ativos.

Ao avaliar aplicativos cross-chain, os usuários devem separar o risco de bridge do risco de segurança compartilhada.

Uma camada de segurança compartilhada robusta ainda pode ser combinada com uma bridge fraca.

Uma experiência segura para o usuário exige validação segura e movimentação segura de ativos.

Segurança econômica

Segurança econômica é o valor em risco que torna os ataques caros.

Em sistemas Proof of Stake, a segurança econômica frequentemente vem de ativos em staking que os validadores podem perder se violarem as regras.

Em uma camada de segurança compartilhada, a segurança econômica pode ser reutilizada ou agrupada entre vários serviços.

Isso pode tornar serviços pequenos mais seguros, pois eles não precisam criar sozinhos um grande orçamento de segurança.

O perigo é que a segurança econômica pode ser superestimada se o mesmo staking for prometido a serviços demais com riscos sobrepostos.

Os usuários devem perguntar quanto staking pode realmente sofrer slashing em uma chain ou serviço específico.

Também devem perguntar se o slashing está ativo, é aplicável, atrasado, mediado por governança ou apenas parcialmente implementado.

A segurança econômica não é apenas um número de destaque.

Ela depende de condições de slashing, liquidez, comportamento dos validadores, estrutura jurídica, contratos inteligentes e valor de mercado.

Uma segurança compartilhada forte exige penalidades e monitoramento confiáveis.

Slashing na segurança compartilhada

Slashing é uma penalidade que remove ou queima staking quando validadores ou operadores violam regras.

Em sistemas de segurança compartilhada, o slashing pode proteger chains e serviços conectados ao tornar o mau comportamento custoso.

A documentação de termos-chave do EigenLayer define slashing como uma penalidade pela realização inadequada ou incorreta de tarefas atribuídas em conjuntos de operadores.

A visão geral de restaking do EigenLayer explica que o staking delegado pode se tornar sujeito a slashing quando um operador aloca staking a conjuntos de operadores.

Isso significa que os participantes de staking devem monitorar o que seus operadores escolhidos estão protegendo.

O slashing pode melhorar a responsabilização, mas também cria novo risco para participantes de staking.

Se um operador falhar em um serviço, os ativos delegados poderão ser afetados mesmo que o participante de staking não tenha executado pessoalmente o software.

As regras de slashing devem ser claras, objetivas quando possível e aplicáveis.

Regras de slashing pouco claras podem gerar incerteza, disputas e confusão para os usuários.

Uma camada de segurança compartilhada é tão confiável quanto sua capacidade de detectar e punir falhas graves de forma justa.

Recompensas na segurança compartilhada

As recompensas compensam validadores, operadores e participantes de staking por proteger sistemas adicionais.

As recompensas podem vir de taxas de consumer chains, inflação, pagamentos por serviços, incentivos de protocolo ou receita de aplicativos.

Um modelo de segurança compartilhada deve equilibrar recompensas e risco.

Se as recompensas forem muito baixas, os validadores poderão não querer proteger o sistema conectado.

Se as recompensas forem muito altas e insustentáveis, o modelo poderá atrair capital de curto prazo sem segurança duradoura.

Sistemas de restaking podem remunerar operadores e participantes de staking por apoiar AVSs.

Sistemas de provider chain podem direcionar recompensas de consumer chains a validadores e delegadores.

Sistemas no estilo Polkadot podem vincular o acesso à segurança ao coretime e à alocação de recursos da rede.

Os usuários não devem avaliar a segurança compartilhada apenas pelo rendimento.

Devem comparar as recompensas com o risco de slashing, de contratos inteligentes, de liquidez, de operadores e de governança.

Segurança compartilhada e interoperabilidade

A segurança compartilhada pode melhorar a interoperabilidade porque sistemas conectados podem operar sob premissas de confiança comuns.

Se várias chains dependerem da mesma camada de segurança, mensagens cross-chain podem ser mais fáceis de analisar do que mensagens entre chains não relacionadas.

A documentação da relay chain da Polkadot descreve interoperabilidade segura por meio de comunicação cross-chain nativa.

A segurança compartilhada pode tornar aplicativos cross-chain mais práticos porque usuários e desenvolvedores podem depender de uma base de segurança comum.

No entanto, a segurança compartilhada não resolve automaticamente todos os problemas de interoperabilidade.

Formatos de mensagens, contratos de bridge, relayers, latência, liquidez, finalidade e lógica de aplicativos ainda importam.

Uma camada de segurança compartilhada pode reduzir a fragmentação de confiança, mas não elimina a necessidade de um design cross-chain seguro.

Desenvolvedores devem explicar o que é compartilhado, o que é verificado e o que ainda depende de infraestrutura separada.

Os usuários não devem presumir que todas as mensagens entre chains com segurança compartilhada são livres de riscos.

A interoperabilidade é mais segura quando as premissas de segurança são explícitas.

Segurança compartilhada e blockchains modulares

Blockchains modulares dividem funções de blockchain em camadas separadas, como execução, liquidação, consenso e disponibilidade de dados.

Uma camada de segurança compartilhada pode fornecer segurança a uma ou mais dessas funções.

Por exemplo, um serviço pode usar segurança compartilhada para disponibilidade de dados, enquanto usa outra chain para liquidação e outro ambiente para execução.

Esse design modular pode melhorar a especialização e o desempenho.

Também pode tornar o risco mais difícil de entender, pois os usuários devem avaliar várias camadas ao mesmo tempo.

Uma falha em um módulo pode afetar todo o aplicativo.

Uma falha de disponibilidade de dados pode afetar a recuperação de um rollup.

Uma falha de sequenciamento pode afetar a ordenação e a experiência do usuário.

Uma falha de bridge pode afetar o resgate de ativos.

Uma camada de segurança compartilhada ajuda sistemas modulares a coordenar a confiança, mas os usuários ainda precisam entender toda a stack.

Segurança compartilhada e MEV

MEV, ou valor máximo extraível, pode surgir quando validadores, sequenciadores ou operadores influenciam a ordenação, inclusão ou execução de transações.

Uma camada de segurança compartilhada pode reduzir alguns riscos ao criar regras comuns e operadores responsáveis.

Ela também pode concentrar o poder de ordenação se muitos aplicativos dependerem dos mesmos operadores.

Se os operadores protegerem vários serviços, poderão visualizar mais fluxo de transações e oportunidades entre domínios.

Isso pode criar eficiência e risco.

Políticas de MEV, monitoramento, regras para proponentes, sistemas de ordenação justa e transparência são importantes em designs de segurança compartilhada.

Os usuários devem entender se a camada de segurança compartilhada protege contra censura ou apenas aplica penalidades econômicas após conduta indevida.

Desenvolvedores devem evitar presumir que a segurança compartilhada cria automaticamente ordenação justa.

A segurança compartilhada pode apoiar uma coordenação melhor, mas a gestão de MEV exige design específico.

A ordenação de transações continua sendo um dos problemas mais difíceis da infraestrutura multichain.

Resistência à censura

Resistência à censura é a capacidade de os usuários incluírem transações válidas sem bloqueio injusto.

Uma camada de segurança compartilhada pode melhorar a resistência à censura se tiver um conjunto grande e diversificado de validadores.

Ela pode enfraquecer a resistência à censura se a validação for controlada por poucos operadores ou se as consumer chains dependerem de um subconjunto limitado.

Modelos parciais de segurança compartilhada podem ser flexíveis, mas exigem uma análise cuidadosa da participação dos validadores.

A documentação do Cosmos Partial Set Security explica que chains opt-in podem não receber uma quantidade fixa de segurança e talvez precisem monitorar a participação de validadores.

Isso importa porque um pequeno grupo de operadores pode ser mais fácil de pressionar, subornar ou coordenar.

Os usuários devem verificar se existem rotas de saída, mecanismos de contingência ou processos de governança caso ocorra censura.

Desenvolvedores devem projetar aplicativos para que os usuários entendam o risco de finalidade e inclusão de transações.

A resistência à censura não é garantida pela expressão segurança compartilhada.

Ela depende da diversidade de validadores, dos incentivos, das regras e da infraestrutura do mundo real.

Vitalidade

Vitalidade significa que o sistema continua progredindo e processando transações válidas.

Uma camada de segurança compartilhada deve proteger tanto a segurança quanto a vitalidade.

Segurança significa que o sistema não finaliza estados inválidos ou conflitantes.

Vitalidade significa que o sistema não para indefinidamente.

A segurança compartilhada pode melhorar a vitalidade quando muitos validadores confiáveis apoiam os serviços conectados.

Também pode criar risco de vitalidade se os validadores precisarem executar chains demais, se atualizações de software falharem ou se os incentivos dos operadores forem fracos.

Uma consumer chain pode parar se não houver validadores compartilhados suficientes participando corretamente.

Um AVS pode deixar de fornecer o serviço se os operadores estiverem offline ou configurados incorretamente.

Os usuários devem verificar o histórico de uptime, relatórios de incidentes, participação de validadores e procedimentos de emergência.

Uma camada de segurança compartilhada segura deve conseguir continuar funcionando sob estresse.

Governança na segurança compartilhada

A governança decide como uma camada de segurança compartilhada muda ao longo do tempo.

A governança pode aprovar consumer chains, alterar requisitos de validadores, atualizar regras de slashing, modificar recompensas, atualizar contratos ou responder a emergências.

Em alguns sistemas de segurança compartilhada, a governança da provider chain pode decidir quais consumer chains podem participar.

Em sistemas de restaking, a governança do protocolo ou os provedores de serviço podem definir conjuntos de operadores e condições de slashing.

A governança pode melhorar a adaptabilidade, mas também pode criar risco de centralização.

Se um pequeno grupo puder mudar regras rapidamente, os usuários poderão enfrentar mudanças inesperadas de segurança.

Se a governança for lenta demais, o ecossistema poderá não responder a ameaças urgentes.

Os usuários devem verificar timelocks, distribuição do poder de voto, permissões de atualização, controles de emergência e transparência.

Segurança compartilhada não é apenas um sistema técnico.

Também é um sistema de governança e coordenação.

Concentração de operadores

A concentração de operadores ocorre quando um pequeno número de operadores controla uma grande parcela da validação ou da segurança em restaking.

Isso pode reduzir a descentralização e aumentar o risco de falhas correlacionadas.

Se muitos usuários delegarem ao mesmo operador, o erro desse operador poderá afetar muitos participantes de staking.

Se muitos serviços dependerem do mesmo grupo de operadores, uma falha de infraestrutura poderá afetar vários sistemas ao mesmo tempo.

A concentração de operadores também pode criar influência de governança e concentração de MEV.

Os usuários devem verificar a diversidade de operadores antes de delegar ativos em restaking ou depender de um serviço.

Desenvolvedores devem criar incentivos que estimulem uma ampla base de operadores.

Operadores grandes podem ser profissionais e confiáveis, mas o tamanho por si só não deve ser tratado como segurança.

Uma camada de segurança compartilhada saudável deve reduzir pontos únicos de falha.

A segurança descentralizada depende tanto do staking econômico quanto da distribuição operacional.

Riscos da segurança compartilhada

O primeiro risco é o slashing correlacionado entre vários serviços.

O segundo risco é a sobrecarga dos operadores causada por obrigações de validação demais.

O terceiro risco é a captura de governança ou atualizações inseguras.

O quarto risco é um design de slashing fraco que não pune falhas reais.

O quinto risco é um slashing excessivamente agressivo que pune erros honestos de forma injusta.

O sexto risco é a vulnerabilidade em contratos inteligentes de restaking, delegação, recompensas ou bridges.

O sétimo risco é uma falha de vitalidade se validadores ou operadores pararem de participar.

O oitavo risco é a compreensão pouco clara dos usuários sobre qual camada protege cada componente.

O nono risco é a superestimação da segurança econômica quando o staking divulgado não pode sofrer slashing integralmente por um serviço específico.

O décimo risco é a dependência compartilhada, em que uma falha da camada de segurança afeta vários sistemas conectados ao mesmo tempo.

Benefícios das camadas de segurança compartilhada

O primeiro benefício é o início mais rápido da segurança para novas chains e serviços.

O segundo benefício é uma segurança econômica mais robusta do que muitos conjuntos pequenos e independentes de validadores conseguem alcançar sozinhos.

O terceiro benefício é um custo de lançamento menor para desenvolvedores.

O quarto benefício é uma interoperabilidade melhor entre sistemas conectados.

O quinto benefício é a eficiência de capital, pois ativos em staking podem dar suporte a mais de um serviço útil.

O sexto benefício é maior profissionalismo dos validadores, pois operadores estabelecidos podem apoiar várias redes.

O sétimo benefício é facilitar o desenvolvimento de chains específicas para aplicativos.

O oitavo benefício é maior alinhamento do ecossistema entre provider chains, consumer chains, operadores e usuários.

O nono benefício é uma arquitetura de blockchain modular mais flexível.

O décimo benefício é que a segurança compartilhada pode tornar uma infraestrutura de alto valor mais confiável antes que ela tenha uma grande economia de token nativo.

Como avaliar uma camada de segurança compartilhada

Comece identificando a fonte de segurança.

Verifique se a segurança vem de uma provider chain, relay chain, protocolo de restaking, marketplace de validadores ou outro design.

Verifique quanto staking realmente protege a chain ou serviço específico.

Verifique se o conjunto de validadores é completo, parcial, opt-in, permissionado ou sem permissão.

Verifique se o slashing está ativo, é objetivo, aplicável, atrasado ou mediado por governança.

Verifique se os validadores ou operadores são diversificados e confiáveis.

Verifique quais recompensas são pagas e se elas são sustentáveis.

Verifique se o sistema conectado possui riscos próprios de contratos inteligentes, bridge, oráculo ou governança.

Verifique se os usuários podem sair com segurança caso o serviço falhe ou a relação de segurança mude.

Uma boa avaliação pergunta o que é compartilhado, quem o aplica, o que pode falhar e quem paga quando falha.

Boas práticas para desenvolvedores

Explique claramente seu modelo de segurança na documentação para usuários.

Informe se sua chain ou serviço usa segurança compartilhada completa, parcial, operadores opt-in ou segurança em restaking.

Publique detalhes sobre validadores, operadores, recompensas, slashing e governança em um formato que os usuários possam entender.

Evite alegar que seu aplicativo herda toda a segurança de uma chain-base se apenas um componente usar segurança compartilhada.

Use contratos auditados para a lógica de staking, delegação, recompensas, bridges e slashing.

Monitore operadores e validadores continuamente.

Crie recompensas que compensem os operadores pelo trabalho e risco reais.

Prepare procedimentos de resposta a incidentes para falhas de vitalidade, disputas de slashing, pausas de bridges e emergências de governança.

Facilite que os usuários vejam quais ativos ou serviços estão expostos a quais riscos.

A segurança compartilhada deve ser apresentada como uma arquitetura precisa, e não como um slogan de marketing.

Boas práticas para usuários

Leia a documentação oficial antes de usar uma chain ou serviço que alegue ter segurança compartilhada.

Verifique se a camada de segurança protege todo o sistema ou apenas um módulo.

Verifique a participação de validadores ou operadores antes de depositar fundos.

Entenda o risco de slashing antes de fazer staking, delegar ou fazer restaking de ativos.

Não busque recompensas mais altas sem verificar quais riscos adicionais criam essas recompensas.

Analise os riscos de bridge, oráculo, contratos inteligentes e governança separadamente das alegações de segurança compartilhada.

Use pequenas transações de teste ao experimentar uma nova chain ou serviço.

Acompanhe a quais operadores ou validadores seus ativos estão expostos.

Monitore os anúncios, pois as relações de segurança compartilhada podem mudar por governança ou atualizações.

Trate a segurança compartilhada como um modelo de risco a ser entendido, não como uma garantia de segurança.

Erros comuns sobre camadas de segurança compartilhada

Um erro comum é presumir que segurança compartilhada significa risco zero.

Outro erro é presumir que toda chain conectada recebe o mesmo nível de segurança.

Um terceiro erro é confundir uma bridge com uma camada de segurança compartilhada.

Um quarto erro é tratar o valor total em staking divulgado como proteção totalmente disponível para todos os serviços.

Um quinto erro é ignorar a concentração de validadores ou operadores.

Um sexto erro é ignorar as condições de slashing.

Um sétimo erro é presumir que a segurança compartilhada protege contra todos os bugs de contratos inteligentes.

Um oitavo erro é ignorar a governança e as permissões de atualização.

Um nono erro é presumir que as recompensas de restaking são rendimento gratuito.

Um décimo erro é não verificar se a camada de segurança compartilhada está ativa, é parcial, experimental ou ainda está mudando.

FAQ

O que significa Shared Security Layer no mercado cripto?

Uma camada de segurança compartilhada é um sistema de segurança de blockchain no qual várias chains, serviços ou módulos dependem de um conjunto comum de validadores, staking agrupado ou garantia em restaking.

Por que os projetos usam uma Shared Security Layer?

Os projetos usam uma camada de segurança compartilhada para evitar iniciar a segurança do zero e acessar validadores, staking, interoperabilidade e infraestrutura mais robustos.

Segurança compartilhada é o mesmo que uma bridge?

Não. Uma bridge move ativos ou mensagens, enquanto a segurança compartilhada oferece validação, staking ou proteção criptoeconômica a chains ou serviços.

Segurança compartilhada é o mesmo que uma sidechain?

Não. Uma sidechain geralmente possui seu próprio conjunto de validadores, enquanto uma chain com segurança compartilhada depende de uma fonte comum de segurança ou camada provedora.

O que é restaking na segurança compartilhada?

O restaking permite que ativos em staking ou tokens de staking líquido protejam serviços adicionais além da chain-base original.

A segurança compartilhada pode reduzir riscos?

Sim. A segurança compartilhada pode reduzir o risco inicial para novos sistemas, mas também introduz riscos de operadores, slashing, governança, contratos e falhas correlacionadas.

O que é uma provider chain?

Uma provider chain é uma blockchain que fornece segurança a consumer chains ou serviços conectados.

O que é uma consumer chain?

Uma consumer chain é uma blockchain que recebe segurança de uma provider chain ou camada de segurança compartilhada.

Qual é o maior risco da segurança compartilhada?

Um risco importante é que uma falha no sistema compartilhado de validadores, operadores, governança ou slashing pode afetar vários serviços conectados ao mesmo tempo.

Como os usuários devem avaliar alegações de segurança compartilhada?

Os usuários devem verificar a fonte de segurança, a participação de validadores, a concentração de operadores, as regras de slashing, as recompensas, os poderes de governança e quais partes do sistema são realmente protegidas.

Conclusão

Uma camada de segurança compartilhada é uma arquitetura de segurança cripto na qual várias chains, aplicativos ou serviços dependem de um pool comum de validadores, participantes de staking, operadores ou garantia em restaking.

Ela ajuda novos sistemas a serem lançados com uma segurança mais robusta do que poderiam alcançar sozinhos.

Ela é usada de várias formas, incluindo segurança de relay chain, Interchain Security, restaking, conjuntos agrupados de validadores e serviços de infraestrutura modular.

A segurança compartilhada pode melhorar a escalabilidade, interoperabilidade, eficiência de capital, velocidade de desenvolvimento e alinhamento do ecossistema.

Também pode criar novos riscos por meio de exposição a slashing, concentração de operadores, dependência de governança, bugs de contratos inteligentes, risco de bridge, falhas de vitalidade e falhas correlacionadas entre sistemas conectados.

Os desenvolvedores devem explicar exatamente o que é protegido, quem o protege, como funcionam as recompensas e o que ocorre quando validadores ou operadores falham.

Os usuários devem avaliar cuidadosamente alegações de segurança compartilhada, em vez de presumir que um sistema conectado herda automaticamente toda a segurança de uma chain maior.

Para iniciantes, uma camada de segurança compartilhada é mais bem entendida como uma base de segurança que vários sistemas cripto podem usar juntos.

Para usuários avançados, é uma camada de coordenação criptoeconômica que conecta staking, validadores, operadores, regras de serviço, condições de slashing, recompensas, governança e interoperabilidade em vários sistemas.

No contexto de um glossário cripto, Shared Security Layer significa uma estrutura de segurança agrupada que permite que várias redes blockchain ou serviços dependam de validadores ou garantias compartilhados, aceitando os riscos específicos desse modelo compartilhado.

O ponto principal é que a segurança compartilhada pode tornar a infraestrutura cripto mais robusta e eficiente, mas somente quando usuários e desenvolvedores entendem o conjunto exato de validadores, as regras de slashing, os poderes de governança, os incentivos de recompensa e os caminhos de falha por trás da alegação de segurança.