Introdução:

Este artigo fornece uma introdução proativa a um paradigma de design de infraestrutura Web3 um tanto não convencional: o Paradigma de Consenso Baseado em Armazenamento (SCP). Esse modelo de design diverge significativamente das soluções de blockchain modular mainstream como Ethereum Rollups na teoria. No entanto, ele demonstra alta viabilidade em termos de simplicidade na implementação e integração com plataformas Web2. SCP não pretende se limitar a um caminho estreito de realização como Rollups. Em vez disso, ele visa adotar uma estrutura mais ampla e aberta para mesclar plataformas Web2 com infraestrutura Web3. Essa abordagem pode ser vista como altamente imaginativa e inovadora.

Vamos imaginar uma solução de dimensionamento de blockchain público com as seguintes características:

• Tem velocidades comparáveis às aplicações ou exchanges tradicionais da Web2, superando em muito qualquer blockchain público, Layer 2 (L2), rollups, sidechains, etc.

• Não há taxas de gás, e o custo de uso é quase zero.

• Alta segurança financeira, superando instalações centralizadas como exchanges, inferior a Rollups mas maior ou igual a sidechains.

• Uma experiência de usuário idêntica à Web2, sem exigir qualquer conhecimento de chaves públicas e privadas de blockchain, carteiras, infraestrutura, etc.

Uma solução assim é realmente muito empolgante: por um lado, ela essencialmente alcançou o ápice em termos de escalabilidade; por outro lado, ela lança uma base sólida para a adoção em massa do Web3, essencialmente preenchendo a lacuna entre as experiências dos usuários do Web2 e Web3. No entanto, parece que temos poucas soluções abrangentes como esta, já que as discussões e práticas mainstream são realmente muito poucas.

Usamos o conhecido tópico de escalabilidade como introdução acima, mas o SCP não se limita aos casos de uso de escalabilidade. Sua inspiração de design realmente vem das soluções de escalabilidade e discussões da comunidade de blockchains públicos como Bitcoin e Ethereum. Sua visão e aplicação prática é construir uma nova geração de infraestrutura sem confiança, até mesmo plataformas computacionais não baseadas em estruturas de blockchain.

Componentes Básicos do SCP e Princípios de Funcionamento

De um modo geral, o SCP, como o "blockchain modular" mencionado pelas comunidades Ethereum e Celestia, tem vários módulos, como uma camada de disponibilidade de dados, camada de execução, camada de consenso e camada de liquidação.

• Camada de Disponibilidade de Dados: Gerida por uma blockchain pública amplamente reconhecida e bem testada, ou por instalações de armazenamento que funcionam como a camada de disponibilidade de dados, como Ethereum, Arweave, Celestia, etc.

• Camada de Execução: Um servidor, usado para receber transações de usuários e executá-las, enquanto também envia em lote os dados de transações assinadas para a camada DA, semelhante aos sequenciadores em Rollups. No entanto, a camada de execução não precisa necessariamente de uma estrutura de cadeia estilo blockchain; pode ser inteiramente um sistema de banco de dados + computação Web2, mas todo o sistema de computação deve ser de código aberto, com transparência.

• Camada de Consenso: Composta por um grupo de nós que puxam os dados submetidos à camada DA pela camada de execução e usam o mesmo algoritmo que a camada de execução para processar esses dados, confirmando se a saída da camada de execução está correta e pode servir como uma redundância de recuperação de desastres para a camada de execução. Os usuários também podem ler os dados retornados pelos nós da camada de consenso para garantir que não haja comportamento fraudulento na camada de execução.

• Camada de Liquidação: Composta por um grupo de nós e contratos ou endereços em outras cadeias, responsável por lidar com depósitos de usuários no SCP, ou saques do SCP, algo semelhante à operação de pontes entre cadeias. Os nós da camada de liquidação controlam a função de saque do endereço de depósito por meio de contratos multisig ou endereços baseados em TSS. Para depósitos, os usuários transferem ativos para um endereço designado em sua cadeia; para saques, eles enviam uma solicitação, e depois que os nós da camada de liquidação leem os dados, eles liberam os ativos por meio de multisig ou TSS. O nível de segurança da camada de liquidação depende do mecanismo entre cadeias usado.

Estrutura de Prática SCP

