Tomando a Rede de Partículas como exemplo, a tecnologia interpreta os problemas de experiência dos produtos Web3 atuais

Autor: Wuyue, Geek Web3

Introdução: Embora a carteira AA tenha reduzido o limite para os usuários em grande medida e inicialmente realizado pagamento de gás e login de conta web2, o design relacionado à adoção em massa, como login de privacidade - transação privada, conta AA unificada de cadeia completa e arquitetura dedicada de intenção, ainda precisa ser adicionado com base no AA.

Embora possamos ver muitas soluções de otimização de UX, como carteiras MPC como ZenGo ou carteiras de contratos inteligentes como Argent, que efetivamente diminuem o limiar para os usuários, elas apenas resolvem alguns dos problemas acima, e não cobrem totalmente a facilidade de uso do produto.

Obviamente, a maioria das carteiras AA ou produtos semelhantes ainda não são capazes de suportar a adoção em massa da Web3. Por outro lado, do ponto de vista ecológico, o lado do promotor é um nível muito importante, que só é atraente para os utilizadores comuns em termos de produtos, mas é difícil formar uma escala devido à sua influência insuficiente do lado do promotor. **O surgimento de cada vez mais soluções de otimização da experiência de desenvolvimento tem demonstrado a importância do lado do desenvolvedor para o ecossistema do produto.

Tomaremos a Rede de Partículas como exemplo para explicar em detalhes os problemas atuais da experiência dos produtos Web3 e como projetar uma solução técnica abrangente, que pode ser uma condição necessária para a adoção em massa. Ao mesmo tempo, a estratégia de negócios BtoBtoC da Pparticle é uma ideia com a qual muitas partes do projeto precisam aprender. **

Solução completa de estrutura de produto de partículas

Com o núcleo de resolver o limiar de uso, a Particle Network propõe um conjunto completo de soluções para a adoção em larga escala da Web3 com a ideia de construção de produtos B2B2C e desenvolvimento ecológico. Seus módulos principais são três:

**zkWaaS, um serviço Wallet-as-a-service (WaaS) baseado em provas de conhecimento zero. **Os desenvolvedores podem integrar rapidamente o módulo de carteira inteligente em seu próprio dApp com base no SDK fornecido pelo Particle. A carteira é uma carteira de contrato inteligente sem chave baseada na abstração da conta, que pode não apenas realizar cenários básicos de AA, como pagamento de gás, mas também fornecer métodos de login de privacidade OAuth no estilo Web2 e transações privadas e outras funções.

Particle Chain - Uma solução Omnichain Account Abstraction dedicada à Particle, dedicada a resolver a implantação, manutenção e invocação de carteiras de contratos inteligentes entre cadeias. Há também um Token de Gás Unificado (Unified Gas Token) para resolver o problema de usar diferentes moedas de gás para transações de várias cadeias.

**O Intent Fusion Protocol, que inclui uma linguagem DSL (Domain Specific Language) concisa, Intent Framework, Intent Solver Network, etc., é usado para construir um conjunto de estruturas de interação Web3 baseadas em Intent. Os usuários declaram diretamente sua intenção de transação em vez de executar cada ação específica, liberando os usuários de um caminho complicado e reduzindo sua compreensão da complexa infraestrutura subjacente.

zkWaaS – Smart Wallet-as-a-Service combinado com ZK

No lado da carteira, a Particle fornece principalmente SDKs para desenvolvedores dApp na forma de WaaS (Smart Contract Wallet-as-a-Service), a fim de permitir que os desenvolvedores acessem sua estrutura completa de opções em massa Web3. Esta solução BtoBtoC tem várias vantagens do ponto de vista empresarial e ecológico:

**A concorrência das carteiras C-end puras tornou-se branca-quente, e as funções são relativamente semelhantes, e as carteiras C-end já não são um bom ponto de entrada. Por outro lado, os desenvolvedores do dApp estão cada vez mais inclinados a construir carteiras no dApps para evitar a perda de experiência quando os usuários precisam trocar de carteira ao conectar carteiras e transações, e fornecer recursos mais personalizáveis.

**O custo de aquisição de clientes é alto no lado C, mas é diferente no lado B. **O crescimento de usuários WaaS é impulsionado principalmente por dApps integrados com SDKs. Desde que a relação entre a BD e os desenvolvedores seja boa, todo o ecossistema pode ser expandido em um estilo de “cidade ao redor do campo”.

**Atualmente, as carteiras C-end estão focadas principalmente em finanças e ativos, e é difícil para nós dizer que este é o principal cenário da Web3 no futuro. Para realmente alcançar a adoção em massa da Web3, deve haver projetos que abstraiam os recursos mais básicos - identidade do usuário (conta) e operação do usuário (envio de transações/transações) como um serviço de baixo nível, e entregar os cenários mais ricos da camada superior para o dApp.

