Ordliste

Periodisk publicering af et State Commitment fra rollup'en på Bitcoins basislag. Forankringen fastlægger en tilstandsforpligtelse og gør det muligt at opdage senere ændringer; i sig selv garanterer den dog hverken tilstandens korrekthed, datatilgængeligheden eller sikkerheden i bridge'en.

Opcode i Bitcoins scriptsprog, hvormed op til 80 byte vilkårlige data kan indlejres i en transaktion, hvorved outputtet påviseligt gøres umuligt at forbruge. Den kan anvendes til at forankre State Commitments.

Opgradering af Bitcoin (BIP 341/342, aktiveret i november 2021), som introducerer Schnorr-signaturer og MAST. Den forbedrer fortroligheden, effektiviteten og fleksibiliteten i scripterne og er interessant med henblik på mere effektive forankringsmekanismer.

Unspent Transaction Output (ikke-forbrugt transaktionsoutput). Bitcoins bogføringsmodel: i stedet for « konti » findes der « ikke-forbrugte outputs », der svarer til bestemte beløb. Den adskiller sig fra kontomodellen, som SVM og Ethereum anvender.

Layer 2-løsning, der udfører transaktioner off-chain og periodisk publicerer en komprimeret tilstand på basislaget (L1). Den kombinerer off-chain-skalerbarheden med en sikkerhed, der — afhængigt af den valgte model — bygger på L1.

Uafhængig blockchain, der er forbundet med L1 via en bridge. Dens sikkerhed afhænger primært af dens egen konsensusmekanisme og bridge'ens design, ikke direkte af L1's sikkerhed.

Arkitektur, der ligner en rollup, og hvor de data, der er nødvendige for at rekonstruere tilstanden, opbevares uden for L1. Den kan sænke omkostningerne og øge kapaciteten, men introducerer yderligere antagelser om datatilgængeligheden: bliver disse data utilgængelige, kan brugerne miste muligheden for at verificere tilstanden eller hæve deres midler.

Rollup, der som udgangspunkt betragter tilstandsovergange som gyldige — deraf betegnelsen « optimistisk ». Den bygger på svindelbeviser, hvormed ukorrekte overgange kan anfægtes inden for et tidsvindue, på Ethereum typisk syv dage.

Rollup, der anvender gyldighedsbeviser — ofte baseret på zero-knowledge-kryptografi — til at påvise, at tilstandsovergangene overholder protokollens regler. Den kan afkorte bekræftelsestiderne sammenlignet med en Optimistic Rollup, selv om den reelle finalitet ligeledes afhænger af L1 og systemets design.

Eksekverings-runtime udviklet af Solana Labs. Den muliggør parallel eksekvering ved at kræve, at hver transaktion eksplicit deklarerer de accounts, den anvender. Ifølge projektet anvender Bitcoin Hyper den som eksekveringsmiljø.

Paralleliserings-runtime i SVM'en. Den analyserer de accounts, som hver transaktion deklarerer, og gør det muligt at eksekvere de transaktioner parallelt, som ikke er i konflikt med hinanden. Den er en af de byggesten, der bidrager til Solanas ydeevne og — ifølge projektet — til det tilsigtede design af Bitcoin Hyper.

Rust-framework til udvikling af SVM-programmer. Det tilføjer makroer, konventioner og testværktøjer, der letter udviklingen på Solana. Ifølge projektet ønsker Bitcoin Hyper at tilbyde en tilsvarende toolchain; den faktiske kompatibilitet mangler endnu at blive verificeret.

Bibliotek af standardprogrammer på SVM'en: tokens (SPL Token), staking, governance med mere. Ifølge projektet tilstræber Bitcoin Hyper kompatibilitet med SPL, hvilket ville muliggøre genbrug af tokens og programmer fra Solana.

Komponent i rollup'en, der ordner transaktionerne før deres eksekvering. Den part, der driver sequenceren, kan bestemme denne rækkefølge — med konsekvenser for MEV og censur. Ved lanceringen af Bitcoin Hyper er det forudset, at den er centraliseret.

Værdi, der kan udvindes ved at omordne, indsætte eller udelade transaktioner inden for en blok eller en batch. En centraliseret sequencer kan råde over betydelige muligheder for at skumme eller påvirke rollup'ens MEV.

Mekanisme, der giver brugerne mulighed for at « fremtvinge » medtagelsen af en transaktion via Bitcoins L1 og derved omgå en sequencer, der måtte udøve censur. I Bitcoin Hyper var denne funktion den 28. april 2026 fortsat under udvikling.

