Переслати оригінальний заголовок：Розшифрування моделі розумних контрактів та старонніх АА в Starknet：технічний маєток

Автори оригіналу: Шев та Фауст, радники Web3: CryptoNerdCn, головний розробник ядра Starknet, засновник платформи розробки Cairo WASM для браузера

Анотація:

До основних технологічних особливостей Starknet можна віднести каїрську мову, яка сприяє генерації доказів ZK, АА нативного рівня та модель смарт-контракту, де бізнес-логіка не залежить від сховища станів. Cairo – це універсальна мова ZK, яку можна використовувати для реалізації смарт-контрактів на Starknet, а також для розробки додатків з традиційними нахилами. Процес компіляції представляє Sierra як проміжну мову, що дозволяє часто повторювати Cairo без безпосередньої зміни базового байт-коду. Крім того, стандартна бібліотека Каїра включає багато базових структур даних, необхідних для абстракції облікових записів. Смарт-контракти Starknet відокремлюють бізнес-логіку від зберігання даних стану, на відміну від EVM-ланцюжків. Розгортання каїрських контрактів включає три етапи: компіляцію, декларування та розгортання, де бізнес-логіка оголошується в класі Contract. Екземпляри контрактів, що містять дані стану, можуть бути пов'язані з класом і викликати код, який він містить.

Вищезгадана модель смарт-контракту Старкнет сприяє повторному використанню коду, повторному використанню стану контракту, шаруванню сховищ, та виявленню непотрібних контрактів. Це також сприяє реалізації оренди сховища та паралелізації транзакцій. Хоча останні два ще не були реалізовані, структура смарт-контрактів Каїро створила "необхідні умови" для них. На ланцюжку Старкнет є лише рахунки смарт-контрактів, а не рахунки EOA. Він підтримує абстракцію рахунків AA на рівні нативних з самого початку. Його план AA в певній мірі включає ідеї ERC-4337, дозволяючи користувачам обирати високорівневі індивідуалізовані рішення обробки транзакцій. Для запобігання можливим сценаріям атак, Старкнет прийняв багато контрзаходів та зробив важливі дослідження у екосистемі AA.

текст: Слідом за випуском токенов на Starknet, STRK поступово став незамінним елементом в очах оглядачів Ethereum. Ця зірка рівня 2 Ethereum, відома своїм ставленням до «незалежності» та «нехтування користувацьким досвідом», непомітно викроїла власну територію в процвітаючій екосистемі рівня 2, сумісній з EVM. Через надмірне нехтування користувачами, і навіть відверте налаштування каналу «електронного жебрака» на Discord, Starknet одного разу піддався критиці з боку спільноти. На тлі звинувачень у «нелюдськості» його глибока технічна експертиза здавалася миттєво знеціненою, ніби лише UX та створення багатства — це все. Рядок з «Храму Золотого павільйону» - «той факт, що мене не розуміють інші, був моїм єдиним джерелом гордості» - це майже автопортрет Старнета. Однак, якщо відкинути ці дрібниці світу, засновані виключно на технічному смаку код-гіків, Starknet і StarkEx, як піонери ZK Rollup, є майже скарбами в очах каїрських ентузіастів. На думку деяких розробників блокчейн-ігор, Starknet і Cairo — це просто все в Web3, перевершуючи Solidity і Move. Найбільший розрив між «технічними вундеркіндами» та «користувачами» сьогодні значною мірою пояснюється нерозумінням людьми Starknet. Керуючись інтересом до технології блокчейн та вивченням цінності Starknet, автор цієї статті починає з моделі смарт-контрактів Starknet та нативної АА, щоб коротко окреслити її технічні рішення та дизайн механізмів, прагнучи продемонструвати технічні функції Starknet більшій кількості людей, а також сподіваючись допомогти людям зрозуміти цього «неправильно зрозумілого самотнього рейнджера». Після короткого вступу до каїрської мови в наступному розділі ми зосередимося на обговоренні моделі смарт-контрактів Starknet та абстракції нативного облікового запису, пояснюючи, як Starknet досягає нативної АА. Прочитавши цю статтю, читачі також зрозуміють, чому в Starknet не можна змішувати мнемонічні фрази з різних гаманців. Але перш ніж вводити нативну абстракцію облікового запису, давайте спочатку розберемося з інноваційною каїрською мовою, створеною Starknet. У процесі розробки Cairo існували ранні версії під назвою Cairo0, за якими слідувала сучасна версія. Загальний синтаксис сучасної версії Cairo схожий на Rust і фактично є універсальною мовою ZK. Крім того, що він використовується для написання смарт-контрактів на Starknet, його також можна використовувати для розробки загальних додатків. Наприклад, ми можемо розробити систему перевірки особи ZK за допомогою каїрської мови, і ця програма може працювати на нашому власному сервері, не залежачи від мережі StarkNet. Можна сказати, що будь-яка програма, що вимагає перевірених обчислювальних властивостей, може бути реалізована за допомогою каїрської мови. І Каїр в даний час може бути мовою програмування, найбільш сприятливою для генерації доказів ZK.