A partir da entrada de conexão dApp anterior, você pode observar a estreita relação de ligação entre a carteira e o dApp. **É muito importante aumentar a quota de mercado das carteiras tanto quanto possível do lado do dApp. Esta é a primeira prioridade para o modelo B2B2C. **

Construir um WaaS que atenda às necessidades dos usuários, reduza a barreira de entrada e seja de fácil acesso para os desenvolvedores é outro pilar do sucesso da solução. O zkWaaS da partícula tem três núcleos:

**1. Login de privacidade. **Usando métodos tradicionais de login Web2 em carteiras de contrato, como Twitter, Google, login WeChat e outros métodos de verificação OAuth, os usuários podem se livrar completamente das amarras do gerenciamento de chaves privadas e entrar na Web3 da maneira mais familiar e simples. Ao mesmo tempo, provas de conhecimento zero são usadas para ocultar identidades de usuários.

2. Transações de privacidade. **Implemente transferências privadas universais peer-to-peer através do mecanismo Smart Stealth Address e use ERC4337 Paymaster para permitir que o Stealth Address use ativos (patrocinadores de gás) sem gás.

**3. Conclua a função da carteira AA. **O módulo de carteira da Partícula está totalmente em conformidade com os requisitos básicos do ERC-4337, incluindo Bundler, EntryPoint, Paymaster, Smart Wallet Account e outras partes importantes dos fluxos de trabalho do ERC-4337, one-stop para atender aos requisitos funcionais do DAPP ou usuários para carteiras inteligentes.

Login de privacidade da carteira on-chain baseado em contas web2

A solução de login privado da Partícula faz uso do JWT (Json Web Token), que pode ser usado para autenticação de identidade Web2 e operação de carteira dentro do contrato.

JWT é um tipo de certificado de identidade emitido pelo servidor para o cliente que é amplamente utilizado na Internet tradicional, e o cliente confia nessa prova para autenticar cada vez que interage com o servidor.

Existem vários campos-chave no JWT que são a base para o contrato verificar a identidade:

·" iss" (Emissor) indica o editor do JWT, ou seja, o servidor, como Google, Twitter, etc.

·" aud" (Audiência) indica o serviço ou aplicativo usado pelo JWT, se você fizer login no Medium com o Twitter, este campo indicará que o JWT se aplica ao Medium quando o Twitter emite o JWT.

·" sub" (Assunto) refere-se à identidade do usuário que aceita o JWT, que geralmente é marcado por um UID.

Na prática, o ISS e o sub não mudarão na grande maioria dos casos, caso contrário trará uma enorme bagunça de sistemas internos e referências externas. Portanto, esses parâmetros podem ser usados pelo contrato para determinar a identidade do usuário,** para que o usuário não precise gerar e manter a chave privada. **

O conceito correspondente ao JWT é JWK (JSON Web Key), que é um conjunto de pares de chaves no lado do servidor. Quando o servidor emite um JWT, ele assina com a chave privada do JWK, e a chave pública correspondente é pública e usada para verificar sua assinatura para outros serviços.

Por exemplo, se você fizer login no Twitter no Medium, o Medium verificará o JWT com a chave pública JWK que o Google tornou pública para confirmar que o JWT é autêntico — que ele foi realmente emitido pelo Google. JWK também é usado para validação de contrato de JWT.

O fluxo da solução de login privado da partícula é mostrado na figura a seguir:

Entre eles, vamos pular o circuito ZK específico aqui. Liste apenas alguns dos pontos-chave do processo:

**O contrato do Verificador que verifica as informações de login só perceberá uma Prova ZK relacionada à identidade do usuário-JWT, bem como um eph_pk inócuo, e não poderá obter diretamente a chave pública da carteira correspondente ou informações JWT, de modo a proteger a privacidade do usuário, e o mundo exterior não pode saber a identidade da pessoa de login a partir dos dados on-chain. **

Eph_pk (par de chaves efêmeras) é um par de chaves usado em uma única sessão, não a chave pública ou privada da carteira, e o usuário não precisa se importar.

Este sistema também pode ser usado para verificação off-chain, e pode ser usado para carteiras de contrato que usam lógica, como MPC.

Uma vez que este é um verdadeiro esquema de verificação de contrato baseado em logins tradicionais, os usuários também podem designar outros contatos sociais como seus guardiões em caso de situações muito extremas, como o cancelamento da conta Web2.

Transações privadas baseadas no método de troca de chaves DH

