Interpretação do SCP: Rompendo com o paradigma de infraestrutura confiável baseado em Rollup

Como sair da mentalidade Rollup e integrar a plataforma Web2 com Web3 com uma estrutura mais ampla e aberta?

Escrito por Wuyue, Geek Web3

**Introdução: **Este artigo apresentará prospectivamente um paradigma de design de infraestrutura Web3 que parece um pouco único - Paradigma de Consenso Baseado em Armazenamento (SCP). Embora este modelo de design de produto seja, em teoria, bastante diferente do modelo modular convencional soluções blockchain como Ethereum Rollup, mas é muito viável em termos de facilidade de implementação e facilidade de conexão com a plataforma Web2, porque desde o início, eu não pretendia me limitar a um caminho de implementação estreito como Rollup. queria usar uma estrutura mais ampla e aberta para integrar a plataforma Web2 e os recursos Web3, o que pode ser considerado um cérebro. Uma abordagem totalmente aberta e imaginativa.

Texto: Imaginemos uma solução de expansão de cadeia pública com as seguintes características:

• Possui uma velocidade comparável a aplicativos ou trocas Web2 tradicionais, excedendo em muito qualquer cadeia pública, L2, rollup, cadeia lateral, etc.
• Não há taxa de gás e o custo de uso é quase zero.
• A segurança dos fundos é elevada, excedendo em muito a das instalações centralizadas, como as bolsas, inferior ao Rollup, mas superior ou igual às cadeias laterais.
• A mesma experiência de usuário do Web2, sem qualquer conhecimento das chaves públicas e privadas, carteiras, infraestrutura, etc. do blockchain.

Tal solução é realmente muito interessante: por um lado, basicamente alcançou o máximo em expansão de capacidade; por outro lado, também estabeleceu uma base muito sólida para a adoção em massa da Web3, basicamente eliminando a lacuna entre Web2 e Web3 experiência de uso.

No entanto, não conseguimos imaginar quantas soluções podem ser tão completas, porque há, de facto, muito pouca discussão e prática corrente.

Usamos a expansão, um tópico muito familiar, como introdução acima. Na verdade, o SCP não se limita à expansão. Sua inspiração de design vem dos planos de expansão e das discussões comunitárias de redes públicas como Bitcoin e Ethereum. Sua visão e aplicação prática é construir uma nova geração de infraestrutura confiável, até mesmo uma plataforma de computação não-blockchain. **

Componentes básicos e princípios de funcionamento do SCP

De modo geral, **SCP também é como o que as comunidades Ethereum e Celestia chamam de “blockchain modular”. **Tem divisões de módulos, como camada de disponibilidade de dados, camada de execução, camada de consenso e camada de liquidação.

• Camada de disponibilidade de dados: É assumida por uma cadeia pública amplamente reconhecida e comprovada, ou instalações de armazenamento como camada de disponibilidade de dados, como Ethereum, Arweave, Celestia, etc.
• Camada de execução: Um servidor usado para receber transações do usuário e executá-las e, ao mesmo tempo, enviar dados de transações assinadas pelo usuário para a camada DA em lotes, semelhante ao sequenciador do Rollup. Mas a camada de execução não tem necessariamente uma estrutura de lista vinculada no estilo blockchain, pode ser completamente um banco de dados Web2 + sistema de computação, mas todo o sistema de computação deve ser de código aberto e transparente.
• Camada de consenso: É composta por um grupo de nós, que puxam os dados enviados pela camada de execução para a camada DA e usam o mesmo algoritmo da camada de execução para operar nesses dados e confirmar se o resultado a saída da camada de execução está correta e pode ser usada como redundância de prevenção de desastres para a camada de execução. Os usuários também podem ler os dados retornados por cada nó na camada de consenso para garantir que não haja fraude na camada de execução.
• Camada de liquidação: É composta por um grupo de nós e contratos ou endereços em outras cadeias. É usada para lidar com o comportamento dos usuários recarregando no SCP ou retirando dinheiro do SCP. É um pouco semelhante ao modo de operação de uma ponte de cadeia cruzada. O nó da camada de liquidação controla a função de retirada do endereço de recarga por meio de contratos multi-assinados ou endereços baseados em TSS. Ao recarregar, o usuário deposita os ativos no endereço designado na cadeia e, ao retirar, é enviada uma solicitação.Após a leitura dos dados, o nó da camada de liquidação libera os ativos por meio de assinatura múltipla ou TSS. O nível de segurança da camada de liquidação depende do mecanismo cross-chain adotado.

