Análise técnica: Camada de acesso da Web aberta construída pela Particle Network

Introdução: Embora as carteiras AA tenham reduzido significativamente as barreiras à entrada dos utilizadores e conseguido pagamentos de gás e logins de contas web2, os aspectos relacionados com a adoção em massa, como o login confidencial, as transacções confidenciais, a omnichain AA e o protocolo de fusão de intenções, ainda requerem um maior desenvolvimento na base da AA.

Embora vejamos várias soluções de otimização da experiência do utilizador, como a carteira MPC da ZenGo ou carteiras de contratos inteligentes como a Argent, que reduzem eficazmente as barreiras do utilizador, apenas abordam uma parte das questões acima mencionadas, sem abranger totalmente as preocupações gerais de usabilidade do produto.

É evidente que a maioria das carteiras AA ou produtos semelhantes não podem ainda suportar a adoção generalizada da Web3. Por outro lado, do ponto de vista do ecossistema, o lado do programador é um aspeto crucial. A atratividade para os utilizadores regulares, por si só, sem um impacto suficiente do lado dos programadores, não é suscetível de alcançar a escalabilidade. O aparecimento de mais soluções de otimização da experiência do programador indica a importância crescente do lado do programador no ecossistema do produto.

Tomando a Particle Network como exemplo, iremos analisar os actuais desafios de UX enfrentados pelos produtos Web3 e discutir como conceber uma solução técnica abrangente e direccionada. Este tipo de solução integrada pode ser uma condição necessária para a adoção em massa. Além disso, a estratégia comercial BtoBtoC da Particle serve como uma abordagem notável que muitas equipas de projeto podem considerar benéfica.

Repartição da estrutura do produto de partículas

A Particle Network, com o seu foco principal na redução das barreiras de utilização, adopta uma abordagem de construção de produtos B2B2C e de desenvolvimento ecológico, fornecendo uma solução abrangente para a adoção generalizada da Web3. Os seus módulos principais são constituídos por três componentes-chave:

zkWaaS refere-se a zero-knowledge wallet-as-a-service. Os programadores podem integrar rapidamente módulos de carteiras inteligentes nas suas dApps utilizando o SDK da Particle. A carteira é uma carteira de contrato inteligente sem chave baseada na abstração de contas, permitindo pagamentos de gás e oferecendo login confidencial OAuth de estilo Web2 e transacções confidenciais.

Particle Chain - O esquema dedicado de abstração de contas Omnichain concebido para o Particle visa resolver os desafios de implementação, manutenção e invocação entre cadeias para carteiras de contratos inteligentes. Inclui também o Token de Gás Unificado, simplificando a utilização de diferentes tokens de gás em transacções multi-cadeia.

Protocolo de fusão de intenções - Inclui uma linguagem específica do domínio (DSL) concisa, uma estrutura de intenções, uma rede de solucionadores de intenções, etc., para construir uma estrutura de interação Web3 baseada em intenções. Os utilizadores declaram diretamente as suas intenções de transação em vez de executarem cada operação específica, libertando-os de considerações intrincadas sobre o percurso e reduzindo a necessidade de compreender uma infraestrutura subjacente complexa.

zkWaaS - Wallet-as-a-Service de conhecimento zero

No lado da carteira, a Particle fornece principalmente SDKs para desenvolvedores de dApp na forma de Wallet-as-a-Service (WaaS). O objetivo é permitir que os programadores se integrem na sua estrutura abrangente de adoção em massa da Web3. Esta abordagem BtoBtoC tem várias vantagens, tanto do ponto de vista empresarial como do ponto de vista do ecossistema:

O mercado das carteiras electrónicas é altamente competitivo e as funcionalidades estão a tornar-se cada vez mais semelhantes. As carteiras dos consumidores já não são o ponto de entrada ideal. Por outro lado, os criadores de dApp preferem integrar carteiras nas suas aplicações para melhorar a experiência do utilizador e fornecer funcionalidades mais personalizáveis.