Antes de falar sobre a solução de transação privada da Particle, vamos primeiro examinar como conseguir transações privadas para destinatário dentro do sistema EVM existente, ou seja, ocultar o endereço do destinatário.

Vamos supor que Alice é o emissor e Bob é o recetor, e temos alguns conhecimentos comuns:

1. Bob gera a chave de gastos raiz m e o meta-endereço furtivo M. M pode ser gerado por m, e a relação entre os dois é M = G * m, que representa uma relação matemática em operações criptográficas.

2. Alice obtém o meta endereço M furtivo de Bob de qualquer maneira.

3. Alice gera uma chave privada temporária r e usa generate_address algorítmicos (r,M) para gerar um endereço oculto A. **Este endereço é exclusivo de Bob **** endereço furtivo, e Bob tem o controle do endereço depois de receber os ativos. **

4. Alice então gera uma chave pública temporária R com base na chave privada temporária r e a envia para o contrato de registro de chave pública temporária (ou qualquer local mutuamente acordado, seja qual for o canal, desde que Bob possa obtê-la).

5. Bob precisa verificar periodicamente o contrato de registro de chave pública temporária e registrar cada chave pública temporária atualizada. Como o efêmero contrato de chave pública é público e contém chaves relacionadas a transações privadas enviadas por outros, Bob não sabe qual Alice enviou para ele.

6. Bob verifica cada registro atualizado e executa generate_address (R,m) para calcular o endereço editado. Se houver um ativo no endereço, ele é gerado por Alice e autorizado a ser controlado por Bob, caso contrário, não tem nada a ver com Bob.

7. Bob executa o generate_spending_key(R,m) para gerar a chave privada do consumidor para o endereço furtivo, ou seja, p = m + hash(A), e então pode controlar o endereço A gerado por Alice.

A descrição do processo acima na verdade simplifica muitas operações matemáticas complexas,**Todo o processo de troca de inteligência é como dois espiões escrevendo algumas palavras de código que só podem ser decifradas um pelo outro em um quadro de avisos público,**Embora os métodos de geração e descriptografia de palavras de código sejam públicos, apenas dois espiões conhecem os dados importantes necessários no meio, portanto, mesmo que o mundo exterior conheça os métodos de geração e descriptografia de palavras de código, elas ainda não podem ser descriptografadas sem problemas.

Este processo de troca é muito semelhante ao conhecido método de troca de chaves Diffie-Hellman, no qual ambas as partes podem calcular o segredo compartilhado – Endereço oculto A acima – sem revelar seus respetivos segredos (a chave privada do consumidor raiz de Bob m e a chave privada temporária r de Alice). **Se você não sabe sobre a troca DH, você pode usar o diagrama de coloração a seguir para entendê-lo metaforicamente.

Um passo adicional em comparação com o DH é que, depois que cada um deles descobriu o endereço secreto compartilhado A, eles não podem usá-lo como a chave privada, porque Alice também conhece A. É necessário construir a chave privada do consumidor p = m + hash(A), e tratar A como uma chave pública. Como mencionado anteriormente, a chave privada do consumidor raiz m é conhecida apenas por Bob, então Bob se torna o único controlador do endereço furtivo. **

Obviamente, com este método de transferências privadas, cada vez que o destinatário recebe uma nova transação, os fundos para essa transação fluirão para um novo endereço EOA. O recetor pode usar a chave privada de consumo raiz para calcular a chave privada de consumo de cada endereço separadamente para ver qual está realmente relacionado a ele.

Mas agora há outro problema, este endereço stealth recém-gerado ainda é uma conta EOA no início, pode não haver tokens de gás como ETH nele, Bob não tem como iniciar transações diretamente, ** precisa usar a função Paymaster da carteira de contrato inteligente para pagamento de gás, a fim de alcançar transações privadas. **Portanto, é necessário fazer algumas alterações no endereço de recebimento:

Calcule um endereço contrafactual usando o método de cálculo de endereço no método CREATE2 quando o contrato é implantado, com os parâmetros correspondentes (definindo o endereço oculto A como o proprietário do contrato, etc.). Este é um endereço de contrato calculado, mas o contrato ainda não foi implantado, e ainda é EOA por enquanto.

**Alice irá transferir dinheiro diretamente para o endereço contrafactual. **Quando Bob quiser usá-lo, ele pode criar uma carteira de contrato diretamente neste endereço, para que ele possa ligar para o serviço de pagamento de gás (este passo também pode ser feito pela rede Alice ou Particle em seu nome).

Podemos chamar o endereço Counterfactual acima de um endereço furtivo inteligente. Bob usa o seguinte processo para usar anonimamente os ativos sob o endereço Smart Cloak:

Recarregue o Paymaster através de qualquer um dos seus próprios endereços, e o Paymaster devolverá uma prova de fundos (ZK).

Com o mecanismo AA, envie uma UserOperation para o nó Bundler com qualquer outro endereço (pode não ter saldo) para chamar os ativos sob o endereço oculto acima. Bob simplesmente fornece prova de fundos para a Paymaster com um novo endereço, e a Paymaster paga pela transação de empacotamento do Bundler.

Isto é realmente semelhante ao funcionamento do Tornado Cash, através de proof-of-funds (ZK), que pode provar que houve um recheio no conjunto de nós de folha na árvore Merkle, e ninguém pode saber qual nó de folha foi consumido quando foi gasto, de modo a cortar a conexão entre o consumidor e o depositante.

Resumindo, o Particle combina AA e endereços ocultos, e inteligentemente realiza transferências privadas na forma de carteiras ocultas inteligentes.

Cadeia de partículas & Abstração de Conta de Cadeia Completa

Particle Chain é uma cadeia POS projetada para Omnichain Account Abstraction. Concentrando-se na situação atual e no futuro, é impossível ser um mundo de cadeia única, e é crucial melhorar a experiência do usuário em um ambiente de trabalho multicadeia.

Atualmente ERC4337 sistema de abstração de contas terá alguns problemas no caso de cadeias múltiplas:

O endereço do mesmo utilizador em diferentes cadeias pode não ser uniforme, dependendo da conceção do contrato.

Os usuários precisam repetir manualmente as operações de gerenciamento entre várias cadeias para gerenciar carteiras de contrato em cadeias diferentes, como a mudança de administradores. Pior ainda, se os privilégios de administrador forem atualizados em uma cadeia e, em seguida, o antigo método de autenticação de administrador for descartado, a carteira não poderá ser alterada em outras cadeias.

Para usar diferentes cadeias, você precisa ter moedas de gás em cada cadeia, ou ter fundos pré-depositados no Paymaster em cada cadeia. Há também uma certa quantidade de problemas para os desenvolvedores, se eles querem que os usuários usem ou implementem outras funções a custo zero sob certas condições, eles também precisam implantar seu próprio Paymaster personalizado em cada cadeia e depositar fundos nela.

A abstração de conta de cadeia completa da Particle Chain aborda os pontos problemáticos acima:

Crie uma carteira AA no Particle Chain.

Através do protocolo de cadeia cruzada AMB (Arbitrary Message Bridge), como o LayerZero, várias operações, como novas permissões de criação, atualização, alteração, etc., são sincronizadas com outras cadeias. **Pode-se entender que outras carteiras na cadeia são referências às carteiras na cadeia, e apenas o corpo principal precisa ser modificado para ser sincronizado com todas as carteiras.

**Contrato Deployer com parâmetros consistentes para garantir que o endereço da carteira em cada cadeia seja o mesmo. **

As carteiras entre cadeias também podem ligar umas para as outras através da AMB, nem todas iniciadas a partir da Cadeia de Partículas.

**Emissão de Token de Gás Unificado, uma moeda de gás de cadeia completa. **O ERC20 é implementado pelo mecanismo Paymaster como uma taxa de gás. Mesmo que não haja gás ou fundos pré-depositados Paymaster em uma determinada cadeia, você pode iniciar uma transação entre cadeias em uma cadeia qualificada para consumir o Token de Gás Unificado.

Para além das utilizações acima referidas, a cadeia de partículas pode também ser utilizada no futuro:

Uma rede descentralizada gerada pelo Proof and Salt da zkWaaS.

A camada de incentivo de cada cadeia Bundler ajuda o Bundler a alcançar uma melhor descentralização.

Uma rede Solver como um protocolo de fusão de intenção.

Na narrativa da Cadeia de Partículas, o Token de Gás Unificado é o valor central de todo o ecossistema:

A função de pagar taxas de gás é uma forte lógica de captura de demanda e valor que tem sido repetidamente verificada em criptomoedas.

O Token de Gás Unificado abstrai o conceito de camada de gás da ecologia de cadeia pública existente, e essa abstração não pode ser alcançada sem Cadeia de Partículas e carteira, então o Token de Gás Unificado é uma retirada de valor de toda a ecologia de partículas. Com a camada de gás, a interação do usuário e o crescimento de cada cadeia e o valor da moeda local são mutuamente benéficos e simbióticos com o Token de Gás Unificado.

