Батько мови Move: мова смарт-контрактів Sui Move підходить для продуктів Web3

Походження: Sui Network

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

Ось зміст цього інтерв’ю:

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

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

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

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

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

**Q2、****Чи можете ви розповісти більше про розвиток Move? **

**Переміщення виникло в рамках проекту Facebook Libra. **Моїм завданням на той час було не створити нову мову, а «*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 робить так звані ad-hoc комбінації набагато легшими. **Якщо канали збігаються, ми можемо зробити це за одну транзакцію.

**Q5、****Які переваги програмованих блоків транзакцій для користувачів? **

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

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

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

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

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

Правильно, це все.

**Q7、****Ви торкнулися цього, коли згадали Sui Move і загальні об’єктно-орієнтовані функції Sui. Але чи можете ви чіткіше сформулювати зв’язок між дизайном Sui Move і здатністю Sui досягти масового впровадження Web3, низької затримки, низької вартості та масштабованості? **

Одна з речей, з якою ми дуже обережно ставимося до внеску в Sui, і проблема, з якою стикаються інші платформи, полягає в тому, що якщо у вас обмежена ємність, чи то 15 транзакцій на секунду (TPS), як Ethereum, чи 100 чи 1000 транзакцій, якщо це фіксоване число, то коли платформа стане надто успішною, вона досягне верхньої межі ємності. На цьому етапі досвід для всіх користувачів платформи погіршується. Якщо є лише 1000 вакансій, ви повинні вибрати найважливіші 1000, які можна вибрати через тендер на газ або іншими методами. Для всіх зростуть ціни на газ, зросте затримка або і те, і інше. Багато варіантів використання було виключено, оскільки лише ті, хто спроможний заплатити найвищу комісію, досягнуть успіху, тоді як іншим доведеться шукати в іншому місці або чекати довше. Це погана ситуація.

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

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

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

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

Q8、** На вищому рівні, як ви обговорюєте потенціал децентралізованої технології з розробниками, які скептично ставляться до Web2? **

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

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

**Якщо між додатками A та B більше немає бар’єру сумісності, але вони створені на тій самій базовій платформі, тож ви можете передавати речі з одного додатка в інший, будь то елементи в додатку, дані, рекламні акції чи треті -партійні продукти, побудовані на обох. ** Або уявіть собі Інтернет, де веб-сайти обмінюються даними один з одним за допомогою файлів cookie, але ці файли cookie є метаданими лише для читання. Що, якби ці файли cookie могли стати валютою? Або це може бути витратний предмет? Або це можуть бути програми лояльності та купони? Усе має вбудовану цю функцію. Це дуже абстрактно, але саме в цьому криється потенціал. Зазвичай людина, яка будує, думатиме про це як про нові надздібності, які він може використати, щоб створити щось більш привабливе.

Q9、** Для кінцевих користувачів, навіть якщо вони не мають технічних знань, чи відчуваєте ви вагання, коли вони розглядають довіру до коду, навіть якщо іншим варіантом є велика центральна сутність, яка є непрозорою? **

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

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

**Q10、****Які ваші очікування щодо майбутнього розвитку Sui Move? **

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

**Ми працюємо над багатьма функціями, пов’язаними з цим, особливо над типами enum. **Ми також багато працюємо над покращенням підключення Move до зовнішнього коду. Ми часто жартуємо, що типова програма Sui складається з 5% коду Move і 95% інтерфейсного коду. Тому ми дуже зосереджені на цих 95%. Ми витратили багато часу на розмови про Move, але ми також зосередилися на тому, щоб зробити інші частини ефективнішими та полегшити з’єднання. Загалом ми дуже зосереджені на тому, як зробити так, щоб додаток складався з Move для більшої безпеки. У той же час, як зробити ці 95% коду зрозумілими як для програмістів Move, так і для програмістів, які не використовують Move.