A aquisição de utilizadores do lado do consumidor é dispendiosa, mas do lado da empresa é diferente. O crescimento do número de utilizadores da WaaS resulta principalmente das dApps integradas no SDK. Com um desenvolvimento comercial eficaz e relações com os programadores, o ecossistema pode expandir-se organicamente.

As actuais carteiras dos consumidores centram-se principalmente nas finanças e nos activos, o que pode não representar os principais cenários para o futuro da Web3. Para conseguir uma adoção generalizada da Web3, as características fundamentais como a identidade do utilizador (contas) e as operações do utilizador (início de transacções) devem ser abstraídas como um serviço fundamental, deixando cenários mais ricos para serem tratados por dApps.

Historicamente, o ponto de entrada para dApps tem mostrado uma relação estreita entre carteiras e dApps. Aumentar a quota de mercado da carteira no lado da dApp é crucial. Isto é particularmente vantajoso para o modelo B2B2C.

Para construir uma solução que satisfaça as necessidades dos utilizadores, reduza as barreiras à entrada e facilite a integração dos programadores, o zkWaaS da Particle é um componente essencial com três características principais:

1. Login confidencial: Aproveitar os métodos tradicionais de login da Web2, como a verificação OAuth de plataformas como Twitter, Google, WeChat, etc., na carteira de contratos inteligentes. Isto permite que os utilizadores se libertem completamente dos constrangimentos da gestão de chaves privadas, entrando na Web3 da forma mais familiar e direta possível. Simultaneamente, a identidade do utilizador é ocultada utilizando provas de conhecimento zero.

2. Transacções confidenciais: Implementação de transferências de privacidade ponto-a-ponto através do mecanismo Smart Stealth Address, garantindo a privacidade universal nas transacções. Além disso, a utilização do Paymaster do ERC-4337 permite a utilização de activos sem gás para Smart Stealth Addresses (patrocínio de gás).

3. Funcionalidade abrangente da carteira AA: O módulo de carteira da Particle está em total conformidade com os requisitos fundamentais do ERC-4337. Inclui componentes essenciais como Bundler, EntryPoint, Paymaster, Smart Wallet Account e outros, cobrindo todos os aspectos críticos do fluxo de trabalho ERC-4337. Esta solução única satisfaz eficazmente as exigências funcionais das DApps ou dos utilizadores de carteiras inteligentes.

Login confidencial para carteiras na cadeia com base em contas Web2

A solução de login confidencial da Particle utiliza JSON Web Tokens (JWT), permitindo a autenticação de identidade Web2 e operações de carteira dentro do contrato inteligente.

O JWT é uma forma amplamente utilizada de prova de identidade em aplicações tradicionais da Internet, emitida pelo servidor para o cliente. O cliente utiliza esta prova para autenticação da identidade em cada interação com o servidor.

(Fonte: Documentação do FlutterFlow)

Existem vários campos-chave no JWT que constituem a base para a verificação da identidade pelo contrato:

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

- "aud" (Audiência): Especifica o serviço ou a aplicação a que se destina o JWT. Por exemplo, ao iniciar sessão no Medium utilizando o Twitter, o JWT emitido pelo Twitter incluirá este campo indicando a sua aplicabilidade ao Medium.

- "sub" (Assunto): Refere-se à identidade do utilizador que recebe o JWT, normalmente identificado pelo UID.

Na prática, os termos "iss" e "sub" mantêm-se geralmente constantes para evitar confusões substanciais entre sistemas internos e referências externas. Por conseguinte, estes parâmetros podem ser utilizados pelo contrato para determinar a identidade do utilizador, eliminando a necessidade de os utilizadores gerarem e salvaguardarem chaves privadas.

Correspondendo ao JWT está o conceito de JSON Web Key (JWK), um conjunto de pares de chaves no servidor. Ao emitir o JWT, o servidor assina-o com a chave privada do JWK, enquanto a chave pública correspondente é tornada pública para que outros serviços possam verificar a assinatura.

