Інтерв'ю з батьком Move: чому мова смартконтрактів Sui Move підходить для створення продуктів Web3?

Нещодавно ми поспілкувалися з технічним директором Mysten Labs, творцем мови програмування Move Семом Блекшеаром, обговорюючи, чому він розробив нову мову програмування смартконтрактів Sui Move, можливості масштабування Sui та переваги децентралізованих технологій для розробників.

Наступне містить зміст цього інтерв'ю:

Q1. По-перше, чи можете ви коротко викласти, що таке мова програмування, які якості найбільше цікавлять розробників при виборі мови програмування та що спонукало вас розробити власну мову програмування?

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

А в мовах програмування найважливішим є наявність точно визначеного семантичного значення. Коли ви пишете програму, ви чітко знаєте, що вона має робити. Якщо ви вносите невеличкі зміни, ви знаєте, який результат вони принесуть. Це має зберігатися на кількох рівнях, наприклад, ви можете написати код однією мовою, він має одне значення, а потім бути перетворений в іншу форму, і тоді він також має мати таке ж значення, поки не досягне модулів обробки машини.

Я вважаю, що на відміну від природних мов, сутність мов програмування полягає в тому, щоб бути спрямованими на конкретні області або конкретні завдання. Інакше можна було б використовувати одну мову програмування для виконання всіх завдань. Але існує безліч мов програмування, тому що ви не можете добре впоратися з усіма сферами. Вони намагаються націлитися на конкретні проблемні області і зосередитися на вирішенні цих проблем. Наприклад, якщо ви подивитеся на мову програмування Rust, яку ми використовуємо для написання блокчейну Sui та більшості інших систем, що працюють на Mysten, вона зосереджується на написанні як швидкого, так і високопродуктивного коду, забезпечуючи при цьому безпеку. Вона дозволяє вам отримати доступ до деталей нижнього рівня, таких як пам'ять, структура потоків або паралелізм, але не дозволяє вам помилятися в цьому, як це було в попередніх мовах (наприклад, C або C++).

Отже, історія Move дуже схожа на це. Коли я його створював, я не мав на меті створити нову мову. Ви раніше згадували, що розробники шукають в мові. Вони запитують: "Чи підходить ця мова для завдання, яке я хочу виконати?" Але я вважаю, що, можливо, важливіше запитати: "Чи має ця мова величезну спільноту? Чи є багато доступних баз даних? Чи є багато програмістів, які її використовують? Чи є хороші освітні ресурси?" Усе це дуже важливо, тому поріг для створення нової мови повинен бути дуже високим, навіть якщо сама мова краща, але якщо у неї немає цих факторів, тоді її переваги не мають сенсу. Створити велику та динамічну спільноту з нуля дуже важко.

Q2, ви можете поділитися більше інформації про розробку Move?

Move походить з проекту Libra від Facebook. Моє завдання тоді полягало не в створенні нової мови, а в тому, що "Libra потребує смартконтрактів, тому дізнайтеся, що нам слід робити". Я переглянув різні варіанти. Чи можемо ми використовувати Solidity в EVM? Чи повинні ми використовувати звичайну універсальну мову, таку як WASM або JVM, і застосувати її для Libra? Чи слід нам створити щось власне?

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

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

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

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

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

Q3. Sui використовує варіант Move, відомий як Sui Move. Що спонукало до цих змін? Які особливості Sui Move особливо підходять для створення продуктів у Web3?

Наступні кілька факторів сприяли цим змінам, один з яких полягає в тому, що початкова мета проекту Libra полягала у створенні відповідної платіжної мережі. Тому ми намагалися розробити Move як універсальну мову. Але ми також свідомо зробили кілька речей, оскільки Libra хотіла мати обмеження. Однією з важливих речей є те, що вони не бажали, щоб люди могли надсилати певні активи куди завгодно. Вони хотіли, щоб люди явно створювали облікові записи і встановлювали кілька правил під час створення облікового запису, наприклад, власник облікового запису повинен пройти KYC-ідентифікацію. Або, можливо, потрібно буде сплатити збори за створення облікового запису, або облікові записи можуть створювати лише невелика частина людей, які мають право на створення облікових записів. Оскільки вся мета полягає в тому, що Libra хоче здійснювати відповідні платежі та відповідні смартконтракти, існують ці обмеження. Але в більш загальній сфері Web3 ситуація є прямо протилежною. Ви не хочете, щоб на базовому рівні були вимоги до відповідності, це концепція смартконтрактів. Ви хочете, щоб речі були якомога більш вільними, повністю можливо надсилати щось на будь-яку адресу. Тоді вам не слід явно створювати облікові записи, оскільки це блокуватиме різні варіанти використання. Це важливий фактор.

