Étant donné que Particle Network a récemment publié l’abstraction de compte de la chaîne complète, on a l’impression qu’il doit superposer une « couche intermédiaire » au-dessus des normes ERC4337 existantes, pourquoi devez-vous faire cela ? Si vous êtes familier avec le statu quo actuel de l’abstraction des comptes, il n’est pas difficile de trouver la réponse :
À l’heure actuelle, chaque chaîne équivalente EVM, y compris la chaîne d’applications de couche 1 et de couche 2 et de couche 3, a une approche complètement différente, et ce type d’abstraction est basé sur la chaîne, et non orienté vers l’utilisateur ;
Afin de réaliser véritablement l’orientation utilisateur, par exemple en permettant à un utilisateur de connecter toutes les chaînes associées sur la base d’une entrée et d’une adresse, afin d’obtenir une expérience interactive plus cohérente et globale, un rôle de « couche intermédiaire » capable de définir la spécification unifiée et les normes d’intention de mise en œuvre est devenu indispensable ;
Pourquoi la pratique actuelle du marché de « l’abstraction des comptes » est-elle trop divisée ? Comment l’abstraction de compte de la chaîne complète de Particle Network est-elle techniquement mise en œuvre ? Jusqu’où peut-on parvenir à l’adoption massive de la voie abstraite centrée sur l’intention ? Analysons-les un par un :
Abstraction de compte Les solutions AA sont unifiées au niveau de l’ingénierie, et la couche pratique est multiforme
En termes de simplicité technique, l’abstraction de compte est une série d’intentions que les utilisateurs insèrent dans le pool de mémoire UserOP, et le bundler les emballe et les envoie au contrat Entrypoint pour exécution, où les transactions par lots peuvent être traitées via l’agrégation de signatures de l’agrégateur, et les détails du paiement du gaz sont gérés par Paymaster.
Il s’agit d’un ensemble de normes définies par ERC4337, et la logique d’implémentation back-end est également unifiée, mais il s’agit essentiellement d’une abstraction de la chaîne EVM, et le front-end qui connecte les utilisateurs n’est pas nécessairement « unifié ».
Par exemple, zkSync utilise des adresses EOA pour lier des comptes, et tout ce que les utilisateurs voient est une adresse fantôme transférable, et le front-end ressent à peine l’existence de comptes AA. Starknet, quant à lui, se présente sous la forme d’un compte de contrat évolutif, et les utilisateurs doivent constamment mettre à jour le contrat pour mettre à jour la fonction de compte. De plus, Argent utilise le mécanisme de récupération sociale du mécanisme Guardian, et le schéma d’abstraction de compte d’Unipass tend à être appliqué dans des applications multi-chaînes hétérogènes dans des environnements non-EVM.
Attendez, ce genre d’incohérence à l’entrée semble être une sorte de personnalisation, mais cela augmente sans aucun doute le seuil pour les utilisateurs. L’abstraction va et vient, pourquoi le seuil est-il plus élevé dans le « orienté utilisateur » ? Cela se manifeste par le fait qu’il est impossible pour un utilisateur d’interagir avec une seule chaîne dans un environnement multi-chaînes et multi-couches2, et que le coût d’apprentissage est généré à partir de rien lorsqu’il s’étend sur plusieurs portefeuilles et plusieurs chaînes ; Un utilisateur générera plusieurs adresses de contrat différentes sur différentes chaînes EVM, ce qui pose des défis à la gestion unifiée des actifs.
Comment une implémentation d’ingénierie multi-chaînes ERC4337 standard aussi fragmentée peut-elle conduire à une adoption de masse orientée vers l’utilisateur ?
Quelle est la difficulté dans la logique de pratique abstraite des comptes unifiés ? Prenons l’exemple de l’abstraction de compte de la chaîne complète
Comme mentionné précédemment, l’abstraction du compte courant n’est basée que sur la chaîne EVM, mais l’adresse EOA peut toujours être unifiée avec la chaîne EVM, pourquoi ?
Étant donné que les adresses EOA sont dérivées du calcul de clé publique, tant que les algorithmes des différentes chaînes sont les mêmes et que la clé privée est la même, l’adresse dérivée est également la même. Cependant, l’adresse du contrat est calculée à partir de l’adresse du créateur et du nonce, et l’adresse du contrat est différente en raison des différents nonces de chaque chaîne. Une approche apparemment réalisable consiste à utiliser une approche de registre pour mapper la même adresse entre différentes chaînes, mais il existe un risque de centralisation.
D’autre part, le diagramme de structure abstrait de Particle Network de l’ensemble du compte de la chaîne, il essaie d’assumer le rôle d’un « centre de répartition » avec le cadre natif de la chaîne décentralisée, et chaque nouvelle chaîne avec une nouvelle adresse sera générée par le contrat général du centre de répartition, et le sous-contrat de déploiement sera uniformément connecté au contrat de déploiement pour un fonctionnement unifié, y compris le déploiement et la mise à niveau, tous les aspects seront uniformément planifiés par le contrat général.
La seule difficulté est la fluidité de la communication instantanée entre des chaînes hétérogènes, ce qui nécessite que la « couche intermédiaire » agisse comme un moyen de communication efficace, ce qui peut réaliser une planification unifiée en distribuant des contrats sur chaque nœud léger de la chaîne, et le schéma de pratique est similaire à la solution cross-chain de LayerZero.
Cette approche permet au moins de surmonter les limitations d’attributs des chaînes EVM, de sorte que toute multi-chaîne qui prend en charge l’interopérabilité des contrats de chaîne hétérogène et le schéma EIP-4337 sera incluse dans le système multi-chaînes. L’abstraction de compte de la chaîne complète peut être mise en œuvre à grande échelle.
Cependant, les chaînes non EVM comme Aptos et Sui ne sont actuellement pas en mesure de se connecter de la même manière en série. Il s’agit d’un marché suffisamment important à un moment où l’écosystème Ethereum est absolument dominant dans les catégories Layer, Layer 2 et Layer 3.
Quel type d’imagination peut être libéré par d’autres services abstraits modulaires dans la « couche intermédiaire » ?
Bien sûr, pour vraiment obtenir une gamme complète d’abstraction « orientée utilisateur », l’abstraction de compte de la chaîne complète n’est qu’un début. En plus de l’abstraction du compte lui-même pour améliorer l’expérience, un centre de répartition de niveau intermédiaire peut également essayer d’effectuer d’autres tâches abstraites :
Le transfert d’actifs inter-chaînes et la couche de règlement unifiée permettent aux utilisateurs de réaliser la gestion et la circulation des actifs de manière décentralisée entre les différentes chaînes, réduisant ainsi la consommation possible de friction de glissement des chaînes croisées.
Le DID inter-chaînes unifie la concaténation de l’identité et du crédit, avec la couche intermédiaire comme « centre d’authentification », pour réaliser le partage d’identité et la synchronisation des données entre plusieurs chaînes, puis dériver le « crédit » qui peut être appliqué à travers les chaînes, réduire le seuil multiplateforme pour les utilisateurs, et en même temps briser la séparation des données entre les chaînes, et vraiment réaliser l’expérience interactive de la norme « identité » ;
Mettez en œuvre une solution de solveur décentralisée unifiée, il est préférable d’agréger ces solveurs dispersés dans un centre de répartition super solveur, par exemple, les utilisateurs peuvent se connecter à UniswapX et Cowswap et SUAVE de Flashbot et à d’autres solutions de solveur sur une seule plate-forme, et construire un solveur qui convient aux participants potentiels du solveur tels que les teneurs de marché, les traders institutionnels et les scientifiques de l’arbitrage. Parce que sans la couche intermédiaire pour l’ordonnancement, il ne fait aucun doute que ces solveurs existeront toujours en fragments entre les chaînes.
Vous pouvez comprendre qu’en partant du principe qu’il existe différentes divisions standard dans l’écosystème EVM, ERC4337 définit les règles de communication, et la communication repose toujours sur un IBC qui agit comme la « couche intermédiaire » pour émerger.
Et ne sous-estimez pas la valeur de ce type d’infra de niveau intermédiaire, car il est probable qu’il s’agisse d’un complément nécessaire pour que l’abstraction des comptes s’éloigne de la couche d’abstraction d’ingénierie et s’oriente vers une vulgarisation à grande échelle.
Comment maximiser la valeur de la norme ERC4337, comment unifier les produits et les normes de protocole des différents portefeuilles, chaînes et autres constructeurs de la piste, et comment vraiment lisser l’écart entre l’expérience utilisateur Web2 et les caractéristiques natives de la chaîne Web3 basées sur l’orientation utilisateur sont autant de sujets qui doivent être surmontés.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
Pourquoi l’actuelle « abstraction de compte » est-elle trop divisée, et comment tendre vers une abstraction unifiée « orientée utilisateur » ?
Auteur : Haotian
Étant donné que Particle Network a récemment publié l’abstraction de compte de la chaîne complète, on a l’impression qu’il doit superposer une « couche intermédiaire » au-dessus des normes ERC4337 existantes, pourquoi devez-vous faire cela ? Si vous êtes familier avec le statu quo actuel de l’abstraction des comptes, il n’est pas difficile de trouver la réponse :
Pourquoi la pratique actuelle du marché de « l’abstraction des comptes » est-elle trop divisée ? Comment l’abstraction de compte de la chaîne complète de Particle Network est-elle techniquement mise en œuvre ? Jusqu’où peut-on parvenir à l’adoption massive de la voie abstraite centrée sur l’intention ? Analysons-les un par un :
Abstraction de compte Les solutions AA sont unifiées au niveau de l’ingénierie, et la couche pratique est multiforme
En termes de simplicité technique, l’abstraction de compte est une série d’intentions que les utilisateurs insèrent dans le pool de mémoire UserOP, et le bundler les emballe et les envoie au contrat Entrypoint pour exécution, où les transactions par lots peuvent être traitées via l’agrégation de signatures de l’agrégateur, et les détails du paiement du gaz sont gérés par Paymaster.
Il s’agit d’un ensemble de normes définies par ERC4337, et la logique d’implémentation back-end est également unifiée, mais il s’agit essentiellement d’une abstraction de la chaîne EVM, et le front-end qui connecte les utilisateurs n’est pas nécessairement « unifié ».
Par exemple, zkSync utilise des adresses EOA pour lier des comptes, et tout ce que les utilisateurs voient est une adresse fantôme transférable, et le front-end ressent à peine l’existence de comptes AA. Starknet, quant à lui, se présente sous la forme d’un compte de contrat évolutif, et les utilisateurs doivent constamment mettre à jour le contrat pour mettre à jour la fonction de compte. De plus, Argent utilise le mécanisme de récupération sociale du mécanisme Guardian, et le schéma d’abstraction de compte d’Unipass tend à être appliqué dans des applications multi-chaînes hétérogènes dans des environnements non-EVM.
Attendez, ce genre d’incohérence à l’entrée semble être une sorte de personnalisation, mais cela augmente sans aucun doute le seuil pour les utilisateurs. L’abstraction va et vient, pourquoi le seuil est-il plus élevé dans le « orienté utilisateur » ? Cela se manifeste par le fait qu’il est impossible pour un utilisateur d’interagir avec une seule chaîne dans un environnement multi-chaînes et multi-couches2, et que le coût d’apprentissage est généré à partir de rien lorsqu’il s’étend sur plusieurs portefeuilles et plusieurs chaînes ; Un utilisateur générera plusieurs adresses de contrat différentes sur différentes chaînes EVM, ce qui pose des défis à la gestion unifiée des actifs.
Comment une implémentation d’ingénierie multi-chaînes ERC4337 standard aussi fragmentée peut-elle conduire à une adoption de masse orientée vers l’utilisateur ?
Quelle est la difficulté dans la logique de pratique abstraite des comptes unifiés ? Prenons l’exemple de l’abstraction de compte de la chaîne complète
Comme mentionné précédemment, l’abstraction du compte courant n’est basée que sur la chaîne EVM, mais l’adresse EOA peut toujours être unifiée avec la chaîne EVM, pourquoi ?
Étant donné que les adresses EOA sont dérivées du calcul de clé publique, tant que les algorithmes des différentes chaînes sont les mêmes et que la clé privée est la même, l’adresse dérivée est également la même. Cependant, l’adresse du contrat est calculée à partir de l’adresse du créateur et du nonce, et l’adresse du contrat est différente en raison des différents nonces de chaque chaîne. Une approche apparemment réalisable consiste à utiliser une approche de registre pour mapper la même adresse entre différentes chaînes, mais il existe un risque de centralisation.
D’autre part, le diagramme de structure abstrait de Particle Network de l’ensemble du compte de la chaîne, il essaie d’assumer le rôle d’un « centre de répartition » avec le cadre natif de la chaîne décentralisée, et chaque nouvelle chaîne avec une nouvelle adresse sera générée par le contrat général du centre de répartition, et le sous-contrat de déploiement sera uniformément connecté au contrat de déploiement pour un fonctionnement unifié, y compris le déploiement et la mise à niveau, tous les aspects seront uniformément planifiés par le contrat général.
La seule difficulté est la fluidité de la communication instantanée entre des chaînes hétérogènes, ce qui nécessite que la « couche intermédiaire » agisse comme un moyen de communication efficace, ce qui peut réaliser une planification unifiée en distribuant des contrats sur chaque nœud léger de la chaîne, et le schéma de pratique est similaire à la solution cross-chain de LayerZero.
Cette approche permet au moins de surmonter les limitations d’attributs des chaînes EVM, de sorte que toute multi-chaîne qui prend en charge l’interopérabilité des contrats de chaîne hétérogène et le schéma EIP-4337 sera incluse dans le système multi-chaînes. L’abstraction de compte de la chaîne complète peut être mise en œuvre à grande échelle.
Cependant, les chaînes non EVM comme Aptos et Sui ne sont actuellement pas en mesure de se connecter de la même manière en série. Il s’agit d’un marché suffisamment important à un moment où l’écosystème Ethereum est absolument dominant dans les catégories Layer, Layer 2 et Layer 3.
Quel type d’imagination peut être libéré par d’autres services abstraits modulaires dans la « couche intermédiaire » ?
Bien sûr, pour vraiment obtenir une gamme complète d’abstraction « orientée utilisateur », l’abstraction de compte de la chaîne complète n’est qu’un début. En plus de l’abstraction du compte lui-même pour améliorer l’expérience, un centre de répartition de niveau intermédiaire peut également essayer d’effectuer d’autres tâches abstraites :
Le transfert d’actifs inter-chaînes et la couche de règlement unifiée permettent aux utilisateurs de réaliser la gestion et la circulation des actifs de manière décentralisée entre les différentes chaînes, réduisant ainsi la consommation possible de friction de glissement des chaînes croisées.
Le DID inter-chaînes unifie la concaténation de l’identité et du crédit, avec la couche intermédiaire comme « centre d’authentification », pour réaliser le partage d’identité et la synchronisation des données entre plusieurs chaînes, puis dériver le « crédit » qui peut être appliqué à travers les chaînes, réduire le seuil multiplateforme pour les utilisateurs, et en même temps briser la séparation des données entre les chaînes, et vraiment réaliser l’expérience interactive de la norme « identité » ;
Mettez en œuvre une solution de solveur décentralisée unifiée, il est préférable d’agréger ces solveurs dispersés dans un centre de répartition super solveur, par exemple, les utilisateurs peuvent se connecter à UniswapX et Cowswap et SUAVE de Flashbot et à d’autres solutions de solveur sur une seule plate-forme, et construire un solveur qui convient aux participants potentiels du solveur tels que les teneurs de marché, les traders institutionnels et les scientifiques de l’arbitrage. Parce que sans la couche intermédiaire pour l’ordonnancement, il ne fait aucun doute que ces solveurs existeront toujours en fragments entre les chaînes.
Vous pouvez comprendre qu’en partant du principe qu’il existe différentes divisions standard dans l’écosystème EVM, ERC4337 définit les règles de communication, et la communication repose toujours sur un IBC qui agit comme la « couche intermédiaire » pour émerger.
Et ne sous-estimez pas la valeur de ce type d’infra de niveau intermédiaire, car il est probable qu’il s’agisse d’un complément nécessaire pour que l’abstraction des comptes s’éloigne de la couche d’abstraction d’ingénierie et s’oriente vers une vulgarisation à grande échelle.
Comment maximiser la valeur de la norme ERC4337, comment unifier les produits et les normes de protocole des différents portefeuilles, chaînes et autres constructeurs de la piste, et comment vraiment lisser l’écart entre l’expérience utilisateur Web2 et les caractéristiques natives de la chaîne Web3 basées sur l’orientation utilisateur sont autant de sujets qui doivent être surmontés.