Por exemplo, quando o Medium utiliza o Twitter para iniciar sessão, o Medium valida o JWT utilizando o JWK público da Google para confirmar a sua autenticidade - que foi efetivamente emitido pela Google. A verificação do JWT no contrato implicará também a utilização do JWK.

O processo da solução de início de sessão confidencial do Particle está representado no diagrama abaixo:

Não falaremos aqui do circuito ZK específico, limitando-nos a salientar alguns pontos-chave do processo:

O contrato do verificador que valida as informações de início de sessão apenas terá em conta uma prova ZK relacionada com o JWT de identidade do utilizador e um eph_pk. Não pode adquirir diretamente a chave pública da carteira correspondente ou as informações JWT, garantindo a privacidade do utilizador e impedindo que entidades externas identifiquem o utilizador de início de sessão a partir de dados na cadeia.

eph_pk (ephemeral key pair) é um par de chaves utilizado numa única sessão e não é o par de chaves público-privado da carteira. Os utilizadores não precisam de se preocupar com isso.

Este sistema suporta a verificação fora da cadeia e pode ser utilizado para carteiras de contratos que utilizam uma lógica como a MPC (Multiparty Computation).

Uma vez que se trata de uma solução de verificação de contrato genuinamente baseada nos métodos de início de sessão tradicionais, os utilizadores podem também designar outros contactos sociais como tutores em casos extremos, como a desativação da conta Web2.

Transacções confidenciais baseadas na troca de chaves DH

Antes de discutir as transacções confidenciais do Particle, vamos examinar como conseguir transacções confidenciais para o destinatário dentro do sistema EVM existente, especificamente escondendo o endereço do destinatário.

Supondo que Alice é o remetente e Bob é o destinatário, ambas as partes partilham algum conhecimento comum:

1. O Bob gera uma chave de despesa de raiz (m) e um meta-endereço furtivo (M). M pode ser gerado por m, e a sua relação é representada por M = G * m, indicando uma relação matemática em operações criptográficas.

2. Alice obtém o meta-endereço secreto M do Bob através de qualquer meio.

3. Alice gera uma chave privada efémera (r) e utiliza o algoritmo generate_address(r, M) para criar um endereço furtivo (A). Este endereço serve como um endereço furtivo dedicado preparado para o Bob, com o Bob a ganhar controlo assim que os activos forem recebidos.

4. Alice gera uma chave pública efémera (R) com base na chave privada efémera r e envia-a para o contrato de registo da chave pública efémera (ou para qualquer local mutuamente acordado a que Bob possa aceder).

5. Bob examina periodicamente o contrato de registo de chaves públicas efémeras, registando todas as chaves públicas efémeras actualizadas. Uma vez que o contrato efémero de chave pública é público e contém chaves relacionadas com transacções de privacidade enviadas por outros, o Bob não sabe qual delas a Alice enviou para ele ver.

6. O Bob analisa cada registo atualizado, executando generate_address(R, m) para calcular o endereço furtivo. Se houver activos nesse endereço, isso significa que Alice o gerou e autorizou para o controlo de Bob; caso contrário, é irrelevante para Bob.

7. O Bob executa generate_spending_key(R, m) para gerar a chave de despesa para esse endereço furtivo, ou seja, p = m + hash(A). Assim, o Bob pode controlar o endereço A gerado pela Alice.

O processo descrito simplifica muitas operações matemáticas complexas. Todo o processo de troca de informações é semelhante a dois agentes secretos que escrevem mensagens enigmáticas num quadro de avisos público, mensagens que só podem ser decifradas um pelo outro. Embora os métodos de geração e desencriptação destas mensagens sejam públicos, os dados cruciais necessários para ambos os agentes só são conhecidos por eles. Consequentemente, mesmo que alguém de fora compreenda os métodos, a descodificação bem sucedida continua a ser difícil.