Іншим фактором є те, що, незважаючи на те, що ми в Move зосереджувалися на активах, на той момент у Libra ми не враховували, як перенести увагу на активи в саму угоду. Тому, коли ви досягаєте рівня угоди, у вас все ще є тільки це API, в яке ви вводите числа та логічні значення, які не є активами, а потім у Move ви використовуєте ці числа для вилучення активів з рахунку та виконання інших операцій. Виявляється, що більшість коду, який ви запускаєте, є такою неприємною бухгалтерською роботою, яка включає вилучення цього, вилучення того, вилучення інших речей, добре, я маю всі активи, які мені потрібні. Вони тут, у моїй майстерні, тепер я можу почати робити щось значуще. А потім наприкінці цього процесу ви, можливо, скажете: "Добре, поверніть ці активи на цей рахунок, поверніть їх на той рахунок, реорганізуйте їх."

У Sui ми ретельно продумали, чи можемо ми абстрагувати це, якщо кожна програма починається і закінчується таким чином? Отже, логіка, що використовується для обробки транзакцій, буде виконана програмістами, з точки зору яких їм потрібно лише підготувати необхідні активи та відразу почати цікаву роботу. Це те, що існує в Sui як об'єктно-орієнтована модель даних. У первісному Move ми маємо модель даних на основі рахунків, активи зберігаються під рахунком, і програмісти повинні явно їх витягувати. А в Sui, коли вони входять у частину Move транзакції, активи вже отримуються виконуваним середовищем Sui. Це зручніше для програмістів, оскільки їм не потрібно виконувати всю цю облікову роботу до і після, і це також є секретною зброєю, яка дозволяє нам визначити, чи можна паралельно виконати одну транзакцію з іншою, горизонтально розширити Sui та ефективніше виконувати інші операції без фактичного виконання.

Ми також виконали деяку іншу дуже цікаву роботу, наприклад, використовуючи об'єктно-орієнтовану модель даних для програмованих торгових блоків. Це досить технічна тема, і я з радістю обговорю це детальніше. Але ці два фактори є основними причинами, які призвели до розбіжностей з оригінальним Move.

Q4, чи можете поділитися більше інформації про програмовані торгові блоки та їх функції?

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

Щоб зробити цю концепцію більш конкретною, у простому випадку, якщо ви хочете надіслати 100 транзакцій для випуску 100 NFT, ви можете надіслати одну транзакцію на випуск 100 NFT. Вартість такої транзакції майже така ж, як вартість випуску одного NFT. Ви також можете виконати гетерогенні пакети транзакцій, наприклад, перша транзакція в блоці витягує персонажа Маріо з вашого мультипідписного гаманця, а друга транзакція запитує Маріо і дозволяє вам грати в гру. Якщо ви виграєте гру і отримаєте трофей, можливо, третя транзакція помістить трофей у трофейну шафу, якою ви ділитеся з друзями. Круто, що програмовані блоки транзакцій дозволяють програмістам писати код таким чином, що гра не повинна знати про мультипідписний гаманець або спосіб зберігання Маріо, їй також не потрібно знати про вашу трофейну шафу або спосіб її реалізації.

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

Q5, які переваги програмовані торгові блоки надають користувачам?

Переваги програмованих торгових блоків для користувачів включають нижчі витрати на газ, оскільки ви можете упакувати всі операції в одну угоду, а не виконувати окремі угоди. Крім того, кількість необхідних затверджень також зменшиться. Якщо система, яку ви використовуєте, вимагає затвердження угоди, вам потрібно буде здійснити затвердження лише один раз, і потім вона виконає всі операції одноразово. Ще однією перевагою є атомарність: якщо ви хочете виконати три різні дії і бажаєте, щоб третя дія була успішною лише тоді, коли перші дві дії завершаться успішно, ви не зможете цього досягти, якщо ці дії повинні бути незалежними угодами. Але якщо ви можете об’єднати їх в одну угоду, ви зможете легко це реалізувати.

Q6, Я чув, як ви та інші говорили, що розробка на Sui є чудовим досвідом для програмістів, і це важливо. Чи є у вас якісь цікаві історії, якими ви можете поділитися щодо досвіду досвідчених та нових програмістів Web3, які починають використовувати Sui Move?

Для тих, хто походить з інших мов програмування Web3, досвід розробки на Move та Sui Move дійсно є більш ефективним та безпечним. Я щойно брав участь у подкасті про Bucket Protocol, який будує не на Sui.