Web3 Trends Uitgave 1: Interpretatie van Jito BAM, BRC2.0 en EIP-7999

Welkom bij de "Web3 Trends" serie, waarin Shisijun een geconcentreerde analyse en interpretatie biedt van recente nieuwe technologieën, protocollen en producten in de Web3-industrie.

De reden is dat AI de snelheid waarmee ik nieuwe projecten kan onderzoeken heeft verdubbeld. Ik denk dat in de toekomst de waarde van mensen meer gericht zal zijn op denken, oordelen en inspiratie.

Daarom zal deze serie je helpen om in de kortste tijd de kernveranderingen te begrijpen en de trends die ze kunnen veroorzaken te beoordelen vanuit drie perspectieven: industriële achtergrond → technische principes → potentiële impact.

De meeste standpunten van de auteur zijn pessimistisch en zijn niet bedoeld als investeringsadvies, noch zijn ze gericht op enige projectpartij.

Jito BAM｜Block Ordering + Plug-in Block Building Market op Solana

Wat is het:

Eenvoudig gezegd is BAM een "block building" platform op Solana. Vergelijkbaar met het doel van Ethereum Builder Net om PBS (block builder en validator scheiding) te doen, zijn beide gericht op een meer geordende transactievolgorde, het bestrijden van MEV, en het voorkomen van het risico van gecentraliseerde kwaadwilligheid.

Wie heeft het gelanceerd en wat voor achtergrond:

De leidende partij is het Jito-kamp, het grootste handelsveiling platform op Solana, dat 90% van de validator client markt bezet en een sterke leiderschapsinvloed heeft. De auteur heeft eerder gedetailleerd onderzoek uitgevoerd, waarnaar kan worden verwezen als: 10.000-woorden onderzoeksrapport: De evolutie van het MEV-landschap op Solana en de voor- en nadelen ervan

De line-up van deelnemers is ook zeer sterk, waaronder Triton One, SOL Strategies, Figment, Helius, Drift, Pyth, DFlow, enz. Dit is duidelijk een gezamenlijke actie van Solana officieel en mainstream projecten.

Deze motivatie is gemakkelijk te begrijpen: Solana staat onder druk van de explosieve groei van "native orderboek ketens" zoals Hyperliquid, waarvan de kernwaarde ligt in het vermogen om market maker operaties te faciliteren. De inherente ontwikkelingsaard van Solana maakt het echter moeilijk om dit gericht te optimaliseren. Als de transacties binnen het hele blok echter kunnen worden aangepast, dan kunnen de beperkingen van Solana's lineaire blokgeneratie worden overwonnen, waardoor de optimalisatie van verschillende DeFi-scenario's wordt vergemakkelijkt.

Het officiële implementatieplan is: in de beginfase zal Jito Labs de nodes beheren, met een klein aantal validators die deelnemen; op middellange termijn zal het worden uitgebreid naar meer node-operators, met als doel 30%+ van de netwerkstaking te dekken; en uiteindelijk zal de code open source worden en gedecentraliseerd bestuur krijgen.

Gekoppeld aan de narratieve trend van de industrie van "verifieerbare eerlijkheid", kan de richting van BAM gemakkelijk steun krijgen van validators en protocolpartijen. Daarom gelooft de auteur dat het meer gebaseerd is op het concept van het nastreven van eerlijkheidsoptimalisatie zoals TEE + PBS en werd gelanceerd in de achtergrond.

Hoe het principe wordt geïmplementeerd:

Daarnaast moet je, om de waarde ervan te begrijpen, ook een functie van Solana's eigen POH-algoritme begrijpen.

Dat wil zeggen, de blokgeneratie is eigenlijk geleidelijk en lineair (een slot heeft 64 tip tijdsperioden onder 400ms. Wanneer elke tijdsperiode verstrijkt, wordt de huidige transactie verzonden en zal niet worden gewijzigd tenzij teruggedraaid). Dit verschilt van Ethereum's "arrangeer het hele blok, bereik eerst consensus, en synchroniseer dan" model.

Via dit BAM-systeem kan jito gemakkelijk de clients van een groot aantal validators upgraden, waardoor het aandeel van het BAM-systeem dat door validators wordt geaccepteerd, toeneemt.

Laten we kijken naar de BAM-systeemstructuur zoals hieronder weergegeven. Het paarse deel in het midden en de Plugin-code aan de rechterkant zijn BAM.