Bitcoin Hypers officielle bridge, der muliggør overførsel af BTC fra L1 til rollup'en og omvendt. Ved lanceringen: fødereret eller centraliseret opbevaring med de dertil knyttede tillidsantagelser. Roadmap'en forudser en gradvis decentralisering, der endnu mangler at blive verificeret.

Mekanisme, der giver brugerne mulighed for at hæve deres midler ud af rollup'en, selv når sequenceren eller bridge'en ikke medvirker, ved at gøre brug af Bitcoins L1. Der er tale om en kritisk sikkerhedsfunktion, der fortsat er under udvikling.

Garanti for, at data fra alle transaktioner er offentligt tilgængelige. Mangler dataene, kan ingen rekonstruere rollup'ens tilstand. Hos Bitcoin Hyper undersøges den endelige løsning fortsat.

Komprimeret repræsentation — typisk en Merkle-rod — af rollup'ens fulde tilstand på et givet tidspunkt. Den publiceres periodisk som forankring på Bitcoin; denne publicering svarer ikke til en fuldstændig verifikation af tilstanden.

Trædannet datastruktur, hvor hver forældreknude svarer til hashen af sine børneknuder. Den muliggør effektive beviser — Merkle-beviser — for, at data indgår i mængden, uden at afsløre hele mængden.

Token, som projektdokumentationen fremstiller som Bitcoin Hypers native token. Det annoncerede samlede udbud udgør 21 milliarder. Ifølge den offentliggjorte dokumentation er det tiltænkt anvendt til at betale gebyrer, deltage i staking og — på et senere tidspunkt — i governance-mekanismerne. Den annoncerede fordeling lyder som følger: 25 % Treasury, 30 % udvikling, 20 % marketing, 15 % belønninger og 10 % listings.

Mekanisme til gradvis frigivelse af tokens over tid. Ifølge de vilkår, der er offentliggjort for forsalget, skulle $HYPER have en vesting-periode på syv dage.

Begivenhed, hvor et token oprettes og distribueres for første gang. Ifølge whitepaperet skal sikkerhedsauditterne være afsluttet inden Bitcoin Hypers TGE.

Den samlede værdi af de aktiver, der er placeret i et netværks DeFi-protokoller. Der er tale om en indikator, der anvendes til at måle udbredelsen og tilliden inden for et økosystem.

DeFi-protokol, der anvender matematiske formler — typisk x*y=k — til at fastsætte priserne ved ombytning uden at gøre brug af en traditionel ordrebog.

Tjeneste, der bringer data fra den virkelige verden ind i blockchainen — priser, begivenheder og så videre. Den er af central betydning for DeFi: lån, derivater og talrige kontrakter afhænger af pålidelige eksterne prisdata.

Kryptografisk bevis, der påviser, at en tilstandsovergang er ugyldig. Det anvendes i Optimistic Rollups til at anfægte svigagtige tilstande i løbet af anfægtelsesperioden.

Gennemgang af kildekoden foretaget af uafhængige eksperter med henblik på at identificere mulige sårbarheder. I Bitcoin Hypers tilfælde har projektet annonceret offentliggørelse af audits inden TGE; pr. 28. april 2026 blev der ikke konstateret nogen offentlig auditrapport om protokollen eller bridge'en.

Det tidspunkt, fra hvilket en transaktion i henhold til systemets regler og antagelser betragtes som uigenkaldelig. I det design, der er beskrevet for Bitcoin Hyper, ville tilstandsforpligtelserne efter deres publicering samle bekræftelser på Bitcoin; dette garanterer ikke i sig selv hverken tilstandens gyldighed eller muligheden for at hæve midlerne.

Betalingsnetværk på Bitcoin baseret på kanaler. Det er først og fremmest designet til hurtige og billige betalinger og tilbyder ikke et universelt smart contract-miljø, der kan sammenlignes med en virtuel maskine. Det har været i produktion siden 2018.

Smart contract-netværk, der er forbundet med Bitcoin og gør brug af PoX-mekanismen (Proof of Transfer). Det råder over sit eget sprog, Clarity, og lagrer information om sine blokke i Bitcoin.

Bitcoin-sidechain, der er kompatibel med EVM og gør brug af merge-mining. Den anvender RBTC, et aktiv knyttet til BTC, som token til betaling af gas. Den har været i drift siden 2018.