Este processo de troca é um pouco análogo ao conhecido método de troca de chaves Diffie-Hellman. Sem revelarem os seus segredos (a chave de gastos de raiz do Bob (m) e a chave privada efémera da Alice (r)), ambas as partes podem calcular um segredo partilhado - o endereço furtivo (A) mencionado anteriormente. Se não estiver familiarizado com o intercâmbio de DH, a compreensão metafórica pode ser facilitada através do diagrama abaixo.

Um passo adicional em relação ao DH é que, depois de calcular o segredo partilhado - endereço secreto (A), este não pode ser utilizado diretamente como chave privada porque Alice também conhece A. É necessário construir a chave de despesa (p = m + hash(A)) tratando A como uma chave pública. Como já foi referido, apenas o Bob conhece a chave de despesa de raiz (m), o que faz do Bob o único controlador deste endereço furtivo.

É claro que, neste método de transferência de privacidade, para cada nova transação recebida, os fundos irão para um novo endereço EOA. O destinatário pode utilizar a chave de despesa de raiz para calcular iterativamente a chave de despesa para cada endereço, experimentando até encontrar a que está genuinamente associada a eles.

No entanto, há ainda um problema. Inicialmente, este endereço furtivo recém-gerado ainda é uma conta EOA e pode não ter ETH ou outros tokens de gás. O Bob não pode iniciar transacções diretamente e precisa de utilizar o Paymaster de uma carteira de contrato inteligente para o pagamento de gás para conseguir transacções confidenciais. Por conseguinte, são necessárias algumas modificações no endereço do destinatário:

Utilizando o método de cálculo de endereço da função CREATE2 durante a implementação do contrato, juntamente com os parâmetros correspondentes (definindo o endereço furtivo A como o proprietário do contrato, etc.), calcule um endereço contrafactual. Trata-se de um endereço de contrato computorizado ainda não implementado, atualmente uma EOA.

Alice transfere diretamente os fundos para este endereço contrafactual. Quando Bob quiser utilizá-lo, cria diretamente uma carteira de contratos neste endereço, permitindo a invocação do serviço de pagamento de gás (esta etapa também pode ser tratada previamente por Alice ou pela rede Particle).

Podemos referir-nos ao endereço contrafactual acima mencionado como um endereço furtivo inteligente. O Bob utiliza anonimamente os activos ao abrigo deste Smart Stealth Address através do seguinte processo:

Deposite o Paymaster em qualquer um dos seus endereços, e o Paymaster devolver-lhe-á um comprovativo de fundos (baseado em ZK).

-Com o mecanismo AA, utilize qualquer outro endereço, que pode não ter saldo, para enviar UserOperation ao nó Bundler, invocando os activos sob o endereço furtivo mencionado. O Bob só precisa de fornecer um comprovativo de fundos ao Paymaster utilizando um novo endereço, e o Paymaster paga ao Bundler pela embalagem da transação.

Este processo é semelhante ao funcionamento da Tornado Cash. A prova de fundo (baseada em ZK) pode provar que ocorreu uma recarga no conjunto de nós folha da árvore de Merkle. No entanto, quando se gasta, ninguém pode determinar que fundos específicos do nó folha foram consumidos, cortando assim a ligação entre o consumidor e o recarregador.

Em resumo, o Particle combina inteligentemente AA com endereços furtivos, conseguindo transferências confidenciais através da forma de carteiras furtivas inteligentes.

Cadeia de partículas & Abstração da conta Omnichain

A Particle Chain é uma cadeia de POS concebida para a Omnichain Account Abstraction. Tendo em conta o presente e o futuro, é improvável que haja um domínio de uma única cadeia. É fundamental melhorar a experiência do utilizador num cenário de várias cadeias.

Atualmente, o sistema de abstração de contas ERC4337 pode deparar-se com alguns problemas numa situação de várias cadeias:

• Os endereços do mesmo utilizador em cadeias diferentes podem não ser uniformes, dependendo da conceção do contrato.
• A gestão de diferentes carteiras de contratos em cadeia requer operações manuais em várias cadeias, como a mudança de administradores. Em cenários piores, se as permissões de administrador forem actualizadas numa cadeia, seguido da eliminação do antigo método de validação de administrador, torna-se impossível fazer alterações noutras cadeias, tornando a carteira inutilizável.
• A utilização de cadeias diferentes requer a existência de fichas de gás para cada cadeia, ou fundos pré-armazenados no Paymaster de cada cadeia. Para os programadores, isto pode ser problemático. Se pretenderem que os utilizadores utilizem determinadas condições a custo zero ou implementem outras funções, têm de implementar os seus Paymasters personalizados em cada cadeia e pré-financiá-los.

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

• Estabeleça carteiras AA na Cadeia de Partículas.
• Use o LayerZero e outros protocolos de cadeia cruzada do Arbitrary Message Bridge (AMB) para sincronizar várias operações, como criação, atualização e alteração de permissões, para outras cadeias. Pode ser entendido como carteiras noutras cadeias que são referências à carteira nessa cadeia, com modificações no corpo principal a sincronizarem-se com todas as carteiras.
• Assegure endereços uniformes para as carteiras em cada cadeia através de um Contrato de Implementador de parâmetros consistente.
• As carteiras em cadeias diferentes podem também ligar-se umas às outras através da AMB, não necessariamente iniciadas a partir da cadeia de partículas.
• Emita uma ficha de gás unificada. O mecanismo Paymaster implementa ERC20 como taxas de gás. Mesmo numa cadeia sem gás ou fundos pré-armazenados no Paymaster, as transacções entre cadeias que consomem tokens de gás unificados podem ser iniciadas em cadeias compatíveis.

Para além dos casos de utilização acima mencionados, a Particle Chain também pode ser utilizada para:

• A rede descentralizada para provas de zkWaaS e geração de sal.
• Camadas de incentivos para os agregadores em diferentes cadeias, ajudando-os a alcançar uma maior descentralização.
• Servir de rede de solucionadores para o protocolo de fusão de intenções.

Na narrativa da Particle Chain, o token de gás unificado serve como uma proposta de valor central para todo o ecossistema:

• A funcionalidade de pagamento de taxas de gás é uma lógica de forte procura e captura de valor validada repetidamente no espaço criptográfico.
• O Token de Gás Unificado abstrai o conceito de camadas de gás dos ecossistemas de cadeias públicas existentes. Esta abstração, sem a cadeia de partículas e as carteiras, não pode ser alcançada. Portanto, o token de gás unificado representa uma realização de valor para todo o ecossistema da Particle. Com a camada de gás, a interação do utilizador, o crescimento e o valor do token nativo em diferentes cadeias estão numa relação mutuamente benéfica com o token de gás unificado.
• O gás unificado é também um dos factores determinantes para a realização do Chainless. Para os utilizadores, a utilização de uma moeda única simplifica muito o processo de utilização e a compreensão dos custos. No futuro, mesmo num cenário de várias cadeias, os utilizadores poderão não ter conhecimento e não precisar de se preocupar com o funcionamento da infraestrutura subjacente. À semelhança do que acontece atualmente na Web2, interagimos com os servidores sem nos preocuparmos com a localização dos centros de dados, as suas configurações ou as linguagens e bases de dados que utilizam.
• Os utilizadores importados por dApps dão diretamente poder ao token de gás unificado, oferecendo uma vasta gama de casos de utilização.

Protocolo de fusão de intenções

Normalmente, ao utilizar vários dApps, os utilizadores precisam de considerar constantemente os caminhos de utilização:

• Se não houver liquidez num DEX, é necessário verificar outro DEX.
• Escolha a dApp mais adequada dentro da mesma categoria para uma transação ou tarefa.
• Compreender o conceito de "Aprovar" antes de poder utilizar muitas funcionalidades.
• Tirar o pó das carteiras, converter várias pequenas quantidades de tokens num token específico - um processo fastidioso.
• Concluir várias etapas em diferentes aplicações para atingir um objetivo final. Por exemplo, no empréstimo de elevada alavancagem: troca, aposta, empréstimo, obtenção de fichas, troca de novo, aposta e empréstimo.