Estrutura prática do SCP

Podemos entender o paradigma SCP através da seguinte estrutura. Um produto que atenda à estrutura do SCP pode ter funções principais, como recarga, transferência, saque, troca, etc., e pode ser expandido ainda mais nesta base. A imagem abaixo é um diagrama esquemático de tal produto:

• A camada DA do projeto usa o armazenamento permanente Arweave, o grande círculo na imagem.
• **Coordenador, a camada de execução. **O usuário envia a transação ao coordenador, o coordenador executa a operação e exibe os resultados da operação e, em seguida, envia os dados de entrada originais do usuário para a camada DA em lotes.
• Detector extrai os dados da transação original enviados pelo coordenador do Arweave e usa o algoritmo consistente com o coordenador para verificar os dados e resultados. O cliente detector também é de código aberto e pode ser executado por qualquer pessoa.
• **Watchmen, grupo de testadores encarregados da multiassinatura do sistema de saque. **As solicitações de saque serão verificadas e liberadas com base nos dados da transação. Além disso, o vigilante também é responsável pela assinatura da proposta.

Podemos ver todo o sistema, e o consenso que eles alcançaram está todo localizado fora da cadeia. Este é o núcleo do paradigma de consenso de armazenamento - ele abandona o sistema de consenso de nós no estilo blockchain e libera a camada de execução do consenso pesado. A comunicação e o processo de confirmação requer apenas o trabalho de um servidor, alcançando assim TPS e economia quase ilimitados. Isso é muito semelhante ao Rollup, mas o SCP seguiu um caminho diferente do Rollup, transformando-o de um caso de uso dedicado para expansão de capacidade em um novo modelo de transição da Web2 para a Web3. **

O coordenador citado acima é um servidor, mas isso não significa que o coordenador possa fazer o que quiser. Semelhante ao classificador do Rollup, depois que os dados originais enviados pelos usuários são enviados em lotes no Arweave, qualquer pessoa pode executar o programa detector para verificá-los e compará-los com o status retornado pelo coordenador. **Até certo ponto, isso é exatamente igual à ideia dos aplicativos de inscrição. **

Sob esta arquitetura, um servidor e banco de dados centralizados não representam um desafio fundamental. Este é também outro ponto do paradigma SCP, que une e separa os dois conceitos de “centralização” e “entidade única” - **Em um sistema sem confiança, pode haver componentes centralizados, **pode até ser um componente central, mas isso não afeta a falta de confiança geral.

Podemos gritar esse slogan - “A próxima geração de infraestrutura confiável não precisa depender de protocolos de consenso, mas deve ser sistemas de código aberto e redes de nós P2P”.

A intenção original das pessoas que inventam e usam o blockchain é desconfiar, livros-razão consistentes, fundamentos infalsáveis, rastreáveis e outros fundamentos comuns, que são claramente declarados no white paper do Bitcoin. **Mas depois do Ethereum, **seja o plano de expansão da antiga cadeia pública, ou Rollup ou blockchain modular, todos formaram uma mentalidade: o que fazemos deve ser um blockchain (consiste no protocolo de consenso dos nós), ou uma solução como Rollup que se parece com uma cadeia (possui apenas a estrutura de dados do blockchain, mas os nós não trocam mensagens de consenso diretamente).

Mas agora, sob a estrutura baseada em SCP, mesmo que não seja um blockchain, uma série de requisitos como falta de confiança, consistência contábil, não falsificação, rastreabilidade, etc. podem ser alcançados. Claro, a premissa é que deve haver detalhes de implementação mais claros.

Camada de execução

A camada de execução é crucial em todo o sistema, pois realiza o processo de computação de todo o sistema e determina quais aplicativos podem ser executados no sistema.

Infinitos ambientes de execução possíveis