Podemos entender o paradigma SC através do seguinte framework. Um produto que atende ao framework SC pode ter características principais como depósito, transferência, saque, troca, etc., e pode ser ainda mais expandido. Abaixo está um diagrama esquemático de tal produto:

• A camada DA deste projeto utiliza a instalação de armazenamento permanente Arweave, representada pelo grande círculo no diagrama.
• O Coordenador, ou a camada de execução, é onde os usuários enviam suas transações. O Coordenador executa cálculos, exibe os resultados e, em seguida, agrupa os dados de entrada originais dos usuários e os envia para a camada DA.
• O Detector puxa os dados originais da transação enviados pelo Coordenador da Arweave e, usando o mesmo algoritmo do Coordenador, valida os dados e resultados. O cliente do Detector também é de código aberto, permitindo que qualquer pessoa o execute.
• Os Guardiões, um grupo de Detectores, gerenciam o sistema multi-assinatura do sistema de saque. Eles validam e autorizam solicitações de saque com base em dados de transação. Além disso, os Guardiões são responsáveis por assinar propostas.

Podemos ver que o consenso alcançado por todo o sistema é totalmente off-chain, que é o núcleo do paradigma de consenso de armazenamento. Ele abandona o sistema de consenso de nó típico de blockchains, liberando a camada de execução do pesado processo de comunicação e confirmação de consenso. Isso permite que ele funcione eficientemente como um único servidor, alcançando assim TPS quase ilimitado e custo-benefício. Esse aspecto é muito semelhante aos Rollups, mas o SCP (Storage Consensus Paradigm) toma um caminho diferente dos Rollups. O SCP tenta fazer a transição de um caso de uso específico de dimensionamento para um novo modo de transição da Web2 para a Web3. O referido Coordenador é um servidor, mas isso não significa que o Coordenador possa agir arbitrariamente. Semelhante ao sequenciador em Rollups, após o envio em lote dos dados originais dos usuários no Arweave, qualquer pessoa pode executar o programa Detector para verificá-lo e compará-lo com o estado retornado pelo Coordenador. De certa forma, isso é semelhante à abordagem de aplicações do tipo inscrição. Nessa arquitetura, um servidor ou banco de dados centralizado não representa um desafio fundamental. Este é outro ponto do paradigma SCP: ele desacopla os conceitos de "centralização" e "entidade única" — em um sistema sem confiança, pode haver componentes centralizados, até mesmo um componente central, sem afetar a falta de confiança geral do sistema.

Podemos gritar este slogan: 'A próxima geração de infraestrutura sem confiança não precisa necessariamente depender de protocolos de consenso, mas deve ser um sistema de código aberto com uma rede de nós Peer-to-Peer (P2P).' A intenção original de inventar e usar blockchain era alcançar a descentralização, consistência de livro-razão, imutabilidade e rastreabilidade, conforme explicitamente declarado no whitepaper do Bitcoin. No entanto, pós-Ethereum, quer se trate de soluções de expansão da antiga cadeia pública, Rollups ou blockchains modulares, houve uma mentalidade fixa: o que estamos criando deve ser ou uma blockchain (composta por protocolos de consenso de nós) ou algo como Rollup (que parece ser uma cadeia com estruturas de dados de blockchain, mas sem trocas diretas de mensagens de consenso entre nós). Agora, sob o framework baseado no SCP (Protocolo de Consenso Stellar), é evidente que mesmo sem ser uma blockchain, é possível alcançar descentralização, consistência de livro-razão, imutabilidade e rastreabilidade, desde que haja mais detalhes de implementação explícitos.

Camada de Execução

A camada de execução é crucial em todo o sistema, pois realiza os processos computacionais do sistema e determina os tipos de aplicativos que podem ser executados no sistema.

Possibilidades infinitas no ambiente de execução

Teoricamente, o ambiente de execução na camada de execução pode assumir qualquer forma, com possibilidades infinitas, dependendo de como os desenvolvedores do projeto posicionam seu projeto:

1. Exchanges. Usando SCP, pode-se construir uma troca pública e transparente com altas taxas de Transações Por Segundo (TPS), combinando as características rápidas e sem custos de uma Centralized Exchange (CEX) e a descentralização de uma Decentralized Exchange (DEX). Aqui, a distinção entre CEX e DEX se torna turva.

2. Redes de pagamento. Semelhante ao Alipay, PayPal, etc.

