Bienvenue dans la série spéciale « Web3 Indicateur », c'est une analyse et interprétation concentrée des nouvelles technologies, des protocoles et des produits de l'industrie Web3 récemment par quatorze experts.
La raison est que l'IA a doublé ma vitesse de recherche de nouveaux projets, je pense que la valeur des personnes à l'avenir sera davantage axée sur la réflexion, le jugement et l'inspiration.
Ainsi, cette série abordera trois angles : contexte industriel → principes techniques → impacts potentiels, afin de vous aider à saisir les changements essentiels dans les plus brefs délais et à évaluer les tendances qu'ils pourraient déclencher.
L'opinion de l'auteur est majoritairement teintée de pessimisme, sans constituer un investissement ou une transaction, et ne cible aucun projet en particulier.
Jito BAM｜« tri de blocs + marché de construction de blocs modulaire » sur Solana
Que est-il :
En résumé, BAM est une plateforme de "construction de blocs" sur Solana, dont l'objectif est similaire à celui du réseau builder d'Ethereum qui fait du PBS (séparation des constructeurs de blocs et des validateurs), visant à organiser l'ordre des transactions, lutter contre le MEV et prévenir les risques de malveillance centralisée.
Par qui, dans quel contexte :
Le principal acteur est le camp Jito, la plus grande plateforme d'enchères de transactions sur Solana, qui détient 90 % du marché des clients de validation, avec une forte influence de leadership. L'auteur a précédemment effectué une recherche détaillée à ce sujet : Rapport de dix mille mots : Évolution du paysage MEV sur Solana et ses mérites et démérites.
La composition des participants est également très solide : Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, DFlow, etc. Il est évident qu'il s'agit d'une action conjointe de la part de Solana et des projets majeurs.
Et une telle motivation est en réalité très compréhensible : d'une part, Solana fait face à la pression du développement explosif de Hyperliquid, une "chaîne de livres de commandes natifs", et la valeur fondamentale de Hyperliquid est très favorable aux opérations des teneurs de marché. Cependant, la nature même du développement de Solana rend difficile l'optimisation ciblée à cet égard. Mais si l'ensemble des transactions du bloc peut être personnalisé, cela pourrait résoudre les limitations liées à la génération linéaire des blocs de Solana, facilitant ainsi l'optimisation de divers scénarios DeFi.
Le plan de déploiement officiel est le suivant : au début, les nœuds seront gérés par Jito Labs avec la participation de quelques validateurs ; à moyen terme, il s'étendra à davantage d'opérateurs de nœuds, visant à couvrir plus de 30 % du staking réseau ; enfin, le code sera open source et gouvernance décentralisée.
Avec la tendance narrative de l'industrie vers la "justice vérifiable", le projet BAM a facilement obtenu le soutien des validateurs et des parties prenantes du protocole. Ainsi, l'auteur pense qu'il repose davantage sur la quête d'optimisations de l'équité telles que TEE et PBS, d'où son lancement.
Quel principe est mis en œuvre :
De plus, pour comprendre sa valeur, il est nécessaire de comprendre une caractéristique de l'algorithme POH de Solana.
C'est-à-dire que sa génération de blocs est en réalité progressive et linéaire (un slot de 400 ms comporte 64 périodes de tips, et lorsque chaque période arrive, les transactions en cours sont envoyées, et elles ne changent plus à moins d'un rollback), ce qui est différent du modèle d'Ethereum qui "prépare d'abord l'ensemble du bloc, puis consensus, puis synchronisation".
Avec ce système BAM, en tant que jito, il est en fait possible de mettre à niveau facilement un grand nombre de clients de validateurs, augmentant ainsi la part d'acceptation du système BAM par les validateurs.
Regardons à nouveau la structure du système BAM, comme dans l'image ci-dessous. La partie violette au centre, ainsi que la partie Plugin code à droite, c'est BAM.
Il fera en sorte que les transactions sur Solana ne soient pas envoyées une par une au Leader, mais qu'elles soient d'abord ordonnées dans le TEE (environnement d'exécution de confiance) selon l'ordre des transactions de "tout ce bloc" (en utilisant certaines règles de tri fixes mises en œuvre par le code Plugin), puis soumises en une seule fois aux validateurs.
Et le validateur doit également fournir une preuve TEE, indiquant qu'il a effectivement alloué tout l'espace de bloc (exclusivité) à ce marché d'ordres.
Ici, ce qui est assez caractéristique, c'est la fonctionnalité des plugins, qui peut « figer » les règles dans le classement des ordres de transaction de Tee. En fait, cela a une réelle signification pratique :
Par exemple : la plateforme oracle a besoin de mettre à jour le prix et de le fixer comme la première transaction dans un bloc. Cela peut réduire le caractère aléatoire des transactions de mise à jour des prix sur la chaîne, évitant ainsi les problèmes causés par des mises à jour de prix tardives. De même, pour un dex, on peut écrire un plugin pour identifier les transactions avec une forte probabilité d'échec et ne pas les inclure directement dans le Tee, puis attendre progressivement l'expiration de la transaction, réduisant ainsi les frais générés par les échecs.
Il peut coexister avec le système actuel de processus de blocage Solana : ce sont toujours trois ensembles parallèles, à savoir le flux de commandes ordinaire, le bundle Jito et BAM. BAM signifie "ne recevoir que des blocs entiers BAM dans un certain bloc".
Comment l'évaluer :
L'auteur pense que : c'est une voie "avec une forte équipe, une forte narration et une focalisation sur la scène", mais je ne suis pas optimiste quant à son adoption en tant que chemin principal sur le marché.
Tout comme le Builder net sur Ethereum et le très attendu mev share, les raisons pour lesquelles ces projets ont du mal à progresser sont similaires.
En raison de la réalité, le coût des TEE est élevé et la limite de QPS est également de l'ordre de mille (en 2013, le TEE avait seulement 128 Mo de mémoire, et bien qu'il ait beaucoup évolué depuis, il ne peut toujours atteindre qu'un QPS de mille). Cependant, aujourd'hui, 40 % des blocs sur Ethereum sont déjà construits par des TEE.
Cependant, le débit des données et des calculs de Solana est là, vous devez empiler beaucoup de TEE pour supporter le volume, en plus de la reprise après sinistre, de la mémoire et de la bande passante pour toute l'exploitation. Si ce projet n'a pas d'incitations économiques continues, il sera très difficile d'obtenir un rendement positif.
En fait, les revenus de Jito ne sont pas très élevés (par rapport aux protocoles à haut rendement sur la chaîne), par exemple, seulement au deuxième trimestre 2025, Jito a gagné 22 391,31 SOL (environ 4 millions de dollars) grâce aux pourboires. Une fois que l'énorme volume de transactions de Solana sera transféré, la panne de Tee sera inévitable, et Tee présente également de nombreuses caractéristiques telles que la panne mémoire et la suppression de stockage, ce qui augmentera le risque de panne et entraînera le risque de disparition massive des transactions.
Mais il a "le potentiel d'un argument de vente à prix élevé de type killer" : par exemple, la séquence des oracles et l'absence de paiement en cas d'échec sont toutes des bénéfices d'expérience "visibles". Les teneurs de marché et les transactions de niveau entreprise seront prêts à payer. De plus, la participation de Solana dans l'idée est en accord, ce qui en fait un bon moyen de générer du bruit.
Enfin : le positionnement de BAM n'est pas celui d'un volume de traitement 7x24, c'est un outil "pour garantir la certitude des blocs clés", mais beaucoup de garanties de certitude dépendent d'une certitude absolue et non de 30 % de certitude, et pas dans un cas de 100 %, même à 99 %, c'est 0. C'est la clé des décisions finales des grands projets web3.
BRC 2.0｜“mappage EVM”：capacité programmable alimentée par BTC
Que est-il :
Le 2 septembre 2025 sera activé, je comprends que c'est un système d'ombre à double chaîne "piloté par BTC et exécuté par EVM". Notez qu'il ne s'agit pas de BRC20, mais de la deuxième génération de BRC, concernant le contexte de BRC20, vous pouvez vous référer à : Interprétation du protocole Oridinals de Bitcoin et des normes BRC20 : innovations et limitations.
Le cœur de la version 2.0 est que vous écrivez des "instructions" sur BTC avec inscription ou commit-reveal, et que vous exécutez un "EVM modifié" dans l'indexeur pour effectuer le déploiement et l'appel correspondants. L'EVM ne prélève pas de gas (les paramètres sont conservés mais ne sont pas tarifés), les frais de transaction sont inclus dans la transaction BTC.
Fondamentalement similaire au protocole Alkanes (méthane), le méthane est basé sur le champ op-return de btc pour écrire des instructions de transaction, fonctionnant sur la machine virtuelle WASN, tandis que lui fonctionne sur l'EVM.
Par qui, dans quel contexte :
Le contexte de l'initiateur est : la plateforme bestinslot qui a émergé à l'époque des inscriptions BTC, poursuivant l'idée du BRC-20 : ne pas toucher au consensus BTC tout en essayant d'ajouter une "programmabilité".
Le contexte de l'industrie est le suivant : ces deux dernières années, ( en fait, c'est la narration de BTC programmable/L2 qui a pris de l'ampleur. Tout le monde cherchait des chemins d'ingénierie viables, mais l'écart entre les opportunités du marché et le rythme du développement était vraiment trop grand, ce qui a conduit à l'émergence cette année de modèles tels que brc2.0 et alkanes.
Le volume du marché est quelque peu limité, car la scène du BTC n'a jamais eu une force d'agrégation pour guider, et de nombreux protocoles peuvent être dérivés d'autres protocoles. Ainsi, en réalité, le brc2.0 pourrait très bien n'avoir aucune relation pratique avec le brc20.
Quel principe est mis en œuvre :
Il est dans l'indexeur, ce n'est pas sur la chaîne BTC ni sur une chaîne distincte, mais opère la logique EVM. Notez que ce n'est pas considéré comme une chaîne, car il n'y a pas de consensus.
L'adresse sur l'EVM que l'utilisateur doit contrôler est obtenue en hachant l'adresse BTC de l'utilisateur et en la mappant à une "adresse EVM virtuelle".
Pour opérer ce système, en fait, c'est très similaire à la logique de contrôle des actifs de BRC20, ce n'est qu'une chaîne de caractères json, dans brc2.0, elle est définie comme suit :
On peut voir que vous codez des instructions sur BTC, avec divers codes d'octets/données d'appel, qui sont exécutés en replay dans l'EVM.
Et la signature ainsi que le Gas ont également été modifiés : faire en sorte que le gasPrice=0 au niveau de la couche EVM, uniquement pour la limite de ressources ; les frais réels sont reflétés dans les frais de transaction BTC.
En fait, cela comporte beaucoup de risques. À l'époque, j'ai demandé à l'IA de chercher dans leur code de nœud et je n'ai pas trouvé de protection contre "la limite de profondeur d'appel/de pas". Donc, théoriquement, un contrat avec "récursion infinie/autocall" pourrait faire planter cette VM (bien sûr, cette protection n'est pas difficile à ajouter : il suffit de définir une profondeur maximale).
Comment l'évaluer :
Tout d'abord, il sait toujours comment nommer les choses. Au moins, le volume de brc2.0 sera meilleur que de créer un nouveau terme de protocole, c'est aussi pourquoi RGB a de nouveau fait parler de lui récemment.
Ensuite, il n'est pas complètement étranger au brc20, après tout, sa conception de protocole, son schéma de champ, sont essentiellement les mêmes, mais ce n'est pas vraiment une question de droits d'auteur. Cependant, je n'ai pas vu l'auteur original du brc20 faire une apparition, donc l'association ne devrait pas être très forte.
Enfin, toutes les plateformes explorant la programmabilité pourraient vouloir partager la valeur de ce consensus mondial de premier plan. Cependant, l'auteur pense que le BTC ne devrait en fait pas poursuivre la programmabilité, car il est certain que cette quête ne pourra jamais rivaliser avec les optimisations fonctionnelles et d'expérience des différentes chaînes à haute vitesse.
De plus, une fois que la programmabilité sera intégrée au BTC lui-même, cela briserait son piège d'évaluation. Un projet pouvant être réellement appliqué pourrait être évalué sur la base du PE, mais le BTC actuel est fort précisément parce qu'il repose sur un modèle d'offre et de demande limitée. L'offre et la demande limitées ne peuvent donc pas être évaluées, ce qui entraîne la formation d'un prix, accompagné d'un consensus autour de ce prix. Ainsi, c'est justement la limitation inhérente au BTC qui contribue à son succès.
EIP-7999 | proposition de marché des frais multidimensionnels d'Ethereum
Que est-il :
Proposé par Vitalik, ce protocole mérite d'être examiné. De plus, dans le dernier EIP, il a été renommé de EIP-0000 à EIP-7999, donc cet article conservera les deux appellations.
C'est un nouveau type de transaction proposé dans le contexte de la "division des frais de transaction" (c'est-à-dire le prix du blob dans une transaction, le coût des données de calcul et le prix selon eip-1559) après EIP-4844, qui consiste en un "plafond de prix total + vecteur de prix multi-ressources".
Vous pouvez comprendre cela comme : regrouper toutes les offres de ressources en une seule fois, faire une offre avec une signification uniforme, dans le but de résoudre le problème des trop nombreuses dimensions de tarification sur la chaîne.
Par qui, dans quel contexte :
La direction a été poussée par plusieurs articles de Vitalik. Auparavant, il y avait un paragraphe sur l'EIP des "4 zéros" qui a ensuite été numéroté 7999, dont le nom n'est pas si impressionnant, et cette direction est également le fruit des réflexions de Vitalik dans plusieurs de ses publications, dans lesquelles on peut voir l'évolution de sa pensée entre 2022 et 2024.
Pourquoi le proposer maintenant ?
Parce que les portefeuilles, les routeurs et les enchérisseurs de prix ressentent déjà clairement l'expérience de la rupture du "système de prix multiple" : chaque bloc n'a que 6 blobs, donc pour utiliser les transactions blob, il faut enchérir ; et la transaction elle-même est toujours dans l'eip-1559 ; sans oublier les calldata qui existent depuis 2015 et les prix unitaires différents pour les octets 0/non 0... Les développeurs de L2 ont déjà été poussés dans leurs retranchements, car ils doivent établir des plafonds de frais indépendants pour chaque dimension de ressource, et si l'un des plafonds est fixé trop bas, cela entraîne l'échec de la transaction entière, même si le budget total des frais de l'utilisateur est suffisant, car une augmentation soudaine des frais de base d'une ressource peut empêcher l'exécution de la transaction.
Quel principe est mis en œuvre :
La proposition prévoit d'introduire un marché de frais multidimensionnel unifié, dont la conception principale est de permettre aux utilisateurs de définir un seul paramètre max_fee (remplaçant plusieurs max_fee_per_gas sur différents champs), tandis que le processus d'exécution EVM alloue automatiquement ce frais de manière dynamique entre différentes ressources (EVM gas, blob gas, calldata gas).
Pour y parvenir, ce ne sera certainement pas facile, son plan est d'introduire un nouveau type de transaction, dont les champs sont les suivants :
Il est clair que ce design est un peu meilleur, après tout, après avoir vu la conception des frais de Gas de l'ERC-4337, cela devient trop complexe.
Détails ici : De 4337 à 7702 : Analyse approfondie du passé et de l'avenir de la voie d'abstraction des comptes Ethereum.
Comment l'évaluer :
L'auteur pense que cette direction est bonne et qu'elle a un sens de frais unifiés, ce qui facilitera beaucoup les choses lors de la mise en œuvre de L2/L3 à l'avenir, et correspond très bien à la grande stratégie actuelle d'Ethereum pour L2.
Mais la complexité va clairement augmenter et l'avancement du projet nécessitera un rythme plus stable. Parce que cette proposition entraînera des changements correspondants dans l'en-tête de bloc, le codage RLP, les limites, etc. Ce n'est pas seulement un changement au niveau du hard fork, mais cela nécessitera également l'adaptation d'autres plateformes sur toute la chaîne, en particulier un certain nombre de portefeuilles.
Bien qu'ils puissent ne pas prendre en charge ce type de transaction, il est nécessaire d'analyser l'état de cette transaction.
Donc, il est certain que cela ne se concrétisera pas à court terme, au moins après 1 à 2 grands forks, mais les deux articles de Vitalik sur le marché des frais sont des réflexions économiques très profondes, qui méritent d'être examinées de près.
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.
Web3 Indicateur de tendance, première édition : Interprétation de Jito BAM, BRC2.0, EIP-7999
Bienvenue dans la série spéciale « Web3 Indicateur », c'est une analyse et interprétation concentrée des nouvelles technologies, des protocoles et des produits de l'industrie Web3 récemment par quatorze experts.
La raison est que l'IA a doublé ma vitesse de recherche de nouveaux projets, je pense que la valeur des personnes à l'avenir sera davantage axée sur la réflexion, le jugement et l'inspiration.
Ainsi, cette série abordera trois angles : contexte industriel → principes techniques → impacts potentiels, afin de vous aider à saisir les changements essentiels dans les plus brefs délais et à évaluer les tendances qu'ils pourraient déclencher.
L'opinion de l'auteur est majoritairement teintée de pessimisme, sans constituer un investissement ou une transaction, et ne cible aucun projet en particulier.
Jito BAM｜« tri de blocs + marché de construction de blocs modulaire » sur Solana
Que est-il :
En résumé, BAM est une plateforme de "construction de blocs" sur Solana, dont l'objectif est similaire à celui du réseau builder d'Ethereum qui fait du PBS (séparation des constructeurs de blocs et des validateurs), visant à organiser l'ordre des transactions, lutter contre le MEV et prévenir les risques de malveillance centralisée.
Par qui, dans quel contexte :
Le principal acteur est le camp Jito, la plus grande plateforme d'enchères de transactions sur Solana, qui détient 90 % du marché des clients de validation, avec une forte influence de leadership. L'auteur a précédemment effectué une recherche détaillée à ce sujet : Rapport de dix mille mots : Évolution du paysage MEV sur Solana et ses mérites et démérites.
La composition des participants est également très solide : Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, DFlow, etc. Il est évident qu'il s'agit d'une action conjointe de la part de Solana et des projets majeurs.
Et une telle motivation est en réalité très compréhensible : d'une part, Solana fait face à la pression du développement explosif de Hyperliquid, une "chaîne de livres de commandes natifs", et la valeur fondamentale de Hyperliquid est très favorable aux opérations des teneurs de marché. Cependant, la nature même du développement de Solana rend difficile l'optimisation ciblée à cet égard. Mais si l'ensemble des transactions du bloc peut être personnalisé, cela pourrait résoudre les limitations liées à la génération linéaire des blocs de Solana, facilitant ainsi l'optimisation de divers scénarios DeFi.
Le plan de déploiement officiel est le suivant : au début, les nœuds seront gérés par Jito Labs avec la participation de quelques validateurs ; à moyen terme, il s'étendra à davantage d'opérateurs de nœuds, visant à couvrir plus de 30 % du staking réseau ; enfin, le code sera open source et gouvernance décentralisée.
Avec la tendance narrative de l'industrie vers la "justice vérifiable", le projet BAM a facilement obtenu le soutien des validateurs et des parties prenantes du protocole. Ainsi, l'auteur pense qu'il repose davantage sur la quête d'optimisations de l'équité telles que TEE et PBS, d'où son lancement.
Quel principe est mis en œuvre :
De plus, pour comprendre sa valeur, il est nécessaire de comprendre une caractéristique de l'algorithme POH de Solana.
C'est-à-dire que sa génération de blocs est en réalité progressive et linéaire (un slot de 400 ms comporte 64 périodes de tips, et lorsque chaque période arrive, les transactions en cours sont envoyées, et elles ne changent plus à moins d'un rollback), ce qui est différent du modèle d'Ethereum qui "prépare d'abord l'ensemble du bloc, puis consensus, puis synchronisation".
Avec ce système BAM, en tant que jito, il est en fait possible de mettre à niveau facilement un grand nombre de clients de validateurs, augmentant ainsi la part d'acceptation du système BAM par les validateurs.
Regardons à nouveau la structure du système BAM, comme dans l'image ci-dessous. La partie violette au centre, ainsi que la partie Plugin code à droite, c'est BAM.
Il fera en sorte que les transactions sur Solana ne soient pas envoyées une par une au Leader, mais qu'elles soient d'abord ordonnées dans le TEE (environnement d'exécution de confiance) selon l'ordre des transactions de "tout ce bloc" (en utilisant certaines règles de tri fixes mises en œuvre par le code Plugin), puis soumises en une seule fois aux validateurs.
Et le validateur doit également fournir une preuve TEE, indiquant qu'il a effectivement alloué tout l'espace de bloc (exclusivité) à ce marché d'ordres.
Ici, ce qui est assez caractéristique, c'est la fonctionnalité des plugins, qui peut « figer » les règles dans le classement des ordres de transaction de Tee. En fait, cela a une réelle signification pratique :
Par exemple : la plateforme oracle a besoin de mettre à jour le prix et de le fixer comme la première transaction dans un bloc. Cela peut réduire le caractère aléatoire des transactions de mise à jour des prix sur la chaîne, évitant ainsi les problèmes causés par des mises à jour de prix tardives. De même, pour un dex, on peut écrire un plugin pour identifier les transactions avec une forte probabilité d'échec et ne pas les inclure directement dans le Tee, puis attendre progressivement l'expiration de la transaction, réduisant ainsi les frais générés par les échecs.
Il peut coexister avec le système actuel de processus de blocage Solana : ce sont toujours trois ensembles parallèles, à savoir le flux de commandes ordinaire, le bundle Jito et BAM. BAM signifie "ne recevoir que des blocs entiers BAM dans un certain bloc".
Comment l'évaluer :
L'auteur pense que : c'est une voie "avec une forte équipe, une forte narration et une focalisation sur la scène", mais je ne suis pas optimiste quant à son adoption en tant que chemin principal sur le marché.
Tout comme le Builder net sur Ethereum et le très attendu mev share, les raisons pour lesquelles ces projets ont du mal à progresser sont similaires.
En raison de la réalité, le coût des TEE est élevé et la limite de QPS est également de l'ordre de mille (en 2013, le TEE avait seulement 128 Mo de mémoire, et bien qu'il ait beaucoup évolué depuis, il ne peut toujours atteindre qu'un QPS de mille). Cependant, aujourd'hui, 40 % des blocs sur Ethereum sont déjà construits par des TEE.
Cependant, le débit des données et des calculs de Solana est là, vous devez empiler beaucoup de TEE pour supporter le volume, en plus de la reprise après sinistre, de la mémoire et de la bande passante pour toute l'exploitation. Si ce projet n'a pas d'incitations économiques continues, il sera très difficile d'obtenir un rendement positif.
En fait, les revenus de Jito ne sont pas très élevés (par rapport aux protocoles à haut rendement sur la chaîne), par exemple, seulement au deuxième trimestre 2025, Jito a gagné 22 391,31 SOL (environ 4 millions de dollars) grâce aux pourboires. Une fois que l'énorme volume de transactions de Solana sera transféré, la panne de Tee sera inévitable, et Tee présente également de nombreuses caractéristiques telles que la panne mémoire et la suppression de stockage, ce qui augmentera le risque de panne et entraînera le risque de disparition massive des transactions.
Mais il a "le potentiel d'un argument de vente à prix élevé de type killer" : par exemple, la séquence des oracles et l'absence de paiement en cas d'échec sont toutes des bénéfices d'expérience "visibles". Les teneurs de marché et les transactions de niveau entreprise seront prêts à payer. De plus, la participation de Solana dans l'idée est en accord, ce qui en fait un bon moyen de générer du bruit.
Enfin : le positionnement de BAM n'est pas celui d'un volume de traitement 7x24, c'est un outil "pour garantir la certitude des blocs clés", mais beaucoup de garanties de certitude dépendent d'une certitude absolue et non de 30 % de certitude, et pas dans un cas de 100 %, même à 99 %, c'est 0. C'est la clé des décisions finales des grands projets web3.
BRC 2.0｜“mappage EVM”：capacité programmable alimentée par BTC
Que est-il :
Le 2 septembre 2025 sera activé, je comprends que c'est un système d'ombre à double chaîne "piloté par BTC et exécuté par EVM". Notez qu'il ne s'agit pas de BRC20, mais de la deuxième génération de BRC, concernant le contexte de BRC20, vous pouvez vous référer à : Interprétation du protocole Oridinals de Bitcoin et des normes BRC20 : innovations et limitations.
Le cœur de la version 2.0 est que vous écrivez des "instructions" sur BTC avec inscription ou commit-reveal, et que vous exécutez un "EVM modifié" dans l'indexeur pour effectuer le déploiement et l'appel correspondants. L'EVM ne prélève pas de gas (les paramètres sont conservés mais ne sont pas tarifés), les frais de transaction sont inclus dans la transaction BTC.
Fondamentalement similaire au protocole Alkanes (méthane), le méthane est basé sur le champ op-return de btc pour écrire des instructions de transaction, fonctionnant sur la machine virtuelle WASN, tandis que lui fonctionne sur l'EVM.
Par qui, dans quel contexte :
Le contexte de l'initiateur est : la plateforme bestinslot qui a émergé à l'époque des inscriptions BTC, poursuivant l'idée du BRC-20 : ne pas toucher au consensus BTC tout en essayant d'ajouter une "programmabilité".
Le contexte de l'industrie est le suivant : ces deux dernières années, ( en fait, c'est la narration de BTC programmable/L2 qui a pris de l'ampleur. Tout le monde cherchait des chemins d'ingénierie viables, mais l'écart entre les opportunités du marché et le rythme du développement était vraiment trop grand, ce qui a conduit à l'émergence cette année de modèles tels que brc2.0 et alkanes.
Le volume du marché est quelque peu limité, car la scène du BTC n'a jamais eu une force d'agrégation pour guider, et de nombreux protocoles peuvent être dérivés d'autres protocoles. Ainsi, en réalité, le brc2.0 pourrait très bien n'avoir aucune relation pratique avec le brc20.
Quel principe est mis en œuvre :
Il est dans l'indexeur, ce n'est pas sur la chaîne BTC ni sur une chaîne distincte, mais opère la logique EVM. Notez que ce n'est pas considéré comme une chaîne, car il n'y a pas de consensus.
L'adresse sur l'EVM que l'utilisateur doit contrôler est obtenue en hachant l'adresse BTC de l'utilisateur et en la mappant à une "adresse EVM virtuelle".
Pour opérer ce système, en fait, c'est très similaire à la logique de contrôle des actifs de BRC20, ce n'est qu'une chaîne de caractères json, dans brc2.0, elle est définie comme suit :
On peut voir que vous codez des instructions sur BTC, avec divers codes d'octets/données d'appel, qui sont exécutés en replay dans l'EVM.
Et la signature ainsi que le Gas ont également été modifiés : faire en sorte que le gasPrice=0 au niveau de la couche EVM, uniquement pour la limite de ressources ; les frais réels sont reflétés dans les frais de transaction BTC.
En fait, cela comporte beaucoup de risques. À l'époque, j'ai demandé à l'IA de chercher dans leur code de nœud et je n'ai pas trouvé de protection contre "la limite de profondeur d'appel/de pas". Donc, théoriquement, un contrat avec "récursion infinie/autocall" pourrait faire planter cette VM (bien sûr, cette protection n'est pas difficile à ajouter : il suffit de définir une profondeur maximale).
Comment l'évaluer :
Tout d'abord, il sait toujours comment nommer les choses. Au moins, le volume de brc2.0 sera meilleur que de créer un nouveau terme de protocole, c'est aussi pourquoi RGB a de nouveau fait parler de lui récemment.
Ensuite, il n'est pas complètement étranger au brc20, après tout, sa conception de protocole, son schéma de champ, sont essentiellement les mêmes, mais ce n'est pas vraiment une question de droits d'auteur. Cependant, je n'ai pas vu l'auteur original du brc20 faire une apparition, donc l'association ne devrait pas être très forte.
Enfin, toutes les plateformes explorant la programmabilité pourraient vouloir partager la valeur de ce consensus mondial de premier plan. Cependant, l'auteur pense que le BTC ne devrait en fait pas poursuivre la programmabilité, car il est certain que cette quête ne pourra jamais rivaliser avec les optimisations fonctionnelles et d'expérience des différentes chaînes à haute vitesse.
De plus, une fois que la programmabilité sera intégrée au BTC lui-même, cela briserait son piège d'évaluation. Un projet pouvant être réellement appliqué pourrait être évalué sur la base du PE, mais le BTC actuel est fort précisément parce qu'il repose sur un modèle d'offre et de demande limitée. L'offre et la demande limitées ne peuvent donc pas être évaluées, ce qui entraîne la formation d'un prix, accompagné d'un consensus autour de ce prix. Ainsi, c'est justement la limitation inhérente au BTC qui contribue à son succès.
EIP-7999 | proposition de marché des frais multidimensionnels d'Ethereum
Que est-il :
Proposé par Vitalik, ce protocole mérite d'être examiné. De plus, dans le dernier EIP, il a été renommé de EIP-0000 à EIP-7999, donc cet article conservera les deux appellations.
C'est un nouveau type de transaction proposé dans le contexte de la "division des frais de transaction" (c'est-à-dire le prix du blob dans une transaction, le coût des données de calcul et le prix selon eip-1559) après EIP-4844, qui consiste en un "plafond de prix total + vecteur de prix multi-ressources".
Vous pouvez comprendre cela comme : regrouper toutes les offres de ressources en une seule fois, faire une offre avec une signification uniforme, dans le but de résoudre le problème des trop nombreuses dimensions de tarification sur la chaîne.
Par qui, dans quel contexte :
La direction a été poussée par plusieurs articles de Vitalik. Auparavant, il y avait un paragraphe sur l'EIP des "4 zéros" qui a ensuite été numéroté 7999, dont le nom n'est pas si impressionnant, et cette direction est également le fruit des réflexions de Vitalik dans plusieurs de ses publications, dans lesquelles on peut voir l'évolution de sa pensée entre 2022 et 2024.
Pourquoi le proposer maintenant ?
Parce que les portefeuilles, les routeurs et les enchérisseurs de prix ressentent déjà clairement l'expérience de la rupture du "système de prix multiple" : chaque bloc n'a que 6 blobs, donc pour utiliser les transactions blob, il faut enchérir ; et la transaction elle-même est toujours dans l'eip-1559 ; sans oublier les calldata qui existent depuis 2015 et les prix unitaires différents pour les octets 0/non 0... Les développeurs de L2 ont déjà été poussés dans leurs retranchements, car ils doivent établir des plafonds de frais indépendants pour chaque dimension de ressource, et si l'un des plafonds est fixé trop bas, cela entraîne l'échec de la transaction entière, même si le budget total des frais de l'utilisateur est suffisant, car une augmentation soudaine des frais de base d'une ressource peut empêcher l'exécution de la transaction.
Quel principe est mis en œuvre :
La proposition prévoit d'introduire un marché de frais multidimensionnel unifié, dont la conception principale est de permettre aux utilisateurs de définir un seul paramètre max_fee (remplaçant plusieurs max_fee_per_gas sur différents champs), tandis que le processus d'exécution EVM alloue automatiquement ce frais de manière dynamique entre différentes ressources (EVM gas, blob gas, calldata gas).
Pour y parvenir, ce ne sera certainement pas facile, son plan est d'introduire un nouveau type de transaction, dont les champs sont les suivants :
Il est clair que ce design est un peu meilleur, après tout, après avoir vu la conception des frais de Gas de l'ERC-4337, cela devient trop complexe.
Détails ici : De 4337 à 7702 : Analyse approfondie du passé et de l'avenir de la voie d'abstraction des comptes Ethereum.
Comment l'évaluer :
L'auteur pense que cette direction est bonne et qu'elle a un sens de frais unifiés, ce qui facilitera beaucoup les choses lors de la mise en œuvre de L2/L3 à l'avenir, et correspond très bien à la grande stratégie actuelle d'Ethereum pour L2.
Mais la complexité va clairement augmenter et l'avancement du projet nécessitera un rythme plus stable. Parce que cette proposition entraînera des changements correspondants dans l'en-tête de bloc, le codage RLP, les limites, etc. Ce n'est pas seulement un changement au niveau du hard fork, mais cela nécessitera également l'adaptation d'autres plateformes sur toute la chaîne, en particulier un certain nombre de portefeuilles.
Bien qu'ils puissent ne pas prendre en charge ce type de transaction, il est nécessaire d'analyser l'état de cette transaction.
Donc, il est certain que cela ne se concrétisera pas à court terme, au moins après 1 à 2 grands forks, mais les deux articles de Vitalik sur le marché des frais sont des réflexions économiques très profondes, qui méritent d'être examinées de près.