З точки зору процесу компіляції, Каїро використовує метод компіляції на основі проміжної мови, як показано на малюнку нижче. Sierra на картинці є проміжним представленням (IR) у процесі компіляції мовою Каїро, і Sierra буде скомпільована в представлення бінарного коду нижчого рівня, що називається CASM, який виконується безпосередньо на пристрої вузла Starknet.

Введення Sierra як проміжного представлення полегшує додавання нових функцій для каїрської мови. У багатьох випадках необхідно лише маніпулювати проміжною мовою Sierra без прямої зміни базового коду CASM. Це позбавляє від багатьох проблем, а клієнт вузла Starknet не потрібно часто оновлювати. Таким чином, часті ітерації каїрської мови можуть бути досягнуті, не змінюючи основну логіку StarkNet. Стандартна бібліотека Каїра також включає багато базових структур даних, необхідних для абстракції облікового запису. Серед інших нововведень Каїра – теоретичне рішення під назвою Cairo Native, яке планує скомпілювати Cairo в низькорівневий машинний код, який може адаптуватися до різних апаратних пристроїв. Вузлам Starknet не доведеться покладатися на віртуальну машину CairoVM під час запуску смарт-контрактів. Це може значно підвищити швидкість виконання коду [вона все ще знаходиться на теоретичній стадії і ще не реалізована].

Модель розумного контракту Starknet: видалення логіки коду та зберігання стану

На відміну від сумісних з Ethereum ланцюгів, Starknet внесла революційні інновації в проектування своєї системи смарт-контрактів, в основному, готуючись до нативних AA та майбутніх функцій, таких як паралельна обробка транзакцій. Тут важливо зрозуміти, що, на відміну від традиційних публічних ланцюгів, таких як Ethereum, розгортання смарт-контрактів на Starknet ґрунтується на іншому процесі. Давайте розглянемо приклад розгортання смарт-контракту Ethereum:

1. Розробники пишуть код смарт-контракту локально та компілюють програму Solidity в байткод EVM за допомогою редактора. Цей байткод може бути зрозумілим та обробленим безпосередньо EVM.

1. Розробник ініціює транзакцію для розгортання смарт-контракту, розгортаючи скомпільований байткод EVM на ланцюжок Ethereum.

Джерело: not-satoshi.com

Хоча розумні контракти Starknet також слідкують за ідеєю "спочатку компілювати, а потім розгортати", розумні контракти розгортаються на ланцюжку у вигляді байт-коду CASM, підтриманого CairoVM. Однак між Starknet та EVM-сумісними ланцюжками існують великі відмінності у методі виклику та режимі зберігання стану розумних контрактів. Точно, розумний контракт Ethereum = бізнес-логіка + інформація про стан. Наприклад, контракт USDT не лише реалізує загальні функції, такі як Передача та Погодження, але й зберігає статус активів усіх власників USDT. Код та стан зв'язані разом, що приносить багато неприємностей. По-перше, це не сприяє оновленню контрактів DAPP та міграції стану, не сприяє паралельній обробці транзакцій. Це важке технічне бреміння.

У відповідь на це, Starknet покращив спосіб зберігання стану. У своєму рішенні щодо реалізації смарт-контракту, бізнес-логіка DApps повністю відокремлена від стану активів і зберігається окремо. Ці переваги цього підходу очевидні: по-перше, він дозволяє системі швидко відрізняти, чи є дублювання або зайві розгортання коду. Ось як це працює: в Ethereum смарт-контракт складається як з бізнес-логіки, так і з даних стану. Якщо у кількох контрактів однакова бізнес-логіка, але різні дані стану, їх хеші також будуть відрізнятися, що ускладнює завдання системи визначити, чи існують «сміттєві контракти». Однак у рішенні Starknet код та дані стану розділені, що полегшує системі виявити, чи був розгорнутий однаковий код кілька разів на основі хешу частини коду. Це допомагає запобігти дублюванню розгортання коду та зекономити місце зберігання на вузлах Starknet.

