Słownik pojęć

Okresowa publikacja state commitment rollupu w warstwie bazowej Bitcoina (L1). Zakotwiczenie rejestruje state commitment i umożliwia wykrycie późniejszych zmian; samo w sobie nie gwarantuje jednak poprawności stanu, dostępności danych ani bezpieczeństwa bridge’a.

Kod operacji (opcode) w skrypcie Bitcoina, który pozwala osadzić w transakcji do 80 bajtów dowolnych danych, dzięki czemu można dowieść, że powstały output jest niewydawalny. Może służyć do zakotwiczania state commitments.

Aktualizacja Bitcoina (BIP 341/342, aktywowana w listopadzie 2021 r.), która wprowadza podpisy Schnorra i MAST. Poprawia prywatność, efektywność i elastyczność skryptów oraz ma znaczenie dla bardziej efektywnych mechanizmów zakotwiczania.

Unspent Transaction Output. Model księgowy Bitcoina: zamiast „kont” istnieją „niewydane outputy” odpowiadające konkretnym kwotom. Różni się to od modelu kontowego stosowanego przez SVM i Ethereum.

Rozwiązanie Layer 2, które wykonuje transakcje off-chain i okresowo publikuje skompresowany stan w warstwie bazowej (L1). Łączy skalowalność off-chain z bezpieczeństwem, które — zależnie od przyjętego modelu — czerpie z L1.

Odrębny blockchain połączony z L1 za pomocą bridge’a. Jego bezpieczeństwo zależy przede wszystkim od własnego mechanizmu konsensusu oraz konstrukcji bridge’a, a nie bezpośrednio od bezpieczeństwa L1.

Architektura zbliżona do rollupu, w której dane niezbędne do odtworzenia stanu są przechowywane poza L1. Może obniżać koszty i zwiększać przepustowość, wprowadza jednak dodatkowe założenia dotyczące dostępności danych: jeśli dane staną się niedostępne, użytkownicy mogą utracić możliwość zweryfikowania stanu lub wypłaty swoich środków.

Rollup, który domyślnie zakłada poprawność przejść stanu — stąd określenie „optimistic” (optymistyczny). Opiera się na fraud proofs, które umożliwiają zakwestionowanie błędnych przejść w określonym oknie czasowym — zwykle siedmiu dni w przypadku Ethereum.

Rollup, który wykorzystuje dowody poprawności — często oparte na kryptografii wiedzy zerowej — aby udowodnić, że przejścia stanu są zgodne z regułami protokołu. Może skracać czas potwierdzania w porównaniu z Optimistic Rollupem, choć rzeczywista finalność również tutaj zależy od L1 i konstrukcji systemu.

Silnik wykonawczy (runtime) opracowany przez Solana Labs. Umożliwia równoległe wykonywanie transakcji, wymagając od każdej z nich jawnego zadeklarowania wykorzystywanych kont. Według projektu Bitcoin Hyper wykorzystuje go jako swoje środowisko wykonawcze.

Silnik równoległego przetwarzania (runtime) działający w ramach SVM. Analizuje konta zadeklarowane przez poszczególne transakcje i umożliwia równoległe wykonywanie transakcji, które ze sobą nie kolidują. To jeden z elementów składowych, które wpływają na przepustowość Solany oraz — według projektu — na planowaną architekturę Bitcoin Hyper.

Framework w języku Rust do tworzenia programów SVM. Wprowadza makra, konwencje i narzędzia testowe, które upraszczają programowanie na Solanie. Według projektu Bitcoin Hyper ma oferować równoważny zestaw narzędzi (toolchain); rzeczywista kompatybilność pozostaje do zweryfikowania.

Biblioteka standardowych programów dla SVM: tokeny (SPL Token), staking, governance i inne. Według projektu Bitcoin Hyper dąży do zgodności ze SPL, co pozwoliłoby na ponowne wykorzystanie tokenów i programów Solany.

Komponent rollupu odpowiedzialny za porządkowanie transakcji przed ich wykonaniem. Podmiot obsługujący sequencer może decydować o tej kolejności, co ma implikacje dla MEV i cenzury. Przy starcie Bitcoin Hyper ma on być scentralizowany.

Wartość możliwa do wyodrębnienia dzięki zmianie kolejności, wstawianiu lub pomijaniu transakcji w bloku lub batchu. Scentralizowany sequencer może mieć znaczną swobodę w przechwytywaniu MEV rollupu lub wpływaniu na nie.

Mechanizm pozwalający użytkownikom „wymusić” uwzględnienie transakcji za pośrednictwem Bitcoin L1, z pominięciem cenzurującego sequencera. Według stanu na 28 kwietnia 2026 funkcja ta w Bitcoin Hyper była wciąż w fazie rozwoju.