Teoricamente, o ambiente de execução na camada de execução pode ter qualquer formato, e as possibilidades são infinitas, dependendo de como a parte do projeto posiciona seu projeto:

*Intercâmbio. Com base no SCP, pode-se construir uma exchange aberta, transparente e de alto TPS, que pode não apenas ter as características de velocidade e custo zero da CEX, mas também manter a descentralização da DEX. A distinção entre CEX e DEX fica confusa aqui.

• Rede de pagamento. Semelhante a Alipay, PayPal, etc.
• Suporte a máquina virtual/blockchain para carregar programas/contratos. Qualquer desenvolvedor pode implantar qualquer aplicativo nele, compartilhar todos os dados do usuário com outros programas e operar de acordo com as instruções do usuário.

**SCP, um modelo de design que suporta ambientes de execução arbitrários, tem seus benefícios exclusivos: **Você não precisa mais depender de determinados componentes com bagagem histórica, especialmente o conceito de “abstração de conta” exclusivo da comunidade Ethereum, que é muito importante ao SCP. Diz-se que não é necessário por natureza.

Na arquitetura SCP, não há conceito de abstração de conta - você pode usar contas padrão Web2 e contas blockchain à vontade. Dessa perspectiva, muitos casos de uso maduros da Web2 podem ser usados diretamente no SCP sem repensar e construir. Este pode ser o benefício do SCP em comparação com o Rollup. **

Transparência e Assimetria

O sistema de contas foi mencionado acima. Leitores sensíveis devem ter descoberto que embora o SCP possa fazer uso do sistema de contas Web2, parece haver problemas em usá-lo inalterado.

Porque todo este sistema é totalmente transparente! O uso direto do modelo de interação usuário-servidor causará sérios problemas, resultando em falta de segurança para todo o sistema. Vamos primeiro revisar como funciona o modelo servidor-usuário tradicional:

1. Cadastro de conta: O usuário digita o nome de usuário e senha na página de cadastro do aplicativo. Para proteger a senha do usuário, o servidor processa a senha por meio de uma função hash após recebê-la. Para aumentar a complexidade do hash e proteger contra ataques à tabela arco-íris, a senha de cada usuário é frequentemente concatenada com uma string gerada aleatoriamente (chamada de “sal”) e misturada com hash. **O nome de usuário, salt e hash são armazenados em texto não criptografado no banco de dados do provedor de serviços e não são divulgados ao público. **Mas mesmo assim, a salga e o tratamento de segurança ainda são necessários para prevenir ataques internos e ataques.

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

3. Autenticação de operação: Após a autenticação de login ser aprovada, o sistema criará uma sessão para o usuário. Normalmente, as informações da sessão são armazenadas no servidor e o servidor envia uma identificação (como um token) ao navegador ou aplicativo do usuário. Os usuários não precisam mais digitar novamente seu nome de usuário e senha nas operações subsequentes: o navegador ou aplicativo salvará o identificador e o incluirá em cada solicitação para indicar que tem permissão do servidor associado.

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

1. Registro de conta: Na verdade, não há processo de registro de conta e não há sistema de nome de usuário-senha. As contas (endereços) não precisam ser cadastradas, elas existem naturalmente, e quem possui a chave privada controla a conta. A chave privada é gerada aleatoriamente localmente pela carteira e não envolve o processo de rede.

2. Login do usuário: O uso do blockchain não requer login. A maioria dos dApps não possui o processo de login, mas se conecta à carteira. Alguns dApps exigirão que os usuários realizem a verificação de assinatura após se conectarem à carteira para garantir que o usuário realmente possua a chave privada, em vez de apenas passar o endereço da carteira para o front end.

**3. Autenticação da operação: ** O usuário envia diretamente os dados assinados ao nó. Após a verificação, o nó transmitirá a transação para toda a rede blockchain. Após atingir o consenso da rede blockchain, a operação do usuário será confirmada .

A diferença entre os dois modos é causada pela simetria e pela assimetria. Em uma arquitetura servidor-usuário, ambas as partes possuem os mesmos segredos. Em uma arquitetura de usuário blockchain, apenas o usuário detém o segredo.

