Переклад і вичитка: "Китайська спільнота StarkNet"
Резюме
Вбудовані функції оптимізують процес перевірки. Однак кожне підтвердження обчислюється з макета. Для певної перевірочної роботи переваги вбудованих функцій будуть значно зменшені, якщо макет неефективний. Наразі існує невеликий статичний список макетів, і кожне підтвердження обчислюється на основі найбільш відповідного макета з цього списку. Цей спосіб розміщення статичних списків має два недоліки. По-перше, існує обмежена різноманітність макетів. Це неефективно для більшості перевірочних робіт і створює складні механізми комісії, які створюють непотрібні витрати для користувачів. По-друге, складно вести список вручну. Коли кількість вбудованих модулів стає занадто високою, ручне технічне обслуговування стає складним і може фактично перешкоджати процесу перевірки ефективності вбудованих модулів, які підтримують велику кількість нюансів. Щоб вирішити ці проблеми, команда StarkWare розробляє динамічну систему макетів, де макети створюються на замовлення для кожного підтвердження роботи.
Стек Cairo полегшує обчислення загального призначення шляхом компіляції коду Cairo в інструкції для дружніх до STARK архітектур ЦП: Cairo VM (надалі CVM). Багато переваг ЦП загального призначення пов’язані з невід’ємною ціною, і CVM не оптимізовано для деяких звичайних операцій. Хеш-функції Keccak, Pedersen, Poseidon є звичайними такими операціями, як і операції з еліптичною кривою, перевірка діапазону (тобто перевірка того, чи певне число знаходиться в певному діапазоні значень) та інші.
Щоб усунути відносну неефективність CVM, стек Cairo вводить концепцію вбудованих модулів для критичних операцій: плагіни, які оптимізують такі операції для підтвердження складності. Вбудовані функції можна порівняти з ASIC: ASIC є інтегральними схемами для конкретної програми, а вбудовані функції – це алгебраїчні обмеження для конкретної програми (AIR). Якщо ви не знаєте або не пам’ятаєте, що таке AIR, це коротко описано далі в цій статті; прочитайте цю статтю, щоб дізнатися більше.
Коротше кажучи, складність доказів пов’язана (приблизно лінійно) з ресурсами, які називаються одиницями трасування, а вбудовані функції спрощують докази конкретних операцій, використовуючи набагато менше одиниць трасування, ніж Cairo VM.
Тепер, коли пояснено переваги вбудованих функцій, стає зрозуміло, чому вбудовані функції були розроблені для багатьох поширених операцій. Це легше сказати, ніж зробити. Поточний процес впровадження нових вбудованих модулів у Starknet складається з таких кроків:
Написання AIR
Інтеграція з прувером, створивши новий макет (описано нижче)
Інтегруйте в Starknet, тобто змініть його базу коду та інструменти розробника для використання нових вбудованих функцій
Окрім складнощів, пов’язаних із написанням AIR, є багато можливостей для вдосконалення на двох етапах, що залишилися. У цій розширеній статті докладніше описано вбудовані функції AIR як програми, зазначені вище проблеми та плани на майбутнє.
Вбудовані функції: AIR для конкретної програми
AIR — це абревіатура від Algebraic Intermediate Representation. У цій та інших статтях StarkWare AIR — це поліноміальна система для представлення віртуальних машин. Наприклад, Cairo отримав свою назву від CPU AIR: поліноміальна система, що представляє певну архітектуру ЦП. Розв’язки цієї поліноміальної системи представляють ефективні переходи станів, які називаються ефективними алгебраїчними траєкторіями виконання (AET).
STARK доводить, що робота віртуальної машини правильна, доводячи, що траєкторія виконання, яка відповідає заданому AIR, є дійсною. Грубо кажучи, траєкторія виконання — це таблиця чисел, і протокол STARK доводить, що ці числа разом розв’язують поліноміальну систему.
Одну і ту саму операцію можна обчислити багатьма способами, деякі з яких більш ефективні. У цьому документі складність доказу в основному залежить від розміру доріжки, тобто кількості комірок доріжки в таблиці. Оскільки трасування створюються для AIR, AIR розроблено для програм, щоб значно зменшити трасування виконання для конкретних обчислень. Вбудовані функції є спеціалізованими AIR, оптимізованими для програми.
У таблиці нижче показано підвищення ефективності для окремих вбудованих функцій (усі у виробництві).
Схема траєкторії: теперішнє та майбутнє
Як згадувалося раніше, AET — це приблизно таблиця чисел, яка представляє послідовність кроків у закодованій віртуальній машині (тобто виконання програми). Щоб обчислити доказ, перевірка запускає протокол STARK на доріжці виконання пов’язаного AIR.
Вище ми представили вбудовані функції як AIR для конкретної програми, призначені для мінімізації складності доказів шляхом зменшення кількості одиниць трасування, необхідних для кодування обчислень. Однак, якщо вбудовані функції випадковим чином інтегровані в Starknet, багато одиниць траєкторії можуть бути витрачені даремно, а очікувані переваги будуть зменшені. Пояснимо докладно нижче.
Коротше кажучи, макет доріжки - це призначення комірок доріжки різним «компонентам». У цій статті цими компонентами є CVM і вбудовані функції. Зокрема, макет визначає відносну кількість комірок треків, які отримує кожен компонент. (Конструкції макета завжди використовуються для спрощення перевірки. Щоб дізнатися більше, прочитайте розділ «Простота» цієї публікації).
Ключовим моментом є те, що складність перевірки залежить від загальної кількості комірок треків, виділених макетом, і розподіл комірок треків може бути більшим, ніж насправді потрібно. Наприклад, щоб продемонструвати впорядкування кроків CVM, макет, який призначає компонентам CVM лише комірки трасування, приблизно вдвічі ефективніший, ніж макет, який призначає половину комірок трасування вбудованим функціям Poseidon. Підсумовуючи, відповідний макет може значно зменшити складність підтвердження конкретного обчислення.
Зараз існує список макетів, який підтримується вручну, і він з часом збільшується з двох основних причин:
Вбудовані функції можна використовувати лише для компонування призначеної їм гусеничної одиниці. Тому для додавання вбудованих компонентів потрібен принаймні новий макет.
Макет, розроблений для виконання коду Cairo, оптимізує розподіл клітинок. Тому оптимізація варіантів використання в осередках часто вимагає нових макетів.
Код для прувера та валідатора (валідатори Solidity та Cairo) налаштовується відповідно до списку макетів.
З додаванням вбудованих модулів Keccak і Poseidon ставало все важче підтримувати списки макетів достатньо малими, щоб розмістити багато вбудованих компонентів і забезпечити ефективне виконання більшості блоків Starknet. Крім того, очікується, що ефективність суттєво впаде, оскільки будуть введені додаткові вбудовані компоненти, оскільки компонування має враховувати багато можливих комбінацій і співвідношень між вбудованими компонентами.
Зараз команда StarkWare працює над удосконаленням системи, відмовившись від попередньо створених списків макетів на користь «динамічних макетів», які є миттєвими налаштуваннями для кожного виконання коду Cairo. Dynamic Layout завжди виконає найкращий розподіл для завдання перевірки. З інженерної точки зору підтримка динамічної типізації вимагала б значних змін у кодовій базі. Тим не менш, команда StarkWare сподівається спростити перевірочний рівень Starknet, скориставшись перевагами динамічного макета, покращеного використання одиниць доріжки та кращого використання пруверів.
З динамічними макетами зникає турбота про ручне обслуговування багатьох вбудованих модулів, що спрощує процес інтеграції нових вбудованих модулів у Starknet.
Динамічний макет і комісії
Однією з цілей комісії за транзакції є стягнення з користувачів граничних витрат протоколу, понесених транзакціями. Оскільки одиницею комісії за транзакцію є валюта, механізм комісії передбачає перетворення ресурсів (наприклад, кроків віртуальної машини, вбудованих функцій, даних викликів, газу Ethereum) у токени (наприклад, STRK, ETH).
Наразі, оскільки перевіряючі стягують плату на основі загальної кількості слідів, а не коефіцієнтів використання, витрати ресурсів покриваються користувачами. Динамічний макет покращить використання одиниць доріжки, тим самим зменшуючи стягнення «непотрібних» комісій за транзакції (включаючи споживання ресурсів, не спричинене безпосередньо транзакціями користувача).
Інтеграція вбудованої функції Starknet
На даний момент інтеграція вбудованих функцій є меншою за останній крок, який полягає в модифікації бази коду Starknet для реалізації практичного використання. Ступінь модифікації коду пов’язаний із програмою макета, і необхідно змінити код, щоб гарантувати, що операційна система Starknet викликає вбудовані функції, коли це можливо. Наприклад, операційна система Starknet викликає хеш-функцію Poseidon під час виконання коду Cairo і в той же час викликає вбудовану функцію Poseidon.
Подібно до макетів, вбудовані компоненти Starknet тепер можна підтримувати вручну. Однак, на відміну від макета, ця підтримка вручну не є перешкодою для інтеграції, навіть незважаючи на наявність багатьох вбудованих функцій. Іншими словами, підтримка вбудованих модулів Starknet не є перешкодою для інтеграції, динамічний макет дійсно прокладе шлях для створення та інтеграції додаткових вбудованих модулів.
Підведіть підсумки
У цій статті ми пояснюємо, що таке вбудовані функції, їхні переваги, виклики та плани StarkWare. Поточна увага зосереджена на динамічному макеті, який не тільки покращить ефективність процесу перевірки, але й полегшить інтеграцію нових вбудованих компонентів.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Переваги та труднощі вбудованих функцій Starknet
Оригінал: вбудовані та динамічні макети
Переклад і вичитка: "Китайська спільнота StarkNet"
Резюме
Вбудовані функції оптимізують процес перевірки. Однак кожне підтвердження обчислюється з макета. Для певної перевірочної роботи переваги вбудованих функцій будуть значно зменшені, якщо макет неефективний. Наразі існує невеликий статичний список макетів, і кожне підтвердження обчислюється на основі найбільш відповідного макета з цього списку. Цей спосіб розміщення статичних списків має два недоліки. По-перше, існує обмежена різноманітність макетів. Це неефективно для більшості перевірочних робіт і створює складні механізми комісії, які створюють непотрібні витрати для користувачів. По-друге, складно вести список вручну. Коли кількість вбудованих модулів стає занадто високою, ручне технічне обслуговування стає складним і може фактично перешкоджати процесу перевірки ефективності вбудованих модулів, які підтримують велику кількість нюансів. Щоб вирішити ці проблеми, команда StarkWare розробляє динамічну систему макетів, де макети створюються на замовлення для кожного підтвердження роботи.
Стек Cairo полегшує обчислення загального призначення шляхом компіляції коду Cairo в інструкції для дружніх до STARK архітектур ЦП: Cairo VM (надалі CVM). Багато переваг ЦП загального призначення пов’язані з невід’ємною ціною, і CVM не оптимізовано для деяких звичайних операцій. Хеш-функції Keccak, Pedersen, Poseidon є звичайними такими операціями, як і операції з еліптичною кривою, перевірка діапазону (тобто перевірка того, чи певне число знаходиться в певному діапазоні значень) та інші.
Щоб усунути відносну неефективність CVM, стек Cairo вводить концепцію вбудованих модулів для критичних операцій: плагіни, які оптимізують такі операції для підтвердження складності. Вбудовані функції можна порівняти з ASIC: ASIC є інтегральними схемами для конкретної програми, а вбудовані функції – це алгебраїчні обмеження для конкретної програми (AIR). Якщо ви не знаєте або не пам’ятаєте, що таке AIR, це коротко описано далі в цій статті; прочитайте цю статтю, щоб дізнатися більше.
Коротше кажучи, складність доказів пов’язана (приблизно лінійно) з ресурсами, які називаються одиницями трасування, а вбудовані функції спрощують докази конкретних операцій, використовуючи набагато менше одиниць трасування, ніж Cairo VM.
Тепер, коли пояснено переваги вбудованих функцій, стає зрозуміло, чому вбудовані функції були розроблені для багатьох поширених операцій. Це легше сказати, ніж зробити. Поточний процес впровадження нових вбудованих модулів у Starknet складається з таких кроків:
Написання AIR
Інтеграція з прувером, створивши новий макет (описано нижче)
Інтегруйте в Starknet, тобто змініть його базу коду та інструменти розробника для використання нових вбудованих функцій
Окрім складнощів, пов’язаних із написанням AIR, є багато можливостей для вдосконалення на двох етапах, що залишилися. У цій розширеній статті докладніше описано вбудовані функції AIR як програми, зазначені вище проблеми та плани на майбутнє.
Вбудовані функції: AIR для конкретної програми
AIR — це абревіатура від Algebraic Intermediate Representation. У цій та інших статтях StarkWare AIR — це поліноміальна система для представлення віртуальних машин. Наприклад, Cairo отримав свою назву від CPU AIR: поліноміальна система, що представляє певну архітектуру ЦП. Розв’язки цієї поліноміальної системи представляють ефективні переходи станів, які називаються ефективними алгебраїчними траєкторіями виконання (AET).
STARK доводить, що робота віртуальної машини правильна, доводячи, що траєкторія виконання, яка відповідає заданому AIR, є дійсною. Грубо кажучи, траєкторія виконання — це таблиця чисел, і протокол STARK доводить, що ці числа разом розв’язують поліноміальну систему.
Одну і ту саму операцію можна обчислити багатьма способами, деякі з яких більш ефективні. У цьому документі складність доказу в основному залежить від розміру доріжки, тобто кількості комірок доріжки в таблиці. Оскільки трасування створюються для AIR, AIR розроблено для програм, щоб значно зменшити трасування виконання для конкретних обчислень. Вбудовані функції є спеціалізованими AIR, оптимізованими для програми.
У таблиці нижче показано підвищення ефективності для окремих вбудованих функцій (усі у виробництві).
Схема траєкторії: теперішнє та майбутнє
Як згадувалося раніше, AET — це приблизно таблиця чисел, яка представляє послідовність кроків у закодованій віртуальній машині (тобто виконання програми). Щоб обчислити доказ, перевірка запускає протокол STARK на доріжці виконання пов’язаного AIR.
Вище ми представили вбудовані функції як AIR для конкретної програми, призначені для мінімізації складності доказів шляхом зменшення кількості одиниць трасування, необхідних для кодування обчислень. Однак, якщо вбудовані функції випадковим чином інтегровані в Starknet, багато одиниць траєкторії можуть бути витрачені даремно, а очікувані переваги будуть зменшені. Пояснимо докладно нижче.
Коротше кажучи, макет доріжки - це призначення комірок доріжки різним «компонентам». У цій статті цими компонентами є CVM і вбудовані функції. Зокрема, макет визначає відносну кількість комірок треків, які отримує кожен компонент. (Конструкції макета завжди використовуються для спрощення перевірки. Щоб дізнатися більше, прочитайте розділ «Простота» цієї публікації).
Ключовим моментом є те, що складність перевірки залежить від загальної кількості комірок треків, виділених макетом, і розподіл комірок треків може бути більшим, ніж насправді потрібно. Наприклад, щоб продемонструвати впорядкування кроків CVM, макет, який призначає компонентам CVM лише комірки трасування, приблизно вдвічі ефективніший, ніж макет, який призначає половину комірок трасування вбудованим функціям Poseidon. Підсумовуючи, відповідний макет може значно зменшити складність підтвердження конкретного обчислення.
Зараз існує список макетів, який підтримується вручну, і він з часом збільшується з двох основних причин:
Вбудовані функції можна використовувати лише для компонування призначеної їм гусеничної одиниці. Тому для додавання вбудованих компонентів потрібен принаймні новий макет.
Макет, розроблений для виконання коду Cairo, оптимізує розподіл клітинок. Тому оптимізація варіантів використання в осередках часто вимагає нових макетів.
Код для прувера та валідатора (валідатори Solidity та Cairo) налаштовується відповідно до списку макетів.
З додаванням вбудованих модулів Keccak і Poseidon ставало все важче підтримувати списки макетів достатньо малими, щоб розмістити багато вбудованих компонентів і забезпечити ефективне виконання більшості блоків Starknet. Крім того, очікується, що ефективність суттєво впаде, оскільки будуть введені додаткові вбудовані компоненти, оскільки компонування має враховувати багато можливих комбінацій і співвідношень між вбудованими компонентами.
Зараз команда StarkWare працює над удосконаленням системи, відмовившись від попередньо створених списків макетів на користь «динамічних макетів», які є миттєвими налаштуваннями для кожного виконання коду Cairo. Dynamic Layout завжди виконає найкращий розподіл для завдання перевірки. З інженерної точки зору підтримка динамічної типізації вимагала б значних змін у кодовій базі. Тим не менш, команда StarkWare сподівається спростити перевірочний рівень Starknet, скориставшись перевагами динамічного макета, покращеного використання одиниць доріжки та кращого використання пруверів.
З динамічними макетами зникає турбота про ручне обслуговування багатьох вбудованих модулів, що спрощує процес інтеграції нових вбудованих модулів у Starknet.
Динамічний макет і комісії
Однією з цілей комісії за транзакції є стягнення з користувачів граничних витрат протоколу, понесених транзакціями. Оскільки одиницею комісії за транзакцію є валюта, механізм комісії передбачає перетворення ресурсів (наприклад, кроків віртуальної машини, вбудованих функцій, даних викликів, газу Ethereum) у токени (наприклад, STRK, ETH).
Наразі, оскільки перевіряючі стягують плату на основі загальної кількості слідів, а не коефіцієнтів використання, витрати ресурсів покриваються користувачами. Динамічний макет покращить використання одиниць доріжки, тим самим зменшуючи стягнення «непотрібних» комісій за транзакції (включаючи споживання ресурсів, не спричинене безпосередньо транзакціями користувача).
Інтеграція вбудованої функції Starknet
На даний момент інтеграція вбудованих функцій є меншою за останній крок, який полягає в модифікації бази коду Starknet для реалізації практичного використання. Ступінь модифікації коду пов’язаний із програмою макета, і необхідно змінити код, щоб гарантувати, що операційна система Starknet викликає вбудовані функції, коли це можливо. Наприклад, операційна система Starknet викликає хеш-функцію Poseidon під час виконання коду Cairo і в той же час викликає вбудовану функцію Poseidon.
Подібно до макетів, вбудовані компоненти Starknet тепер можна підтримувати вручну. Однак, на відміну від макета, ця підтримка вручну не є перешкодою для інтеграції, навіть незважаючи на наявність багатьох вбудованих функцій. Іншими словами, підтримка вбудованих модулів Starknet не є перешкодою для інтеграції, динамічний макет дійсно прокладе шлях для створення та інтеграції додаткових вбудованих модулів.
Підведіть підсумки
У цій статті ми пояснюємо, що таке вбудовані функції, їхні переваги, виклики та плани StarkWare. Поточна увага зосереджена на динамічному макеті, який не тільки покращить ефективність процесу перевірки, але й полегшить інтеграцію нових вбудованих компонентів.