Інтерв'ю з засновником мови 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-runtime. Це зручніше для програмістів, оскільки їм не потрібно виконувати всю цю бухгалтерську роботу до і після, і це також є секретною зброєю, що дозволяє нам визначити, чи можна паралельно виконати одну транзакцію з іншою, горизонтально масштабувати Sui і ефективніше виконувати деякі інші операції.
Ми також виконали деякі дуже цікаві роботи, такі як використання об'єктно-орієнтованої моделі даних для програмованих торгових блоків. Це технічна тема, я із задоволенням обговорю її детальніше. Але ці два фактори є основними динаміками, які призвели до розбіжностей з оригінальним Move.
Q4、Чи могли б ви поділитися більше інформації про програмовані торгові блоки та їх функції?
Мені подобається використовувати аналогію для пояснення: інші блокчейни схожі на фуд-корт у торговому центрі. Якщо ти хочеш з'їсти морозиво, ти підходиш до стенду з морозивом, дістаєш свою кредитну картку і платиш. Але якщо ти вирішуєш, що хочеш ще гамбургер, тоді ти йдеш до стенду з гамбургерами і знову платиш. Я не жадібна людина, але якщо я хочу з'їсти вісім страв, мені потрібно буде зробити вісім окремих транзакцій. А Sui більше схоже на шведський стіл: кожна транзакція - це не лише одна річ. Як тільки ти заплатив за шведський стіл, ти можеш робити багато речей без додаткових витрат. Ти можеш їсти морозиво, ти можеш їсти гамбургери, ти можеш змішувати їх.
Щоб зробити цю концепцію більш конкретною, у простому випадку, якщо ви хочете надіслати 100 транзакцій для карбування 100 NFT, ви можете надіслати одну транзакцію для карбування 100 NFT. Вартість такої транзакції практично дорівнює вартості карбування одного NFT. Ви також можете виконувати гетерогенні пакування транзакцій, наприклад, перша транзакція в блоці витягує персонажа Мário з вашого мультипідписного гаманця, а друга транзакція запитує Мário, а потім дозволяє вам грати в гру. Якщо ви виграєте гру та отримаєте трофей, можливо, третя транзакція помістить трофей у трофейний шафу, що ділиться з друзями. Круто те, що програмовані блоки транзакцій дозволяють програмістам писати код таким чином, що гра не повинна знати про мультипідписний гаманець або спосіб зберігання Мário, вона також не повинна знати про ваш трофейний шафу чи його реалізацію.
Програмовані торгові блоки складаються з операцій, які мають об'єкти введення та виведення. Якщо вам потрібен об'єкт введення, ви можете отримати його, не турбуючись про те, звідки він походить, а потім передати його вивід об'єкту, якому він потрібен, також не турбуючись про те, куди його передадуть. На інших блокчейнах зв'язність є більш сильною, тому ігри повинні інтегруватися з мультипідписними гаманцями та трофейними шафами, або всі вони повинні реалізувати якісь спільні інтерфейси і мати більшу зв'язність. Sui робить так звані тимчасові комбінації більш простими. Так, якщо труба підходить, ми можемо завершити в одній операції.
Q5, які переваги має програмована торгова зона для користувачів?
Переваги програмованих торгових блоків для користувачів включають нижчі витрати на газ, оскільки ви можете упакувати всі операції в одну транзакцію, а не виконувати окремі транзакції. Крім того, кількість необхідних затверджень також зменшиться. Якщо система, яку ви використовуєте, вимагає затвердження транзакцій, вам потрібно буде зробити лише одне затвердження, а потім воно буде виконувати всі операції одноразово. Іншою перевагою є атомарність: якщо ви хочете зробити три різні речі і хочете, щоб третя операція була успішною лише за умови, що перші дві операції успішні, якщо ці операції повинні бути незалежними транзакціями, ви не зможете цього досягти. Але якщо ви можете об'єднати їх в одну транзакцію, ви зможете легко реалізувати це.
Q6, я чув, як ви та інші говорили, що розробка на Sui є чудовим досвідом для програмістів, і це важливо. Які у вас є анекдоти, які ви можете поділитися щодо досвіду досвідчених та нових Web3 програмістів, коли вони починають використовувати Sui Move?
Для тих, хто є розробниками з інших мов програмування Web3, їхній досвід розробки на Move та Sui Move дійсно є більш ефективним та безпечним. Я щойно брав участь у подкасті про Bucket Protocol, який розробляє дуже класний проект на Sui.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
21 лайків
Нагородити
21
7
Поділіться
Прокоментувати
0/400
GasOptimizer
· 07-18 07:39
рухаємо!
Переглянути оригіналвідповісти на0
GasOptimizer
· 07-17 16:03
tps буде швидше ETH в 8.64 разів, вже підраховано
Переглянути оригіналвідповісти на0
AirdropHuntress
· 07-15 22:08
Ще один рекламний трюк, хто вивчав ранній код контрактів?
Переглянути оригіналвідповісти на0
HodlKumamon
· 07-15 22:04
Дивлюсь, дані не сходяться, о Move тату.
Переглянути оригіналвідповісти на0
CryptoAdventurer
· 07-15 22:02
All in і все. Давно не бачив move.
Переглянути оригіналвідповісти на0
Degen4Breakfast
· 07-15 21:57
move знову починає хвалитися
Переглянути оригіналвідповісти на0
NftPhilanthropist
· 07-15 21:54
хмм, ще один засновник web3 намагається врятувати нас зі своїм технологічним стеком
Розкриття засновника Move: як Sui Move допомагає у розробці продуктів Web3
Інтерв'ю з засновником мови 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-runtime. Це зручніше для програмістів, оскільки їм не потрібно виконувати всю цю бухгалтерську роботу до і після, і це також є секретною зброєю, що дозволяє нам визначити, чи можна паралельно виконати одну транзакцію з іншою, горизонтально масштабувати Sui і ефективніше виконувати деякі інші операції.
Ми також виконали деякі дуже цікаві роботи, такі як використання об'єктно-орієнтованої моделі даних для програмованих торгових блоків. Це технічна тема, я із задоволенням обговорю її детальніше. Але ці два фактори є основними динаміками, які призвели до розбіжностей з оригінальним Move.
Q4、Чи могли б ви поділитися більше інформації про програмовані торгові блоки та їх функції?
Мені подобається використовувати аналогію для пояснення: інші блокчейни схожі на фуд-корт у торговому центрі. Якщо ти хочеш з'їсти морозиво, ти підходиш до стенду з морозивом, дістаєш свою кредитну картку і платиш. Але якщо ти вирішуєш, що хочеш ще гамбургер, тоді ти йдеш до стенду з гамбургерами і знову платиш. Я не жадібна людина, але якщо я хочу з'їсти вісім страв, мені потрібно буде зробити вісім окремих транзакцій. А Sui більше схоже на шведський стіл: кожна транзакція - це не лише одна річ. Як тільки ти заплатив за шведський стіл, ти можеш робити багато речей без додаткових витрат. Ти можеш їсти морозиво, ти можеш їсти гамбургери, ти можеш змішувати їх.
Щоб зробити цю концепцію більш конкретною, у простому випадку, якщо ви хочете надіслати 100 транзакцій для карбування 100 NFT, ви можете надіслати одну транзакцію для карбування 100 NFT. Вартість такої транзакції практично дорівнює вартості карбування одного NFT. Ви також можете виконувати гетерогенні пакування транзакцій, наприклад, перша транзакція в блоці витягує персонажа Мário з вашого мультипідписного гаманця, а друга транзакція запитує Мário, а потім дозволяє вам грати в гру. Якщо ви виграєте гру та отримаєте трофей, можливо, третя транзакція помістить трофей у трофейний шафу, що ділиться з друзями. Круто те, що програмовані блоки транзакцій дозволяють програмістам писати код таким чином, що гра не повинна знати про мультипідписний гаманець або спосіб зберігання Мário, вона також не повинна знати про ваш трофейний шафу чи його реалізацію.
Програмовані торгові блоки складаються з операцій, які мають об'єкти введення та виведення. Якщо вам потрібен об'єкт введення, ви можете отримати його, не турбуючись про те, звідки він походить, а потім передати його вивід об'єкту, якому він потрібен, також не турбуючись про те, куди його передадуть. На інших блокчейнах зв'язність є більш сильною, тому ігри повинні інтегруватися з мультипідписними гаманцями та трофейними шафами, або всі вони повинні реалізувати якісь спільні інтерфейси і мати більшу зв'язність. Sui робить так звані тимчасові комбінації більш простими. Так, якщо труба підходить, ми можемо завершити в одній операції.
Q5, які переваги має програмована торгова зона для користувачів?
Переваги програмованих торгових блоків для користувачів включають нижчі витрати на газ, оскільки ви можете упакувати всі операції в одну транзакцію, а не виконувати окремі транзакції. Крім того, кількість необхідних затверджень також зменшиться. Якщо система, яку ви використовуєте, вимагає затвердження транзакцій, вам потрібно буде зробити лише одне затвердження, а потім воно буде виконувати всі операції одноразово. Іншою перевагою є атомарність: якщо ви хочете зробити три різні речі і хочете, щоб третя операція була успішною лише за умови, що перші дві операції успішні, якщо ці операції повинні бути незалежними транзакціями, ви не зможете цього досягти. Але якщо ви можете об'єднати їх в одну транзакцію, ви зможете легко реалізувати це.
Q6, я чув, як ви та інші говорили, що розробка на Sui є чудовим досвідом для програмістів, і це важливо. Які у вас є анекдоти, які ви можете поділитися щодо досвіду досвідчених та нових Web3 програмістів, коли вони починають використовувати Sui Move?
Для тих, хто є розробниками з інших мов програмування Web3, їхній досвід розробки на Move та Sui Move дійсно є більш ефективним та безпечним. Я щойно брав участь у подкасті про Bucket Protocol, який розробляє дуже класний проект на Sui.