Embora a camada de execução do SCP possa não ser um blockchain, todos os dados precisam ser sincronizados com a camada DA visível publicamente. ** Portanto, os métodos de login e verificação de operação usados pelo SCP devem ser assimétricos. **Mas como não queremos que os usuários mantenham chaves privadas, usem carteiras e outras ações complicadas e experiências ruins que afetem a adoção em larga escala, há também uma forte demanda por aplicativos desenvolvidos em SCP para usar senhas de ID tradicionais ou OAuth autenticação de três partes para fazer login. Então, como combinar os dois?

Devido à natureza assimétrica da criptografia assimétrica e das provas de conhecimento zero, Imaginei duas soluções possíveis:

• Se desejar utilizar o sistema ID-senha, não poderá incluir este módulo de salvamento de senha no SCP, para que não fique visível para outras pessoas. A camada de execução SCP ainda usa as contas de chave pública e privada e a lógica de operação do blockchain, e não há registro, login, etc. **O ID do usuário corresponde na verdade a uma chave privada. **Claro, esta chave privada não pode ser salva no lado do projeto. Uma solução mais viável é usar 2-3 MPC para resolver o problema de armazenamento centralizado sem permitir que os usuários tenham o fardo de usar chaves privadas.
• **Ao depender do OAuth para fazer login, o JWT (Json Web Token) pode ser usado como método de autenticação. **Este método será um pouco mais centralizado do que o anterior, porque depende essencialmente do serviço de login de terceiros fornecido pelo principal fabricante do Web2 para autenticação de identidade.

• Ao usar um terceiro para efetuar login pela primeira vez, cadastre os campos no JWT que representam a identidade do usuário e a identidade do provedor de serviços no sistema. Nas operações subsequentes do usuário, as instruções de operação são usadas como entrada pública, e o JWT como um todo é usado como testemunha secreta para verificar a transação de cada usuário com o ZKP.
• Cada JWT tem um limite de tempo de expiração, e o usuário também solicitará um novo JWT na próxima vez que fizer login, portanto não há necessidade de mantê-lo permanentemente. Além disso, este sistema também precisa contar com JWK, que pode ser entendido como a chave pública fornecida pelo fabricante para verificar o JWK. Portanto, também vale a pena explorar como inserir JWK no sistema de maneira descentralizada e como lidar com a rotação de chaves privadas no futuro.

**Não importa qual método seja utilizado, os custos de desenvolvimento e computação são superiores aos do método tradicional, mas este também é um preço necessário a pagar pela descentralização. **Claro, se a parte do projeto não achar que a descentralização extrema é necessária, ou se houver diferentes marcos em diferentes estágios de desenvolvimento, está tudo bem sem esses projetos, porque a descentralização não é preto e branco, mas há uma área cinzenta entre.

Privacidade

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

PEDÁGIO

A forma como a camada executiva cobra é outro ponto que merece atenção. Porque o envio de dados para a camada DA também exige custos, incluindo a operação do seu próprio servidor. O primeiro objetivo principal do blockchain tradicional que cobra taxas de gás dos usuários é evitar que os usuários danifiquem a rede de transações fazendo um grande número de transações repetidas, e o segundo é classificar as transações com base no gás. Web2 não tem preocupações semelhantes, portanto existem apenas conceitos básicos como inundação e DDoS.

**A camada de execução pode personalizar diversas estratégias de cobrança, como totalmente gratuita ou parcialmente cobrada. **Também pode lucrar com outros comportamentos, como MEV (muito maduro no sequenciador), atividades de mercado, etc.

Resistência à censura

A camada de execução não é resistente à censura e pode, teoricamente, negar as transações dos usuários sem limites. No Rollup, a resistência à censura pode ser garantida pela função de coleta forçada do contrato L1, enquanto a cadeia lateral ou cadeia pública é uma rede blockchain distribuída completa e é difícil de censurar.

**Atualmente não existe uma solução clara para o problema da resistência à censura, que é um problema do paradigma SCP. **

Camada de consenso

Esta camada é composta por nós soltos, que não formam ativamente uma rede, portanto não é uma camada de consenso em sentido estrito, mas é usada apenas para confirmar o status atual da camada de execução para o mundo externo (como usuários).