O gás unificado também é um dos fatores determinantes para a realização do Chainless. Para os utilizadores, pagar numa moeda única simplifica muito o processo e a compreensão dos custos. No futuro, mesmo no cenário de várias cadeias, é provável que os utilizadores sejam insensíveis e não precisem de se preocupar com o funcionamento da infraestrutura subjacente. Assim como atualmente na Web2, não nos importamos em qual região a sala de computadores está localizada, qual configuração, qual idioma é usado e qual banco de dados funciona.

Os usuários importados pelo dApp habilitam diretamente o Unified Gas Token, e os cenários de uso são muito ricos.

Protocolo de fusão de intenção

Normalmente, precisamos pensar constantemente sobre o caminho de uso ao usar vários dApps:

Se não houver liquidez em um DEX, você precisa olhar para outro DEX.

Eu não sei qual dApp da mesma categoria deve escolher para melhor concluir a transação ou transação.

· Aprovar então tem um monte de recursos para usar, e o que é aprovar?

Pó de carteira, vários pequenos tokens em uma determinada moeda, o processo é complicado.

Para atingir o objetivo final, são necessárias várias aplicações. Como empréstimos de alta alavancagem: trocar, prometer, pedir emprestado, obter Token e depois trocar, prometer, pedir emprestado…

O acima é apenas a ponta do iceberg em nosso mundo DeFi atual, e na era da adoção em massa da Web3, onde os dApps estão se tornando mais diversos, as interações podem ser muito mais complexas do que você pensa.

Portanto, substituir etapas de operação específicas por intenção de intenção pode ser muito diferente para a experiência do usuário. A intenção é mais do que operacional, assim como a programação declarativa está para a programação funcional. As declarações declarativas tendem a parecer simples e diretas, apenas declaram o que vou fazer e não me importam com os detalhes, e isso requer uma variedade de instruções de programação funcional que são encapsuladas na parte inferior.

Então, o uso de Intents não é exceção, e também precisa ser apoiado por uma série de facilidades. Vamos dar uma olhada em todo o processo:

**1. O usuário envia para a rede Solver na forma de RFS (Request For Solver), como linguagem natural. **Solver é um intérprete de intenção, e existem agregadores como 1inch que podem encontrar o melhor dex para os usuários, mas eles não são genéricos e poderosos o suficiente em comparação com a nossa visão.

**2. Vários Solvers respondem uns aos outros, e eles estão em competição. Essas respostas são escritas na linguagem Intent DSL e analisadas pelo cliente em um formulário que é fácil para o usuário entender. Essas respostas consistem em Restrições de Entrada e Restrições de Saída, que definem os limites entre entrada e saída. Os usuários também podem especificar suas próprias restrições. Um exemplo simples de entender: ao usar o Swap, o usuário será solicitado ao valor mínimo que pode ser obtido após a troca, que é uma restrição. O usuário escolhe entre as respostas de vários Solvers por conta própria.

3. Assine a intenção.

**4.O Solver especifica um contrato de execução específico e submete a intenção ao reator do contrato de resposta. **

5. O Reator recolhe a entrada necessária (como um ativo) da conta de utilizador, submete uma intenção ao utor, e depois chama o contrato lógico relevante para devolver a saída da transação ao Reator. O reator verifica as restrições e devolve a saída ao usuário se estiver correta.

Podemos pensar neste processo como você diz ao ChatGPT sobre os requisitos, não importa o quão complexos os requisitos, ele pode gerar um resultado final para você, desde que você esteja satisfeito com os resultados, você pode usá-lo diretamente, sem se preocupar com o processo.

Resumo

A Particle Network propõe uma solução abrangente: através da trindade de zkWaaS, Particle Chain e Intent Fusion Protocol, o login de privacidade Web2 OAuth, transações privadas, abstração de conta de cadeia completa e paradigmas de transação de intenção são realizados. Cada recurso cobrirá alguns dos pontos problemáticos do uso da Web3, e esses avanços e otimizações se tornarão a base do produto e da tecnologia para a adoção em massa da Web3 no futuro. Em termos de ecologia e modelo de negócios, o paradigma B2B2C é adotado, WaaS é usado como a entrada para impulsionar a padronização em larga escala de toda a cadeia de produtos, e o ecossistema é construído com desenvolvedores dApp para criar em conjunto um mundo Web3 com baixo limiar e alta experiência para os usuários.

É claro que diferentes projetos têm entendimentos diferentes do caminho de implementação da adoção em massa da Web3. Além da revisão de projetos específicos, esperamos levar a uma compreensão do atrito a bordo que a Web3 está enfrentando atualmente, uma reflexão sobre as necessidades e pontos problemáticos do usuário e uma consideração pela conexão conjunta e desenvolvimento de todo o ecossistema.