Déclaration : Cet article est un contenu reproduit, les lecteurs peuvent obtenir plus d'informations via le lien original. Si l'auteur a des objections à la forme de reproduction, veuillez nous contacter, nous modifierons selon les demandes de l'auteur. La reproduction est uniquement destinée au partage d'informations, ne constitue pas un conseil en investissement et ne représente pas les opinions et positions de Wu.
Jito BAM｜Marché de construction de blocs "tri de blocs + plugin" sur Solana
Qui est-il :
En termes simples, BAM est une plateforme de "construction de blocs" sur Solana, similaire à l'objectif de PBS (séparation des constructeurs de blocs et des validateurs) sur le réseau des constructeurs d'Ethereum, visant à ordonner les séquences de transactions, à lutter contre le MEV et à prévenir les risques de décentralisation.
Par qui et dans quel contexte cela a-t-il été lancé :
Le leader est le camp Jito, la plus grande plateforme d'enchères de transactions sur Solana, occupant 90 % du marché des clients validateurs, avec une forte influence de leadership. L'auteur a précédemment effectué des recherches détaillées qui peuvent être consultées : Rapport de recherche 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 impressionnante : Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, DFlow, etc. Il est évident qu'il s'agit d'une action conjointe des projets officiels de Solana et des projets majeurs.
Et une telle motivation est en fait facile à comprendre : d'un côté, Solana fait face à la pression de développement explosif de Hyperliquid, qui est une "chaîne de livres de commandes natifs", tandis que la valeur fondamentale de Hyperliquid est très favorable aux opérations des market makers. Cependant, le développement de Solana rend en fait difficile l'optimisation ciblée à cet égard. Mais si les transactions de l'ensemble du bloc peuvent être personnalisées, cela pourrait rompre les limitations liées à la génération linéaire des blocs de Solana, ce qui serait bénéfique pour l'optimisation de divers scénarios DeFi.
Le plan de déploiement officiel est le suivant : au début, les nœuds sont gérés par Jito Labs, avec la participation d'un petit nombre de validateurs ; à moyen terme, l'expansion vers davantage d'opérateurs de nœuds, avec pour objectif de couvrir plus de 30 % des mises en réseau ; enfin, le code sera open source et gouverné de manière décentralisée.
Avec la tendance du secteur vers le récit de la "justice vérifiable", il est facile pour BAM de récolter le soutien des validateurs et des parties protocolaires. Par conséquent, l'auteur pense qu'il est davantage ancré dans la recherche de l'équité à travers des concepts tels que TEE + PBS, ce qui en constitue le contexte.
Quel principe est mis en œuvre :
De plus, pour comprendre sa valeur, il est également nécessaire de comprendre une caractéristique de l'algorithme POH de Solana.
C'est-à-dire que son bloc est en fait progressivement linéaire (un slot de 400 ms a 64 segments de temps pour les tips, chaque segment, une fois atteint, envoie la transaction actuelle, et sauf en cas de retour en arrière, il ne sera plus modifié), ce qui est différent du modèle d'Ethereum qui "prépare tout le bloc, puis consensus, puis synchronisation".
Ainsi, grâce à ce système BAM, en tant que jito, il est en fait possible de mettre à niveau facilement un grand nombre de clients de validateurs, ce qui augmente la proportion d'acceptation du système BAM par les validateurs.
La structure du système BAM est illustrée ci-dessous, la partie violette au centre, ainsi que la partie Plugin code à droite, représentent BAM.
Il fera en sorte que les transactions sur Solana ne soient pas envoyées au Leader une par une, mais qu'elles soient d'abord triées dans l'TEE (Environnement d'exécution de confiance) selon l'ordre des transactions dans "l'ensemble de ce bloc" (en combinant certaines règles de tri fixes mises en œuvre par le code Plugin), puis remises aux validateurs en une seule fois.
Le validateur doit également fournir une preuve TEE, indiquant qu'il a effectivement alloué tout l'espace du bloc (exclusivité) à ce marché de flux de commandes.
Ici, ce qui est assez particulier, c'est la fonctionnalité des plugins, qui permet de "figer" les règles dans le tri des ordres de交易 de Tee. En fait, cela a une réelle signification pratique :
Par exemple : la plateforme d'oracle a besoin de placer la mise à jour des prix fixe en première transaction dans un bloc, ce qui peut réduire le caractère aléatoire des transactions pour mettre à jour les prix sur la chaîne et éviter les problèmes causés par des mises à jour de prix tardives. De plus, pour les dex, il est possible d'écrire un plugin pour identifier les transactions à forte probabilité d'échec afin de ne pas les inclure dans le Tee, puis d'attendre progressivement l'expiration des transactions, réduisant ainsi les frais générés par les échecs.
Il peut coexister avec le système de processus de blocage actuel de Solana : il s'agit toujours d'un flux de commandes ordinaires, d'un bundle Jito et des trois ensembles parallèles BAM. BAM signifie "recevoir uniquement des blocs entiers de BAM dans un certain bloc".
Comment l'évaluer :
L'auteur pense que : c'est un chemin avec une "forte formation, un récit fort et un focus sur la scène", mais je ne suis pas optimiste quant à ce qu'il devienne une voie du marché mainstream.
Les raisons pour lesquelles le Builder net sur Ethereum et le mev share très attendu ont du mal à progresser depuis de nombreuses années sont similaires.
En raison de la réalité, le coût du TEE est élevé et la limite de QPS est de niveau millénaire (en 2013, le TEE n'avait que 128 Mo de mémoire, maintenant il a beaucoup évolué, mais il ne peut toujours atteindre que le niveau millénaire de QPS). Cependant, aujourd'hui, 40 % des blocs sur Ethereum sont déjà construits par TEE.
Cependant, le débit des données et des calculs de Solana est là, vous devez empiler beaucoup de TEE pour couvrir le volume, en plus de la continuité des activités, de la mémoire et de la bande passante. Si ce projet n'a pas d'incitations économiques continues, il sera très difficile d'obtenir des bénéfices.
En réalité, les revenus de Jito ne sont pas très élevés (en comparaison avec des protocoles à rendement élevé sur la chaîne), par exemple, au cours du deuxième trimestre de 2025, Jito a gagné seulement 22 391,31 SOL (environ 4 millions de dollars) grâce aux pourboires. Une fois que le volume de transactions énorme de Solana sera transféré, le crash de Tee sera inévitable, et Tee présente également de nombreuses caractéristiques telles que les pannes de mémoire et l'effacement du stockage, ce qui augmentera le risque de pannes et entraînera le risque de disparition massive de transactions.
Mais il a "le potentiel d'un argument de vente à prix élevé" : par exemple, l'oracle de séquençage et le paiement en cas d'échec sont tous deux des avantages d'expérience "visibles". Les teneurs de marché et les plateformes de trading de niveau entreprise seront prêts à payer. De plus, la participation est également soutenue par Solana sur le plan conceptuel, ce qui est un bon moyen de gagner en visibilité.
Enfin : la position de BAM n'est pas celle de traiter un volume 7x24 en continu, c'est un outil "pour garantir la certitude des blocs clés", mais de nombreuses garanties de certitude dépendent d'une certitude absolue, et non de 30 % de certitude. Ce n'est pas dans un cas à 100 %, même si c'est 99 %, c'est 0 %. C'est la clé de la décision finale des grands projets web3.
BRC 2.0｜“mappage EVM” : capacités programmables alimentées par BTC
Que est-il :
Le 2 septembre 2025 sera activé, je comprends cela comme un système d'ombre à double chaîne « piloté par BTC, exécuté par EVM ». Attention, ce n'est pas BRC20, mais cela signifie la deuxième génération de BRC. Pour le contexte de BRC20, vous pouvez vous référer à : Interprétation du protocole Oridinals de Bitcoin et des principes d'innovation et de limitations de la norme BRC20.
Le cœur de la version 2.0 est que vous utilisez une inscription ou un commit-reveal sur BTC pour écrire des "instructions", en exécutant un "EVM modifié" dans l'indexeur pour effectuer les déploiements et les appels correspondants. L'EVM ne prélève pas de frais (les paramètres sont conservés mais non valorisés), les frais de traitement sont inclus dans la transaction BTC.
Fondamentalement similaire au protocole Alkanes (méthane), le méthane est basé sur les instructions de transaction écrites dans le champ op-return de btc, fonctionnant sur la machine virtuelle WASN, tandis que celui-ci fonctionne sur l'EVM.
Par qui et dans quel contexte a-t-il été lancé :
Le contexte de l'initiateur est le suivant : la plateforme bestinslot, qui a connu un succès pendant l'ère des inscriptions BTC, continue dans la lignée de BRC-20 : sans toucher au consensus BTC, elle essaie d'ajouter autant que possible de la "programmabilité".
Le contexte de l'industrie est le suivant : ces deux dernières années, ( en fait, c'est l'histoire de la programmabilité de BTC/L2 qui a pris de l'ampleur, tout le monde cherche un chemin d'ingénierie qui fonctionne, mais l'écart entre le vent du marché et le rythme du développement est vraiment trop important, ce qui a conduit à l'apparition cette année de modèles comme brc2.0 et alkanes.
Le volume du marché est quelque peu limité, car la scène du BTC a toujours été guidée par une force qui manque d'agrégation, et de nombreux protocoles peuvent dériver d'autres protocoles. Donc, en réalité, le BRC2.0 est très susceptible de ne pas avoir de lien réel avec le BRC20.
Quel principe est mis en œuvre :
Il est dans l'indexeur, ce n'est pas sur la chaîne BTC et ce n'est pas une chaîne à part entière, pour faire fonctionner la logique EVM, notez que cela ne compte pas 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 lui-même, puis en la mappant à une "adresse EVM virtuelle".
Pour opérer ce système, cela ressemble en fait beaucoup à la logique de contrôle d'actifs de BRC20, c'est juste une chaîne de caractères json. Dans brc2.0, cela est défini comme suit :
On peut voir que c'est vous qui encodez des instructions sur BTC, en y ajoutant divers bytecodes/données d'appel, qui sont ensuite réexécutés dans l'EVM.
De plus, la signature et le Gas ont également été modifiés : le gasPrice de la couche EVM est fixé à 0, uniquement pour la limite des 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'avais demandé à l'IA de passer en revue leur code de nœud et je n'avais pas trouvé de protection contre la "limite de profondeur / d'étapes d'appel". Donc, théoriquement, un contrat qui fait de la "récursion infinie / auto-appel" pourrait faire planter cette VM (bien sûr, cette protection n'est pas difficile à ajouter : il suffit de définir une profondeur maximale).
Comment évaluer lui :
Tout d'abord, il sait comment nommer les choses, au moins la notoriété de brc2.0 sera meilleure que de créer un nouveau terme de protocole, c'est aussi pourquoi RGB a de nouveau fait parler de lui récemment.
De plus, il n'est pas complètement sans rapport avec le brc20, étant donné que sa conception de protocole, son modèle de champs, sont fondamentalement similaires. Cependant, cela ne constitue pas vraiment un droit d'auteur. Cependant, je n'ai pas vu l'auteur original du brc20 faire de la publicité, donc le lien ne devrait pas être très important.
Enfin, toutes les plateformes explorant la programmabilité pourraient vouloir partager la valeur de ce consensus mondial de classe mondiale. Cependant, l'auteur estime 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 à grande vitesse.
De plus, une fois que la programmabilité est intégrée même dans le btc lui-même, cela briserait son piège d'évaluation. Un projet pouvant être réellement appliqué peut être évalué sur la base du PE, mais le BTC actuel est puissant justement parce qu'il repose sur un modèle d'offre et de demande limité. Une offre et une demande limitées ne peuvent pas être évaluées, donc il y a un prix, et ce prix est accompagné d'un consensus. Ainsi, les limitations du BTC lui-même ont en fait contribué à sa réussite.
EIP-7999 | Proposition de marché des frais multidimensionnels d'Ethereum
Que est-il :
Une proposition menée par Vitalik mérite certainement d'être examinée. De plus, dans la dernière EIP, elle a été renommée de EIP-0000 à EIP-7999, donc cet article maintiendra d'abord les deux noms.
C'est un nouveau type de transaction proposé dans le contexte de la "fractionnement des frais de transaction" (c'est-à-dire que dans une transaction, le blob a un prix, le calldata a son prix, et l'exécution a encore le prix de l'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, en proposant un prix de manière unifiée et sémantique, afin de résoudre le problème des trop nombreuses dimensions de tarification sur la chaîne.
Par qui et dans quel contexte a-t-il été lancé :
La direction a été poussée par plusieurs articles de Vitalik. Auparavant, il y avait le EIP avec « 4 zéros » qui a ensuite été numéroté 7999, le nom n'est plus aussi impressionnant, et cette direction est également une réflexion que Vitalik a exprimée dans plusieurs de ses publications, où l'on peut voir l'évolution de sa pensée depuis les publications de 2022 jusqu'à celles de 2024.
Pourquoi le dire maintenant ?
Parce que les portefeuilles, les routeurs et les enchérisseurs ressentent déjà clairement l'expérience de la rupture du "système de prix multiples" : chaque bloc n'a que 6 blobs, donc pour utiliser les transactions des blobs, il faut enchérir ; et la transaction elle-même est encore dans l'eip-1559 ; il y a aussi le calldata depuis 2015 avec des prix différents selon les octets 0/non 0... Les développeurs de L2 sont déjà coincés dans un coin, car ils doivent définir des limites de frais indépendantes pour chaque dimension de ressource, toute dimension définie trop bas peut entraîner l'échec de la transaction entière, même si le budget total des frais de l'utilisateur est suffisant, il se peut qu'une augmentation soudaine des frais de base d'une certaine ressource empêche 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 centrale permet 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 répartira automatiquement ces frais 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 évident que ce design est encore meilleur, après tout, après avoir vu la conception des frais de Gas de l'ERC-4337, cela devient vraiment trop compliqué.
Détails disponibles : De 4337 à 7702 : Une analyse approfondie du passé et de l'avenir de la piste d'abstraction des comptes Ethereum.
Comment l'évaluer :
Je pense que cette direction est correcte et qu'elle a un sens de frais unifiés, ce qui facilitera considérablement les choses lors de la mise en œuvre de L2/L3 à l'avenir, et cela correspond parfaitement à la stratégie générale actuelle d'Ethereum sur L2.
Mais la complexité va clairement augmenter, et l'avancement du projet nécessitera un rythme plus stable. Car cette proposition va entraîner des changements dans les en-têtes de bloc, l'encodage RLP, les limites, etc. Ce ne sont pas seulement des modifications de niveau de 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 ne puissent pas prendre en charge ce type de transaction, ils doivent analyser l'état de cette transaction.
Donc, à court terme, il ne sera certainement pas mis en œuvre, 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 valent la peine 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 : interprétation de Jito BAM, BRC2.0, EIP-7999
Auteur : Quatorze Jon
Lien original :
Déclaration : Cet article est un contenu reproduit, les lecteurs peuvent obtenir plus d'informations via le lien original. Si l'auteur a des objections à la forme de reproduction, veuillez nous contacter, nous modifierons selon les demandes de l'auteur. La reproduction est uniquement destinée au partage d'informations, ne constitue pas un conseil en investissement et ne représente pas les opinions et positions de Wu.
Jito BAM｜Marché de construction de blocs "tri de blocs + plugin" sur Solana
Qui est-il :
En termes simples, BAM est une plateforme de "construction de blocs" sur Solana, similaire à l'objectif de PBS (séparation des constructeurs de blocs et des validateurs) sur le réseau des constructeurs d'Ethereum, visant à ordonner les séquences de transactions, à lutter contre le MEV et à prévenir les risques de décentralisation.
Par qui et dans quel contexte cela a-t-il été lancé :
Le leader est le camp Jito, la plus grande plateforme d'enchères de transactions sur Solana, occupant 90 % du marché des clients validateurs, avec une forte influence de leadership. L'auteur a précédemment effectué des recherches détaillées qui peuvent être consultées : Rapport de recherche 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 impressionnante : Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, DFlow, etc. Il est évident qu'il s'agit d'une action conjointe des projets officiels de Solana et des projets majeurs.
Et une telle motivation est en fait facile à comprendre : d'un côté, Solana fait face à la pression de développement explosif de Hyperliquid, qui est une "chaîne de livres de commandes natifs", tandis que la valeur fondamentale de Hyperliquid est très favorable aux opérations des market makers. Cependant, le développement de Solana rend en fait difficile l'optimisation ciblée à cet égard. Mais si les transactions de l'ensemble du bloc peuvent être personnalisées, cela pourrait rompre les limitations liées à la génération linéaire des blocs de Solana, ce qui serait bénéfique pour l'optimisation de divers scénarios DeFi.
Le plan de déploiement officiel est le suivant : au début, les nœuds sont gérés par Jito Labs, avec la participation d'un petit nombre de validateurs ; à moyen terme, l'expansion vers davantage d'opérateurs de nœuds, avec pour objectif de couvrir plus de 30 % des mises en réseau ; enfin, le code sera open source et gouverné de manière décentralisée.
Avec la tendance du secteur vers le récit de la "justice vérifiable", il est facile pour BAM de récolter le soutien des validateurs et des parties protocolaires. Par conséquent, l'auteur pense qu'il est davantage ancré dans la recherche de l'équité à travers des concepts tels que TEE + PBS, ce qui en constitue le contexte.
Quel principe est mis en œuvre :
De plus, pour comprendre sa valeur, il est également nécessaire de comprendre une caractéristique de l'algorithme POH de Solana.
C'est-à-dire que son bloc est en fait progressivement linéaire (un slot de 400 ms a 64 segments de temps pour les tips, chaque segment, une fois atteint, envoie la transaction actuelle, et sauf en cas de retour en arrière, il ne sera plus modifié), ce qui est différent du modèle d'Ethereum qui "prépare tout le bloc, puis consensus, puis synchronisation".
Ainsi, grâce à ce système BAM, en tant que jito, il est en fait possible de mettre à niveau facilement un grand nombre de clients de validateurs, ce qui augmente la proportion d'acceptation du système BAM par les validateurs.
La structure du système BAM est illustrée ci-dessous, la partie violette au centre, ainsi que la partie Plugin code à droite, représentent BAM.
Il fera en sorte que les transactions sur Solana ne soient pas envoyées au Leader une par une, mais qu'elles soient d'abord triées dans l'TEE (Environnement d'exécution de confiance) selon l'ordre des transactions dans "l'ensemble de ce bloc" (en combinant certaines règles de tri fixes mises en œuvre par le code Plugin), puis remises aux validateurs en une seule fois.
Le validateur doit également fournir une preuve TEE, indiquant qu'il a effectivement alloué tout l'espace du bloc (exclusivité) à ce marché de flux de commandes.
Ici, ce qui est assez particulier, c'est la fonctionnalité des plugins, qui permet de "figer" les règles dans le tri des ordres de交易 de Tee. En fait, cela a une réelle signification pratique :
Par exemple : la plateforme d'oracle a besoin de placer la mise à jour des prix fixe en première transaction dans un bloc, ce qui peut réduire le caractère aléatoire des transactions pour mettre à jour les prix sur la chaîne et éviter les problèmes causés par des mises à jour de prix tardives. De plus, pour les dex, il est possible d'écrire un plugin pour identifier les transactions à forte probabilité d'échec afin de ne pas les inclure dans le Tee, puis d'attendre progressivement l'expiration des transactions, réduisant ainsi les frais générés par les échecs.
Il peut coexister avec le système de processus de blocage actuel de Solana : il s'agit toujours d'un flux de commandes ordinaires, d'un bundle Jito et des trois ensembles parallèles BAM. BAM signifie "recevoir uniquement des blocs entiers de BAM dans un certain bloc".
Comment l'évaluer :
L'auteur pense que : c'est un chemin avec une "forte formation, un récit fort et un focus sur la scène", mais je ne suis pas optimiste quant à ce qu'il devienne une voie du marché mainstream.
Les raisons pour lesquelles le Builder net sur Ethereum et le mev share très attendu ont du mal à progresser depuis de nombreuses années sont similaires.
En raison de la réalité, le coût du TEE est élevé et la limite de QPS est de niveau millénaire (en 2013, le TEE n'avait que 128 Mo de mémoire, maintenant il a beaucoup évolué, mais il ne peut toujours atteindre que le niveau millénaire de QPS). Cependant, aujourd'hui, 40 % des blocs sur Ethereum sont déjà construits par TEE.
Cependant, le débit des données et des calculs de Solana est là, vous devez empiler beaucoup de TEE pour couvrir le volume, en plus de la continuité des activités, de la mémoire et de la bande passante. Si ce projet n'a pas d'incitations économiques continues, il sera très difficile d'obtenir des bénéfices.
En réalité, les revenus de Jito ne sont pas très élevés (en comparaison avec des protocoles à rendement élevé sur la chaîne), par exemple, au cours du deuxième trimestre de 2025, Jito a gagné seulement 22 391,31 SOL (environ 4 millions de dollars) grâce aux pourboires. Une fois que le volume de transactions énorme de Solana sera transféré, le crash de Tee sera inévitable, et Tee présente également de nombreuses caractéristiques telles que les pannes de mémoire et l'effacement du stockage, ce qui augmentera le risque de pannes et entraînera le risque de disparition massive de transactions.
Mais il a "le potentiel d'un argument de vente à prix élevé" : par exemple, l'oracle de séquençage et le paiement en cas d'échec sont tous deux des avantages d'expérience "visibles". Les teneurs de marché et les plateformes de trading de niveau entreprise seront prêts à payer. De plus, la participation est également soutenue par Solana sur le plan conceptuel, ce qui est un bon moyen de gagner en visibilité.
Enfin : la position de BAM n'est pas celle de traiter un volume 7x24 en continu, c'est un outil "pour garantir la certitude des blocs clés", mais de nombreuses garanties de certitude dépendent d'une certitude absolue, et non de 30 % de certitude. Ce n'est pas dans un cas à 100 %, même si c'est 99 %, c'est 0 %. C'est la clé de la décision finale des grands projets web3.
BRC 2.0｜“mappage EVM” : capacités programmables alimentées par BTC
Que est-il :
Le 2 septembre 2025 sera activé, je comprends cela comme un système d'ombre à double chaîne « piloté par BTC, exécuté par EVM ». Attention, ce n'est pas BRC20, mais cela signifie la deuxième génération de BRC. Pour le contexte de BRC20, vous pouvez vous référer à : Interprétation du protocole Oridinals de Bitcoin et des principes d'innovation et de limitations de la norme BRC20.
Le cœur de la version 2.0 est que vous utilisez une inscription ou un commit-reveal sur BTC pour écrire des "instructions", en exécutant un "EVM modifié" dans l'indexeur pour effectuer les déploiements et les appels correspondants. L'EVM ne prélève pas de frais (les paramètres sont conservés mais non valorisés), les frais de traitement sont inclus dans la transaction BTC.
Fondamentalement similaire au protocole Alkanes (méthane), le méthane est basé sur les instructions de transaction écrites dans le champ op-return de btc, fonctionnant sur la machine virtuelle WASN, tandis que celui-ci fonctionne sur l'EVM.
Par qui et dans quel contexte a-t-il été lancé :
Le contexte de l'initiateur est le suivant : la plateforme bestinslot, qui a connu un succès pendant l'ère des inscriptions BTC, continue dans la lignée de BRC-20 : sans toucher au consensus BTC, elle essaie d'ajouter autant que possible de la "programmabilité".
Le contexte de l'industrie est le suivant : ces deux dernières années, ( en fait, c'est l'histoire de la programmabilité de BTC/L2 qui a pris de l'ampleur, tout le monde cherche un chemin d'ingénierie qui fonctionne, mais l'écart entre le vent du marché et le rythme du développement est vraiment trop important, ce qui a conduit à l'apparition cette année de modèles comme brc2.0 et alkanes.
Le volume du marché est quelque peu limité, car la scène du BTC a toujours été guidée par une force qui manque d'agrégation, et de nombreux protocoles peuvent dériver d'autres protocoles. Donc, en réalité, le BRC2.0 est très susceptible de ne pas avoir de lien réel avec le BRC20.
Quel principe est mis en œuvre :
Il est dans l'indexeur, ce n'est pas sur la chaîne BTC et ce n'est pas une chaîne à part entière, pour faire fonctionner la logique EVM, notez que cela ne compte pas 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 lui-même, puis en la mappant à une "adresse EVM virtuelle".
Pour opérer ce système, cela ressemble en fait beaucoup à la logique de contrôle d'actifs de BRC20, c'est juste une chaîne de caractères json. Dans brc2.0, cela est défini comme suit :
On peut voir que c'est vous qui encodez des instructions sur BTC, en y ajoutant divers bytecodes/données d'appel, qui sont ensuite réexécutés dans l'EVM.
De plus, la signature et le Gas ont également été modifiés : le gasPrice de la couche EVM est fixé à 0, uniquement pour la limite des 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'avais demandé à l'IA de passer en revue leur code de nœud et je n'avais pas trouvé de protection contre la "limite de profondeur / d'étapes d'appel". Donc, théoriquement, un contrat qui fait de la "récursion infinie / auto-appel" pourrait faire planter cette VM (bien sûr, cette protection n'est pas difficile à ajouter : il suffit de définir une profondeur maximale).
Comment évaluer lui :
Tout d'abord, il sait comment nommer les choses, au moins la notoriété de brc2.0 sera meilleure que de créer un nouveau terme de protocole, c'est aussi pourquoi RGB a de nouveau fait parler de lui récemment.
De plus, il n'est pas complètement sans rapport avec le brc20, étant donné que sa conception de protocole, son modèle de champs, sont fondamentalement similaires. Cependant, cela ne constitue pas vraiment un droit d'auteur. Cependant, je n'ai pas vu l'auteur original du brc20 faire de la publicité, donc le lien ne devrait pas être très important.
Enfin, toutes les plateformes explorant la programmabilité pourraient vouloir partager la valeur de ce consensus mondial de classe mondiale. Cependant, l'auteur estime 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 à grande vitesse.
De plus, une fois que la programmabilité est intégrée même dans le btc lui-même, cela briserait son piège d'évaluation. Un projet pouvant être réellement appliqué peut être évalué sur la base du PE, mais le BTC actuel est puissant justement parce qu'il repose sur un modèle d'offre et de demande limité. Une offre et une demande limitées ne peuvent pas être évaluées, donc il y a un prix, et ce prix est accompagné d'un consensus. Ainsi, les limitations du BTC lui-même ont en fait contribué à sa réussite.
EIP-7999 | Proposition de marché des frais multidimensionnels d'Ethereum
Que est-il :
Une proposition menée par Vitalik mérite certainement d'être examinée. De plus, dans la dernière EIP, elle a été renommée de EIP-0000 à EIP-7999, donc cet article maintiendra d'abord les deux noms.
C'est un nouveau type de transaction proposé dans le contexte de la "fractionnement des frais de transaction" (c'est-à-dire que dans une transaction, le blob a un prix, le calldata a son prix, et l'exécution a encore le prix de l'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, en proposant un prix de manière unifiée et sémantique, afin de résoudre le problème des trop nombreuses dimensions de tarification sur la chaîne.
Par qui et dans quel contexte a-t-il été lancé :
La direction a été poussée par plusieurs articles de Vitalik. Auparavant, il y avait le EIP avec « 4 zéros » qui a ensuite été numéroté 7999, le nom n'est plus aussi impressionnant, et cette direction est également une réflexion que Vitalik a exprimée dans plusieurs de ses publications, où l'on peut voir l'évolution de sa pensée depuis les publications de 2022 jusqu'à celles de 2024.
Pourquoi le dire maintenant ?
Parce que les portefeuilles, les routeurs et les enchérisseurs ressentent déjà clairement l'expérience de la rupture du "système de prix multiples" : chaque bloc n'a que 6 blobs, donc pour utiliser les transactions des blobs, il faut enchérir ; et la transaction elle-même est encore dans l'eip-1559 ; il y a aussi le calldata depuis 2015 avec des prix différents selon les octets 0/non 0... Les développeurs de L2 sont déjà coincés dans un coin, car ils doivent définir des limites de frais indépendantes pour chaque dimension de ressource, toute dimension définie trop bas peut entraîner l'échec de la transaction entière, même si le budget total des frais de l'utilisateur est suffisant, il se peut qu'une augmentation soudaine des frais de base d'une certaine ressource empêche 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 centrale permet 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 répartira automatiquement ces frais 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 évident que ce design est encore meilleur, après tout, après avoir vu la conception des frais de Gas de l'ERC-4337, cela devient vraiment trop compliqué.
Détails disponibles : De 4337 à 7702 : Une analyse approfondie du passé et de l'avenir de la piste d'abstraction des comptes Ethereum.
Comment l'évaluer :
Je pense que cette direction est correcte et qu'elle a un sens de frais unifiés, ce qui facilitera considérablement les choses lors de la mise en œuvre de L2/L3 à l'avenir, et cela correspond parfaitement à la stratégie générale actuelle d'Ethereum sur L2.
Mais la complexité va clairement augmenter, et l'avancement du projet nécessitera un rythme plus stable. Car cette proposition va entraîner des changements dans les en-têtes de bloc, l'encodage RLP, les limites, etc. Ce ne sont pas seulement des modifications de niveau de 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 ne puissent pas prendre en charge ce type de transaction, ils doivent analyser l'état de cette transaction.
Donc, à court terme, il ne sera certainement pas mis en œuvre, 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 valent la peine d'être examinées de près.