Validering av tillgänglighet av Bitcoin-native data i ultralåg-latens L2-miljöer @megaeth, @risechain, @nubit_org Inom blockchain går uttrycket ultralåg latens eller realtid längre än att bara betyda att den upplevda hastigheten är hög, utan syftar också på en struktur där exekvering, respons och tillståndsreflektion konsekvent tillhandahålls på en nivå som är snabbare än gränserna för mänsklig perception. Nyligen har högpresterande lager 2-system designats med millisekunds exekveringsfördröjningar och mycket hög genomströmning, och i denna process har separationen mellan exekveringsskiktet och verifieringslagret blivit vanligt. I en sådan miljö är datatillgänglighet inte en faktor som direkt påverkar hastigheten, utan fungerar snarare som en grund som gör det möjligt för vem som helst att verifiera tillståndsövergångar vid ett senare tillfälle. Realtidssystem för L2 använder tekniker för att genomföra transaktioner i förväg innan de helt inkluderas i ett block, eller för att slutföra ordern genom att dela upp blocket i mycket små enheter. Detta gör att användare kan se nästan omedelbara resultat, men kryptografiskt fullständig verifiering kommer mycket senare. I denna struktur måste datatillgänglighetslagret säkerställa att tillräckligt med data släpps inom en viss tidsperiod för att verifieras, och vid förseningar eller fördoldheter har systemdeltagarna inget annat val än att lita på sekvenserarens integritet under den perioden. Bitcoins inbyggda datatillgänglighet är ett tillvägagångssätt som syftar till att tillhandahålla denna verifieringsfunktion direkt på Bitcoin-blockkedjan. Bitcoins block skapas i genomsnitt på cirka 10 minuter, och mängden data som kan rymmas i ett block är begränsad. Denna struktur erbjuder hög ekonomisk trygghet och stark motstånd mot censur, men har en tydlig övre gräns vad gäller frekvens och genomströmning av data. Som ett resultat antar datatillgänglighet baserad på Bitcoin en genomströmning på flera kilobyte per sekund och en minsta bestämningsfördröjning på mer än några minuter. I en realtids-L2-miljö är exekveringsfördröjningen bara några millisekunder, medan om datatillgänglighet tar mer än några minuter, ökar tidsgapet mellan exekvering och validering kraftigt. Under detta uppehåll kan användare inte självständigt verifiera sin status eller säkert återfå tillgångar, och de kan inte omedelbart verifiera om data faktiskt har publicerats. Detta innebär att datatillgänglighetslagret fördröjer effektiviteten av den ursprungliga avsikten med valideringsbaserad förtroendeminimering under en betydande tid. System som implementerar tillgänglighet av Bitcoin-native data använder hjälpmekanismer som kommittékonsensus, dataprovtagning och periodisk Bitcoin-ankning för att mildra dessa begränsningar. Denna metod ger dock inte den korta valideringsfördröjning som krävs i realtidsexekveringsmiljön, om den inte ändrar Bitcoins egen bearbetningshastighet och blockgenereringscykel. Vid datadold eller fördröjning förändrar det inte att det tar minst en tidsperiod att definitivt bedöma och reagera på den on-chain. Denna egenskap blir ännu tydligare i applikationer som är extremt känsliga för latens, såsom högfrekventa transaktioner eller realtidsspel. I en miljö där ett stort antal transaktioner sker under en kort tidsperiod kan Bitcoin-blockutrymmet inte hantera efterfrågan på datatillgänglighet, och valideringsförseningar hindrar också applikationens normala funktion. Å andra sidan, i applikationer där transaktionsfrekvensen är relativt låg och säkerheten vid slutavveckling är viktigare, kan tillgängligheten av Bitcoin-baserad data spela en viss roll. Sammanfattningsvis har tillgången till Bitcoin-native data strukturella begränsningar såsom valideringsförseningar och genomströmningsbegränsningar i den ultralåg-latens L2-miljön. Även om Bitcoin erbjuder stark säkerhet och tillförlitlighet, gör dess design det olämpligt som ett datatillgänglighetslager baserat på realtidsexekvering. Objektiv analys hittills bekräftar att tillgången till Bitcoin-native data i realtids L2-system ligger på en nivå som fungerar som en långsam men mycket säker hjälpreferenspunkt snarare än det huvudsakliga verifieringsmedlet för att stödja exekvering.