Kakarot: вивчення EVM-сумісної дороги Starknet

Автор: Цинік

TL;DR

• Віртуальна машина — це комп’ютерна система, змодельована програмним забезпеченням, яка забезпечує середовище виконання для програм. Він може емулювати різні апаратні пристрої, щоб програми могли працювати в контрольованому та сумісному середовищі. Віртуальна машина Ethereum (EVM) — це стекова віртуальна машина, яка використовується для виконання смарт-контрактів Ethereum.
• zkEVM — це EVM, який інтегрує технологію підтвердження/достовірності з нульовим знанням. Це дозволяє перевіряти виконання EVM за допомогою доказів з нульовим знанням, не вимагаючи від усіх верифікаторів повторного виконання EVM. На ринку є різні продукти zkEVM, кожен зі своїм підходом і дизайном.
• Причиною для zkEVM є потреба у віртуальній машині, яка підтримує виконання смарт-контракту на рівні 2. Крім того, деякі проекти вирішують використовувати zkEVM, щоб скористатися перевагами широкої екосистеми EVM і створити набір інструкцій, більш дружній до доказів із нульовим знанням.
• Kakarot — це zkEVM, реалізований у Starknet за допомогою мови Cairo. Він моделює стек, пам’ять, виконання та інші аспекти EVM у формі смарт-контрактів Cairo. Kakarot зіткнувся з такими проблемами, як сумісність із системою облікових записів Starknet, оптимізація витрат і стабільність, оскільки мова Cairo все ще була експериментальною.
• Warp — це перекладач із коду Solidity на код Cairo, що забезпечує сумісність на мовному рівні високого рівня. Kakarot, з іншого боку, забезпечує сумісність на рівні EVM шляхом впровадження кодів операцій EVM і попередньої компіляції.

Що таке віртуальна машина?

Щоб пояснити, що таке віртуальна машина, ми повинні спочатку поговорити про процес виконання комп’ютера в рамках поточної основної архітектури фон Неймана. Різноманітні програми, що виконуються на комп’ютері, зазвичай трансформуються за допомогою рівнів мов високого рівня та, нарешті, генерують машинно-зрозумілі машинні коди для виконання. За способом перетворення в машинний код мови високого рівня можна умовно розділити на скомпільовані мови та інтерпретовані мови.

Скомпільована мова означає, що після написання коду його потрібно обробити компілятором, щоб перетворити код мови високого рівня в машинний код і створити виконуваний файл. Після компіляції його можна виконувати кілька разів з більшою ефективністю. Перевага скомпільованої мови полягає в тому, що під час компіляції код було перетворено в машинний код, тому швидкість виконання висока, і програму можна запускати в середовищі без компілятора, що зручно для користувачів і не потребує для встановлення додаткового програмного забезпечення. Поширені скомпільовані мови включають C, C++, Go тощо.

Відповідником компільованих мов є інтерпретовані мови. Інтерпретована мова означає, що код інтерпретується та виконується рядок за рядком через інтерпретатор, і він виконується безпосередньо на комп’ютері, і процес перекладу потребує повторного перекладу кожного разу, коли він виконується. Перевагами інтерпретованих мов є висока ефективність розробки та легке налагодження коду, але швидкість виконання відносно низька. Поширені інтерпретовані мови включають Python, Java, Ruby тощо.

Слід підкреслити, що мова не розрізняє скомпільовані та інтерпретовані типи по суті, але в початковому дизайні будуть певні тенденції. У більшості випадків C/C++ компілюється та виконується, але його також можна інтерпретувати та виконувати (Cint, Cling). Багато інтерпретованих мов у традиційному розумінні зараз компілюються в проміжні коди та виконуються на віртуальних машинах (Python, Lua).

Знаючи процес виконання фізичної машини, давайте зараз поговоримо про віртуальну машину.

Віртуальні машини зазвичай створюють віртуальне комп’ютерне середовище, імітуючи різні апаратні пристрої. Апаратні пристрої, які можуть моделюватися різними віртуальними машинами, відрізняються, але зазвичай включають ЦП, пам’ять, жорсткий диск, мережевий інтерфейс тощо.

Візьмемо для прикладу віртуальну машину Ethereum (EVM). EVM — це стекова віртуальна машина, яка використовується для виконання смарт-контрактів Ethereum. EVM забезпечує віртуальне комп’ютерне середовище, імітуючи апаратні пристрої, такі як ЦП, пам’ять, сховище та стек.

Зокрема, EVM — це стекова віртуальна машина, яка використовує стек для зберігання даних і виконання інструкцій. Набір інструкцій EVM включає різні коди операцій, такі як арифметичні операції, логічні операції, операції зберігання, операції переходу тощо. Ці інструкції можна виконати в стеку EVM для завершення виконання смарт-контрактів.

Пам'ять і сховище, емульовані EVM, є пристроями, які використовуються для зберігання стану та даних смарт-контрактів. EVM розглядає пам’ять і сховище як дві різні області, і він може отримати доступ до стану та даних смарт-контрактів шляхом читання та запису в пам’ять і сховище.