3. Máquinas Virtuais/Blockchains Suportando Programas/Contratos Carregáveis. Qualquer desenvolvedor pode implantar qualquer aplicativo nele, compartilhando todos os dados do usuário com outros programas e operando de acordo com as instruções do usuário.

O padrão de design do SCP, que suporta qualquer ambiente de execução, tem suas vantagens únicas: não há necessidade de depender de componentes com bagagem histórica, especialmente conceitos como a “abstração de conta” única para a comunidade Ethereum. Para o SCP, o conceito de abstração de conta é inherentemente desnecessário. Na arquitetura do SCP, não há conceito de abstração de conta — você pode adotar livremente contas padrão Web2 e contas blockchain, etc. Sob essa perspectiva, muitos casos de uso maduros do Web2 não precisam ser repensados e reconstruídos para serem diretamente aplicáveis ao SCP. Este aspecto pode ser onde o SCP tem uma vantagem sobre os Rollups.

Transparência e Assimetria

O sistema de contas foi mencionado acima, e leitores perspicazes podem ter notado que, enquanto o SCP (Protocolo de Consenso Stellar) pode utilizar o sistema de contas Web2, usá-lo como está parece problemático. Isso ocorre porque todo o sistema é completamente transparente! Empregar diretamente o modelo de interação usuário-servidor do Web2 leva a sérios problemas de segurança, tornando o sistema totalmente inseguro. Vamos revisar como funciona o modelo tradicional de servidor-usuário:

1. Registro de Conta: Os usuários inserem um nome de usuário e senha na página de registro do aplicativo. Para proteger a senha do usuário, o servidor a processa através de uma função de hash ao recebê-la. Para aumentar a complexidade do hash e se defender contra ataques de tabelas arco-íris, uma sequência gerada aleatoriamente (conhecida como "salt") geralmente é anexada a cada senha do usuário antes do hash. O nome de usuário, o salt e o hash são armazenados em texto simples no banco de dados do provedor de serviços e não são tornados públicos. No entanto, mesmo assim, o uso de salt e o processamento seguro são necessários para prevenir ameaças internas e ataques.

1. Login do usuário: Os usuários inserem seu nome de usuário e senha no formulário de login. O sistema compara o hash da senha processada com o hash armazenado no banco de dados. Se os dois hashes corresponderem, isso indica que o usuário forneceu a senha correta e o processo de login continua.

2. Autenticação da Operação : Após a verificação bem-sucedida do login, o sistema cria uma sessão para o usuário. Tipicamente, as informações da sessão são armazenadas no servidor, e o servidor envia um identificador (como um cookie ou token) para o navegador ou aplicativo do usuário. Durante operações subsequentes, os usuários não precisam mais inserir repetidamente seu nome de usuário e senha: o navegador ou aplicativo salva o identificador do cookie e o inclui em cada solicitação, indicando que possuem a permissão do servidor associada ao cookie.

Vamos revisar o sistema típico de interação do usuário de blockchain Web3:

1. Registro de Conta: Na realidade, não há um processo de registro de conta, nem um sistema de nome de usuário e senha. As contas (endereços) não precisam ser registradas; elas existem inerentemente, e quem controla a chave privada controla a conta. A chave privada é gerada aleatoriamente localmente pela carteira e não envolve um processo online.

2. Login do usuário: Usar o blockchain não requer login. A maioria dos dApps não possui um processo de login, mas se conectam a uma carteira. Alguns dApps, após se conectarem a uma carteira, podem exigir que os usuários assinem uma verificação para garantir que realmente possuem a chave privada, em vez de apenas terem enviado um endereço de carteira para o frontend.

3. Autenticação da Operação: Os usuários enviam diretamente os dados assinados para os nós. Após validação, os nós transmitem a transação para toda a rede blockchain. Uma vez que a operação é confirmada pelo consenso da rede blockchain, ela é finalizada.

A diferença entre esses dois modos é causada por fatores simétricos e assimétricos. Em uma arquitetura de servidor-usuário, ambas as partes possuem o mesmo segredo. Em uma arquitetura de blockchain-usuário, apenas o usuário possui o segredo. Embora a camada de execução do SCP (Plataforma de Contrato Inteligente) possa não ser uma blockchain, todos os dados precisam ser sincronizados com uma camada de DA (Disponibilidade de Dados) publicamente visível. Portanto, os métodos de verificação de login e operação do SCP devem ser assimétricos. No entanto, para evitar ações complicadas como gerenciar chaves privadas e usar carteiras, que podem dificultar a adoção generalizada devido a uma experiência ruim do usuário, há uma forte demanda por logins de autenticação de terceiros tradicionais ID-senha ou OAuth em aplicativos construídos no SCP. Então, como combinamos os dois? Devido à natureza assimétrica da criptografia e das provas de conhecimento zero, vislumbro duas soluções possíveis:

• Se for desejado um sistema de ID-senha, o módulo de salvamento de senha pode ser excluído do SCP, tornando-o invisível para outros. Internamente, a camada de execução do SCP ainda usa as contas de chave pública-privada e lógica operacional da blockchain, sem registro ou login. O ID do usuário na verdade corresponderia a uma chave privada. Esta chave privada, é claro, não deve ser armazenada pelo projeto. Uma solução viável é usar 2-3 MPC (Multi-Party Computation) para resolver o problema do armazenamento centralizado sem sobrecarregar o usuário com o uso de uma chave privada.
• Ao confiar no login do OAuth, o JWT (Token da Web JSON) pode ser usado como um meio de autenticação de identidade. Este método é ligeiramente mais centralizado do que o acima, pois essencialmente depende dos serviços de login de terceiros fornecidos pelos gigantes da Web2 para verificação de identidade.
• Na primeira vez que o login de terceiros é usado, os campos JWT que representam as identidades do usuário e do provedor de serviços são registrados no sistema. Nas operações subsequentes do usuário, o comando de operação é tratado como entrada pública, enquanto o JWT como um todo é uma testemunha secreta, usando ZKP (Prova de Conhecimento Zero) para verificar cada uma das transações do usuário.
• Cada JWT tem um limite de validade e os usuários solicitarão um novo JWT na próxima vez que fizerem login, portanto, não há necessidade de armazenamento permanente. Além disso, este sistema depende do JWK (JSON Web Key), que pode ser entendido como a chave pública fornecida pelos gigantes para a verificação do JWK. Como o JWK é inserido de forma descentralizada no sistema e métodos para futura rotação da chave privada também são dignos de exploração.

Independentemente do método utilizado, ambos são mais caros em termos de desenvolvimento e operação do que os métodos tradicionais, mas este é um preço necessário a pagar pela descentralização. Claro, se o projeto não considerar a descentralização extrema necessária, ou tiver marcos diferentes em diferentes estágios de desenvolvimento, é possível prosseguir sem esses designs, pois a descentralização não é preto e branco, mas existe em uma área cinzenta.

Questões de privacidade

As questões de transparência mencionadas acima não afetam apenas o paradigma de interação do usuário, mas também impactam os dados do usuário. Os dados do usuário são diretamente expostos. Embora isso não seja um problema na blockchain, é inaceitável em algumas aplicações. Portanto, os desenvolvedores também podem construir sistemas de transações privadas.

Taxas

Como a camada de execução cobra taxas é outro ponto de interesse. Enviar dados para a camada de Disponibilidade de Dados (DA) também incorre em custos, incluindo a operação de seus próprios servidores. O objetivo principal de cobrar taxas de gás em blockchains tradicionais é evitar que os usuários enviem spam para a rede com inúmeras transações redundantes, sendo a ordenação de transações com base em taxas de gás secundária. No Web2, preocupações semelhantes não existem, apenas conceitos básicos como inundação e ataques DDoS. A camada de execução pode personalizar várias estratégias de cobrança, como ser completamente gratuita ou parcialmente cobrada, ou lucrar com outras atividades como Valor Máximo Extraível (MEV), que já é muito maduro em sequenciadores e atividades de mercado.

Resistência à Censura

A camada de execução não possui resistência à censura e teoricamente pode rejeitar transações de usuários indefinidamente. Nos Rollups, a resistência à censura pode ser assegurada pela função de agregação obrigatória do contrato L1, enquanto sidechains ou blockchains públicas são redes blockchain distribuídas completas, tornando a censura difícil. Atualmente, não há uma solução clara para abordar a questão da resistência à censura, o que é um problema no paradigma SCP.

Camada de Consenso

