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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q3. Що стало причиною змін, які були внесені в Move, що використовується в Sui, відомому як 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 є чудовим досвідом для програмістів, і це важливо. Чи є у вас якісь історії, якими ви могли б поділитися щодо досвіду використання Sui Move для досвідчених та нових Web3 програмістів?

Для розробників, які приходять з інших мов програмування Web3, досвід розробки на Move та Sui Move дійсно є більш ефективним і безпечним. Я нещодавно брав участь у подкасті про Bucket Protocol, де вони створюють дуже класний DeFi проект на Sui. Під час демонстрації системної архітектури вони розповіли, як різні компоненти працюють разом. Вони сказали, що якби вони використовували Solidity для написання цього проекту, це могло б зайняти вісім місяців, але з Sui Move це зайняло лише два місяці, і вони дуже впевнені в його безпеці. Ця мова працює дуже близько до уявлення про їх проектний портфель. А в сфері Solidity ця зв'язок не така пряма.

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

Вони кажуть, що перевага першого гравця дуже важлива, але я думаю, що в цьому випадку важливіша перевага другого.

Так, саме так.

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