Стек, емульований EVM, використовується для зберігання операндів і результатів інструкцій. Більшість інструкцій у наборі інструкцій EVM базуються на стеку, вони зчитують операнди зі стеку та надсилають результати назад у стек.

Коротше кажучи, EVM забезпечує віртуальне комп’ютерне середовище, імітуючи апаратні пристрої, такі як ЦП, пам’ять, накопичувач і стек, які можуть виконувати інструкції смарт-контрактів і зберігати стан і дані смарт-контрактів. У фактичній роботі EVM завантажить байт-код смарт-контракту в пам’ять і виконає логіку смарт-контракту, виконавши набір інструкцій. EVM фактично замінює частину операційної системи + апаратне забезпечення на малюнку вище.

Процес проектування EVM, очевидно, йде знизу вгору. Спочатку завершується змодельоване апаратне середовище (стек, пам’ять), а потім проектується набір інструкцій складання (Opcode) і байт-код (Bytecode) відповідно до відповідного середовища. Незважаючи на те, що набір інструкцій для складання призначений для читання, він вимагає багато знань низького рівня, має високі вимоги до розробників і є громіздким у розробці. Тому потрібна мова високого рівня, щоб захистити незрозумілі та громіздкі низькорівневі дзвінки та надати розробникам кращий досвід. Через налаштований дизайн набору інструкцій асемблера EVM важко безпосередньо використовувати традиційні мови високого рівня та просто відтворити нову мову високого рівня для адаптації до віртуальної машини. Спільнота Ethereum розробила дві скомпільовані мови високого рівня — Solidity та Vyper — для ефективності виконання EVM. Solidity не потрібно наголошувати, Vyper — це мова високого рівня EVM, розроблена Віталіком після покращення деяких недоліків Solidity, але вона не була широко прийнята в спільноті, тому поступово сходить зі сцени історії.

Що таке zkEVM

Простіше кажучи, zkEVM — це EVM, який використовує технологію підтвердження/підтвердження дійсності з нульовим знанням, щоб процес виконання EVM можна було перевірити ефективніше та дешевше за допомогою підтвердження/підтвердження дійсності з нульовим знанням, не вимагаючи від усіх верифікаторів Carry вивести процес виконання EVM.

На ринку є багато продуктів zkEVM, і трек гарячий. Основні гравці включають Starknet, zkSync, Scroll, Taiko, Linea, Polygon zkEVM (раніше Polygon Hermez) тощо, які поділені на 5 категорій (1, 2 , 2.5, 3, 4) від vitalik . Конкретний контент можна переглянути на блозі Віталіка.

Навіщо потрібен zkEVM

Це питання необхідно розглядати з двох точок зору.

Початкові спроби zk Rollup можуть досягти лише відносно простих функцій передачі та транзакцій, таких як zkSync Lite, Loopring тощо. Але як тільки море було надто складним, люди використовували повний Тьюринг EVM на Ethereum.Коли було неможливо створювати різні програми за допомогою програмування, люди почали закликати до віртуальних машин на L2. Необхідність написання розумних контрактів одна.

Оскільки деякі проекти в EVM не дружні до генерації підтвердження/підтвердження дійсності з нульовим знанням, деякі гравці вирішують використовувати набір інструкцій, який є дружнім до підтвердження/підтвердження дійсності з нульовим знанням на нижньому рівні, наприклад Starknet Cairo Assembly та zkSync Інструкція по цинку. Але в той же час усі не бажають відмовлятися від величезної екологічності користувача EVM, тому вони вибирають сумісність з EVM на верхньому рівні, який є типом 3 і 4 zkEVM. Деякі гравці все ще наполягають на традиційному наборі інструкцій EVM Opcode та зосереджуються на створенні більш ефективних доказів для Opcode, якими є тип 1 і тип 2 zkEVM. Величезна екологія EVM ділиться на дві частини.

Kakarot: віртуальна машина на віртуальній машині?

Чому на віртуальній машині можна створити іншу віртуальну машину? Ця річ є звичайною для комп’ютерних практиків, але вона може бути не такою очевидною для користувачів, які не розуміються на комп’ютерах. Насправді, це легко зрозуміти. Це схоже на будівельні блоки. Поки нижній рівень достатньо міцний (з повним середовищем виконання Тьюринга), будівельні блоки можна без обмежень укладати на верхній шар. Але незалежно від того, скільки рівнів буде створено, остаточне виконання все одно має здійснюватися фізичним обладнанням найнижчого рівня, тому збільшення кількості рівнів призведе до зниження ефективності. У той же час, через різні конструкції різних будівельних блоків (різні конструкції віртуальних машин), оскільки будівельні блоки будуються все вище і вище, вірогідність руйнування будівельних блоків (помилки в роботі) зростає, що вимагає вищого рівня технічної підтримки.

