Introdução:

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

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

• Tem velocidades comparáveis às aplicações ou exchanges Web2 tradicionais, 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 bolsas, inferior a Rollups mas maior ou igual a sidechains.

• Uma experiência do utilizador idêntica à Web2, sem requerer qualquer conhecimento das chaves públicas e privadas da blockchain, carteiras, infraestrutura, etc.

Uma solução como esta é realmente muito emocionante: por um lado, atingiu essencialmente o auge em termos de escalabilidade; por outro lado, lança uma base sólida para a adoção em massa do Web3, essencialmente aproximando a experiência do usuário do Web2 e Web3. No entanto, parece que temos poucas soluções abrangentes como esta, uma vez que as discussões e práticas mainstream são de fato muito escassas.

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

Em termos gerais, SCP, como a "blockchain modular" mencionada pelas comunidades Ethereum e Celestia, possui 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ário e executá-las, enquanto também submete em lote os dados de transação assinados para a camada DA, semelhante aos sequenciadores em Rollups. No entanto, a camada de execução não necessariamente precisa 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 retiram os dados enviados para a camada de DA pela camada de execução e usam o mesmo algoritmo da 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 os depósitos do utilizador no SCP, ou levantamentos do SCP, algo semelhante à operação de pontes entre cadeias. Os nós da camada de liquidação controlam a função de levantamento do endereço de depósito através de contratos multisig ou endereços baseados em TSS. Para depósitos, os utilizadores transferem ativos para um endereço designado na sua cadeia; para levantamentos, enviam um pedido, e depois de os nós da camada de liquidação lerem os dados, libertam os ativos através de multisig ou TSS. O nível de segurança da camada de liquidação depende do mecanismo entre cadeias utilizado.

Estrutura de Prática SCP

Podemos entender o paradigma SC através do seguinte quadro. Um produto que cumpra o quadro SC pode ter funcionalidades principais como depósito, transferência, levantamento, 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 círculo grande no diagrama.
• O Coordenador, ou a camada de execução, é onde os utilizadores submetem as suas transações. O Coordenador executa cálculos, exibe os resultados e depois agrupa os dados de entrada originais dos utilizadores e submete-os à camada DA.
• O Detector puxa os dados originais da transação submetidos pelo Coordenador da Arweave e, usando o mesmo algoritmo que o Coordenador, valida os dados e resultados. O cliente do Detector também é de código aberto, permitindo que qualquer pessoa o execute.
• Os Vigilantes, um grupo de Detectores, gerenciam o sistema de multi-assinatura do sistema de retirada. Eles validam e autorizam pedidos de retirada com base em dados de transação. Além disso, os Vigilantes são responsáveis por assinar propostas.

Podemos ver que o consenso alcançado por todo o sistema é completamente off-chain, que é o núcleo do paradigma de consenso de armazenamento. Abandona o sistema de consenso de nós típico das blockchains, libertando a camada de execução do processo de comunicação e confirmação de consenso oneroso. Isso permite que funcione eficientemente como um único servidor, alcançando assim um TPS quase ilimitado e eficiência de custos. Este aspeto é muito semelhante aos Rollups, mas o SCP (Paradigma de Consenso de Armazenamento) segue um caminho diferente dos Rollups. O SCP tenta fazer a transição de um caso de uso específico de escalabilidade para um novo modo de transição de Web2 para Web3. O Coordenador mencionado é um servidor, mas isso não significa que o Coordenador possa agir arbitrariamente. Similar ao sequenciador nos Rollups, após submeter em lote os dados originais dos utilizadores no Arweave, qualquer pessoa pode executar o programa Detector para verificá-lo e compará-lo com o estado devolvido pelo Coordenador. De certa forma, isso é semelhante à abordagem de aplicações do tipo inscrição. Nesta arquitetura, um servidor centralizado ou banco de dados não representa um desafio fundamental. Este é outro ponto do paradigma do SCP: desvincula os conceitos de "centralização" e "entidade única" — num sistema sem confiança, pode haver componentes centralizados, até mesmo um componente central, sem afetar a confiança geral do sistema.

Podemos gritar este slogan: "A próxima geração de infraestrutura sem confiança não necessariamente tem que 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, a consistência do livro-razão, a imutabilidade e a rastreabilidade, como explicitamente declarado no whitepaper do Bitcoin. No entanto, após o Ethereum, quer seja as soluções de expansão da cadeia pública antiga, Rollups, ou blockchains modulares, houve uma mentalidade fixa: o que estamos a criar deve ser ou uma blockchain (composta por protocolos de consenso dos 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 (Stellar Consensus Protocol), é evidente que mesmo sem ser uma blockchain, é possível alcançar descentralização, consistência do 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 aplicações que podem ser executadas 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 o seu projeto:

1. Trocas. Usando SCP, pode-se construir uma troca pública e transparente com altas Taxas de Transação por Segundo (TPS), combinando as características rápidas e sem custos de uma Troca Centralizada (CEX) e a descentralização de uma Troca Descentralizada (DEX). Aqui, a distinção entre CEX e DEX torna-se turva.

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

3. Máquinas Virtuais/Blocos de Cadeia que Suportam Programas/Contratos Carregáveis. Qualquer programador pode implementar qualquer aplicação nela, partilhando todos os dados do utilizador com outros programas e operando de acordo com as instruções do utilizador.

O padrão de design do SCP, que suporta qualquer ambiente de execução, tem suas vantagens únicas: não há necessidade de confiar em 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 é intrinsecamente desnecessário. Na arquitetura do SCP, não há conceito de abstração de conta — é possível adotar livremente contas padrão Web2 e contas de blockchain, etc. A partir desse ponto de vista, muitos casos de uso maduros do Web2 não precisam ser repensados e reconstruídos para serem diretamente aplicáveis ao SCP. Esse 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, embora o SCP (Protocolo de Consenso Stellar) possa 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 completamente inseguro. Vamos rever como funciona o modelo tradicional de servidor-usuário:

1. Registo de Conta: Os utilizadores introduzem um nome de utilizador e uma palavra-passe na página de registo da aplicação. Para proteger a palavra-passe do utilizador, o servidor processa-a através de uma função de hash ao recebê-la. Para aumentar a complexidade do hash e defender-se contra ataques de tabela arco-íris, uma string gerada aleatoriamente (conhecida como "salt") é normalmente apendada a cada palavra-passe do utilizador antes do hashing. O nome de utilizador, salt e hash são armazenados em texto simples na base de dados do fornecedor de serviços e não são tornados públicos. No entanto, mesmo assim, o salting e o processamento seguro são necessários para prevenir ameaças internas e ataques.

1. Login do utilizador: Os utilizadores inserem o seu nome de utilizador e palavra-passe no formulário de login. O sistema compara o hash da palavra-passe processada com o hash armazenado na base de dados. Se os dois hashes coincidirem, isso indica que o utilizador forneceu a palavra-passe correta e o processo de login prossegue.

2. Autenticação de operação: Após a verificação bem-sucedida do login, o sistema cria uma sessão para o utilizador. Tipicamente, a informação da sessão é armazenada no servidor e o servidor envia um identificador (como um cookie ou token) para o navegador ou aplicação do utilizador. Durante operações subsequentes, os utilizadores já não precisam de inserir repetidamente o seu nome de utilizador e palavra-passe: o navegador ou aplicação guarda o identificador do cookie e inclui-o em cada pedido, indicando que têm a permissão do servidor associada ao cookie.

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

1. Registo de Conta: Na realidade, não existe um processo de registo de conta, nem um sistema de nome de utilizador e palavra-passe. As contas (endereços) não precisam de ser registadas; 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 utilizador: Utilizar a blockchain não requer fazer login. A maioria das dApps não possui um processo de login, mas em vez disso conectam-se a uma carteira. Algumas dApps, após se conectarem a uma carteira, podem exigir que os utilizadores assinem uma verificação para garantir que realmente possuem a chave privada, em vez de apenas terem submetido um endereço de carteira à interface do utilizador.

3. Autenticação de operação: Os utilizadores submetem diretamente os dados assinados aos nós. Após validação, os nós difundem a transação para toda a rede blockchain. Uma vez que a operação é confirmada pelo consenso da rede blockchain, fica finalizada.

A diferença entre esses dois modos é causada por fatores simétricos e assimétricos. Em uma arquitetura servidor-usuário, ambas as partes possuem o mesmo segredo. Em uma arquitetura 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 login e verificação de operação do SCP devem ser assimétricos. No entanto, para evitar ações complicadas como gerenciamento de chaves privadas e uso de carteiras, que podem dificultar a adoção generalizada devido a uma experiência do usuário ruim, 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, imagino duas soluções possíveis:

• Se for desejado um sistema de ID e senha, o módulo de salvamento de senha pode ser excluído do SC, tornando-o invisível para os outros. Internamente, a camada de execução do SC ainda usa as contas de chave pública-privada e lógica operacional do blockchain, sem registro ou login. O ID do usuário realmente corresponderia a uma chave privada. Esta chave privada, é claro, não deve ser armazenada pelo lado do projeto. Uma solução viável é usar 2-3 MPC (Computação Multi-Partes) para resolver o problema de armazenamento centralizado sem sobrecarregar o usuário com o uso de uma chave privada.
• Ao confiar no login do OAuth, o JWT (Token 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 de serviços de login de terceiros fornecidos por gigantes Web2 para verificação de identidade.
• A primeira vez que é utilizado um login de terceiros, os campos JWT que representam as identidades do utilizador e do fornecedor de serviços são registados no sistema. Nas operações subsequentes do utilizador, o comando de operação é tratado como uma entrada pública, enquanto o JWT como um todo é uma testemunha secreta, utilizando ZKP (Prova de Conhecimento Zero) para verificar cada uma das transações do utilizador.
• Cada JWT tem um limite de validade e os utilizadores solicitarão um novo JWT na próxima vez que fizerem login, por isso não é necessário armazenamento permanente. Além disso, este sistema depende de JWK (JSON Web Key), que pode ser entendido como a chave pública fornecida pelos gigantes para verificação de JWK. Como o JWK é introduzido descentralizadamente no sistema e os métodos para futura rotação da chave privada também valem a pena explorar.

Independentemente do método utilizado, ambos são mais dispendiosos 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 extrema descentralização necessária, ou tiver diferentes marcos em diferentes fases de desenvolvimento, é possível avançar sem esses designs, uma vez que a descentralização não é preto e branco, mas existe numa área cinzenta.

Questões de privacidade

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

Taxas

Como a camada de execução cobra taxas é outro ponto de interesse. A submissão de dados à camada de Disponibilidade de Dados (DA) também incorre em custos, incluindo a operação dos seus próprios servidores. O objetivo principal de cobrar taxas de gás em blockchains tradicionais é evitar que os utilizadores spamem a rede com numerosas transações redundantes, sendo a ordenação das transações com base nas 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 totalmente gratuita ou parcialmente cobrada, ou lucrar com outras atividades como Valor Extraível Máximo (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 garantida pela função de agregação obrigatória do contrato L1, enquanto as sidechains ou as cadeias públicas são redes de blockchain distribuídas completas, tornando a censura difícil. Atualmente, não há uma solução clara para abordar o problema da resistência à censura, o que é um problema no paradigma SCP.

Camada de Consenso

Esta camada é composta por nós ligados de forma frouxa que não formam ativamente uma rede, por isso não é estritamente uma camada de consenso, mas apenas confirma o estado atual da camada de execução ao mundo exterior (como os utilizadores). Por exemplo, se duvidar do estado operacional destes nós, pode descarregar o seu cliente de detecção, que executa o mesmo código de programa que o coordenador. No entanto, semelhante aos Rollups, uma vez que os dados são submetidos em lotes, o estado devolvido pela camada de execução aos utilizadores está sempre mais atualizado do que o da camada DA. Isto envolve a questão da pré-confirmação: a camada de execução fornece aos utilizadores pré-confirmação, resultados de finalidade suave, uma vez que ainda não foram submetidos à camada DA; enquanto a camada de consenso fornece finalidade rígida. Os utilizadores podem não estar particularmente preocupados com isso, mas para aplicações como pontes entre cadeias, a finalidade rígida deve ser respeitada. Por exemplo, o sistema de depósito e levantamento das exchanges não confia nos dados transmitidos fora da cadeia pelos sequenciadores Rollup; eles esperam que estes dados estejam na Ethereum antes de os aceitar. Para além de confirmar resultados, a camada de consenso desempenha também um papel crucial como redundância de desastre para a camada de execução. Se a camada de execução parar permanentemente de funcionar ou agir de forma maliciosa, teoricamente qualquer camada de consenso pode assumir o trabalho da camada de execução e aceitar pedidos dos utilizadores. Se ocorrer uma situação tão grave, a comunidade deve escolher nós estáveis e fiáveis como servidores da camada de execução.

Camada de Liquidação

Uma vez que SCP não é Rollup, não pode alcançar levantamentos sem confiança como a camada de resolução de levantamentos 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 testemunha de terceiros, que dependem de gestores de multiassinaturas autorizados para liberar ativos, conhecidos como o modo de testemunha.

Tornar a ponte testemunha o mais descentralizada possível é um tópico de pesquisa para muitas pontes inter-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 reputáveis de múltiplas assinaturas descentralizadas de pontes. Alguns podem perguntar por que 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 contratos de verificação correspondentes puderem ser construídos, 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, esta pode não ser a melhor escolha:

1. O Ethereum não foi especificamente projetado para armazenamento de dados e, em comparação com blockchains dedicados exclusivamente ao armazenamento de dados, é bastante caro. Para o paradigma SCP, um custo de armazenamento suficientemente baixo ou fixo é crucial. Apenas assim pode suportar a taxa de transferência ao nível do 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 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 em 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 planeia implementar um sistema mais amplo e aberto, afastando-se do quadro EVM para integrar mais funcionalidades Web2, então a abordagem do Ethereum Rollup 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 de seguir a abordagem da camada 2 do Ethereum.

Uma ilustração compara SCP com outros paradigmas

Aviso Legal：

1. Este artigo é reproduzido a partir de [GateGate Web3]. Todos os direitos de autor pertencem ao autor original [雾月，极客Web3]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.