Od psacího stolu Bitcoinu do kuchyně Solany

Bitcoin má skriptovací jazyk — jmenuje se Script — a je záměrně omezený. Není Turingovsky úplný, nepodporuje cykly a umožňuje jen elementární operace: ověřování podpisů, kontrolu časových zámků a nastavení schémat s více podpisy. Právě tato jednoduchost jej činí bezpečným a předvídatelným.

Ethereum zvolilo opačný přístup: zavedlo EVM (Ethereum Virtual Machine), Turingovsky úplné prostředí, v němž může kdokoli psát libovolné programy (smart kontrakty). Je mocné, má však jednu nevýhodu: provádění je sériové. Jeden kontrakt po druhém, v pořadí za sebou.

Solana odpověděla na výzvu škálovatelnosti radikálně odlišnou architekturou: SVM (Solana Virtual Machine) a runtime Sealevel.

Model účtů Solany (a SVM)

V Ethereu smart kontrakt svůj stav „vlastní“ — data leží uvnitř kontraktu. V SVM je návrh oddělený:

- Kód (program) je uložen v neměnném účtu
- Data (stav) leží v samostatných účtech, které program řídí

Díky tomu může Sealevel transakce analyzovat předem: pokud se transakce A dotýká účtů {X, Y} a transakce B účtů {Z, W}, lze je provést paralelně bez konfliktu.

Praktickým důsledkem je podstatně vyšší propustnost než u EVM na srovnatelném hardwaru.

Co to znamená pro vývojáře

Programy pro SVM se píší v Rustu (nebo C/C++) a kompilují do bajtkódu eBPF. Nejrozšířenějším frameworkem je Anchor, který přidává makra a konvence usnadňující vývoj.

Deklarovaným cílem Bitcoin Hyper je kompatibilita typu „drop-in“: podle dokumentace projektu by měl existující program pro Solanu běžet na Hyperu s minimálními úpravami — stačí změnit RPC endpoint a několik síťových nastavení. Stejné nástroje (Solana CLI, Anchor, pluginy do IDE) mají fungovat beze změny.

Pokud by se to podařilo, šlo by o zdaleka ne triviální konkurenční výhodu: ekosystém Solany má tisíce vývojářů a rozsáhlý fond existujících programů. Jejich přenesení na Bitcoin Hyper by výrazně snížilo vstupní bariéru. V současnosti však jde spíše o cíl návrhu než o nezávisle ověřený výsledek.

Co zatím není jasné

Několik bodů je přitom třeba uvést otevřeně:

Plná kompatibilita nebyla nezávisle ověřena: přístup k devnetu je výběrový a veřejné testování omezené
Rozdíly v modelu poplatků: Bitcoin Hyper používá pro poplatky $HYPER místo SOL — některé abstrakce se tedy liší
Závislosti na systémových programech Solany: některé aplikace Solany se opírají o systémové programy (například oficiální Token Program), které nemusí být dostupné v identické podobě

Tvrzení o kompatibilitě typu „drop-in“ si zaslouží prostor pro pochybnost — ale také kritické ověření. Než cokoli předpokládáte, otestujte to na devnetu. V produkčním prostředí to dosud nezávisle ověřeno nebylo.

Analogie s franšízou

Představte si SVM jako kuchyni franšízové restaurace. Recept (kód v Rustu) je všude stejný. Provozovna se může lišit (Bitcoin Hyper místo mainnetu Solany), ale vybavení (runtime SVM, Anchor) je identické. Výsledný pokrm by měl být stejný.

Rozdíl je v hlavní ingredienci: místo SOL je „palivem“ této kuchyně $HYPER.

Solana Virtual Machine vysvětlená pro uživatele Bitcoinu