Essa camada consiste em nós vagamente conectados que não formam ativamente uma rede, portanto, não é estritamente uma camada de consenso, mas apenas confirma o estado atual da camada de execução para o mundo externo (como usuários). Por exemplo, se você duvidar do status operacional desses nós, poderá baixar o cliente detector, que executa o mesmo código de programa que o coordenador. No entanto, semelhante aos Rollups, como os dados são enviados em lotes, o estado retornado pela camada de execução aos usuários é sempre mais atualizado do que o da camada DA. Isso envolve a questão da pré-confirmação: a camada de execução fornece aos usuários resultados de pré-confirmação, soft finality, pois eles ainda não foram submetidos à camada DA; enquanto a camada de consenso fornece uma finalidade difícil. Os usuários podem não estar particularmente preocupados com isso, mas para aplicações como pontes de cadeia cruzada, a finalidade rígida deve ser respeitada. Por exemplo, o sistema de depósito e retirada de exchanges não confia na transmissão de dados off-chain por sequenciadores Rollup; eles esperam que esses dados estejam no Ethereum antes da aceitação. Além de confirmar os resultados, a camada de consenso também desempenha um papel crucial como redundância de desastres para a camada de execução. Se a camada de execução parar permanentemente de funcionar ou agir maliciosamente, teoricamente qualquer camada de consenso pode assumir o trabalho da camada de execução e aceitar solicitações do usuário. Se uma situação tão grave ocorrer, a comunidade deve escolher nós estáveis e confiáveis como servidores da camada de execução.

Camada de Liquidação

Uma vez que SCP não é Rollup, não pode alcançar saques sem confiança como a camada de liquidação de saques do Rollup, que é baseada inteiramente em criptografia e código de contrato inteligente sem intervenção manual. O nível de segurança das pontes cruzadas SCP é o mesmo que o das pontes cruzadas de sidechain ou de testemunha de terceiros, que dependem de gerentes de várias assinaturas autorizadas para liberar ativos, conhecido como modo de testemunha.

Tornar a ponte de testemunha tão descentralizada quanto possível é um tópico de pesquisa para muitas pontes entre cadeias. Devido a limitações de espaço, isso não será elaborado aqui. Uma plataforma SCP bem projetada na prática também deve ter parceiros de assinatura múltipla descentralizados e respeitáveis. Alguns podem perguntar por que o SCP não usa uma cadeia com contratos inteligentes como a camada DA? Isso permitiria camadas de liquidação sem confiança com base em contratos. A longo prazo, superando algumas dificuldades técnicas, se a camada DA for colocada no Ethereum ou em outras camadas DA habilitadas para contratos e os contratos de verificação correspondentes puderem ser construídos, o SCP também pode alcançar a mesma segurança de liquidação que o Rollup, sem a necessidade de múltiplas assinaturas.

Na prática, essa pode não ser a melhor escolha:

1. O Ethereum não é especificamente projetado para armazenamento de dados e, comparado a blockchains dedicados exclusivamente ao armazenamento de dados, é bastante caro. Para o paradigma SCP, um custo de armazenamento suficientemente baixo ou fixo é crucial. Somente assim ele pode suportar a taxa de transferência do nível Web2.

2. Desenvolver sistemas de prova é extremamente difícil porque, no SCP, pode-se simular não apenas a EVM (Máquina Virtual Ethereum) mas também implementar qualquer lógica. Considerando o estado atual de projetos como o Optimism, onde suas provas de fraude ainda não foram lançadas, e a complexidade de desenvolver zkEVM (Máquina Virtual Ethereum de conhecimento zero), pode-se imaginar a imensa dificuldade de implementar vários sistemas de prova no Ethereum.

Portanto, a solução Rollup é apenas mais viável na prática em circunstâncias específicas. Se você planeja implementar um sistema mais amplo e aberto, afastando-se do framework EVM para integrar mais recursos da Web2, então a abordagem Rollup do Ethereum não é adequada. O SCP não é apenas um plano de expansão para uma determinada blockchain pública, mas uma arquitetura de plataforma de computação Web3 mais ampla. Portanto, claramente não precisa seguir a abordagem da Camada 2 do Ethereum.

Uma ilustração compara SC com outros paradigmas

Isenção de responsabilidade:

1. Este artigo é reproduzido a partir de [Gate极客Web3]. Todos os direitos autorais pertencem ao autor original [雾月,极客Web3]. Se houver objeções a esta reimpressão, entre em contato com o Portão Aprenderequipe, e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.