Kakarot — це EVM, реалізований мовою Cairo в Starknet. Він використовує розумні контракти Cairo для моделювання стека, пам’яті, виконання тощо в EVM. Відносно кажучи, реалізувати EVM нескладно. Окрім EVM, написаного на Golang у Go-Ethereum, який має найвищий рівень використання, існують також існуючі EVM, написані на Python, Java, Java та Rust.

Технічна складність Kakarot zkEVM полягає в тому, що протокол існує як контракт у ланцюжку Starknet, що породжує дві ключові проблеми.

1. Сумісність Starknet використовує зовсім іншу систему облікових записів, ніж Ethereum. Облікові записи в Ethereum поділяються на EOA (зовнішній обліковий запис) і CA (контрактний обліковий запис). Проте Starknet підтримує власну абстракцію облікових записів, і всі облікові записи є контрактними. У той же час, через різні криптографічні алгоритми, які використовуються, користувачі не можуть використовувати ту саму ентропію для генерації тієї ж адреси в Starknet, що і в Ethereum.
2. Вартість Оскільки kakarot zkEVM існує в ланцюжку як контракт, він має високі вимоги до реалізації коду та потребує максимальної оптимізації для Gas, щоб зменшити витрати на взаємодію.
3. Стабільність На відміну від використання традиційних мов високого рівня, таких як Golang, Rust, Python тощо, мова Cairo все ще знаходиться на експериментальній стадії, від Cairo 0 до Cairo 1 до Cairo 2 (або, якщо хочете, Cairo 1). версія 2), офіційна команда все ще є. Функції мови постійно переглядаються. У той же час Cairo VM недостатньо перевірена, і не можна виключати можливість подальших масштабних перезаписів.

Протокол kakarot складається з п'яти основних компонентів (чотири прописані в документі GitHub, EOA не входить, ця стаття була скоригована для зручності читачів):

• Kakarot (Core): відповідає за виконання транзакцій у формі Ethereum і надання відповідних облікових записів Starknet для користувачів Ethereum
• Контрактні облікові записи: CA у сенсі Ethereum, відповідальний за зберігання байт-коду контракту та стану змінних у контракті
• Зовнішні облікові записи: EOA у сенсі Ethereum, відповідальний за пересилання транзакцій Ethereum до Kakarot Core
• Реєстр облікових записів: зберігає листування між обліковими записами Ethereum і Starknet.
• Blockhash Registry: як спеціальний Opcode, Blockhash потребує попередніх даних блоку, і Kakarot не може безпосередньо отримати дані в ланцюжку. Цей компонент зберігає зв’язок зіставлення block_number -> block_hash, який записує адміністратор і надає Kakarot Core.

Відповідно до відгуків генерального директора kakarot Еліаса Тазартеса, в останній версії команда відмовилася від дизайну Account Resister, а натомість для збереження відповідного зв’язку було використано зіставлення 31-байтової адреси Starknet з 20-бітовою адресою EVM. . У майбутньому, щоб покращити взаємодію та дозволити контрактам Starknet реєструвати власні адреси EVM, дизайн Реєстру облікових записів можна використовувати повторно.

Сумісний з EVM на Starknet: яка різниця між Warp і kakarot

Відповідно до типу zkEVM, визначеного Віталіком, Warp належить до Type-4, а kakarot наразі належить до Type-2.5.

Warp — це перекладач, який перетворює код Solidity на код Cairo. Причина, чому його не називають компілятором, ймовірно, полягає в тому, що вихід Cairo все ще є мовою високого рівня. Завдяки Warp розробники Solidity можуть підтримувати початковий статус розробки без необхідності вивчати нову мову Cairo. Для багатьох учасників проекту Warp знижує поріг для входу в екосистему Starknet і не потребує використання Cairo для переписування великої кількості інженерного коду.

Незважаючи на те, що ідея перекладу проста, сумісність також є найгіршою. Деякі коди Solidity не можна добре перекласти Cairo. Логіка коду, що включає систему облікових записів, криптографічний алгоритм тощо, потребує зміни вихідного коду, щоб завершити міграцію. Конкретні непідтримувані функції можна переглянути в документації Warp. Наприклад, багато проектів розрізнятимуть логіку виконання облікових записів EOA та контрактних облікових записів, але всі облікові записи в Starknet є контрактними, і цю частину коду потрібно змінити перед перекладом.

Warp сумісний на рівні мови високого рівня, а kakarot сумісний на рівні EVM.

Повне переписування EVM і реалізація коду операції один за одним і попередньої компіляції дозволяють kakarot мати вищу нативну сумісність. Зрештою, виконання на одній віртуальній машині (EVM) завжди більш сумісне, ніж виконання на іншій віртуальній машині (Cairo VM). Реєстр облікових записів і Blockhash Registry вміло приховують відмінності в різних системах і мінімізують перешкоди, пов’язані з міграцією користувачів.

Команда Kakarot

Дякуємо команді kakarot за цінні коментарі до цієї статті, особливо Еліасу Тазартесу. Дякую вам сер!