Hij zorgt ervoor dat de transacties op Solana niet één voor één naar de Leader worden gepusht, maar de transactievolgorde van "dit hele blok" wordt eerst gesorteerd in de TEE (Trusted Computing Environment) (gecombineerd met enkele vaste sorteerregels geïmplementeerd door de Plugin-code), en vervolgens in één keer aan de validator overhandigd.

De validator moet uiteindelijk TEE-bewijs leveren dat hij inderdaad de blokruimte (exclusiviteit) aan deze orderstroommarkt heeft gegeven.

Het meest unieke kenmerk hier is de plug-in functie, die regels kan "hardcoderen" in de Tee-transactieordesortering. Dit heeft daadwerkelijk praktische toepassingsbetekenis:

Bijvoorbeeld, orakelplatforms vereisen dat prijsupdates worden gepland als de eerste transactie in een blok. Dit vermindert de willekeurigheid van transacties die on-chain prijzen bijwerken en vermijdt problemen veroorzaakt door niet-tijdige prijsupdates. Voor een ander voorbeeld, voor Dex, zou een plugin kunnen worden geschreven om transacties met een hoge kans op mislukking te identificeren en deze simpelweg niet op te nemen in de Tee, waardoor ze geleidelijk kunnen verlopen, waardoor de kosten in verband met mislukte transacties worden verminderd.

Het kan naast het bestaande Solana-blokproductiesysteem bestaan: de normale orderstroom, Jito-bundel en BAM zijn nog steeds drie parallelle systemen. BAM betekent "alleen BAM-blokken worden geaccepteerd in een blok."

Hoe hem te evalueren:

De auteur gelooft dat dit een pad is met "sterke line-up, sterk verhaal en gerichte scènes", maar ik ben niet optimistisch dat het het mainstream marktpad zal worden.

De redenen zijn vergelijkbaar met die van Builder Net op Ethereum en de zeer gewilde MEV Share, die al jaren moeite hebben om vooruitgang te boeken.

Vanwege de realiteit is TEE duur en de QPS-limiet is slechts in de duizenden (in 2013 had Tee slechts 128M geheugen, en nu heeft het zich veel ontwikkeld, maar het kan slechts duizenden QPS bereiken), hoewel 40% van de blokken op Ethereum nu door TEE worden gebouwd.

Solana's data- en rekendoorvoer is echter hoog, en je zou talrijke TEE's moeten inzetten om het te verwerken, samen met uitgebreide operaties en onderhoud voor disaster recovery, geheugen en bandbreedte. Zonder duurzame economische prikkels is het moeilijk om positieve rendementen te genereren.

De opbrengsten van Jito zijn eigenlijk vrij laag (vergeleken met hoog renderende protocollen op de blockchain). Bijvoorbeeld, alleen al in het tweede kwartaal van 2025 verdiende Jito slechts 22.391,31 SOL (ongeveer $4 miljoen) via tips. Zodra Solana's enorme transactievolume daarheen wordt gemigreerd, is Tee-downtime onvermijdelijk. Bovendien verhogen Tee's talrijke functies, zoals geheugenfouten en opslagzuivering, het risico op downtime en het potentieel voor wijdverspreide transactieverlies.

Het heeft echter potentieel voor killer selling points: oracle sequencing en no-failure betalingen bieden bijvoorbeeld tastbare gebruikersvoordelen. Market makers en handelsplatforms op ondernemingsniveau zullen erin investeren. Bovendien profiteert deelname eraan ook van Solana's officiële ondersteuning, waardoor het een geweldige manier is om erkenning te krijgen.

Ten slotte: BAM zelf is niet gepositioneerd om 24/7 doorvoer te bieden. Het is een hulpmiddel om "deterministische garanties te bieden voor belangrijke blokken." Veel deterministische garanties zijn echter afhankelijk van absolute zekerheid, niet van 30% zekerheid. Als het niet 100% is, zelfs als het 99% is, is het nog steeds 0%. Dit is de sleutel tot de uiteindelijke besluitvorming van grote web3-projecten.

BRC 2.0｜"Mapping EVM": Programmeerbare mogelijkheden aangedreven door BTC

Wat is het:

Het wordt geactiveerd op 2 september 2025. Ik begrijp dit als een dubbele-keten schaduwsysteem aangedreven door BTC en uitgevoerd door EVM. Merk op dat het niet verwijst naar BRC20, maar naar de tweede generatie van BRC. Voor meer informatie over BRC20, raadpleeg: Het interpreteren van het Bitcoin Ordinals Protocol en de innovatie en beperkingen van de BRC20 standaardprincipes.