У системі смарт-контрактів Starknet процес розгортання та використання контрактів поділено на три етапи: «компіляція, декларація та розгортання». Якщо емітент активів хоче розгорнути контракт Cairo, він спочатку компілює написаний код Cairo у форми Sierra та нижчорівневий байткод CASM на своєму локальному пристрої. Потім розгортач контракту публікує транзакцію «декларації», розгортаючи байткод CASM контракту та проміжний код Sierra на ланцюжку, названий як Клас Контракту.

(Джерело: офіційний веб-сайт Starknet)

Пізніше, якщо ви захочете використовувати функціональні можливості, визначені в контракті на актив, ви можете ініціювати транзакцію "deploy" через інтерфейс DApp для розгортання екземпляра Contract, пов'язаного з класом Contract. Цей екземпляр міститиме стан активу. Згодом користувачі можуть викликати функції в класі Contract Class, щоб змінити стан екземпляра Contract. Насправді, будь-хто, хто знайомий з об'єктно-орієнтованим програмуванням, повинен легко зрозуміти, що представляють Class і Instance в Starknet. Клас контрактів, оголошений розробниками, містить лише бізнес-логіку смарт-контракту, що включає функції, які може викликати будь-хто, але він не має фактичного стану активу, а отже, не реалізує безпосередньо «сутності активів», маючи лише «душу» без «тіла». Однак, коли користувачі розгортають певні екземпляри контракту, активи «матеріалізуються». Якщо вам потрібно змінити стан "сутності" активу, наприклад, передати ваші токени комусь іншому, ви можете безпосередньо викликати функції, написані в класі контрактів. Описаний вище процес чимось схожий на «створення екземплярів» в традиційних об'єктно-орієнтованих мовах програмування (хоча і не повністю ідентичний).

Після розподілу смарт-контрактів на класи та екземпляри, бізнес-логіка та дані стану роз'єднані, що призводить до наступних функцій у Starknet:

1. Сприятливо для реалізації сегментації сховища та "системи оренди сховища"

Так званий шарування сховищ означає, що розробники можуть розміщувати дані в налаштованих місцях згідно з власними потребами, наприклад, під ланцюгом Starknet. StarkNet готовий бути сумісним з DA-шарами, такими як Celestia, і розробники DAPP можуть зберігати дані в цих сторонніх DA-шарах. Наприклад, гра може зберігати дані свого найважливішого активу на основній мережі Starknet та зберігати інші дані в офлайнових DA-шарах, таких як Celestia. Це рішення, що полягає в налаштуванні DA-шару згідно з вимогами до безпеки, було названо “Volition” Starknet.

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

У моделі розумного контракту Ethereum власність контракту неясна, і важко відрізнити, чи має платити «орендну плату» за контракт розгортуючий або власник активів ERC-20. Функція оренди сховища не була запущена довгий час, і розгортуючий платить лише плату при розгортанні контракту. Ця модель плати за сховище є нерозумною.

У моделях смарт-контрактів Starknet, Sui, CKB та Solana власність смарт-контрактів чітко поділяється, що ускладнює збір коштів на зберігання [На даний момент Starknet не запускає систему оренди зберігання безпосередньо, але це буде реалізовано у майбутньому]

1. Досягніть справжнього повторного використання коду та зменште розгортання непотрібних контрактів

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

1. Повторне використання реального контракту «статус»

Оновлення контрактів на блокчейні головним чином включають зміни у бізнес-логіці. У сценарії Starknet, бізнес-логіка смарт-контрактів є вроджено відокремлена від статусу активів. Якщо екземпляр контракту змінює пов'язаний клас типу контракту, оновлення бізнес-логіки може бути завершено. Не потрібно мігрувати статус активів в нове місце. Цей вид оновлення контракту є більш ретельним та вродженим, ніж у Ethereum.

