Recap Sui AMA: Move Programming Language с Тоддом Новацким и Дамиром Шаманаевым
Примечание. Дополнительную информацию о языке программирования Move можно найти на нашем портале разработчиков Sui.
Введение
Джен: Большое спасибо за то, что настроились на нашу вторую часть нашей АМА. На этот раз темой стал наш язык программирования Move. Я очень рад представить наших милых гостей, Тодда и Дамира, наших инженеров по программированию движений в Mysten Labs!
Тодд: Меня зовут Тодд, и я работаю над Move с 2018 года. Я занимаюсь компиляцией, а также интеграцией Sui.
Забавный факт: я работаю в Mysten с марта, а до этого восемь лет работал в Facebook (или Meta). Так что в стартапе было весело.
Дамир: Меня зовут Дамир, и я тренирую и использую Move с 2019 года, когда люди в Facebook только разрабатывали язык. Я прошел первый этап Move IR, а затем начал использовать Move. Прежде чем они написали какую-либо документацию для языка, я написал первую книгу о языке.
Вопрос № 1: Какова история Move и что отличает его от других языков программирования, таких как Solidity?
Тодд: Что касается истории, Move был создан как язык программирования для Libra и проекта Diem в Meta. Мета искал языки программирования смарт-контрактов и пытался найти что-то подходящее для проекта, но ничего не подходило. Когда мы смотрим на другие языки программирования блокчейна, а именно на Solidity, в нем нет активов или других элементов блокчейна в качестве элементов первого класса. В некотором смысле это похоже на Javascript, где вы пытаетесь создать программирование своей ценности из сопоставлений, но на самом деле у него нет модели программирования «сначала активы».
Итак, я начал рассматривать эти идеи с линейной логики, линейного программирования, линейных систем типов и интегрировать их как способ ввести дефицит в язык программирования. И это то, чем на самом деле является Move — это язык для программирования с дефицитом.
Мы хотели убедиться, что у вас есть это встроенное понятие: вот некоторые значения, эти значения представляют активы реального мира, вы не должны иметь возможность копировать их, и вы хотите убедиться, что они используются правильно.
Нам нужна эта идея редкости, программирования, которое гарантирует, что активы, которые у вас есть, не могут быть скопированы, что вы используете их так же, как вы используете деньги, и что они ведут себя как физические деньги. Вам также нужны такие вещи, как измерение для языка блокчейна. Важно, чтобы вы, если вы приходите на эти платформы, должны были платить за игру или платить за вычисления, которые вы используете, и иметь для этого какой-то механизм. Таким образом, хотя вы можете взять существующий язык и попытаться добавить к нему редкость, или добавить API или вид программирования с активами, потом будет сложно получить измерение.
Еще сложнее интегрировать детерминизм: механизм в среде блокчейна, который требует, чтобы все узлы согласились с результатом вычислений (т. е. при одинаковых входных данных вы хотите одинаковых выходных данных). Вы должны начать действительно перебирать и запрещать множество библиотек за недетерминированное поведение, например, генерацию случайных чисел.
Итак, мы смотрим на все эти вещи, и это действительно то, с чего начался Move. Мы подумали: давайте просто сделаем действительно простой язык, в котором все эти вещи будут отправной точкой для примитивов языка. Move действительно начинался как очень простой язык для программирования с ресурсами или активами, и со временем мы немного усложнили его. Но такова его история, и именно поэтому мы не взяли готовый язык, такой как Solidity или даже Rust.
Мы начали Move с упрощенного языка и сделали его объектно-ориентированным. Затем мы приняли модульную систему, более похожую на ML. Многие из них были разработаны с целью обеспечения простоты этих блокчейн-приложений. Еще одним важным моментом с первого дня была возможность действительно иметь надежные гарантии и возможность статически подтверждать информацию о программах Move. Мы всегда ставили перед собой цель построить Move Prover в какой-то статической верификации, потому что много раз, когда вы возвращаетесь и хотите выполнить статическую верификацию языка, вам приходится иметь дело со всеми этими гадостями, которые язык добавлен для выразительности, но на самом деле не поддается простой статической проверке. Изначально Move даже не был завершен по Тьюрингу; у нас не было общих циклов или рекурсии. Мы надеялись, что это упростит статическую проверку, но оказалось, что мы действительно этого не делали. Одной вещью, которую мы не оставили за пределами этого языка, была динамическая диспетчеризация или что-то вроде более традиционного подхода к объектно-ориентированным языкам, где нет никаких следов или чего-то подобного. Невозможно иметь косвенные вызовы или функции, где поведение пути кода или какая логика, которую вы используете, действительно являются чисто динамическими в этом смысле. Это просто делает некоторые части проверки намного проще. Хотя вам нужно программировать по-другому, мы думаем, что этот компромисс того стоит. где поведение пути кода или логика, которую вы используете, действительно являются чисто динамическими. Это просто делает некоторые части проверки намного проще. Хотя вам нужно программировать по-другому, мы думаем, что этот компромисс того стоит. где поведение пути кода или логика, которую вы используете, действительно являются чисто динамическими. Это просто делает некоторые части проверки намного проще. Хотя вам нужно программировать по-другому, мы думаем, что этот компромисс того стоит.
Таким образом, язык как бы эволюционировал с этой точки зрения. У нас действительно не было общего набора первого языка. Не было никакого полиморфизма; что пришло позже. Там много действительно забавных вещей. Если вам когда-нибудь станет скучно, просто идите и прочитайте ВМ или ИК; есть много действительно забавных артефактов для изучения, и это своего рода забавная археология. Сначала в Move не было векторов или других типов коллекций, у нас есть этот тип байтового массива, который использовался повсеместно, так что вы можете подумать, что в базе кода все еще есть некоторые ссылки, байтовый массив, что всегда забавно.
Я думаю, что одна из вещей, которыми я больше всего горжусь, это наши проверки безопасности ссылок, у нас есть эта проверка заимствования, вы знаете, Rust очень известен тем, что имеет эту проверку заимствования, это эта статическая проверка вокруг ссылок. И он известен тем, что производит чрезвычайно запутанные ошибки. И я не говорю, что из Move никогда не выходило ничего сбивающего с толку, но я думаю, что с точки зрения сложности системы мы создали что-то, что имеет аналогичные уровни выразительности для эталонной безопасности, будучи, по крайней мере, в с точки зрения формализма или реализации намного проще.
Дамир: Примерно в 2019 году мы разрабатывали блокчейн, который должен был стать блокчейном defi, и нам нужно было выбрать язык. В то время у вас была только Solidity, а два других варианта были в стадии разработки, одним из которых был Move, а другой, если я не ошибаюсь, был создан парнем, который создал криптокитти.
Move first был очень громоздким, практически непригодным для использования языком, потому что в то время он в основном использовался в мобильной дополненной реальности, но у него уже был ряд свойств и ряд идей, которые фактически сводили меня с ума. Затем, через несколько месяцев, я полностью влюбился в язык из-за его выразительных возможностей.
Я пришел из Solidity, и в Solidity вы выражаете вещи, например, кому что-то принадлежит (у меня есть NFT 1, у вас есть NFT 2). Это как централизованная HashMap или база данных. В качестве базы данных вам нужно заново реализовать базу данных, но в Move вы действительно можете владеть типом.
Например, всякий раз, когда я говорю, что есть эта монета, у меня есть тип. Это не написано где-то, как в децентрализованном HashMap, а скорее я буквально владею им. Теперь я думаю типами в голове. Я знаю, что если я передаю монету этого типа где-то, это означает, что я буквально забираю монету у себя и передаю ее куда-то еще.
И эта идея, я имею в виду, как только вы ее поймете, она как будто откроет множество возможностей в программировании в целом. Поэтому, как только вы начинаете думать как объекты, а не как абстракции, которые вы строите поверх программных примитивов, таких как хэш-карта, вы всегда знаете, что делаете, точно так же, как с неограниченной выразительностью с явным указанием типов — что было и что есть.
Я считаю, что это преимущество Move, потому что вы можете выразить все, как в реальной жизни. Когда я в баре объяснял Move, я говорил: «Итак, вот его бутылка и вот этот стакан. Представьте, что они оба являются NFT, и если у нас есть функция, например, «переливание воды» из этой бутылки в стакан, вы буквально передаете их вместе». Функция делает это и возвращает вам полный стакан.
Вопрос № 2. Почему мы выбрали вариант Move для Sui, а не стандартный язык Move?
Тодд: Да, я полагаю, что здесь есть небольшая предыстория того, как настроен Move. Одной из наших целей было создать язык исключительно для дефицита. В языке не так много примитивов блокчейна или других вещей. Если вы пойдете и посмотрите на Solidity, это действительно язык исключительно для Ethereum, там есть все эти вещи, запеченные в различных блоках, таких как родные вещи Ethereum, которые являются основной частью языка, и наша цель состояла в том, чтобы убедиться, что Move чувствует себя например, его можно создать на любом блокчейне или в любом приложении, где вы хотели дефицита.
Но нам нужен был способ правильно обобщить хранилище. Для блокчейна полезно иметь возможность зафиксировать или фактически записать что-то, вы не просто разогреваете процессоры, вы хотите потратить газ, вы хотите убедиться, что вы можете взять на себя обязательство перед кредитором или внести изменения в состояние.
Итак, у Move есть идея глобального хранилища, в котором модули могут объявлять ресурсы или типы, а затем индексировать их в цепочку и говорить: «Хорошо, я возьму свой тип монеты, перемещу его и назначу». это или передать его по этому адресу, поэтому у нас была эта немного большая карта отверстий, где ваши учетные записи и каждая учетная запись имели ресурсы, и вы могли иметь один ресурс для каждого типа.
Таким образом, это было целью сделать обобщение для хранилища блокчейна. Но когда дело дошло до Sui, мы пытаемся сделать блокчейн более эффективным, признавая, что не каждая транзакция связана, и на самом деле наличие этого большого централизованного глобального состояния является недостатком, и это недостаток, но на самом деле он не покупает вас. много. Если я отправляю монету Дамиру, блокчейну не нужно ждать, пока я отправлю другую монету Яну или кому-то еще, это независимые транзакции. Но Move с тем, как он представлял глобальное хранилище, эти концепции были очень, очень разными или трудными для выражения, если не возможными, потому что он был разработан с моделью на основе централизованной учетной записи.
Итак, чтобы сделать это по-другому, нам пришлось подумать о том, как мы представляем отдельные объекты и Move? Как нам взять такую независимость данных и вставить ее в язык? И я не участвовал в разработке этого, но на ранних этапах разработки Move мы думали о том, чтобы иметь все глобальное хранилище вместо того, чтобы у вас был доступ к этим встроенным функциям, о которых мы думали. возможно, это будет параметр, который вы передаете в функции, у вас есть тип хранения, который вы передаете в языке, и это в основном та концепция, к которой мы вернулись для Sui Move и вместо имея централизованные данные как часть примитива языка, вместо этого вы будете передавать объекты, которые хотите использовать, в функции точки входа.
Таким образом, вы явно говорите: «Хорошо, я возьму объект этого типа», а затем на уровне транзакции вы указываете, какой объект этого типа вам нужен, чтобы у вас был некоторый идентификатор для него.
Так что на самом деле, это обычное перемещение просто не настроено для представления объектов этого, и что мы сделали, так это удалили глобальное хранилище, это большое общее централизованное хранилище из языка для Sui. Я перешел к этой индивидуальной объектной модели, так что это действительно то, почему нам нужно было отойти от стандартного настроения, и то, что мы делаем по-другому.
Теперь, с учетом сказанного, я просто хочу прояснить, что он не преобразован в язык, или что-либо Move было создано для того, чтобы отдельные адаптеры, то есть отдельные экземпляры языка, могли добавлять такие вещи, взаимодействуя с виртуальной машиной без приходится фактически импортировать язык или делать что-то другое.
Так что есть средства, которые мы все еще используем в той же стандартной библиотеке, что и другие механизмы и творения. Это тот же вид, та же виртуальная машина, это тот же Move Ling, в который мы вносим свой вклад, просто мы выбрали другой подход к тому, как мы собираемся взаимодействовать с хранилищем.
Дамир: Вы упомянули точки входа, и этого достаточно. Вы знаете, почему все выручили транзакцию в кредит?
Тодд: Да, мы можем поговорить о том, возвращаясь к истории, они немного оригинальны, потому что одна из идей Move заключается в том, что если вы посмотрите на Solidity, это действительно не похоже на программирование на обычном языке программирования, верно? Вы идете туда и строите этот синтезатор, никакого обмена кодом нет. Если вы программируете на ржавчине и хотите заняться каким-то другим крейтом или программировать на Java, вы можете просто импортировать из библиотеки что-то, что на самом деле не существует в Solidity, по крайней мере, не в классическом смысле, верно? Вы должны копировать и вставлять их код или вставлять все эти вещи, вы можете обращаться к другим другим контрактам, но на самом деле это не похоже на обычное связывание с кодом.
Цель модульной системы Move состоит в том, чтобы вести себя как обычная модульная система, которую вы ожидаете от других языков программирования, поэтому, если вы хотите повторно использовать код в цепочке, вы можете сделать это без его повторной публикации.
Теперь вопрос заключался в том, как же мы на самом деле начинаем транзакции? Итак, идея заключалась в том, чтобы в основном иметь разделение, у вас есть модули, которые представляют собой повторно используемый код, а затем сценарий, например, я хочу выполнить эту серию инструкций в блокчейне. Скрипты вроде как росли и росли с течением времени до такой степени, что они действительно выглядят как маленькие мини-модули, и поэтому мы как бы перешли немного больше, вместо того, чтобы обязательно иметь сценарии, вот набор инструкций, пожалуйста, выполните их по цепочке. Вместо этого в модуле вы можете указать, например, вот как транзакция или вот точка входа для выполнения, вы можете вызвать эту функцию в этом модуле, вы можете думать об этом как о повторно используемом сценарии. Это набор инструкций, опубликованных в цепочке, которые вы можете выполнять снова и снова.
Итак, вот откуда это взялось, и это действительно было полезно с точки зрения программирования в Sui для получения таких объектов, потому что теперь модель может определять, как вы можете программировать объекты.
Дамир: Хорошо, но у нас еще есть сценарии, верно? Я имею в виду, где-то.
Тодд: язык, да, я как бы хочу осудить их в пользу немного не по теме здесь. Но мы можем поговорить об этом позже.
Дамир: Я не знал, увижу ли я LDR, так что вы знаете, что можете написать программу, и эта программа будет транзакцией.
Так что обычно вы вызываете определенный метод, вы можете написать всю программу и опубликовать ее как транзакцию. так это как будто вы опубликовали всю вашу программу, и она делает свою работу, чтобы ввести как бы 100 адресов, и она разделит вашу монету примерно на 100 штук, и вы пропишете это как код в Move, и она отошлет на эти 100 адресов и она была действительно классная фича, которой ни у кого не было, а теперь и не надо.
Тодд: Да, я думаю, что это немного сложно, потому что идея заключалась в том, чтобы надеяться, что вам не придется публиковать этот код, но скрипт все равно должен жить где-то в цепочке, и вам нужно иметь возможность зафиксировать себя к этой казни и немного повторите ее.
Я думаю, может быть, мы сейчас немного не по теме. Но да, это особенность обычного перехода, когда мы торгуем точками входа в транзакции немного по-другому, когда мы движемся, но мы фиксируем эти изменения вверх по течению, и вы знаете, у меня есть вся история точек входа, которая изменилась, но недавно для ядра Move не только для Sui.
Вопрос № 3: Как на самом деле работают смарт-контракты для блокчейна?
Тодд: Да, поэтому Суи немного отличается, поскольку всегда говорит, что у вас есть эти модули, и опять же, надежность — это то же самое, что я действительно ненавижу термин, говорящий о смарт-контракте, за то, что он стоит. Я думаю, что это глупый термин, и я думаю, что это действительно похоже на маркетинг вокруг идеи программ, и эта надежность вроде как у меня есть одиночный объект или одноэлементный набор кода, который никто другой не может использовать. И вот некоторые функции, которые вы можете вызвать в нем, и самое похожее на любое другое существующее понятие, по крайней мере, насколько работает Эфириум. Это что-то вроде модели актора. И в некотором роде это похоже на микросервисную модель.
Я просто нахожу термин «умный контракт» немного хитрым маркетингом. В этом нет ничего умного, в этом нет ничего действительно контрактного. Это просто программа. Это мое личное дело, и я знаю людей, которым нравится этот термин.
При этом, что касается модулей в Sui, я говорил, что мы хотели сделать что-то немного другое. Move, имея эти повторно используемые модули кода, мы действительно публикуем их таким образом, который немного более похож на другой. к смарт-контрактам на Ethereum, чем в обычном Move in Sui.
Итак, если вы хотите написать как смарт-контракт, вы берете группу модулей и публикуете их в том, что мы называем пакетом в Sui, так что вы собираете свои модули, вы можете связать их с другими модулями, существующими в цепочке. , а затем вы публикуете их в своей учетной записи. И вы получите за это какое-то удостоверение личности.
Итак, у вас есть объект, который содержит, как я уже говорил, в Sui у нас есть эти объекты для монет и других активов. И эти объекты не обязательно должны быть просто перемещением значений и перемещением кода. Итак, вы берете все эти вещи и упаковываете их, и теперь у вас есть объект, представляющий упаковку. Вот как мы структурируем эти вещи. Но любой может вызвать его и связать с ним из своего собственного кода, вам не нужно выполнять эти функции делегата для другого контракта, который ведет себя немного более похоже на то, как вы могли бы ожидать, что код будет работать. Если вы пишете как Python, Rust или Java.
Есть что-то, Дамир, вы хотите сказать, что, может быть, вы немного лучше разбираетесь в пространстве Эфириума, если вы хотите, возможно, пойти дальше о том, чем оно похоже и отличается.
Дамир: Да, моя теория познания устарела, очень устарела за несколько лет или около того.
Тодд: Я имею в виду, я не знаю, хотите ли вы еще что-нибудь сказать о разнице между смарт-контрактом и пакетом Move и Sui.
Дамир: Ага. Но ты понял правильно. Я имею в виду, что обычно мы пытаемся сломать код как можно более общим. Таким образом, он максимально многоразовый, как если бы у нас был модуль монет, который вы можете видеть, и мы постепенно переходим к следующему вопросу, который касается интерфейсов. Если вы посмотрите на наш фреймворк, вы увидите, что у нас есть монета, но это как бы общая точка, которую любой может использовать для реализации своей монеты.
Итак, если вы сравните это с надежностью, обычно вы публикуете, как правильно заметил Тодд, когда вы хотите опубликовать что-то вроде смарт-контракта, вам обычно нужно реализовать все с нуля. Если у вас есть стандарт ERC 20, у вас есть этот одобренный перенос и так далее, все описано в интерфейсе, и вам нужно реализовать этот интерфейс и вам нужно все закодировать самостоятельно.
Э-э, хорошо и плохо то, что, следуя этому интерфейсу, вам не обязательно реализовывать их стандартным образом. У вас может быть метод перевода, который просто связывает все ваши деньги от вас, просто Excel ваши деньги от вас, когда вы хотите что-то перевести, и это проблема интерфейсов в целом. Мне нравится, как Move решает эту проблему, потому что у нас есть общие реализации для любого типа T, и если вы посмотрите на наш модуль монет, чтобы сделать еще один ERC 20, но я не люблю сравнивать нас с Solidity, но в любом случае, если вы хотите опубликовать монета или токен, вы просто публикуете одну строку, похожую на имя вашего токена, и это будет ваша монета ERC 20 при подаче иска. И тогда вы автоматически получаете все методы, такие как третья основная передача и так далее, и все решения, которые у нас есть в Move, в значительной степени универсальны, и это улучшение называется возможностью повторного использования. И это похоже на одну из величайших особенностей языка. И поэтому даже в наших примерах можно легко изменить, если у вас есть пример бутерброда, вы будете сочетать хлеб с маслом или что-то в этом роде. Вы можете сделать общий модуль Combinator, который каким-то образом объединит два модуля, я имею в виду, что мы можем придумать, как это сделать.
Вопрос № 4: Нужны ли вам интерфейсы и стандарты в Move, такие какRC 721 или новый?
Дамир: В них нет необходимости, и у нас нет интерфейсов. На самом деле существуют замечательные вещи, такие как Opensea. Я имею в виду, во-первых, все является объектом, поэтому, если вы просто хотите, чтобы все можно было передавать или тратить, и так далее, вы просто определяете свой тип, например, набор переопределенных способностей, и разрешаете его передавать. Вот и все. Так же, как мой NFT, мой NFT и обученный NFT, все еще разные типы, но они могут иметь одни и те же свойства и реализовывать один и тот же интерфейс.
Итак, если кто-то хочет построить Opensea, нам не нужно следовать тому же стандарту, что и RC 721, мы можем иметь все, что угодно, пользовательские метаданные, пользовательские отходы для объединения NFT, пользовательские отходы для их сжигания. Но на универсальном рынке Opensea мы сможем работать со всеми из них, если просто укажем правильные способности для этих типов. Так что да, нам не нужны интерфейсы.
Все является общим почти по умолчанию, и все можно настроить, например, эти небольшие изменения в том, как ведет себя тип, в том, как вы определяете способности для этого типа. Они влияют на способ использования этого типа.
Тодд: Если углубиться в то, что говорил Дамир, то интерфейсы — это костыль для того факта, что вы не можете повторно использовать код, и нет никакого способа настроить существующий код. Итак, если у вас есть токен, и вы хотите определить его на солидности, это похоже на то, что я не могу повторно использовать другой существующий код токена. Нет библиотеки подобных токенов. Итак, вы застряли, пытаясь придерживаться этого интерфейса. Таким образом, единственное решение и ход идеи заключается в том, что вы пишете тип монеты один раз, и все готово.
Там вроде монетный модуль. И это описывает поведение монеты. У вас есть актив монеты, тип, представляющий монету, а затем у вас есть функциональность над монетой. То же самое будет и с монетами, где у вас есть разделение и передача, объединение и снятие средств и так далее.
Итак, теперь, когда вы хотите прийти и определить свой собственный тип токена, вы можете создать экземпляр типа монеты с помощью дженериков и заполнить внутренние биты монеты и сказать: «Хорошо, у меня есть монета Sui или монета Eth или монеты Тодда Николса или любые другие фантастические деньги, которые вы хотите заработать в цепочке, вы можете просто создать новый модуль, создать новый тип, а затем инстантировать тип монеты с вашим типом нового типа токена. И теперь это будет работать везде, как только это сработает.
Итак, если у вас есть что-то вроде Opensea, где вы хотите передавать эти вещи, вы можете представить себе, что у вас есть общий тип для монеты или у вас может быть общая оболочка для Opensea NFT. Таким образом, в Opensea вы можете инкапсулировать свои данные в этот тип, и тогда все будет хорошо.
Нет, это похоже на самую прямую связь с тем, как все работает в Solidity, но здесь мы можем сделать немного лучше. Я бы сказал в Move, что Демир говорил об этих способностях для типов, это то, что вы можете определить свой собственный тип, свой собственный NFT, и на самом деле не нужно использовать таких рэперов, как я только что говоря о. Вы можете просто делать все, что хотите, и если у вас есть определенные способности, то передача объекта Sui будет работать в целом по всем направлениям, что у нас есть этот обобщенный объект передачи, вы можете вызвать транзакцию, эту передачу объекта и вы закончили, но вам даже это не нужно, вам не нужно иметь это как общедоступную передачу, вы можете сказать, я хочу, чтобы весь код и вся передача прошли через мой модуль. Я хочу жестко контролировать это поведение. И для Opensea или кого-то из других маркетплейсов было бы достаточно легко раскрыть эту функциональность. Это может быть не очень красиво, но вы можете посмотреть на модуль и сказать: «Эй, у меня есть объект такого типа». Давайте найдем в этом модуле все функции точки входа, использующие этот тип. И вы можете сказать, хорошо, вот все функции, выставленные в этом модуле для этого, для этого типа. И вы даже можете сказать, о, я действительно хочу вызвать эту другую точку входа и какую-то другую функцию. И я мог бы представить себе что-то вроде Opensea или какого-то другого Explorer, торговую площадку, способную сказать: «Хорошо, я хочу пойти посмотреть на этот модуль». И я хочу использовать объект. Я сохранил в обмене или что-то в этом роде, и я хочу использовать его с этой пользовательской логикой. Так что вам не нужно иметь просто потому, что у нас нет интерфейсов. Это не значит, что нет способа сделать собственный код. Я думаю, это моя точка зрения.
Дамир: Я могу добавить к этому. На самом деле у нас есть интерфейсы, и мы обнаружили их месяц назад. Да, это правда, мы все еще открываем новые паттерны, мы все еще открываем новые способы выражения вещей. И если вы перейдете к нашей основной ветке на GitHub, вы перейдете к примерам, там есть пример регулируемой монеты, и он демонстрирует, что у нас могут быть интерфейсы.
Итак, если вы хотите иметь этот тип, вам нужно реализовать модуль, который реализует все методы этого типа, я имею в виду, что это технически интерфейс. Это позволяет вам реализовать собственный интерфейс пользовательского типа. Я имею в виду, реализовать интерфейс, быть удобным для использования, вроде того типа, который вы реализуете. Но, с другой стороны, вы теряете это свойство, как бы я назвал это универсальной способностью? Таким образом, вы не можете повторно использовать этот тип, у нас есть пример обычной монеты в качестве другой монеты, потому что существуют разные типы, и поэтому всегда лучше использовать общие, готовые решения. Но если вы хотите увидеть, как реализованы интерфейсы, взгляните на пример обычной монеты. Сомневаюсь, что кто-нибудь когда-нибудь им воспользуется, но, может быть, кто-нибудь и найдется.
Вопрос № 5: Каковы, по вашему мнению, недостатки языка программирования Move?
Тодд:Ага. Я думаю, что мы как бы интересным образом затрагиваем некоторые из них, я имею в виду, что есть недостатки вещей, которыми я недоволен, и, как, Боже мой, почему мы так и не удосужились добавить, вы знаете, X, Y, функция Z? В языке по-прежнему отсутствуют некоторые базовые вещи, или, по крайней мере, то, что я считаю справедливым, поэтому я считаю, что при этом преимуществе большинство языков, на которых вы программируете, имеют некоторую форму косвенных вызовов, у вас есть какая-то форма косвенности. И если вы программируете на rust, у вас есть черта, которую вы программируете на Java, у вас есть различные интерфейсы или другие вещи, которые вы можете делать. А у нас этого просто нет. Там нет динамики, диспетчеризация не является косвенной. Потому что то, что вы видите, это то, что вы получаете в своем модуле. И это особенность в том, вы получаете действительно надежные гарантии в отношении своего кода и можете доказать в своем коде то, что в противном случае не смогли бы доказать формально. Недостатком является то, что вы должны по-другому думать о том, как вы размещаете свой код. Вы знаете, модуль с монетами великолепен, но это не так, если бы вы работали на другом языке, вы бы, наверное, не настроили код таким образом.
Таким образом, уровень выразительности одинаков, он просто немного отличается, вес и шаблоны программирования, которые вы должны использовать. Так что я бы сказал, что недостатком здесь является то, что для того, чтобы получить такую силу и эти сильные гарантии, вы должны программировать немного по-другому. но я думаю об этом, как о вождении по другой стороне дороги. Как в Великобритании, вы едете по левой стороне дороги, а в США — по правой, и они оба работают. Просто ваша мышечная память в плане вождения, вероятно, будет немного другой, и у вас будут моменты, когда вы будете психовать, например, о Боже, я еду не по той стороне дороги. но вам просто нужно сесть и успокоить себя, что вы все еще сможете добраться туда, куда хотите. Просто нужно быть немного осторожнее. Я не думаю немного иначе, чем вы, возможно, думали раньше.
Вопрос № 6: Как бы вы внедрили DNS в Move?
Дамир: Наш ответ на это таков: мы никогда не будем это внедрять, потому что нам это не нужно. Реальная проблема, которую обычно задают люди, заключается в таких местах, как Solidity, потому что Solidity — это эталонный язык смарт-контрактов. Это изменится, но на данный момент у вас может быть хеш-карта с помощью центральной хэш-карты, в которой говорится, что этот IP-адрес является этим доменным именем, и наоборот, и вы можете пойти в одно место и проверить множество данных в хэш-карте. . Это рассматривалось как одна из основных проблем Move.
У вас не может быть централизованного хранилища, потому что это будет очень дорого. Движение потеряет все свои свойства и станет чрезвычайно медленным. Любое изменение, которое вы сделаете, повлияет на всю хеш-карту. Если бы у вас был миллион записей, и вы изменили или добавили одну, вам пришлось бы снова переписать 1 000 001 запись.
Проблема DNS — это то, что мы не решили, но вы всегда можете найти способ реализовать ее. Как сказал Тодд, вам нужно изменить свое мышление. Вам нужно изменить свою парадигму. Вы всегда можете хранить кучу объектов. Он не будет таким программируемым, как вы обычно привыкли, например, когда вы используете хэш-карту для создания результата адреса или имени DNS веб-сайта.
Это будет что-то другое, и может потребоваться больше инструментов вне цепочки, но в итоге вы получите более эффективный, более масштабируемый результат, но мы стараемся не иметь огромных централизованных хранилищ данных в цепочке, потому что это неэффективно.
Move получает большую часть прибыли от своей децентрализации, когда все активы распределяются по разным адресам, а не объединяются.
Тодд: Чаще всего нам задают такие вопросы: «Я сделал это в Solidity, как мне сделать это в Move?». Ответ: вы этого не делаете, потому что вам это не нужно. Вы должны размещать свой код по-другому. Вы не централизуете все записи для ваших NFT на одной карте.
Вместо этого у вас есть отдельные объекты NFT, и последующие эффекты этих решений означают, что вам просто нужно немного по-другому думать о том, как вы программируете. Например, вы должны программировать в стиле каждого ресурса и не думать о том, как бы я это сделал, имея возможность просматривать весь мир одновременно.
Вопрос № 7. Каковы возможности конфиденциальности в Move? Существуют ли ограничения конфиденциальности, которые вы можете ввести в Move?
Дамир: Вы бы не ожидали от языка, который вы ожидаете от серверной части, потому что M производит байт-код. Этот байт-код может быть создан в обычном виде. Его можно закодировать в другом месте, и вы можете использовать перемещение Mo VM внутри какой-либо платформы, которая преобразует их код в схему Zuki, которую никто никогда не прочитает, если у них нет проверенного ключа и проверяющего ключа.
Это не проблема языка, и не следует относиться к этому так, потому что мы всегда можем закодировать некоторые данные вне цепочки и передать их в Move, а затем вернуть те же закодированные данные. Оно будет приватным, потому что никто не знает исходных данных.
С другой стороны, если нам просто нравится перемещать виртуальную машину и нравится, насколько приватными являются байт-коды, она менее приватна, чем Solidity, байт-код перемещения чище, ее легче декодировать, ее удобнее использовать и в целом лучше, если вы разработчик, работающий над этим. байт-код. С Solidity, если вы получаете контрактный API, вы обычно не можете торговать им, потому что он закодирован странным образом.
У вас много разных направлений компилятора вы не знаете что это было. Конечно, наверняка есть какие-то компиляторы солидности, но обычно к солидности кода относятся как к чему-то вроде AFU, чего вы никогда не получите. В то время как с Move, вы также можете увидеть это в нашем проводнике, каждая программа получает своего рода depi, я имею в виду частично, вы всегда можете видеть подписи, вы всегда можете видеть типы, поэтому все, что происходит с Move, прозрачно, вы можете все проверить это происходит, даже код укуса.
Тодд: Ага. Итак, позвольте мне запрыгнуть туда, я думаю, это все, что вы говорили о Дамире.
Вы знаете, одна из целей Move была поставлена. Язык кода VI, у нас есть надежные гарантии на уровне кода VI, например, есть система типов для кода VI, но все ваши правила актива и редкости, которые гарантируют, что ваши объекты или ваши типы обрабатываются так же, как и за деньги, эти гарантии проверяются на уровне кода VI.
Таким образом, любой мог написать язык программирования или код велосипеда и получить те же гарантии, иначе они были бы привязаны к таким же гарантиям. И когда мы говорим о возможности просматривать все и все подобные сигнатурные функции, которые хранятся в цепочке на уровне байкера, мы называем это своего рода безопасным конвейером компиляции, поэтому, когда мы думаем о программах Move как исходный язык и другой исходный язык могут сделать другой выбор, но язык не добавляет никаких абстракций, которых на самом деле нет на уровне велосипедного кода.
Это не означает, что нет таких функций, которые не тестируются, и есть некоторые аннотации и спецификации для проверки, они существуют только на уровне исходного языка, но когда мы говорим о сигнатурах функций, они точно то же самое на уровне велосипедного кода. И это действительно важно, потому что это означает, что любые гарантии, которые у вас есть в исходном языке, присутствуют на уровне обслуживания. Поэтому, если вы пытаетесь сделать что-то незаконное или неправильное с типом, вы хотите убедиться, что поведение все еще присутствует на уровне байкера, чтобы вы не получали выразительности, пытаясь напрямую взаимодействовать с кодом байка.
Так что это действительно то, о чем мы говорим; безопасная компиляция. Что у нас есть такой же уровень гарантий в дальнейшем. Я думаю, что это важно упомянуть, когда мы говорим о просмотре кода в цепочке.
Вопрос № 8: Итак, Move предлагает уникальную функцию для NFT, но есть ли что-то уникальное для DeFi, чего нет в других языках?
Тодд: Я бы сказал, что система типов не делает ничего уникального для NFT, она делает что-то уникальное для активов. Просто оказалось, что NFT не так интересны с технической точки зрения. На самом деле они представляют собой воплощение правил поведения вещей с предметами реального мира.
Дамир: [Движение] очень быстрое. Он просто предоставляет гарантии безопасности для всего, что вы держите. Он обеспечивает неспособность кого-либо искать ваши активы, изменять ваше состояние, что-то отнимать у вас. Так что вы всегда в безопасности, если у вас есть что-то. У вас есть гарантии безопасности, и единственная проблема, с которой вы можете столкнуться, заключается в том, что максимальное целое число, которое мы поддерживаем, равно u128. Мы думаем о добавлении поддержки u120, u56, но большой вопрос, нужны они нам или нет. Кроме того, вы получаете все, что вам нужно. Вы можете работать с математикой. Вы можете безопасно работать с активами, и, наконец, с Sui вы можете делать это децентрализованно и с большими объемами транзакций.
Спасибо, что настроились на наш язык программирования Move AMA! Если у вас есть какие-либо отзывы о том, как проводились AMA, не стесняйтесь обращаться к [email protected] с вашим мнением. Мы всегда стремимся стать лучше.
Узнать больше о Sui
Стройте вместе с нами!!
Мы в восторге от того, что ждет нас в будущем, и приглашаем создателей и строителей присоединиться к нам .