Oficjalny bridge Bitcoin Hyper do przenoszenia BTC z L1 na rollup i z powrotem. Na starcie: przechowywanie w modelu federacyjnym lub scentralizowanym, wraz z wynikającymi z tego założeniami dot. zaufania. Mapa drogowa przewiduje stopniową decentralizację, co pozostaje do zweryfikowania.

Mechanizm pozwalający użytkownikom wypłacić środki z rollupu za pośrednictwem Bitcoin L1, nawet gdy sequencer lub bridge nie współpracuje. Kluczowa funkcja bezpieczeństwa, wciąż w fazie rozwoju.

Gwarancja, że dane wszystkich transakcji są publicznie dostępne. Bez tych danych nikt nie jest w stanie odtworzyć stanu rollupu. W przypadku Bitcoin Hyper ostateczne rozwiązanie jest wciąż przedmiotem analiz.

Skompresowana reprezentacja — zwykle Merkle root — pełnego stanu rollupu w danym momencie. Jest okresowo publikowana w Bitcoinie jako zakotwiczenie; sama publikacja nie oznacza pełnej weryfikacji stanu.

Struktura danych w kształcie drzewa, w której każdy węzeł nadrzędny jest hashem swoich węzłów podrzędnych. Umożliwia tworzenie efektywnych dowodów — tzw. Merkle proofs — że dany element danych należy do zbioru, bez ujawniania całego zbioru.

Token, który w dokumentacji projektu jest przedstawiany jako natywny token Bitcoin Hyper. Deklarowana całkowita podaż wynosi 21 miliardów. Zgodnie z opublikowaną dokumentacją ma być wykorzystywany do płatności, udziału w stakingu oraz — na dalszym etapie — do governance. Deklarowany podział jest następujący: 25% Skarbiec, 30% Rozwój, 20% Marketing, 15% Nagrody i 10% Listingi.

Mechanizm stopniowego uwalniania tokenów w czasie. Zgodnie z warunkami opublikowanymi dla przedsprzedaży, dla $HYPER podano siedmiodniowy vesting.

Wydarzenie, podczas którego token zostaje po raz pierwszy wyemitowany i rozdystrybuowany. Zgodnie z whitepaperem audyty bezpieczeństwa mają zostać zakończone przed TGE Bitcoin Hyper.

Całkowita wartość aktywów zdeponowanych w protokołach DeFi danej sieci. Wskaźnik służący do oceny poziomu adopcji ekosystemu oraz zaufania do niego.

Protokół DeFi, który wykorzystuje wzory matematyczne — zwykle x*y=k — do ustalania kursów wymiany, eliminując potrzebę tradycyjnej księgi zleceń.

Usługa, która wprowadza do blockchaina dane ze świata rzeczywistego — ceny, zdarzenia i tym podobne. Ma kluczowe znaczenie dla DeFi: kredytowanie, instrumenty pochodne i wiele innych kontraktów zależą od wiarygodnych zewnętrznych danych cenowych.

Dowód kryptograficzny wykazujący, że dane przejście stanu jest nieprawidłowe. Wykorzystywany w Optimistic Rollupach do kwestionowania nieuczciwych stanów w oknie na zgłoszenie sprzeciwu.

Przegląd kodu źródłowego przeprowadzany przez niezależnych specjalistów w celu identyfikacji potencjalnych luk bezpieczeństwa. W przypadku Bitcoin Hyper projekt zapowiedział publikację audytów bezpieczeństwa przed TGE; według stanu na 28 kwietnia 2026 nie udało się potwierdzić żadnego publicznego raportu z audytu protokołu ani bridge’a.

Moment, od którego — zgodnie z regułami i założeniami systemu — transakcję uznaje się za nieodwracalną. W architekturze opisanej dla Bitcoin Hyper state commitments miałyby gromadzić potwierdzenia w Bitcoinie po publikacji; to samo w sobie nie gwarantuje jednak ważności stanu ani możliwości wypłaty środków.

Sieć płatnicza Bitcoina oparta na kanałach. Zaprojektowana przede wszystkim z myślą o szybkich i tanich płatnościach, nie oferuje uniwersalnego środowiska smart kontraktów porównywalnego z maszyną wirtualną. W produkcji od 2018 roku.

Sieć do obsługi smart kontraktów połączona z Bitcoinem, wykorzystująca mechanizm PoX (Proof of Transfer). Ma własny język, Clarity, i zapisuje dane swoich bloków w Bitcoinie.

Sidechain Bitcoina kompatybilny z EVM, wykorzystujący merge-mining. Do opłacania gazu wykorzystuje token RBTC — aktywo powiązane z kursem BTC. Działa od 2018 roku.