Validering av tilgjengelighet av Bitcoin-native data i ultralav-latens L2-miljøer @megaeth, @risechain, @nubit_org I blockchain går uttrykket ultralav latens eller sanntid utover bare å bety at den opplevde hastigheten er rask, men refererer også til en struktur der utførelse, respons og tilstandsrefleksjon konsekvent leveres på et nivå som er raskere enn grensene for menneskelig persepsjon. Nylig er høyytelses lag 2-systemer designet med millisekunds utførelsesforsinkelser og svært høy gjennomstrømning, og i denne prosessen har separasjonen mellom utførelseslaget og verifikasjonslaget blitt vanlig. I et slikt miljø er ikke datatilgjengelighet en faktor som direkte påvirker hastigheten, men fungerer snarere som et fundament som gjør det mulig for hvem som helst å verifisere tilstandsoverganger på et senere tidspunkt. Sanntids L2-systemer bruker teknikker for å utføre transaksjoner på forhånd før de fullt ut inkluderes i en blokk, eller for å ferdigstille rekkefølgen ved å dele blokken opp i svært små enheter. Dette gjør at brukerne kan se nesten umiddelbare resultater, men kryptografisk fullstendig verifisering kommer mye senere. I denne strukturen må datatilgjengelighetslaget sikre at tilstrekkelig data frigjøres innen en viss tidsperiode for å kunne verifiseres, og ved forsinkelser eller skjulinger har systemdeltakerne ikke annet valg enn å stole på integriteten til sekvenseren i denne perioden. Bitcoins native datatilgjengelighet er en tilnærming som søker å tilby denne verifiseringsfunksjonen direkte på Bitcoin-blokkjeden. Bitcoins blokker opprettes i gjennomsnitt på omtrent 10 minutter, og mengden data som kan lagres i en blokk er begrenset. Denne strukturen tilbyr høy økonomisk sikkerhet og sterk sensurmotstand, men har en klar øvre grense når det gjelder hyppighet og kapasitet for datapublisering. Som et resultat antar datatilgjengelighet basert på Bitcoin en gjennomstrømning på flere kilobyte per sekund og en minimumsforsinkelse på mer enn noen få minutter. I et sanntids L2-miljø er utførelsesforsinkelsen bare noen få millisekunder, mens hvis datatilgjengelighet bestemmer at det tar mer enn noen få minutter, øker tidsgapet mellom utførelse og validering kraftig. I dette oppholdet kan brukere ikke uavhengig verifisere sin status eller trygt gjenopprette eiendeler, og de kan heller ikke umiddelbart verifisere om dataene faktisk er publisert. Dette betyr at datatilgjengelighetslaget forsinker effektiviteten av den opprinnelige intensjonen om valideringsbasert tillitsminimering i en betydelig periode. Systemer som implementerer tilgjengelighet av Bitcoin-native data bruker hjelpemekanismer som komitékonsensus, datautvalg og periodisk Bitcoin-ankring for å redusere disse begrensningene. Denne metoden gir imidlertid ikke den korte valideringsforsinkelsen som kreves i sanntidskjøringsmiljøet, med mindre den endrer Bitcoins egen prosesseringshastighet og blokkgenereringssyklus. Ved dataskjuling eller forsinkelse endrer det ikke at det tar minst én tidsblokk å definitivt vurdere og svare på dem on-chain. Denne egenskapen blir enda tydeligere i applikasjoner som er svært følsomme for latenstid, som høyfrekvente transaksjoner eller sanntidsspill. I et miljø hvor et stort antall transaksjoner skjer på kort tid, kan ikke Bitcoin-blokkrommet imøtekomme etterspørselen etter datatilgjengelighet, og valideringsforsinkelser hindrer også applikasjonens normale drift. På den annen side, i applikasjoner hvor transaksjonsfrekvensen er relativt lav og sikkerheten ved endelig oppgjør er viktigere, kan datatilgjengelighet basert på Bitcoin spille en viss rolle. Oppsummert har Bitcoin-native datatilgjengelighet strukturelle begrensninger som valideringsforsinkelser og gjennomstrømningsbegrensninger i det ultralav-latens L2-miljøet. Selv om Bitcoin tilbyr sterk sikkerhet og pålitelighet, gjør designet det uegnet som et datatilgjengelighetslag basert på sanntidsutførelse. Objektiv analyse så langt bekrefter at tilgjengeligheten av Bitcoin-native data i sanntids L2-systemer er på et nivå som fungerer som et langsomt, men svært sikkert hjelpereferansepunkt, snarere enn hovedverifiseringsmetoden for å støtte utførelsen.