L'inscription actuelle d'Ethereum est essentiellement un vieux vin dans une nouvelle bouteille d'Ordinals, un nouveau paradigme sans réelle signification. ETHS présente encore des risques de sécurité, et bien qu'il soit plus décentralisé que Rollup, son processus de retrait repose encore sur un notaire/gestionnaire tiers, et il y a un risque de vol. De toute évidence, actuellement, ETHS relève principalement de l'engouement financier, non pas qu'il puisse apporter des innovations que la couche 2 d'Ethereum ne peut apporter.
La récente popularité des inscriptions écologiques BTC a encouragé les développeurs d'autres chaînes à construire des systèmes similaires. La manière dont les systèmes d'inscription sur les différentes chaînes sont mis en œuvre et les fonctions qu'ils peuvent accomplir sont légèrement différentes, mais ils ont quelques points communs :
1. Les inscriptions utilisent toutes les informations textuelles attachées au transfert pour exprimer l'opération que vous souhaitez effectuer, telles que l'écriture de "transférer 1 pièce à XXX" dans le message. Notez que ces informations sont en texte brut et ne concernent pas des opérations telles que l'exécution de contrats intelligents sur la chaîne.
2. Les développeurs concevront une série de spécifications et de normes pour standardiser toutes les informations textuelles.
3. Le développeur fournit un ensemble d'indexeurs Indexer pour calculer l'état interne du système d'inscription après avoir collecté les informations textuelles de toutes les inscriptions sur la chaîne. Indexer est un composant open source hors chaîne que n'importe qui peut exécuter.
L'inscription BTC Ordinals a établi un mécanisme pour émettre des NFT et des jetons sur BTC, et a également conduit à une réflexion à grande échelle sur le BTC L2. En ce sens, nous pouvons penser qu'Ordinals est quelque peu à la pointe et exploratoire. Cependant, Ordinals était limité par l'architecture propre du BTC en termes de technologie et d'expérience produit, et a également été critiqué par la communauté BTC OG pour des raisons telles que la pollution par la poussière et la consommation de données.
Alors, est-il judicieux de réimprimer l'inscription sur Ethereum? Après tout, Ethereum lui-même a des contrats intelligents complexes, et les ERC20 et les NFT font également partie d'Ethereum lui-même; quel impact auront ces projets d'inscription sur l'écosystème Ethereum, et causeront-ils la controverse et la agitation sur BTC?
Commençons par examiner comment l'Éthique est mise en œuvre. Il s'agit d'un projet d'inscription célèbre sur Ethereum qui utilise principalement Calldata pour fonctionner.
Calldata est l'ensemble des données d'entrée d'origine transmises dans une transaction Ethereum. Elle est généralement utilisée pour transmettre les paramètres nécessaires à l'interaction avec un contrat intelligent, mais elle peut également être utilisée pour envoyer des messages texte (commentaires, inscriptions, notes de transfert, etc.) à une adresse EOA. Dans la figure, les données d'entrée sont les calldata.
Si vous souhaitez utiliser l'ethnographie pour inscrire « Hello world » dans une transaction, vous devez construire une transaction avec les données d'appel suivantes :
Après que l'indexeur hors chaîne surveille cette transaction, il mettra à jour la base de données et notifiera l'utilisateur qu'une nouvelle inscription a été générée, et le contenu de l'inscription est Bonjour le monde. Des contenus plus complexes, tels que la représentation en base64 des informations sur l'image, peuvent également être placés dans l'inscription.
L'ethnicité a maintenant passé 6 ESIPs (propositions similaires à l'EIP) pour définir l'utilisation des inscriptions dans différents scénarios. Cependant, il s'agit uniquement de spécifications d'inscription relativement basiques, telles que le format des transactions d'inscription initiées à partir d'EOA, les événements d'émission de contrat, etc.
Puisque Ethnicity est un projet sur Ethereum, il est également possible de mettre en œuvre un certain degré de logique en utilisant les contrats intelligents d'Ethereum. Il est important de noter qu'interagir directement avec les contrats intelligents n'est pas l'approche recommandée par Ethical.
Bien que les places de marché NFT officielles et similaires soient également mises en œuvre directement à l'aide de contrats intelligents. Selon la documentation officielle, Ethical souhaite fournir aux utilisateurs un service informatique « décentralisé et abordable » : en séparant le calcul de la chaîne, le coût d'utilisation d'Ethereum sera considérablement réduit.
Explorons en détail le coût de l'appel d'un smart contract, qui peut être divisé en trois parties:
·Coûts de transaction de base : Toute transaction Ethereum nécessite un paiement, actuellement 21000 gaz.
Coût de transmission des données (calldata) : Calldata est généralement utilisé pour soumettre des données et des paramètres pour interagir avec des contrats intelligents. Après l'ajustement de l'EIP-2028, calldata consomme généralement 16 gaz par octet (4 gaz si les données sont de 0 octet).
Coût d'exécution du contrat : Si une transaction appelle une fonction dans un contrat intelligent, alors en fonction de la complexité de l'exécution de la fonction, des coûts de calcul doivent également être payés. Par exemple, si une mise à jour de statut est impliquée (comme la mise à jour des informations de solde dans un contrat ERC-20), l'appel à SSTORE peut consommer jusqu'à 5000-20,000 gaz.
Prenons une transaction de transfert USDT très simple. La transaction a coûté un total de 63 197 gaz, et les données d'appel sont :
Analysons ces données d'appel et combien de gaz cela coûtera :
·Les données d'appel Ethereum sont au format hexadécimal, c'est-à-dire que chaque deux chiffres représentent un octet (16^2 = 2^8). Le 0x au début indique que les données sont au format hexadécimal.
·Le a9059cbb après le début 0x est un sélecteur de fonction et occupe 4 octets non nuls.
·Les 32 prochaines octets sont des adresses, avec 12 octets de zéros devant (car les adresses Ethereum font 20 octets, de 0 à 32 octets sont ajoutés à gauche), et 20 octets de données d'adresse non nulles.
Les 32 derniers octets représentent le montant, avec un grand nombre de zéros à gauche, 3b9aca00 données non nulles à la fin et 4 octets non nuls.
· Ainsi, 28 octets non nuls et 40 octets nuls
Par conséquent, callDataGas = 28 * 16 + 40 * 4 = 608 gaz.
Le gaz total est de 63197. Après avoir soustrait le coût des données d'appel et le coût fixe, le coût de calcul du contrat intelligent pour l'exécution de cette transaction est de 41,589 gaz. Les coûts de calcul du contrat représentent la majeure partie de cette transaction, et il s'agit simplement d'une transaction simple. Dans les transactions complexes, le coût du calcul du contrat augmentera davantage.
Déplacer le processus de calcul hors chaîne réduira effectivement considérablement les coûts d'utilisation : si vous ne souhaitez pas appeler directement des contrats intelligents sur la chaîne, vous pouvez vous rendre à une adresse EOA convenue
0x0000000000000000000000000000000face7 Envoyer les données de transaction
Dans les données d'appel de la transaction, spécifiez le contrat que vous vouliez initialement appeler et les paramètres d'entrée correspondants. Étant donné que l'adresse ci-dessus est un compte EOA et qu'il n'y a pas de code de contrat, l'opération décrite ci-dessus ne déclenchera pas de tâches de calcul sur la chaîne; elle envoie simplement un message.
Hors chaîne, après que l'Indexeur a écouté ce message, il l'analysera pour découvrir quel contrat sur la chaîne ETH l'initiateur de ce message voulait initialement appeler, puis l'Indexeur calculera les résultats de l'appel de contrat hors chaîne.
Eh bien, si un indexeur hors ligne veut calculer des inscriptions et des contrats intelligents, il doit disposer d'un ensemble de règles et d'une exécution de la fonction de transition d'état (STF). La partie compliquée peut être appelée une machine virtuelle VM. Ethnic a lancé sa propre VM - VM Ethnic - dans l'ESIP-4, qui a ensuite été renommée Facet VM.
Facet se définit comme une plateforme informatique bon marché, facile à utiliser, sécurisée et décentralisée. Écoutez les données d'appel d'Ethical sur Ethereum, tirez-les vers la VM pour le calcul, et enfin renvoyez les résultats à l'utilisateur. Les facettes ont plusieurs composants clés :
·Facet VM, un ensemble de machines virtuelles écrites en Ruby, est responsable de surveiller les transactions ETHS, d'analyser les données d'appel et d'exécuter des opérations.
· Rubidity, le langage de programmation de contrat intelligent dans Facet, est similaire à Ruby, et conserve également de nombreuses utilisations et concepts de Solidity, afin que les développeurs puissent commencer rapidement.
Contrat stupide, un contrat stupide, un type de contrat qui fonctionne sur Facet. Le nom est plein d'humour. Certaines personnes ont également raison de l'appeler un contrat stupide. Stupide en soi est un jeu de mots; stupide peut décrire le processus silencieux du travail de ce genre de contrat. Mais d'un autre côté, selon le proverbe officiel "Si stupide, ils sont intelligents", cela signifie être stupide, avec un fort sens de la dispute avec les contrats intelligents, donc il n'y a pas de problème à les appeler des contrats stupides.
Le contrat stupide lui-même ne sera pas réellement déployé sur Ethereum ; son code sera publié sur la chaîne ETH sous forme de données d'appel. Voici un exemple de Facet appelant un contrat stupide :
Une transaction de frappe vers une adresse de trou noir EOA
0x000000000000000000000000000face7 soumet les données d'appel dans l'image ci-dessous, indiquant que vous ne voulez que le jeton et le montant de mint. C'est en fait la même chose que les Ordinaux ou les BRC-20 :
Jetons un autre coup d'œil à la comparaison visuelle entre Rubidity et Solidity, comme illustré ci-dessous.
Bien que la déclaration officielle soit que Rubidity a un concept et une structure similaires à Solidity, de sorte que les développeurs peuvent commencer rapidement. Mais nous savons que cela a en fait un impact négatif sur le développement du côté des développeurs. De plus, actuellement, Facet VM ne prend en charge que des contrats stupides sur la liste blanche officielle, ce qui montre que le gouvernement n'a pas beaucoup confiance en ce langage et en VM. S'il est plus difficile de réutiliser l'EVM officiellement en ingénierie que de développer une nouvelle VM et un nouveau langage, je ne sais pas. Mais une chose est certaine : le nouveau langage, le nouveau contrat, le nouvel écosystème et la nouvelle façon d'utiliser Ethereum sont vraiment suffisamment accrocheurs.
La documentation de Facet a fait les commentaires suivants sur l'Ethereum et les contrats intelligents : "Les contrats intelligents sont considérés comme la fonctionnalité qui rend l'Ethereum spécial par-dessus tout, et pourtant la thèse de Facet est que les contrats intelligents sont la plus grande faille de conception de l'Ethereum."
Ils croient que le smart contract d'Ethereum est la plus grande faille de conception, car le contrat lui-même ne nécessite qu'une entrée donnée (calldata) et sa sortie est déterminée, il ne devrait donc pas être calculé sur la chaîne, gaspillant de l'argent pour aucune raison. Associé au service informatique décentralisé et abordable d'Ethical, il est clair qu'Ethnic et Facet veulent vraiment créer une impression sur le marché, "Nous créons un nouveau paradigme d'expansion et de méthode d'utilisation d'Ethereum", mais en réalité, certaines solutions techniques d'ETHS ne sont pas très fiables.
D'un point de vue produit, Facet peut invoquer des contrats intelligents de manière indirecte sous la chaîne, et il possède également son propre système de contrat stupide sous la chaîne. En effet, le gouvernement met en œuvre son slogan.
Cependant, d'un point de vue économique, il n'y a pas de repas gratuits dans le monde ; bien sûr, le stockage et le calcul nécessitent de l'argent. Alors, comment Indexer résout-il cette partie du coût ? Il n'y a pas d'explication officielle à ce sujet, alors imaginons :
· Les utilisateurs sont facturés. Par exemple, les frais de traitement facturés par le marché NFT aux acheteurs, mais nous ne pouvons pas considérer un modèle de tarification simple de projet comme une méthode de tarification à long terme similaire à un réseau L2.
·Devenez riche grâce à votre propre hype écologique. C'est bien sûr possible, mais ce n'est qu'une solution à court terme pour maintenir le projet en vogue pendant un certain temps. Si l'Éthnicité doit devenir un nouveau paradigme d'Éthereum, l'Indexer doit disposer d'un mécanisme économique à long terme, basé sur le réseau, pour garantir le fonctionnement.
Si les biens publics ne sont pas rentables, quelles organisations feront des dons? Je pense qu'au moins la Fondation Ethereum ne sera pas particulièrement active car Ethereum lui-même a une très bonne solution - Rollup.
Si nous avons juste besoin de la forme simple de l'inscription Ethereum, alors un seul projet d'Ethnic suffit. Alors pourquoi sa proposition ESIP-4 a-t-elle engendré Facet à nouveau?
Parce que le système d'inscription ne peut pas être utilisé pour une logique de transaction complexe. Nous pouvons examiner la logique opérationnelle du contrat du marché NFT officiel d'Ethical, qui utilise un mécanisme de commande en attente.
Si vous souhaitez déposer l'inscription NFT dans le contrat, vous n'avez qu'à écrire les données d'appel en tant qu'ethscriptionID de l'inscription et appeler le contrat de marché. Comme cette opération sélectionne délibérément une forme invalide d'appel de fonction, elle déclenche par défaut fallback().
Finalement, un événement appelé PotentialEthScriptionOfferings sera déclenché sur la chaîne Ethereum. Après que le nœud Indexer surveille cet événement hors chaîne, il transférera localement la propriété du NFT dans un contrat de marché.
Afin d'économiser du gaz, le marché de trading ETHS ne stocke pas certains paramètres des ordres en attente du vendeur, tels que le prix, la date limite, etc. dans le contrat ETH, mais les place plutôt hors ligne sous forme de messages. Visuellement, ils auraient dû être stockés sur le serveur d'application décentralisée. Une fois que l'acheteur a surveillé ce message, il peut soumettre un achat en émettant la commande BuyWithSignature().
L'utilisation d'un mécanisme de commande en attente est normale pour les NFT car les NFT eux-mêmes ne sont pas homogènes. Donc, s'il s'agit d'une inscription de jeton homogénéisée, le mécanisme AMM du contrat peut-il être utilisé ? La réponse est non. Le statut des NFT ou jetons inscrits n'est pas sur L1, ce qui est à peu près similaire aux Ordinaux et BRC-20. C'est le contraire complet de certaines propagandes communautaires. Tout le monde doit être prudent. L'inscription n'est pas un actif sur la chaîne ETH au sens propre du terme. Nous ne pouvons pas dire que les calldata qui ont généré l'actif sont sur L1, et nous pouvons déclarer des instructions d'opération sur L1, appelées actif natif sur L1. Sinon, l'actif natif sur L2 sur Rollup peut également être appelé un actif sur L1, car les calldata de Rollup sont tous sur L1. De toute évidence, il est ridicule de qualifier ce genre d'actif d'actif natif sur L1.
Vous vous demandez peut-être, n'est-ce pas simplement un contrat intelligent utilisé pour trader? Pourquoi dit-on que les inscriptions sur le contrat ne peuvent pas être lues et manipulées? En fait, ce contrat est uniquement responsable de collecter de l'argent, de transférer de l'argent et d'organiser des événements pour les nœuds indexeurs sous la chaîne pour écouter et déclencher des opérations correspondantes. Aux yeux de l'EVM Ethereum, l'état de quelque chose comme une inscription ne peut pas être restauré dans la base de données de l'« État du monde » qui stocke spécifiquement l'état d'Ethereum, ni les contrats ne peuvent y faire référence.
Peu importe sous quelle forme un actif se présente, un jeton, un NFT, ou toute chose étrange, je peux donner une norme très simple pour identifier les actifs L1 et L2 : leur état peut-il être restauré à l'état du monde d'Éthereum, L'EVM de L1 peut-il se référer, appeler, interroger et modifier l'état de l'actif ; sinon, ce n'est pas un actif L1.
Par conséquent, vous pouvez également voir que le nom de l'événement de dépôt est PotentialEthscriptionDeposit, c'est-à-dire « rechargement d'inscription possible », plutôt qu'un rechargement définitif, car le contrat ne peut pas déterminer si cette inscription existe, et il est impossible de vérifier son authenticité. Si vous commandez une inscription qui n'existe pas, ou celle de quelqu'un d'autre, le contrat ne vous rejettera pas; c'est juste qu'Indexer n'inclura pas vos actions.
Par conséquent, le système d'inscription ne peut mettre en œuvre que cette logique de pseudo-contrat simple ; les ordres en attente en font partie. L'essence d'un ordre en attente est que les deux parties à la transaction conviennent des informations de l'autre selon une règle. En fait, cela peut être exprimé en texte clair sans contrat intelligent. Cela ressemble au principe d'une inscription.
Nous pouvons imaginer comment ce processus peut être complété sans utiliser de smart contract : le vendeur grave un message dans une transaction normale, me transfère 1ETH, et quelqu'un qui note 123 peut obtenir un NFT avec mon numéro d'inscription 123. Il suffit que l'Indexer prenne en charge cette logique. S'il détecte que quelqu'un a transféré 1ETH au vendeur et ajouté un ABC, alors cela peut être directement transféré à la base de données Indexer hors chaîne.
Bien sûr, cet exemple causera en réalité certains problèmes, tels que des transactions répétées qui peuvent résulter de plusieurs personnes se précipitant pour acheter un NFT. Le vendeur a reçu plusieurs transferts, mais à la fin, les NFT ne peuvent être transférés qu'à une seule personne par l'Indexer. Cela devrait également être l'une des raisons pour lesquelles le gouvernement critique clairement les contrats intelligents mais utilise des contrats pour mettre en œuvre le marché des NFT, vous devriez donc également être en mesure de comprendre l'affirmation officielle selon laquelle l'appel aux contrats intelligents sans calcul via Facet est peu fiable.
Bien sûr, les ordres en attente peuvent théoriquement utiliser du texte brut plutôt que de nécessiter un contrat, mais la logique relativement complexe de l'AMM nécessite des contrats intelligents, car elle ne nécessite pas un accord de pair à pair entre les deux parties, mais une approbation contractuelle. Un contrat agissant en tant que vérificateur fiable nécessite de vérifier des informations de base telles que le solde et la liquidité, et d'effectuer des calculs. Le contrat doit être capable d'obtenir toutes les données d'actifs dont il a besoin.
D'autre part, l'AMM n'est qu'une forme relativement simple de DeFi, et toute autre logique complexe ne peut pas être mise en œuvre sur Ethnic seul. C'est pourquoi Facet a été lancé - la priorité numéro un de Facet est le cross-domaine! En fait, c'est un L2, mais il n'a pas de structure de bloc, donc nous ne l'appelons pas cross-chain mais cross-domain. Lorsque tous les actifs L1 sont cross-domaine vers Facet, il n'y a aucun problème à ce qu'ils ne puissent pas être appelés entre les domaines. Tous les actifs hors chaîne peuvent être exploités avec des contrats stupides sous la chaîne, supportant ainsi une logique contractuelle complexe.
À travers la discussion détaillée ci-dessus, vous devriez être en mesure de voir que la solution d'Ethical est quelque peu similaire à Rollup. Mais ce n'est que "similaire"; strictement parlant, elle n'implémente qu'un sous-ensemble des fonctionnalités essentielles de Rollup. En revanche, les fonctionnalités manquantes ont causé des dommages fatals à son récit, ou ont mis les utilisateurs en grave danger.
Rollup est un système compliqué, et nous n'allons pas le développer ici. Il a quelque chose en commun avec l'Éthanol:
Ils soumettent tous des données d'appel pour les transactions L2 sur Ethereum.
Toutes les calculs sont traités hors chaîne.
Les similitudes sont très claires, et nous devons démontrer les différences en détail.
Dans la plupart des cas, les utilisateurs de Rollup ne soumettent pas directement des transactions à la L1, mais les soumettent plutôt à un séquenceur hors chaîne. Le séquenceur trie toutes les transactions, les regroupe et les compresse, puis envoie les données d'appel à la L1 par lots. En soumettant les données d'appel de plusieurs utilisateurs dans une seule transaction, le coût de base de 21 000 gaz peut être dilué.
Il n'y a pas un tel mécanisme dans l'Ethnicité; tous les utilisateurs soumettent directement les données d'appel à L1.
En utilisant l'exemple de l'USDT ci-dessus (608 gaz pour les données d'appel), supposons que 100 utilisateurs ont initié 100 transactions, et calculons approximativement la différence de coût entre les deux avec très peu de rigueur :
· Chaque utilisateur d'inscription paiera 21608 gaz (608 + 21000). Le reste du calcul n'est pas payé car le calcul est hors chaîne.
Les utilisateurs Rollup paient 818 gaz ((608*100+21000) /100) par personne. La partie mathématique est la même que ci-dessus.
Bien sûr, chaque utilisateur de Rollup doit également payer des frais de calcul et de stockage L2 au séquenceur, mais c'est beaucoup moins cher que L1, donc c'est négligeable dans ce cas. De plus, Rollup nécessite quelques champs spéciaux supplémentaires pour augmenter le volume, mais en même temps, il a également une meilleure compression des données, donc nous n'allons pas développer cela ici.
À travers cette estimation approximative, on peut constater que l'Éthanol n'a aucun avantage en termes de coût sur la Couche 2. De plus, dans la propagande communautaire du projet, j'ai vu des choses comme "4000 inscriptions peuvent être transférées par lots, environ 0,11 ETH, et en moyenne, seulement 0,05U par transfert" pour prouver que l'utilisation de l'Éthanol est bon marché. En fait, cela ne clarifie pas les principes et les détails d'interaction de l'ETHS.
Grâce à un séquenceur hors chaîne, les demandes des utilisateurs de Rollup peuvent être pré-confirmées en moins de 1 seconde. Il s'agit d'une expérience utilisateur bien meilleure que le système d'inscription pendant 12 secondes ou plus sur L1. Bien sûr, les partisans de l'inscription peuvent également faire valoir qu'avant que les données d'appel soient soumises à la chaîne ETH, les résultats finaux de telles transactions sont peu fiables.
Les utilisateurs sur Rollup sont susceptibles d'être censurés par des séquenceurs hors chaîne, alors que Ethical ne peut pas censurer les utilisateurs. Cependant, un Rollup bien conçu aura une fonction d'agrégation forcée pour contrer l'examen du séquenceur, et finalement le séquenceur n'a aucun pouvoir pour examiner les utilisateurs du tout.
Par conséquent, lorsque les utilisateurs utilisent Rollup, ils peuvent également contourner directement le séquenceur sur L1. Rollup offre aux utilisateurs différentes options. Vous pouvez utiliser un séquenceur plus rapide ou utiliser L1 directement. Cependant, Ethnic ne peut utiliser que L1, et il n'y a pas de place pour que les utilisateurs choisissent librement.
De plus, Ethnic a critiqué le séquenceur de Rollup pour être centralisé. Mais l'Indexer lui-même est également un composant très centralisé. Ethnic a expliqué que puisque n'importe qui peut exécuter et vérifier l'Indexer, il n'est pas centralisé, mais en fait, la grande majorité des gens n'exécutent pas eux-mêmes des nœuds. Par conséquent, ETHS ne montre son côté décentralisé que par rapport à Rollup dans des cas extrêmes. Après tout, le séquenceur de Rollup peut tomber en panne ou échouer, mais ETHS peut continuer à fonctionner tant que les membres de la communauté exécutent plusieurs Indexers.
Aucun projet ne peut utiliser l'amour pour générer de l'électricité. Les projets de développement à long terme doivent soigneusement considérer la question des modèles économiques. Qu'il s'agisse d'une entité centralisée ou d'une combinaison d'entités décentralisées, elles doivent être rentables pour protéger la sécurité du réseau pendant une longue période.
Le séquenceur de Rollup a un modèle économique clair : facturer plus de gaz, extraire MEV, etc. Le séquenceur a le pouvoir de garantir le fonctionnement normal du réseau. Étant donné que les utilisateurs soumettent directement les données d'appel à L1, l'Indexer ne facture pas beaucoup.
La plupart des langages de développement de contrats Rollup, des chaînes d'outils, etc. peuvent directement utiliser Ethereum, et les développeurs peuvent migrer facilement vers Rollup. Aucun de ceux-ci n'existe dans l'Ethnic; vous devez maîtriser le nouveau Rubidity, construire de nouvelles analyses, vous familiariser avec les nouveaux VM, etc. Bien sûr, vu sous un autre angle, cette résistance est aussi une opportunité d'exploration qui peut être apportée par le développement d'un nouvel écosystème.
C'est le problème fatal de Facet. Nous savons que Rollup soumet non seulement les calldata (entrées) à L1 par lots, mais soumet également régulièrement le règlement de l'état (sortie) après N opérations à L1. ZKR et OPR ont différentes méthodes de preuve pour déterminer si la relation entre l'entrée et la sortie est correcte. Peu importe la méthode de preuve, la décision finale est un contrat L1. La sortie et l'entrée sur Rollup sont traçables et ne peuvent pas être contrefaites.
Alors, à quoi sert le règlement du statut ? Utilisé pour les retraits, c’est-à-dire les retraits de fonds L2 à L1. Lorsque le statut sur L1 est publié, nous pouvons utiliser la preuve de Merkle et d’autres moyens pour prouver que ma demande de retrait sur L2 est incluse dans cette racine de statut en fonction de la racine de statut. Une fois que le contrat a été correctement vérifié, les actifs peuvent être libérés sur L1.
Facet n'a pas de mécanisme de règlement de statut, il lui est donc impossible d'obtenir des retraits décentralisés et sans permission de L2 à L1. Comme mentionné ci-dessus, il avait également besoin d'une couche L2 pour exécuter une logique de contrat plus complexe. Comme son AMM Swap FacetSwap.
On peut voir que FacetSwap (un dex construit sur Facet avec des contrats stupides) a clairement deux actions : dépôt et retrait. Normalement, il n'y a pas de dépôts ou de retraits pour Swap, car Facet exige que vous traversiez les domaines avant de pouvoir l'utiliser.
Dans Facet, le dépôt nécessite de verrouiller les fonds de L1 sur le contrat de pont L1, et d'émettre l'événement correspondant ethscriptions_protocol_createEthscription pour que l'indexeur soit indexé. Cela est cohérent avec d'autres méthodes de recharge L2.
Les retraits, en revanche, posent de sérieux problèmes de sécurité. Comme il n'y a pas de mécanisme de règlement des statuts sur Facet, les contrats ne peuvent pas être utilisés pour déterminer automatiquement si un retrait est valide de L2 à L1. Alors, quelle méthode Facet a-t-elle utilisée? L'administrateur a publié, ou mécanisme de témoin, similaire au pont Axie précédemment volé.
Jetons un coup d'œil directement au pont de Facet. L'adresse est:
0xd729345aa12c5af2121d96f87b673987f354496b.
HashedMessage est un message signé par le signataire et contient une partie du contenu du retrait. Le signataire est une adresse d'administrateur par défaut. Comme il n'y a pas de règlement de statut, aucune vérification ne peut être effectuée, comme savoir si le compte a autant de pièces sur L2. Par conséquent, tous les fonds du contrat peuvent être retirés avec la signature du signataire, que ce soit une faute de la partie du projet ou une attaque de hacker pour obtenir la clé privée.
Dans le cumul, il n’est pas du tout nécessaire que les témoins libèrent les actifs ; Dans les chaînes latérales, si les témoins veulent faire quelque chose de décentralisé, ils peuvent sélectionner une partie de leur propre système de consensus en tant qu’agents et utiliser des garanties pour dissuader le mal dans une certaine mesure.
Dans Ethnic et Facet, rien. C'est simplement, sans déguisement, une adresse d'administrateur. Cela est probablement trop grossier pour un projet L2 qui crie souvent "les contrats intelligents sont des défauts de conception," "Rollup est centralisé," et "nous sommes une plateforme informatique de nouvelle génération." De toute évidence, il a encore de nombreuses failles, mais nous pouvons continuer à observer, même si ces failles ne sont pas faciles à corriger, et elles existent probablement également dans Bitcoin Layer 2.
Les actifs sur Ethnic et Facet ne sont pas des actifs émis sur L1.
·Pour disposer de capacités de contrat complexes, Facet a évolué en une entité L2, mais elle présente d'énormes risques en matière de sécurité financière.
·La revendication officielle est de supprimer le calcul du contrat sur L1, mais elle n'utilise même pas sa propre application principale.
L'éthanol est similaire à un Rollup avec une fonctionnalité de base très médiocre. Ni le Rollup n'est bon marché et rapide, ni le Rollup n'est sûr. Ce qu'il peut réaliser, le Rollup peut le faire, et il ne peut pas fournir les fonctions très importantes que le Rollup peut réaliser.
·S'il veut résoudre les problèmes ci-dessus, il doit développer un mécanisme de règlement des transactions, ainsi qu'un séquenceur et un bloc L2, puis cela finira par devenir un Rollup.
L'ethnie a profité de l'inscription au BTC et s'est appuyée sur le concept pour faire monter en flèche le vieux vin dans de nouvelles bouteilles, mais n'a pas découvert un nouveau paradigme. Actuellement, ETHS est encore principalement basé sur la spéculation financière, non pas que ce produit lui-même puisse apporter quelque chose que Ethereum Layer 2 n'a pas. La valeur à long terme de ce genre de chose reste clairement à découvrir, mais sous sa forme actuelle, ETHS a pris le "fardeau insupportable de la vie," et son slogan est bien différent de son effet pratique.
L'inscription actuelle d'Ethereum est essentiellement un vieux vin dans une nouvelle bouteille d'Ordinals, un nouveau paradigme sans réelle signification. ETHS présente encore des risques de sécurité, et bien qu'il soit plus décentralisé que Rollup, son processus de retrait repose encore sur un notaire/gestionnaire tiers, et il y a un risque de vol. De toute évidence, actuellement, ETHS relève principalement de l'engouement financier, non pas qu'il puisse apporter des innovations que la couche 2 d'Ethereum ne peut apporter.
La récente popularité des inscriptions écologiques BTC a encouragé les développeurs d'autres chaînes à construire des systèmes similaires. La manière dont les systèmes d'inscription sur les différentes chaînes sont mis en œuvre et les fonctions qu'ils peuvent accomplir sont légèrement différentes, mais ils ont quelques points communs :
1. Les inscriptions utilisent toutes les informations textuelles attachées au transfert pour exprimer l'opération que vous souhaitez effectuer, telles que l'écriture de "transférer 1 pièce à XXX" dans le message. Notez que ces informations sont en texte brut et ne concernent pas des opérations telles que l'exécution de contrats intelligents sur la chaîne.
2. Les développeurs concevront une série de spécifications et de normes pour standardiser toutes les informations textuelles.
3. Le développeur fournit un ensemble d'indexeurs Indexer pour calculer l'état interne du système d'inscription après avoir collecté les informations textuelles de toutes les inscriptions sur la chaîne. Indexer est un composant open source hors chaîne que n'importe qui peut exécuter.
L'inscription BTC Ordinals a établi un mécanisme pour émettre des NFT et des jetons sur BTC, et a également conduit à une réflexion à grande échelle sur le BTC L2. En ce sens, nous pouvons penser qu'Ordinals est quelque peu à la pointe et exploratoire. Cependant, Ordinals était limité par l'architecture propre du BTC en termes de technologie et d'expérience produit, et a également été critiqué par la communauté BTC OG pour des raisons telles que la pollution par la poussière et la consommation de données.
Alors, est-il judicieux de réimprimer l'inscription sur Ethereum? Après tout, Ethereum lui-même a des contrats intelligents complexes, et les ERC20 et les NFT font également partie d'Ethereum lui-même; quel impact auront ces projets d'inscription sur l'écosystème Ethereum, et causeront-ils la controverse et la agitation sur BTC?
Commençons par examiner comment l'Éthique est mise en œuvre. Il s'agit d'un projet d'inscription célèbre sur Ethereum qui utilise principalement Calldata pour fonctionner.
Calldata est l'ensemble des données d'entrée d'origine transmises dans une transaction Ethereum. Elle est généralement utilisée pour transmettre les paramètres nécessaires à l'interaction avec un contrat intelligent, mais elle peut également être utilisée pour envoyer des messages texte (commentaires, inscriptions, notes de transfert, etc.) à une adresse EOA. Dans la figure, les données d'entrée sont les calldata.
Si vous souhaitez utiliser l'ethnographie pour inscrire « Hello world » dans une transaction, vous devez construire une transaction avec les données d'appel suivantes :
Après que l'indexeur hors chaîne surveille cette transaction, il mettra à jour la base de données et notifiera l'utilisateur qu'une nouvelle inscription a été générée, et le contenu de l'inscription est Bonjour le monde. Des contenus plus complexes, tels que la représentation en base64 des informations sur l'image, peuvent également être placés dans l'inscription.
L'ethnicité a maintenant passé 6 ESIPs (propositions similaires à l'EIP) pour définir l'utilisation des inscriptions dans différents scénarios. Cependant, il s'agit uniquement de spécifications d'inscription relativement basiques, telles que le format des transactions d'inscription initiées à partir d'EOA, les événements d'émission de contrat, etc.
Puisque Ethnicity est un projet sur Ethereum, il est également possible de mettre en œuvre un certain degré de logique en utilisant les contrats intelligents d'Ethereum. Il est important de noter qu'interagir directement avec les contrats intelligents n'est pas l'approche recommandée par Ethical.
Bien que les places de marché NFT officielles et similaires soient également mises en œuvre directement à l'aide de contrats intelligents. Selon la documentation officielle, Ethical souhaite fournir aux utilisateurs un service informatique « décentralisé et abordable » : en séparant le calcul de la chaîne, le coût d'utilisation d'Ethereum sera considérablement réduit.
Explorons en détail le coût de l'appel d'un smart contract, qui peut être divisé en trois parties:
·Coûts de transaction de base : Toute transaction Ethereum nécessite un paiement, actuellement 21000 gaz.
Coût de transmission des données (calldata) : Calldata est généralement utilisé pour soumettre des données et des paramètres pour interagir avec des contrats intelligents. Après l'ajustement de l'EIP-2028, calldata consomme généralement 16 gaz par octet (4 gaz si les données sont de 0 octet).
Coût d'exécution du contrat : Si une transaction appelle une fonction dans un contrat intelligent, alors en fonction de la complexité de l'exécution de la fonction, des coûts de calcul doivent également être payés. Par exemple, si une mise à jour de statut est impliquée (comme la mise à jour des informations de solde dans un contrat ERC-20), l'appel à SSTORE peut consommer jusqu'à 5000-20,000 gaz.
Prenons une transaction de transfert USDT très simple. La transaction a coûté un total de 63 197 gaz, et les données d'appel sont :
Analysons ces données d'appel et combien de gaz cela coûtera :
·Les données d'appel Ethereum sont au format hexadécimal, c'est-à-dire que chaque deux chiffres représentent un octet (16^2 = 2^8). Le 0x au début indique que les données sont au format hexadécimal.
·Le a9059cbb après le début 0x est un sélecteur de fonction et occupe 4 octets non nuls.
·Les 32 prochaines octets sont des adresses, avec 12 octets de zéros devant (car les adresses Ethereum font 20 octets, de 0 à 32 octets sont ajoutés à gauche), et 20 octets de données d'adresse non nulles.
Les 32 derniers octets représentent le montant, avec un grand nombre de zéros à gauche, 3b9aca00 données non nulles à la fin et 4 octets non nuls.
· Ainsi, 28 octets non nuls et 40 octets nuls
Par conséquent, callDataGas = 28 * 16 + 40 * 4 = 608 gaz.
Le gaz total est de 63197. Après avoir soustrait le coût des données d'appel et le coût fixe, le coût de calcul du contrat intelligent pour l'exécution de cette transaction est de 41,589 gaz. Les coûts de calcul du contrat représentent la majeure partie de cette transaction, et il s'agit simplement d'une transaction simple. Dans les transactions complexes, le coût du calcul du contrat augmentera davantage.
Déplacer le processus de calcul hors chaîne réduira effectivement considérablement les coûts d'utilisation : si vous ne souhaitez pas appeler directement des contrats intelligents sur la chaîne, vous pouvez vous rendre à une adresse EOA convenue
0x0000000000000000000000000000000face7 Envoyer les données de transaction
Dans les données d'appel de la transaction, spécifiez le contrat que vous vouliez initialement appeler et les paramètres d'entrée correspondants. Étant donné que l'adresse ci-dessus est un compte EOA et qu'il n'y a pas de code de contrat, l'opération décrite ci-dessus ne déclenchera pas de tâches de calcul sur la chaîne; elle envoie simplement un message.
Hors chaîne, après que l'Indexeur a écouté ce message, il l'analysera pour découvrir quel contrat sur la chaîne ETH l'initiateur de ce message voulait initialement appeler, puis l'Indexeur calculera les résultats de l'appel de contrat hors chaîne.
Eh bien, si un indexeur hors ligne veut calculer des inscriptions et des contrats intelligents, il doit disposer d'un ensemble de règles et d'une exécution de la fonction de transition d'état (STF). La partie compliquée peut être appelée une machine virtuelle VM. Ethnic a lancé sa propre VM - VM Ethnic - dans l'ESIP-4, qui a ensuite été renommée Facet VM.
Facet se définit comme une plateforme informatique bon marché, facile à utiliser, sécurisée et décentralisée. Écoutez les données d'appel d'Ethical sur Ethereum, tirez-les vers la VM pour le calcul, et enfin renvoyez les résultats à l'utilisateur. Les facettes ont plusieurs composants clés :
·Facet VM, un ensemble de machines virtuelles écrites en Ruby, est responsable de surveiller les transactions ETHS, d'analyser les données d'appel et d'exécuter des opérations.
· Rubidity, le langage de programmation de contrat intelligent dans Facet, est similaire à Ruby, et conserve également de nombreuses utilisations et concepts de Solidity, afin que les développeurs puissent commencer rapidement.
Contrat stupide, un contrat stupide, un type de contrat qui fonctionne sur Facet. Le nom est plein d'humour. Certaines personnes ont également raison de l'appeler un contrat stupide. Stupide en soi est un jeu de mots; stupide peut décrire le processus silencieux du travail de ce genre de contrat. Mais d'un autre côté, selon le proverbe officiel "Si stupide, ils sont intelligents", cela signifie être stupide, avec un fort sens de la dispute avec les contrats intelligents, donc il n'y a pas de problème à les appeler des contrats stupides.
Le contrat stupide lui-même ne sera pas réellement déployé sur Ethereum ; son code sera publié sur la chaîne ETH sous forme de données d'appel. Voici un exemple de Facet appelant un contrat stupide :
Une transaction de frappe vers une adresse de trou noir EOA
0x000000000000000000000000000face7 soumet les données d'appel dans l'image ci-dessous, indiquant que vous ne voulez que le jeton et le montant de mint. C'est en fait la même chose que les Ordinaux ou les BRC-20 :
Jetons un autre coup d'œil à la comparaison visuelle entre Rubidity et Solidity, comme illustré ci-dessous.
Bien que la déclaration officielle soit que Rubidity a un concept et une structure similaires à Solidity, de sorte que les développeurs peuvent commencer rapidement. Mais nous savons que cela a en fait un impact négatif sur le développement du côté des développeurs. De plus, actuellement, Facet VM ne prend en charge que des contrats stupides sur la liste blanche officielle, ce qui montre que le gouvernement n'a pas beaucoup confiance en ce langage et en VM. S'il est plus difficile de réutiliser l'EVM officiellement en ingénierie que de développer une nouvelle VM et un nouveau langage, je ne sais pas. Mais une chose est certaine : le nouveau langage, le nouveau contrat, le nouvel écosystème et la nouvelle façon d'utiliser Ethereum sont vraiment suffisamment accrocheurs.
La documentation de Facet a fait les commentaires suivants sur l'Ethereum et les contrats intelligents : "Les contrats intelligents sont considérés comme la fonctionnalité qui rend l'Ethereum spécial par-dessus tout, et pourtant la thèse de Facet est que les contrats intelligents sont la plus grande faille de conception de l'Ethereum."
Ils croient que le smart contract d'Ethereum est la plus grande faille de conception, car le contrat lui-même ne nécessite qu'une entrée donnée (calldata) et sa sortie est déterminée, il ne devrait donc pas être calculé sur la chaîne, gaspillant de l'argent pour aucune raison. Associé au service informatique décentralisé et abordable d'Ethical, il est clair qu'Ethnic et Facet veulent vraiment créer une impression sur le marché, "Nous créons un nouveau paradigme d'expansion et de méthode d'utilisation d'Ethereum", mais en réalité, certaines solutions techniques d'ETHS ne sont pas très fiables.
D'un point de vue produit, Facet peut invoquer des contrats intelligents de manière indirecte sous la chaîne, et il possède également son propre système de contrat stupide sous la chaîne. En effet, le gouvernement met en œuvre son slogan.
Cependant, d'un point de vue économique, il n'y a pas de repas gratuits dans le monde ; bien sûr, le stockage et le calcul nécessitent de l'argent. Alors, comment Indexer résout-il cette partie du coût ? Il n'y a pas d'explication officielle à ce sujet, alors imaginons :
· Les utilisateurs sont facturés. Par exemple, les frais de traitement facturés par le marché NFT aux acheteurs, mais nous ne pouvons pas considérer un modèle de tarification simple de projet comme une méthode de tarification à long terme similaire à un réseau L2.
·Devenez riche grâce à votre propre hype écologique. C'est bien sûr possible, mais ce n'est qu'une solution à court terme pour maintenir le projet en vogue pendant un certain temps. Si l'Éthnicité doit devenir un nouveau paradigme d'Éthereum, l'Indexer doit disposer d'un mécanisme économique à long terme, basé sur le réseau, pour garantir le fonctionnement.
Si les biens publics ne sont pas rentables, quelles organisations feront des dons? Je pense qu'au moins la Fondation Ethereum ne sera pas particulièrement active car Ethereum lui-même a une très bonne solution - Rollup.
Si nous avons juste besoin de la forme simple de l'inscription Ethereum, alors un seul projet d'Ethnic suffit. Alors pourquoi sa proposition ESIP-4 a-t-elle engendré Facet à nouveau?
Parce que le système d'inscription ne peut pas être utilisé pour une logique de transaction complexe. Nous pouvons examiner la logique opérationnelle du contrat du marché NFT officiel d'Ethical, qui utilise un mécanisme de commande en attente.
Si vous souhaitez déposer l'inscription NFT dans le contrat, vous n'avez qu'à écrire les données d'appel en tant qu'ethscriptionID de l'inscription et appeler le contrat de marché. Comme cette opération sélectionne délibérément une forme invalide d'appel de fonction, elle déclenche par défaut fallback().
Finalement, un événement appelé PotentialEthScriptionOfferings sera déclenché sur la chaîne Ethereum. Après que le nœud Indexer surveille cet événement hors chaîne, il transférera localement la propriété du NFT dans un contrat de marché.
Afin d'économiser du gaz, le marché de trading ETHS ne stocke pas certains paramètres des ordres en attente du vendeur, tels que le prix, la date limite, etc. dans le contrat ETH, mais les place plutôt hors ligne sous forme de messages. Visuellement, ils auraient dû être stockés sur le serveur d'application décentralisée. Une fois que l'acheteur a surveillé ce message, il peut soumettre un achat en émettant la commande BuyWithSignature().
L'utilisation d'un mécanisme de commande en attente est normale pour les NFT car les NFT eux-mêmes ne sont pas homogènes. Donc, s'il s'agit d'une inscription de jeton homogénéisée, le mécanisme AMM du contrat peut-il être utilisé ? La réponse est non. Le statut des NFT ou jetons inscrits n'est pas sur L1, ce qui est à peu près similaire aux Ordinaux et BRC-20. C'est le contraire complet de certaines propagandes communautaires. Tout le monde doit être prudent. L'inscription n'est pas un actif sur la chaîne ETH au sens propre du terme. Nous ne pouvons pas dire que les calldata qui ont généré l'actif sont sur L1, et nous pouvons déclarer des instructions d'opération sur L1, appelées actif natif sur L1. Sinon, l'actif natif sur L2 sur Rollup peut également être appelé un actif sur L1, car les calldata de Rollup sont tous sur L1. De toute évidence, il est ridicule de qualifier ce genre d'actif d'actif natif sur L1.
Vous vous demandez peut-être, n'est-ce pas simplement un contrat intelligent utilisé pour trader? Pourquoi dit-on que les inscriptions sur le contrat ne peuvent pas être lues et manipulées? En fait, ce contrat est uniquement responsable de collecter de l'argent, de transférer de l'argent et d'organiser des événements pour les nœuds indexeurs sous la chaîne pour écouter et déclencher des opérations correspondantes. Aux yeux de l'EVM Ethereum, l'état de quelque chose comme une inscription ne peut pas être restauré dans la base de données de l'« État du monde » qui stocke spécifiquement l'état d'Ethereum, ni les contrats ne peuvent y faire référence.
Peu importe sous quelle forme un actif se présente, un jeton, un NFT, ou toute chose étrange, je peux donner une norme très simple pour identifier les actifs L1 et L2 : leur état peut-il être restauré à l'état du monde d'Éthereum, L'EVM de L1 peut-il se référer, appeler, interroger et modifier l'état de l'actif ; sinon, ce n'est pas un actif L1.
Par conséquent, vous pouvez également voir que le nom de l'événement de dépôt est PotentialEthscriptionDeposit, c'est-à-dire « rechargement d'inscription possible », plutôt qu'un rechargement définitif, car le contrat ne peut pas déterminer si cette inscription existe, et il est impossible de vérifier son authenticité. Si vous commandez une inscription qui n'existe pas, ou celle de quelqu'un d'autre, le contrat ne vous rejettera pas; c'est juste qu'Indexer n'inclura pas vos actions.
Par conséquent, le système d'inscription ne peut mettre en œuvre que cette logique de pseudo-contrat simple ; les ordres en attente en font partie. L'essence d'un ordre en attente est que les deux parties à la transaction conviennent des informations de l'autre selon une règle. En fait, cela peut être exprimé en texte clair sans contrat intelligent. Cela ressemble au principe d'une inscription.
Nous pouvons imaginer comment ce processus peut être complété sans utiliser de smart contract : le vendeur grave un message dans une transaction normale, me transfère 1ETH, et quelqu'un qui note 123 peut obtenir un NFT avec mon numéro d'inscription 123. Il suffit que l'Indexer prenne en charge cette logique. S'il détecte que quelqu'un a transféré 1ETH au vendeur et ajouté un ABC, alors cela peut être directement transféré à la base de données Indexer hors chaîne.
Bien sûr, cet exemple causera en réalité certains problèmes, tels que des transactions répétées qui peuvent résulter de plusieurs personnes se précipitant pour acheter un NFT. Le vendeur a reçu plusieurs transferts, mais à la fin, les NFT ne peuvent être transférés qu'à une seule personne par l'Indexer. Cela devrait également être l'une des raisons pour lesquelles le gouvernement critique clairement les contrats intelligents mais utilise des contrats pour mettre en œuvre le marché des NFT, vous devriez donc également être en mesure de comprendre l'affirmation officielle selon laquelle l'appel aux contrats intelligents sans calcul via Facet est peu fiable.
Bien sûr, les ordres en attente peuvent théoriquement utiliser du texte brut plutôt que de nécessiter un contrat, mais la logique relativement complexe de l'AMM nécessite des contrats intelligents, car elle ne nécessite pas un accord de pair à pair entre les deux parties, mais une approbation contractuelle. Un contrat agissant en tant que vérificateur fiable nécessite de vérifier des informations de base telles que le solde et la liquidité, et d'effectuer des calculs. Le contrat doit être capable d'obtenir toutes les données d'actifs dont il a besoin.
D'autre part, l'AMM n'est qu'une forme relativement simple de DeFi, et toute autre logique complexe ne peut pas être mise en œuvre sur Ethnic seul. C'est pourquoi Facet a été lancé - la priorité numéro un de Facet est le cross-domaine! En fait, c'est un L2, mais il n'a pas de structure de bloc, donc nous ne l'appelons pas cross-chain mais cross-domain. Lorsque tous les actifs L1 sont cross-domaine vers Facet, il n'y a aucun problème à ce qu'ils ne puissent pas être appelés entre les domaines. Tous les actifs hors chaîne peuvent être exploités avec des contrats stupides sous la chaîne, supportant ainsi une logique contractuelle complexe.
À travers la discussion détaillée ci-dessus, vous devriez être en mesure de voir que la solution d'Ethical est quelque peu similaire à Rollup. Mais ce n'est que "similaire"; strictement parlant, elle n'implémente qu'un sous-ensemble des fonctionnalités essentielles de Rollup. En revanche, les fonctionnalités manquantes ont causé des dommages fatals à son récit, ou ont mis les utilisateurs en grave danger.
Rollup est un système compliqué, et nous n'allons pas le développer ici. Il a quelque chose en commun avec l'Éthanol:
Ils soumettent tous des données d'appel pour les transactions L2 sur Ethereum.
Toutes les calculs sont traités hors chaîne.
Les similitudes sont très claires, et nous devons démontrer les différences en détail.
Dans la plupart des cas, les utilisateurs de Rollup ne soumettent pas directement des transactions à la L1, mais les soumettent plutôt à un séquenceur hors chaîne. Le séquenceur trie toutes les transactions, les regroupe et les compresse, puis envoie les données d'appel à la L1 par lots. En soumettant les données d'appel de plusieurs utilisateurs dans une seule transaction, le coût de base de 21 000 gaz peut être dilué.
Il n'y a pas un tel mécanisme dans l'Ethnicité; tous les utilisateurs soumettent directement les données d'appel à L1.
En utilisant l'exemple de l'USDT ci-dessus (608 gaz pour les données d'appel), supposons que 100 utilisateurs ont initié 100 transactions, et calculons approximativement la différence de coût entre les deux avec très peu de rigueur :
· Chaque utilisateur d'inscription paiera 21608 gaz (608 + 21000). Le reste du calcul n'est pas payé car le calcul est hors chaîne.
Les utilisateurs Rollup paient 818 gaz ((608*100+21000) /100) par personne. La partie mathématique est la même que ci-dessus.
Bien sûr, chaque utilisateur de Rollup doit également payer des frais de calcul et de stockage L2 au séquenceur, mais c'est beaucoup moins cher que L1, donc c'est négligeable dans ce cas. De plus, Rollup nécessite quelques champs spéciaux supplémentaires pour augmenter le volume, mais en même temps, il a également une meilleure compression des données, donc nous n'allons pas développer cela ici.
À travers cette estimation approximative, on peut constater que l'Éthanol n'a aucun avantage en termes de coût sur la Couche 2. De plus, dans la propagande communautaire du projet, j'ai vu des choses comme "4000 inscriptions peuvent être transférées par lots, environ 0,11 ETH, et en moyenne, seulement 0,05U par transfert" pour prouver que l'utilisation de l'Éthanol est bon marché. En fait, cela ne clarifie pas les principes et les détails d'interaction de l'ETHS.
Grâce à un séquenceur hors chaîne, les demandes des utilisateurs de Rollup peuvent être pré-confirmées en moins de 1 seconde. Il s'agit d'une expérience utilisateur bien meilleure que le système d'inscription pendant 12 secondes ou plus sur L1. Bien sûr, les partisans de l'inscription peuvent également faire valoir qu'avant que les données d'appel soient soumises à la chaîne ETH, les résultats finaux de telles transactions sont peu fiables.
Les utilisateurs sur Rollup sont susceptibles d'être censurés par des séquenceurs hors chaîne, alors que Ethical ne peut pas censurer les utilisateurs. Cependant, un Rollup bien conçu aura une fonction d'agrégation forcée pour contrer l'examen du séquenceur, et finalement le séquenceur n'a aucun pouvoir pour examiner les utilisateurs du tout.
Par conséquent, lorsque les utilisateurs utilisent Rollup, ils peuvent également contourner directement le séquenceur sur L1. Rollup offre aux utilisateurs différentes options. Vous pouvez utiliser un séquenceur plus rapide ou utiliser L1 directement. Cependant, Ethnic ne peut utiliser que L1, et il n'y a pas de place pour que les utilisateurs choisissent librement.
De plus, Ethnic a critiqué le séquenceur de Rollup pour être centralisé. Mais l'Indexer lui-même est également un composant très centralisé. Ethnic a expliqué que puisque n'importe qui peut exécuter et vérifier l'Indexer, il n'est pas centralisé, mais en fait, la grande majorité des gens n'exécutent pas eux-mêmes des nœuds. Par conséquent, ETHS ne montre son côté décentralisé que par rapport à Rollup dans des cas extrêmes. Après tout, le séquenceur de Rollup peut tomber en panne ou échouer, mais ETHS peut continuer à fonctionner tant que les membres de la communauté exécutent plusieurs Indexers.
Aucun projet ne peut utiliser l'amour pour générer de l'électricité. Les projets de développement à long terme doivent soigneusement considérer la question des modèles économiques. Qu'il s'agisse d'une entité centralisée ou d'une combinaison d'entités décentralisées, elles doivent être rentables pour protéger la sécurité du réseau pendant une longue période.
Le séquenceur de Rollup a un modèle économique clair : facturer plus de gaz, extraire MEV, etc. Le séquenceur a le pouvoir de garantir le fonctionnement normal du réseau. Étant donné que les utilisateurs soumettent directement les données d'appel à L1, l'Indexer ne facture pas beaucoup.
La plupart des langages de développement de contrats Rollup, des chaînes d'outils, etc. peuvent directement utiliser Ethereum, et les développeurs peuvent migrer facilement vers Rollup. Aucun de ceux-ci n'existe dans l'Ethnic; vous devez maîtriser le nouveau Rubidity, construire de nouvelles analyses, vous familiariser avec les nouveaux VM, etc. Bien sûr, vu sous un autre angle, cette résistance est aussi une opportunité d'exploration qui peut être apportée par le développement d'un nouvel écosystème.
C'est le problème fatal de Facet. Nous savons que Rollup soumet non seulement les calldata (entrées) à L1 par lots, mais soumet également régulièrement le règlement de l'état (sortie) après N opérations à L1. ZKR et OPR ont différentes méthodes de preuve pour déterminer si la relation entre l'entrée et la sortie est correcte. Peu importe la méthode de preuve, la décision finale est un contrat L1. La sortie et l'entrée sur Rollup sont traçables et ne peuvent pas être contrefaites.
Alors, à quoi sert le règlement du statut ? Utilisé pour les retraits, c’est-à-dire les retraits de fonds L2 à L1. Lorsque le statut sur L1 est publié, nous pouvons utiliser la preuve de Merkle et d’autres moyens pour prouver que ma demande de retrait sur L2 est incluse dans cette racine de statut en fonction de la racine de statut. Une fois que le contrat a été correctement vérifié, les actifs peuvent être libérés sur L1.
Facet n'a pas de mécanisme de règlement de statut, il lui est donc impossible d'obtenir des retraits décentralisés et sans permission de L2 à L1. Comme mentionné ci-dessus, il avait également besoin d'une couche L2 pour exécuter une logique de contrat plus complexe. Comme son AMM Swap FacetSwap.
On peut voir que FacetSwap (un dex construit sur Facet avec des contrats stupides) a clairement deux actions : dépôt et retrait. Normalement, il n'y a pas de dépôts ou de retraits pour Swap, car Facet exige que vous traversiez les domaines avant de pouvoir l'utiliser.
Dans Facet, le dépôt nécessite de verrouiller les fonds de L1 sur le contrat de pont L1, et d'émettre l'événement correspondant ethscriptions_protocol_createEthscription pour que l'indexeur soit indexé. Cela est cohérent avec d'autres méthodes de recharge L2.
Les retraits, en revanche, posent de sérieux problèmes de sécurité. Comme il n'y a pas de mécanisme de règlement des statuts sur Facet, les contrats ne peuvent pas être utilisés pour déterminer automatiquement si un retrait est valide de L2 à L1. Alors, quelle méthode Facet a-t-elle utilisée? L'administrateur a publié, ou mécanisme de témoin, similaire au pont Axie précédemment volé.
Jetons un coup d'œil directement au pont de Facet. L'adresse est:
0xd729345aa12c5af2121d96f87b673987f354496b.
HashedMessage est un message signé par le signataire et contient une partie du contenu du retrait. Le signataire est une adresse d'administrateur par défaut. Comme il n'y a pas de règlement de statut, aucune vérification ne peut être effectuée, comme savoir si le compte a autant de pièces sur L2. Par conséquent, tous les fonds du contrat peuvent être retirés avec la signature du signataire, que ce soit une faute de la partie du projet ou une attaque de hacker pour obtenir la clé privée.
Dans le cumul, il n’est pas du tout nécessaire que les témoins libèrent les actifs ; Dans les chaînes latérales, si les témoins veulent faire quelque chose de décentralisé, ils peuvent sélectionner une partie de leur propre système de consensus en tant qu’agents et utiliser des garanties pour dissuader le mal dans une certaine mesure.
Dans Ethnic et Facet, rien. C'est simplement, sans déguisement, une adresse d'administrateur. Cela est probablement trop grossier pour un projet L2 qui crie souvent "les contrats intelligents sont des défauts de conception," "Rollup est centralisé," et "nous sommes une plateforme informatique de nouvelle génération." De toute évidence, il a encore de nombreuses failles, mais nous pouvons continuer à observer, même si ces failles ne sont pas faciles à corriger, et elles existent probablement également dans Bitcoin Layer 2.
Les actifs sur Ethnic et Facet ne sont pas des actifs émis sur L1.
·Pour disposer de capacités de contrat complexes, Facet a évolué en une entité L2, mais elle présente d'énormes risques en matière de sécurité financière.
·La revendication officielle est de supprimer le calcul du contrat sur L1, mais elle n'utilise même pas sa propre application principale.
L'éthanol est similaire à un Rollup avec une fonctionnalité de base très médiocre. Ni le Rollup n'est bon marché et rapide, ni le Rollup n'est sûr. Ce qu'il peut réaliser, le Rollup peut le faire, et il ne peut pas fournir les fonctions très importantes que le Rollup peut réaliser.
·S'il veut résoudre les problèmes ci-dessus, il doit développer un mécanisme de règlement des transactions, ainsi qu'un séquenceur et un bloc L2, puis cela finira par devenir un Rollup.
L'ethnie a profité de l'inscription au BTC et s'est appuyée sur le concept pour faire monter en flèche le vieux vin dans de nouvelles bouteilles, mais n'a pas découvert un nouveau paradigme. Actuellement, ETHS est encore principalement basé sur la spéculation financière, non pas que ce produit lui-même puisse apporter quelque chose que Ethereum Layer 2 n'a pas. La valeur à long terme de ce genre de chose reste clairement à découvrir, mais sous sa forme actuelle, ETHS a pris le "fardeau insupportable de la vie," et son slogan est bien différent de son effet pratique.