У цій трисерійній статті ми розкриємо технічні досягнення, які можуть значно покращити обробку даних для програм, що працюють на протоколі Інтернет Комп'ютер (ICP).
Це оновлення є віхою Stellarator у дорожній карті ICP, яке наразі розгортається по всій мережі. Stellarator є проривом у збереженні даних на ланцюгу, значно підвищуючи масштабованість та обробку даних, відкриваючи нові можливості для складних додатків, які раніше були обмежені системою.
Цей прогрес дозволяє розробникам створювати складні програми, які потребують великомасштабної обробки даних, що відкриває нові практичні рівні для технології блокчейн.
У другій частині цього серіалу Luc Bläser познайомить нас з покращеною ортогональною стійкістю Motoko, якщо ви пропустили першу частину про стійкість даних, ви можете знайти її тут.
Простота, безпека, швидкість: покращена ортогональна стійкість Motoko
Motoko вводить покращену ортогональну стійкість, це унікальна функція, призначена для полегшення навантаження на програмістів, що працюють зі стабільною пам'яттю, шляхом надання простого, безпечного та швидкого механізму оновлення.
Motoko завжди здатна автоматично зберігати стан програми під час оновлення, без необхідності додаткового коду для обробки стійкості, на жаль, попередня реалізація цієї функції не могла масштабуватися для великих або глибоко вкладених даних.
Ця функція тепер значно покращена в плані безпеки, продуктивності та масштабованості, ключовою інновацією є уникнення перенесення стану в стабільну пам'ять шляхом простого збереження, а не стирання основної пам'яті.
Система виконання тепер забезпечує узгодженість даних під час оновлення дуже ефективним способом, незалежно від розміру пам'яті, зрештою, ми перейшли з 32 біт на 64 біти основної пам'яті, зрештою розширюючись до значних обсягів стійких даних.
Контекст
Оновлення контейнерів є викликом на Інтернет Комп'ютері, зазвичай воно пов'язане з досить великою складністю, витратами та деяким ризиком втрати даних, хоча основна пам'ять контейнера (також відома як пам'ять WebAssembly) є стійкою між транзакціями, в минулому вона була очищена під час оновлення, що є досить штучним кроком, оскільки пам'ять вже має резервні копії файлів на Інтернет Комп'ютері.
Причиною такої поведінки є те, що реалізації основних мов програмування не враховують стійкість під час проектування: вони перерозподіляють структури пам'яті неконтрольованим чином під час повторної компіляції або виконання і не можуть просто використовувати пам'ять попередніх версій для відновлення виконання модифікованих програм.
Таким чином, програмісти повинні чітко використовувати API стабільної пам'яті або спеціальні структури стабільних даних, щоб зберегти дані під час оновлення, що схоже на традиційну комп'ютерну архітектуру, яка надає енергонезалежну основну пам'ять і постійну допоміжну пам'ять, але це коштує збільшення складності розробки програмного забезпечення (подумайте про мапери об'єктних баз даних тощо).
На відміну від цього, в Motoko ми можемо повністю контролювати компілятор і систему виконання, тому можемо повністю контролювати розташування пам'яті, що дозволяє підтримувати ортогональну стійкість в Motoko і продовжувати використовувати її навіть під час оновлення.
Отже, програмісти Motoko можуть зручно розробляти будь-які структури даних (типи першого порядку) в стандартних мовних концепціях, не використовуючи явну стабільну пам'ять, спеціалізовані структури стабільних даних або інші подібні абстракції бази даних, система виконання автоматично зберігає необхідні об'єкти.
Раніше система виконання Motoko досягала ортогональної стійкості шляхом серіалізації та десеріалізації стійких об'єктних графів у стабільну пам'ять, що призводило до серйозних проблем зі масштабованістю та продуктивністю, оскільки процес серіалізації/десеріалізації був дуже дорогим, і навіть міг перевищувати обмеження інструкцій, зрештою заважаючи оновленню, ці недоліки робили його непридатним для більших програм, саме тому ми перепроектували підтримку ортогональної стійкості в Motoko.
Змінивши Інтернет Комп'ютер і систему виконання Motoko, ми реалізували масштабовані оновлення без необхідності дорогого серіалізації та десеріалізації в допоміжному стабільному просторі пам'яті, навпаки, ми просто зберігаємо стійкість основної пам'яті під час оновлення, одночасно розширюючи адресний простір ортогональної стійкості до 64 біт для (майбутнього) розширення до такої ж ємності, що надається 64-бітною стабільною пам'яттю.
Покращена ортогональна стійкість
Наша мета - спростити розробку програмного забезпечення на Інтернет Комп'ютері та зменшити навантаження на програмістів, що працюють зі стабільною пам'яттю, для цього Motoko була оптимізована для стійкості на Інтернет Комп'ютері, одночасно забезпечуючи прості, безпечні та швидкі оновлення:
Просто: завдяки ортогональній стійкості (стійкі змінні в Motoko), будь-яка передавана досяжна структура першого порядку буде автоматично зберігатися під час оновлення, без необхідності у стабільній пам'яті або стабільних структурах даних.
Безпека: Система виконання строго перевіряє сумісність типів під час оновлення та підтримує різні зміни даних через неявну міграцію, будь-яка складніша міграція може бути реалізована за допомогою спеціального коду, що може запобігти будь-якому пошкодженню даних або непорозумінню на рівні пам'яті.
Швидкість: Оновлення стало надзвичайно швидким, оскільки основна пам'ять під час оновлення просто зберігається, без необхідності копіювання в стабільну пам'ять або з стабільної пам'яті, основна пам'ять була розширена до 64 біт, щоб у майбутньому можна було розширити до розміру стабільної пам'яті.
Огляд дизайну
Як передумова для покращеної ортогональної стійкості, протокол Інтернет Комп'ютера був розширено для підтримки збереження основної пам'яті між оновленнями та 64-бітної основної пам'яті на основі пропозиції WebAssembly Memory64.
Завдяки кастомізованому дизайну компілятора та системи виконання, Motoko визначає компіляційно незмінну структуру пам'яті, в якій всі об'єкти розподілені в динамічному купі, з достатньою метаданими, що дозволяє новим версіям програм безпечно отримувати стан попередніх версій.
Таким чином, пасивні сегменти даних WebAssembly виявилися корисними, оскільки вони дозволяють відкладати виділення статичних програмних даних (наприклад, текстових рядків) у системі виконання без необхідності зберігати статичні адресні діапазони.
Ми навіть зберігатимемо стан інкрементного збору сміття (GC) під час оновлення, що означає, що оновлення може відбуватися в будь-який час, не чекаючи завершення роботи GC.
Щоб забезпечити сувору безпеку пам'яті та типів, система виконання зберігає типи поточної версії програми та використовує цю інформацію для перевірки сумісності пам'яті при спробі оновлення до нової версії програми.
Оскільки ця перевірка залежить лише від кількості типів, а не від кількості об'єктів, оновлення відбувається дуже швидко і може бути розширене до будь-якого розміру пам'яті, деякі міграції даних (наприклад, додавання або видалення стабільних змінних, підвищення типів, додавання варіантів тощо) будуть автоматично підтримуватися, тоді як будь-які більш складні міграції можуть бути програмні вручну, при цьому продовжуючи захищати безпеку типів.
Motoko реалізувала автоматичну міграцію даних з традиційної стійкості до покращеної ортогональної стійкості, щоб дозволити можливі радикальні зміни в розташуванні пам'яті в майбутньому (ми очікуємо, що це трапиться рідко), Motoko також включає механізм допоміжної стійкості на основі серіалізації стабільної пам'яті та алгоритм графічного копіювання, а також безмежну детерміністичну часову розподіл, яка не підпадає під будь-які обмеження інструкцій Інтернет Комп'ютера.
Ви можете знайти більше деталей про покращену ортогональну стійкість, її дизайн, реалізацію, сценарії міграції даних та оцінку продуктивності в нашій нещодавно опублікованій статті (реалізація більш розумних оновлень контрактів за допомогою ортогональної стійкості).
Виробнича реалізація
Перший крок, покращену ортогональну стійкість можна використовувати як опційна функція, її можна активувати за допомогою параметра компілятора '--enhanced-orthogonal-persistence', відповідний параметр можна вказати в dfx.json наступним чином:
Motoko автоматично мігрує з класичної 32-бітної стійкості до покращеної ортогональної стійкості, але зверніть увагу, що не підтримується зворотна операція переходу з EOP до класичної 32-бітної стійкості.
У поточній версії, незважаючи на те, що ми перейшли на 64 біти, Інтернет Комп'ютер надає лише 4 ГБ основної пам'яті, це лише обережний крок першого етапу, ми дотримуємося підходу до випуску, що уникати ризиків, починаючи з малих обсягів і поступово збільшуючи ємність з часом.
Фактично, через перехід на 64 біти та початкове обмеження в 4 ГБ, очікується, що чисте використання пам'яті на початковому етапі буде меншим, ніж у 32 бітах (оскільки розмір покажчика зріс удвічі), вартість інструкцій для доступу до 64-бітної пам'яті також зросла, щоб обережно покрити витрати на апаратуру, що може знизитися в майбутньому.
Але найголовніше, оновлення стане дуже швидким і більше не досягне обмежень Інтернет Комп'ютера, навіть при максимальному використанні купи (також враховуючи, що більше не потрібні гачки для оновлення).
Наступні кроки, після збору відгуків та потенційного покращення системи та розширення ємності пам'яті, ми плануємо зробити покращену ортогональну стійкість за замовчуванням.
Висновок
Покращена ортогональна стійкість Motoko дозволяє розробникам Інтернет Комп'ютера зосередитися на їхніх основних програмах, не турбуючись про стабільну пам'ять.
Це не лише дозволяє реалізувати просту, безпечну стійкість, але й значно знижує витрати на оновлення Інтернет Комп'ютера та доступ до даних.
Покращена ортогональна стійкість може бути досягнута лише через кастомізований компілятор і систему виконання, як у нас зараз для Motoko.
Додаткова інформація
Luc Bläser, Claudio Russo, Gabor Greif, Ryan Vandersmith та Jason Ibrahim, реалізація більш розумних оновлень контрактів за допомогою ортогональної стійкості, VMIL 2024:
https://dl.acm.org/doi/10.1145/3689490.3690401
Пост на форумі DFINITY - Бета-тестування покращеної ортогональної стійкості:
https://forum.dfinity.org/t/beta-testing-motoko-s-enhanced-orthogonal-persistence-eop/35787
Документація - Покращена ортогональна стійкість Motoko:
https://internetcomputer.org/docs/current/motoko/main/canister-maintenance/orthogonal-persistence/enhanced
Документація - Стійкі змінні, оновлення та міграція даних в Motoko:
https://internetcomputer.org/docs/current/motoko/main/canister-maintenance/upgrades
Ми раді отримати ваші відгуки, будь ласка, діліться своїми думками на каналі DFINITY Developers X або в репозиторії Motoko GitHub.
Приєднуйтесь до нас завтра на третій частині нашої подорожі Stellarator, разом з Kamil Popielarz та Yvonne-Anne Pignolet, щоб дізнатися, як покращити пропускну здатність вхідних повідомлень.
Контент IC, який вас цікавить
Технічні досягнення | Інформація про проект | Глобальні події
Зберігайте та слідкуйте за каналом IC Binance
Будьте в курсі новин