Por exemplo, se você tiver alguma dúvida sobre a saúde desses nós, poderá baixar o cliente detector, que executará o mesmo código do programa do coordenador. **

No entanto, isso é semelhante ao Rollup: como os dados são enviados em lotes, o status retornado ao usuário pela camada de execução é sempre mais recente que o da camada DA. Isso envolve um problema de pré-confirmação:

**A camada de execução fornece aos usuários resultados pré-confirmados e finais suaves, **porque eles ainda não foram submetidos à camada DA;

**A camada de consenso fornece aos usuários uma finalidade definitiva. **Os usuários podem não se importar particularmente com isso, mas para aplicações como pontes de cadeia cruzada, a finalidade rígida deve ser seguida. Por exemplo, o sistema de depósito e retirada da bolsa não acreditará nos dados transmitidos fora da cadeia pelo sequenciador Rollup. Ele deve esperar até que os dados sejam carregados no Ethereum antes de serem reconhecidos.

Além de ser utilizada para confirmar resultados, a camada de consenso também desempenha um papel muito importante, que é como redundância de prevenção de desastres para a camada de execução. **Se a camada de execução entrar em greve permanente e cometer crimes graves, em teoria qualquer camada de consenso pode assumir o trabalho da camada de execução e receber solicitações dos usuários. Se ocorrer uma situação tão grave, a comunidade deve escolher um nó estável e confiável como servidor da camada de execução.

Camada de liquidação

Como o SCP não é um Rollup, ele não pode realizar retiradas sem confiança que não exijam intervenção manual e sejam totalmente baseadas em criptografia e código de contrato inteligente, como a camada de liquidação de retiradas do Rollup. **O nível de segurança da ponte de cadeia cruzada SCP é o mesmo da ponte de cadeia lateral ou da ponte de cadeia cruzada de testemunha de terceiros. **Ela precisa contar com gerenciadores de assinaturas múltiplas autorizados para liberar ativos. Chamamos isso de modo testemunha .

Tornar a ponte testemunha o mais descentralizada possível é um tópico de muitos estudos de pontes entre cadeias. Devido às limitações de espaço, não entraremos em detalhes aqui. Na prática, uma plataforma SCP bem projetada também deve ter um parceiro respeitável com múltiplas assinaturas de uma ponte descentralizada.

**Alguém pode perguntar por que o SCP não usa uma cadeia com contratos inteligentes como camada DA? **Isso permite uma camada de liquidação baseada em contrato e totalmente sem confiança.

No longo prazo, desde que algumas dificuldades técnicas sejam superadas, se a camada DA for colocada na camada DA com contratos como o Ethereum, e os contratos correspondentes para verificação puderem ser construídos, o SCP também poderá obter a mesma segurança de liquidação que o Rollup. Não há necessidade de usar múltiplas assinaturas.

Mas na prática esta pode não ser a melhor escolha:

1. Ethereum não é usado especificamente para armazenamento de dados e o preço é muito alto em comparação com uma cadeia pública de armazenamento de dados puro. **Para o paradigma SCP, custos de armazenamento suficientemente baixos ou fixos são cruciais. **Somente desta forma será possível oferecer suporte à taxa de transferência no nível Web2.

2.** Prova que o sistema é muito difícil de desenvolver, pois o SCP pode não apenas simular EVM, mas também implementar qualquer lógica. **E quando olhamos para equipes como a Optimism, cuja prova de fraude ainda não está online, e como é difícil desenvolver o zkEVM, podemos imaginar que é extremamente difícil implementar a prova de vários sistemas no Ethereum.

Portanto, **Rollup é uma solução que tem melhor viabilidade prática apenas em circunstâncias específicas.**Se você planeja implementar uma solução mais ampla e aberta, livre-se do sistema EVM e integre mais recursos Web2, então Ethernet A ideia de Fang Rollup não é adequado.

**SCP não é um plano de expansão de cadeia pública específico, mas uma arquitetura de plataforma de computação Web3 maior, portanto, obviamente não é necessário seguir a ideia da Camada 2 do Ethereum. **

Uma imagem comparando SCP e outros paradigmas