Для зміни бізнес-логіки контракту Ethereum часто потрібно “віддати замовлення” на агентський контракт та змінити бізнес-логіку основного контракту, змінивши залежний агентський контракт. Однак цей метод не є досить лаконічним і не є “природнім”.

Джерело: wtf Academy

У деяких сценаріях, якщо старий контракт Ethereum повністю залишається, статус активів всередині не може бути безпосередньо мігрований на нове місце, що дуже неприємно; контракт Каїро не потребує міграції статусу і може безпосередньо «перевикористовувати» старий статус.

1. Сприятливо для паралельної обробки транзакцій

Для максимізації паралелізму різних торговельних інструкцій необхідним кроком є збереження статусу активів різних осіб в окремих місцях, як це можна побачити в Bitcoin, CKB та Sui. Передумовою для вищезазначеної мети є розділення бізнес-логіки смарт-контрактів від даних статусу активів. Хоча Starknet ще не здійснив глибоку технічну реалізацію паралельних транзакцій, він буде розглядати паралельні транзакції як важливу мету у майбутньому.

Внутрішнє AA та розгортання контракту облікового запису Starknet

Фактично, концепцію абстракції рахунку (AA) та EOA (рахунки, що належать зовнішнім власникам) винаходила спільнота Ethereum як унікальну концепцію. У багатьох нових громадських ланцюгах не існує розрізнення між рахунками EOA та рахунками смарт-контрактів, уникнення пасток системи рахунків у стилі Ethereum з самого початку. Наприклад, за налаштуванням Ethereum, контролер рахунку EOA повинен мати ETH на ланцюгу, перш ніж він зможе ініціювати транзакцію. Немає можливості безпосередньо вибирати різноманітні методи автентифікації, і додавання деякої настроєної логіки оплати є надзвичайно турботливим. Деякі люди навіть вважають, що конструкція рахунків Ethereum просто антисуспільна.

Якщо ми розглянемо флагманські продукти, такі як Starknet або zkSyncEra 'Native AA' ланцюг, очевидно можна виявити різницю: по-перше, Starknet і zkSyncEra мають уніфіковані типи рахунків. На ланцюжку є лише рахунки з розумними контрактами. З самого початку немає чогось подібного до рахунку EOA. (zkSync Era автоматично розгорне набір кодів контрактів на новоствореному рахунку користувача, щоб симулювати характеристики рахунку EOA Ethereum, щоб він був сумісний з Metamask).

Проте Starknet не розглядає пряму сумісність з Ethereum периферійними пристроями, такими як Metamask. Коли користувачі використовують гаманець Starknet вперше, автоматично розгортається окремий рахунок контракту. Іншими словами, раніше згаданий екземпляр контракту розгортається, і цей екземпляр пов'язаний з класом контракту, розгорнутим напередодні проекту гаманця. Користувачі можуть безпосередньо викликати деякі функціональні можливості, написані у класі. Тепер давайте заглибимося в цікаву тему: коли претендують на STRK airdrops, багато людей виявили, що гаманці Argent і Braavos не сумісні між собою. Імпорт мнемоніки з Argent до Braavos не дозволяв експортувати відповідний рахунок, головним чином через різні алгоритми генерації рахунків, використовані Argent та Braavos, що призводить до різних адрес рахунків, згенерованих з однакової мнемоніки. Зокрема, у Starknet новостворена адреса контракту може бути отримана за допомогою детермінованого алгоритму, наступним чином:

Функція 'pedersen()' , згадана вище, є алгоритмом хешування, який легко використовувати в системах ZK. Процес генерації облікового запису включає надання кількох спеціальних параметрів функції pedersen для генерації відповідного хешу, який є згенерованим адресою облікового запису. На зображенні вище показані параметри, які використовує Starknet для генерації «нової адреси контракту». 'Адреса розгортання' представляє адресу «розгортувача контракту». Цей параметр може бути порожнім, що означає, що навіть якщо у вас немає облікового запису контракту Starknet заздалегідь, ви все одно можете розгорнути новий контракт. 'Сіль' - це значення солі, яке використовується для обчислення адреси контракту, яке зазвичай є випадковим числом, введеним для уникнення дублювання адрес контрактів. 'Хеш класу' відповідає хешу значення класу, згаданому раніше, з яким пов'язаний екземпляр контракту. 'Хеш конструктора даних виклику' представляє хеш параметрів ініціалізації контракту.

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