O conteúdo acima representa apenas um vislumbre do panorama atual da DeFi e, à medida que avançamos para a era da adoção generalizada de diversas dApps na Web3, a complexidade das interacções pode exceder em muito a nossa imaginação.

Por conseguinte, a substituição de etapas operacionais específicas por intenções proporciona uma experiência muito diferente aos utilizadores. As intenções, comparadas com as operações, são semelhantes à programação declarativa versus programação funcional. As declarações declarativas dão frequentemente uma sensação de simplicidade, exigindo apenas uma declaração do que deve ser feito, sem se preocupar com os pormenores subsequentes. Para tal, são necessários vários níveis de declarações de programação funcional encapsuladas nas camadas subjacentes.

Do mesmo modo, a utilização de Intents requer o apoio de uma série de instalações. Vamos examinar todo o processo:

1. Os utilizadores submetem as suas intenções, descrevendo-as de alguma forma, por exemplo em linguagem natural, sob a forma de RFS (Request For Solver), submetidas à rede Solver. O Solver é um intérprete de intenções e os solvers comuns, como o 1inch, um agregador que procura o DEX ideal para os utilizadores. No entanto, estes Solvers, em comparação com a nossa visão, podem não ser suficientemente versáteis e poderosos.

2. Vários solucionadores respondem, competindo entre si. Estas respostas são escritas na linguagem Intent DSL, posteriormente analisadas pelo cliente numa forma que seja fácil de compreender pelos utilizadores. Estas respostas incluem Restrições de Entrada e Restrições de Saída, que definem os limites das entradas e saídas. Os utilizadores também podem especificar as suas próprias restrições. Um exemplo simples para compreender: quando utiliza o Swap, o utilizador é informado do montante mínimo que pode receber após a troca, o que é uma forma de restrição. Os utilizadores escolhem entre as respostas fornecidas por vários Solvers.

3. Assine a intenção.

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

5. O Reator recolhe os dados necessários (como um ativo específico) da conta do utilizador, submete a intenção ao Executor e, depois de chamar o contrato lógico relevante, devolve o resultado da transação ao Reator. O Reator verifica as restrições e, se estiverem correctas, devolve o resultado ao utilizador.

Podemos imaginar este processo como se estivesse a explicar os seus requisitos ao ChatGPT. Independentemente da complexidade dos requisitos, pode gerar um resultado final para si. Desde que esteja satisfeito com o resultado, pode utilizá-lo diretamente sem se preocupar com o processo subjacente.

Conclusão

A Particle Network propôs uma solução abrangente: através da forma integrada do zkWaaS, da Particle Chain e do Intent Fusion Protocol, consegue o login de privacidade Web2 OAuth, as transacções de privacidade, a abstração da conta omnichain e um paradigma de transação baseado na intenção. Cada funcionalidade aborda uma parte dos pontos problemáticos na utilização da Web3. Estes avanços e optimizações servirão de base para a futura adoção generalizada de produtos e tecnologias Web3. Em termos de ecossistema e modelos de negócio, a adoção do paradigma B2B2C, a utilização de WaaS como ponto de entrada para impulsionar a escalabilidade e a normalização de toda a cadeia de produtos, a co-construção do ecossistema com os criadores de dApp e a criação conjunta de um mundo Web3 de baixo limiar e elevada experiência para os utilizadores.

Naturalmente, os diferentes projectos têm interpretações diferentes do caminho de implementação para a adoção em massa da Web3. Para além da análise de projectos específicos, esperamos utilizar diferentes soluções para realçar a compreensão da fricção de onboarding que a Web3 enfrenta atualmente, a contemplação das necessidades e pontos de dor dos utilizadores e as considerações para a ligação e desenvolvimento coletivo de todo o ecossistema.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[极客 Web3], Todos os direitos autorais pertencem ao autor original[雾月，极客Web3]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.