De kern van 2.0 is dat je "instructies" op Bitcoin schrijft met behulp van inscription of commit-reveal, en een gemodificeerde EVM draait in de indexer om de bijbehorende implementatie en aanroepen uit te voeren. De EVM rekent geen gas aan (de parameters worden behouden maar niet berekend), en de transactiekosten worden toegevoegd aan de Bitcoin-transactie.

Het is in wezen vergelijkbaar met het Alkanes-protocol (Methane). Methane schrijft transactie-instructies op basis van het op-return veld van Bitcoin en draait in de WASN virtuele machine, terwijl het in de EVM draait.

Wie heeft het gelanceerd en wat voor achtergrond:

De achtergrond van de initiatiefnemer is: het bestinslot-platform, dat populair werd in het BTC-inscriptietijdperk, zet het idee van BRC-20 voort: zonder de BTC-consensus te veranderen, proberen "programmeerbaarheid" toe te voegen.

De industriële achtergrond is: in de afgelopen twee jaar (eigenlijk de afgelopen twee jaar) is het verhaal van BTC-programmeerbaarheid/L2 populair geweest, en iedereen zoekt naar een engineeringpad dat soepel kan lopen. De kloof tussen markttrends en ontwikkelingsvoortgang is echter te groot, wat resulteert in de opkomst van willekeurige modellen zoals BRC2.0 en Alkanes pas dit jaar.

De marktstem is enigszins beperkt omdat het BTC-podium nooit een samenbindende kracht heeft gehad om het te leiden, en veel protocollen kunnen worden afgeleid van andere protocollen, dus in feite heeft BRC2.0 waarschijnlijk geen daadwerkelijke relatie met BRC20.

Hoe het principe wordt geïmplementeerd:

Het is in de indexer, niet op de BTC-keten noch een aparte keten, om de EVM-logica te bedienen. Merk op dat het niet als een keten wordt beschouwd omdat er geen consensus is.

Het adres op de EVM dat de gebruiker wil controleren, wordt verkregen door de eigen BTC-adres van de gebruiker te hashen en het vervolgens in een "virtueel EVM-adres" te mappen.

Om dit systeem te bedienen, is de logica eigenlijk zeer vergelijkbaar met die van BRC20's asset control. Het is gewoon een JSON-string. In BRC2.0 is het als volgt gedefinieerd:

Het is te zien dat je instructies op BTC codeert, met verschillende bytecodes/call data, en het wordt gereplayeerd en uitgevoerd in de EVM.

Daarnaast zijn ook de handtekening en gasprijzen gewijzigd: de EVM-laag gasPrice is ingesteld op 0, wat alleen dient als een resourcelimiet; de werkelijke verwerkingskosten worden weerspiegeld in de BTC-transactiekosten.

Dit is eigenlijk vrij riskant. Ik liet mijn AI hun nodecode doorzoeken en vond geen bescherming tegen "call depth/step limit." Dus, theoretisch zou een contract met oneindige recursie/zelf-oproepen potentieel de VM kunnen laten crashen. (Natuurlijk is deze bescherming gemakkelijk te repareren: stel gewoon een maximale call depth in.)

Hoe hem te evalueren:

Ten eerste weet hij nog steeds hoe hij dingen moet benoemen. Tenminste brc2.0 zal populairder zijn dan het creëren van een nieuwe protocolnaam. Dit is ook de reden waarom RGB onlangs weer populair is geworden.

Ten tweede is het niet volledig ongerelateerd aan BRC20. Tenslotte zijn het protocolontwerpconcept en de veldmodus in wezen hetzelfde, maar dit telt niet als auteursrecht. Ik heb echter de oorspronkelijke auteur van BRC20 niet op het platform gezien, dus de connectie is waarschijnlijk niet significant.

Ten slotte willen alle platforms die programmeerbaarheid hebben onderzocht misschien de waarde van deze wereldklasse consensus delen. De auteur gelooft echter dat BTC geen programmeerbaarheid zou moeten nastreven, omdat het, ongeacht hoe het wordt nagestreefd, niet in staat zal zijn om de optimalisatie van functies en ervaring van verschillende hogesnelheidketens bij te houden.

Bovendien, zodra programmeerbaarheid in BTC zelf is ingebouwd, zal het zijn waarderingsval doorbreken. Een project dat in de praktijk kan worden gebruikt, kan worden gewaardeerd op basis van PE. De huidige kracht van BTC ligt echter in zijn beperkte vraag- en aanbodmodel. Beperkt vraag en aanbod kan niet worden gewaardeerd, dus er is een prijs, en dan is er een consensus over de prijs. Daarom zijn het precies de beperkingen van BTC zelf die BTC succesvol hebben gemaakt.