1. Спочатку користувачі визначають екземпляр контракту, який вони хочуть розгорнути, та з яким класом контракту його асоціювати, використовуючи хеш класу як один з параметрів ініціалізації, та обчислюють сіль для визначення згенерованої адреси контракту.
2. Після визначення місця розгортання контракту користувачі спочатку перераховують певну кількість ETH на цю адресу як плату за розгортання контракту. Загалом цей ETH потрібно перерахувати з L1 в мережу Starknet через міст міжланцюжкового.
3. Користувачі ініціюють запит на транзакцію для розгортання контракту.

Фактично всі облікові записи Starknet розгортаються через вищезазначений процес, але більшість гаманців приховують деталі, і користувачі не сприймають процес як розгортання їх контрактного облікового запису, як тільки вони переказують ETH.

Вищезазначене рішення спричинило деякі проблеми з сумісністю, оскільки при генерації рахункових адрес різними гаманцями результати є неузгодженими. Змішати можна лише гаманці, які відповідають наступним умовам:

1. Приватний ключ, похідний від відкритого ключа, що використовується гаманцем, співпадає з алгоритмом підпису;
2. Процес обчислення солі гаманця однаковий;
3. Класи смарт-контрактів гаманця в цілому не відрізняються за деталями впровадження; \

У випадку, згаданому раніше, як Аргент і Бравос використовували алгоритм підпису ECDSA, але методи обчислення солі відрізнялися між ними, що призвело до невідповідних адрес рахунків, створених з того ж мнемокоду.

Зараз давайте повернемося до теми абстракції облікового запису. Starknet та zkSync Era перенесли ряд процесів, пов'язаних з обробкою транзакцій, таких як перевірка ідентичності (перевірка цифрових підписів) та оплата газової комісії, за межі „ланцюжкового шару“. Користувачі можуть налаштувати деталі реалізації вищезазначеної логіки у власних облікових записах. Наприклад, ви можете розгорнути спеціалізовану функцію перевірки цифрового підпису у своєму обліковому записі розумного договору Starknet. Коли вузол Starknet отримує транзакцію, ініційовану вами, він викликає ряд логіки обробки транзакцій, налаштований вами на ланцюжку.

Цей підхід безумовно надає більше гнучкості. Проте в дизайні Ethereum логіка, така як перевірка ідентичності (цифрові підписи), зашита в код клієнта вузла і не може нативно підтримувати налаштовані функції облікового запису.

Схематична діаграма власного рішення AA, вказаного архітектором Starknet. Перевірка транзакцій та перевірка кваліфікації плати за газ передаються на ланцюговий контракт для обробки. Основна віртуальна машина ланцюга може викликати ці функції, налаштовані або вказані користувачем.

За словами представників zkSyncEra та Starknet, цей модульний підхід до функціональності облікового запису натхненний EIP-4337. Проте те, що відрізняє їх, полягає в тому, що zkSync та Starknet поєднали типи облікових записів від самого початку, уніфіковані типи транзакцій та використовували один вхід для отримання та обробки всіх транзакцій. На відміну від цього, Ethereum, через історичне багатство та бажання фонду уникати агресивних стратегій ітерацій, таких як жорсткі вилки, підтримав EIP-4337, використовуючи інший спосіб вирішення проблеми. Проте результатом є те, що облікові записи EOA та рішення EIP-4337 мають незалежні робочі процеси обробки транзакцій, які виглядають нескладно та важкодоступно, на відміну від гнучкості вбудованих AAs.

Джерело: ArgentWallet

Однак, вбудована абстракція облікового запису в Starknet ще не досягла повної зрілості. З практичної точки зору, хоча облікові записи AA Starknet реалізували алгоритми звичайної перевірки підпису, вони наразі підтримують тільки оплату комісій за газ у ETH та STRK, і ще не підтримують оплату газу від третіх сторін. Тому прогрес Starknet у вбудованих AA можна описати як "теоретична рамка в основному зріла, тоді як практична реалізація все ще триває". Оскільки у Starknet внутрішньо лише облікові записи смарт-контрактів, увесь процес його транзакцій враховує вплив облікових смарт-контрактів. По-перше, після того, як транзакція надійде у пам'ять вузла Starknet (Mempool), вона проходить верифікацію, яка включає:

1. Перевірка правильності цифрового підпису транзакції, після чого викликається користувальницька функція перевірки облікового запису підписанта;
2. Перевірка, чи може баланс рахунку ініціатора покрити вартість газової комісії. \

Тут слід зауважити, що використання власної функції перевірки підпису в умовах розумного контракту облікового запису означає наявність сценарію атаки. Тому що пул пам'яті не стягує плату за газ при перевірці підпису нових транзакцій. (Якщо плата за газ стягується безпосередньо, відбудуться більш серйозні сценарії атак). Злоумисні користувачі можуть спочатку налаштувати суперскладну функцію перевірки підпису в своєму контракті облікового запису, а потім ініціювати велику кількість транзакцій. Коли ці транзакції перевіряються, вони викликають налаштовану складну функцію перевірки підпису, що може безпосередньо вичерпати обчислювальні ресурси вузла. Щоб уникнути цієї ситуації, StarkNet накладає на транзакції наступні обмеження:

1. Існує верхній ліміт на кількість транзакцій, які один користувач може ініціювати протягом одиниці часу;
2. Функція перевірки власного підпису в договорі облікового запису Starknet має обмеження складності, і занадто складні функції перевірки підпису не будуть виконані. Starknet обмежує ліміт споживання газу функції перевірки підпису. Якщо кількість газу, використана функцією перевірки підпису, занадто велика, то операція буде прямо відхилена. В той же час функція перевірки підпису в контракті облікового запису не має права викликати інші контракти.

Схема транзакцій Starknet виглядає наступним чином:

Варто зазначити, що для подальшого прискорення процесу верифікації транзакцій клієнт вузла Starknet безпосередньо реалізував алгоритми перевірки підпису гаманців Braavos та Argent. Коли вузол виявляє транзакції, згенеровані з цих двох основних основних гаманців Starknet, він викликає вбудовані алгоритми підпису Braavos/Argent у клієнті. Завдяки цьому підходу, подібному до кешування, Starknet може скоротити час перевірки транзакцій. Після того, як дані транзакції будуть перевірені секвенсором (кроки перевірки секвенсера набагато ретельніші, ніж у пулу пам'яті), секвенсор упакує та передасть транзакції з пулу пам'яті до генератора доказів ZK. З транзакцій, що переходять на цю стадію, стягуватиметься плата за газ, навіть якщо вони не відбудуться. Однак, якщо читачі знайомі з історією Starknet, вони помітять, що попередні версії Starknet не стягували комісію за невдалі транзакції. Найпоширеніший сценарій провалу транзакції – це коли користувач має лише 1 ETH, але намагається перевести 10 ETH назовні, що явно вказує на логічну помилку та неминуче зазнає невдачі, але ніхто не знає результату до виконання. Однак у минулому StarkNet не стягував комісію за такі невдалі транзакції. Ці безкоштовні помилкові транзакції витрачають обчислювальні ресурси вузла Starknet і можуть призвести до сценаріїв DDoS-атак. На перший погляд, стягнення комісії за помилкові транзакції здається простим, але насправді це досить складно. Starknet представив нову версію мови Cairo1 в основному для вирішення проблеми плати за газ за невдалі транзакції. Як ми всі знаємо, доказ ZK є доказом валідності, а результат невдалої транзакції є недійсним і не може залишити вихідний результат у ланцюжку. Спроба використати доказ валідності, щоб довести, що певне виконання інструкцій є недійсним і не може видати вихідні результати, звучить дивно і насправді є непрацездатною. Тому в минулому Starknet виключав невдалі транзакції, які не могли дати вихідних результатів при генерації пруфів. Пізніше команда Starknet прийняла більш розумне рішення і створила нову мову контрактів, Cairo1, яка гарантує, що «всі інструкції транзакцій можуть давати вихідні результати і бути ончейн». На перший погляд, той факт, що всі транзакції можуть давати вихідні результати, означає, що логічних помилок ніколи не виникає. Однак у більшості випадків транзакції зазнають невдачі, оскільки вони стикаються з помилками, які переривають виконання інструкцій. Гарантувати, що транзакції ніколи не перериваються та успішно приносять вихідні результати, важко досягти, але насправді існує просте альтернативне рішення, яке полягає в тому, щоб дозволити транзакціям видавати вихідні результати при зіткненні з логічними помилками, які призводять до переривань, хоча і повертає значення False, яке вказує на те, що виконання транзакції не було гладким. Важливо зазначити, що повернення значення False також повертає вихідний результат, а це означає, що в Cairo1, незалежно від того, чи стикається інструкція з логічною помилкою, чи тимчасово переривається, вона може видавати вихідні результати та бути ончейн. Результатом виведення може бути правильне повідомлення або повідомлення про помилку False. Наприклад, розглянемо наступний фрагмент коду:

На цьому етапі _balances::read(from) - amount може спричинити помилку переливання, що призведе до переривання відповідної транзакційної інструкції та зупинки без залишення результату транзакції на ланцюжку. Однак, якщо це буде переписано у такій формі, воно все одно поверне результат виведення, коли транзакція зазнає невдачі, залишаючи його на ланцюжку. Чисто з естетичної точки зору, здається, що всі транзакції можуть плавно залишати транзакційні виведення на ланцюжку, що робить рівномірне збирання комісії особливо розумним.

Огляд контракту StarknetAA

Оскільки деякі читачі цієї статті можуть мати програмістську підготовку, ось коротка демонстрація інтерфейсу контракту абстрактного рахунку в Starknet:

підтверджувати_означатиінтерфейс, зазначений вище, використовується для перевірки декларованих транзакцій, ініційованих користувачами, під час підтвердитивикористовується для загальної перевірки транзакцій, переважно для перевірки правильності підпису користувача. З іншого боку, виконання використовується для виконання транзакції. Особливість контрактних рахунків Starknet полягає в тому, що вони інтегровано підтримують multicall, що дозволяє здійснювати кілька викликів. Функціональність multicall може сприяти різноманітним цікавим можливостям, таким як пакування наступних трьох транзакцій при взаємодії з певними протоколами DeFi:

1. Авторизація токенів для контракту DeFi у першій транзакції.
2. Запуск логіки контракту DeFi у другій транзакції.
3. Відкликання авторизації до угоди DeFi у третій транзакції.

Звичайно, через атомарність багатозвізкового виклику існує більше складних випадків використання, таких як виконання арбітражних угод.

Огляд

Основні технологічні особливості Starknet включають мову Cairo, оптимізовану для генерації ZK-доказів, абстракцію облікового запису на рівні мови програмування та модель смарт-контракту, що відокремлює бізнес-логіку від зберігання стану.

Cairo - універсальна ZK-мова, яку можна використовувати для розумних контрактів на Starknet, а також для розробки більш традиційних додатків. Її процес компіляції вводить Sierra як проміжну мову, що дозволяє Каїро часто ітерувати без зміни базового байткоду, лише впроваджуючи зміни до проміжної мови. Стандартна бібліотека Каїро також включає багато базових структур даних, необхідних для абстракції облікового запису.

Смарт-контракти Starknet розділяють бізнес-логіку від зберігання даних стану, на відміну від ланцюгів EVM. Розгортання контракту у Каїрі включає три етапи: компіляцію, декларацію та розгортання. Бізнес-логіка вказується у класах контрактів, а екземпляри контрактів, що містять дані стану, можуть бути пов'язані з класом та викликати код, який він містить.

Модель смарт-контрактів Starknet сприяє повторному використанню коду, повторному використанню стану контракту, шаруванню сховищ та виявленню сміттєвих контрактів. Вона також сприяє впровадженню здачі сховищ та паралелізації транзакцій, хоча ці функції ще не були повністю реалізовані. Архітектура смарт-контрактів Cairo створює необхідні умови для цих функцій.

Starknet має лише рахунки смарт-контрактів, без рахунків EOA, і підтримує абстракцію рахунку AA на рівні рівня від початку. Його рішення AA частково поглиблює ідеї ERC-4337, що дозволяє користувачам обирати високорівневі індивідуалізовані рішення обробки транзакцій. Щоб запобігти потенційним сценаріям атак, Starknet впровадив різноманітні протидії, роблячи важливі дослідження для екосистеми AA.

Disclaimer：

1. Ця стаття розміщена з [ Web3]. *Пересилайте Оригінальний Заголовок‘Розшифрування моделі розумних контрактів та стороннього AA Starknet: технічний гігант самовпевнено вирушає вперед’. Усі авторські права належать оригінальному автору [Shew & Faust]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжітьсяGate Learnкоманди, які оперативно вирішать це.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно авторськими і не становлять жодної інвестиційної поради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.