Технически анализ · 10 мин ·

Solana Virtual Machine, обяснена за потребители на Bitcoin

Ръководство за Solana Virtual Machine за читатели, които познават Bitcoin: моделът на акаунтите, паралелното изпълнение, инструментите за разработка и границите на съвместимостта, заявена от Bitcoin Hyper.

#SVM#solana#смартдоговор#sealevel#разработчици

Образователна цел. Съдържанието на тази статия има единствено информационен и разяснителен характер. То не представлява финансов съвет. Пълен отказ от отговорност.

От работната маса на Bitcoin към кухнята на Solana

Bitcoin разполага със скриптов език — наречен Script — който е умишлено ограничен. Той не е Тюринг-пълен, не допуска цикли и позволява само базови операции: проверка на подписи, работа с времеви ограничения (timelock) или изграждане на схеми с множествен подпис (multisig). Тази простота допринася поведението на Bitcoin да бъде предвидимо и намалява повърхността на изпълнение, макар че сигурността на Bitcoin зависи от много компоненти на протокола.

Ethereum избира друг път: въвежда EVM (Ethereum Virtual Machine) — Тюринг-пълна среда, в която могат да се изпълняват смарт договори. На ниво протокол преходите на състоянието се обработват по последователен модел, макар че отделните имплементации могат да извършват някои вътрешни задачи паралелно.

Solana отговаря на предизвикателството с мащабируемостта чрез коренно различна архитектура: SVM (Solana Virtual Machine) и средата за изпълнение Sealevel.

Моделът на акаунтите в Solana (и в SVM)

В Ethereum смарт договорът „притежава“ своето състояние: данните се намират в самия договор. В SVM този дизайн е разделен:

  • - Кодът се намира в програмен акаунт; възможността за обновяването му зависи от механизма на разгръщане и от определен за целта орган (authority)
  • - Данните (състоянието) се намират в отделни акаунти, контролирани от програмата

Това позволява на Sealevel да анализира транзакциите предварително: ако транзакция A засяга акаунти {X, Y}, а транзакция B — акаунти {Z, W}, двете могат да бъдат изпълнени паралелно и без конфликт.

Този модел допуска паралелно изпълнение на транзакции, които не засягат едни и същи акаунти. Той може да повиши пропускателната способност, но сам по себе си не дава основание за заключение относно количествено предимство спрямо EVM при съпоставим хардуер. За Bitcoin Hyper не е публикуван конкретен тест за производителност.

Какво означава това за разработчиците

Програмите за SVM се пишат на Rust (или на C/C++) и се компилират до eBPF байткод. Широко използвана рамка е Anchor, която добавя макроси и конвенции, улесняващи разработката.

Документацията на Bitcoin Hyper си поставя за цел пряка съвместимост, или „drop-in съвместимост“, с екосистемата на Solana. Според проекта съществуваща програма би могла да работи с ограничени промени — например чрез смяна на RPC крайната точка и на няколко мрежови параметъра. Документацията предвижда и съвместимост с инструменти като Solana CLI, Anchor и приставки за среди за разработка. Действителната степен на съвместимост тепърва подлежи на независима проверка.

Ако такава степен на съвместимост бъде постигната, тя би могла да намали бариерата пред разработчиците, запознати със Solana. Общата основа на среда, базирана на SVM, обаче сама по себе си не гарантира съвместимост на програмите, на API интерфейсите, на системните програми, на инструментите или на поведението при изпълнение. Това остава проектна цел, а не независимо проверен резултат.

Какво тепърва предстои да бъде изяснено

Въпреки това няколко въпроса заслужават да бъдат поставени открито:

  1. Пълната съвместимост не е независимо проверена: достъпът до devnet е селективен, а публичното тестване — ограничено
  2. Разлики в модела на таксите: според документацията на проекта Bitcoin Hyper използва $HYPER за таксите вместо SOL, което означава, че някои абстракции се различават
  3. Зависимости от системните програми на Solana: част от приложенията в Solana разчитат на системни програми (например официалната Token Program), които може да не са налични в идентичен вид

Твърдението за „drop-in“ съвместимост тепърва предстои да бъде проверено. Оценката му изисква публична техническа документация, достатъчен достъп до devnet и възпроизводими тестове, обхващащи програмите, инструментите и системните зависимости.

Аналогията с франчайза

За SVM може да се мисли като за кухнята на ресторант по франчайз. Рецептата съответства на кода, а помещението — на мрежата, в която той работи. Bitcoin Hyper си поставя за цел да предложи инструменти, съвместими със Solana, но все още не е доказано, че всички компоненти са идентични или че резултатът е един и същ във всички случаи.

Разликата е в основната съставка: вместо SOL тук като „гориво“ на кухнята би се използвал $HYPER.


Прочетете още