Недавно мы поговорили с Сэмом Блэкширом, техническим директором Mysten Labs и создателем языка программирования Move, о том, почему он разработал Sui Move, новый язык программирования смарт-контрактов, о возможностях, которые Sui может расширить, и о влиянии децентрализованных технологий на создание преимуществ. получателя.
Вот содержание этого интервью:
**Вопрос 1. Во-первых, можете ли вы дать общее представление о том, что такое язык программирования, на какие качества больше всего обращают внимание разработчики при выборе языка программирования и что побуждает вас разрабатывать собственный язык программирования? **
Язык программирования — это всего лишь инструмент для удобного, безопасного, эффективного и понятного взаимодействия с компьютером, и для компьютеров это особенно важно. Мы не можем общаться с компьютерами на естественном языке, потому что весь смысл естественного языка в том, чтобы быть богатым и выразительным. Когда вы используете немного другой тон или выбираете несколько иные способы выражения слов, ваше предложение или абзац могут иметь совершенно другое значение.
**В языках программирования самое главное — иметь точно определенную семантику. **Когда вы пишете программу, вы знаете, что она будет делать. Если вы внесете в него небольшие изменения, вы знаете, куда пойдут эти изменения. Это должно поддерживаться на нескольких уровнях, например, вы можете писать код на исходном языке, у него есть смысл, а затем он переводится в другие формы представления, тогда он также должен иметь то же значение, пока не достигнет машины. то же самое касается модулей обработки.
** Я думаю, что языки программирования по своей природе являются предметно-ориентированными или специфичными для конкретных задач, в отличие от естественных языков. ** В противном случае, используя только один язык программирования, вы можете делать все. Но причина существования нескольких языков программирования в том, что вы не можете быть хороши во всех областях. Они пытаются нацелиться на конкретные проблемные области и сосредоточиться на решении этих проблем. В качестве примера, если вы посмотрите на язык программирования Rust, который мы используем для написания блокчейна Sui и большей части другой системной работы, которую мы выполняем в Mysten, он фокусируется на написании кода, который является быстрым и производительным при сохранении безопасности. Он дает вам доступ к низкоуровневым деталям, таким как память, структуры потоков или параллелизм, но не позволяет совершать ошибки, как в предыдущих языках, таких как C или C++.
Так что история Move очень похожа на эту. Когда я его создал, я не собирался создавать новый язык. Вы упомянули ранее, что разработчики ищут в языке. Они спрашивают: «*Подходит ли этот язык для того, чего я пытаюсь достичь?». Но я думаю, что, возможно, более важно: «*У этого языка большое сообщество? Имеется ли много баз данных? Много ли их используют программисты? есть ли хорошие образовательные ресурсы? *" Это очень важно, поэтому планка для создания нового языка должна быть очень высокой, даже если сам язык лучше, но если он не имеет этих факторов, то его преимущество бессмысленно. Создать большое и динамичное сообщество с нуля очень сложно.
**Q2、****Можете ли вы рассказать больше о разработке Move? **
** Движение было создано в рамках проекта Facebook Libra. ** Моя задача в то время заключалась не в том, чтобы создать новый язык, а в том, чтобы «*Весам нужны смарт-контракты, поэтому выясните, что нам следует делать». Я смотрел на все виды вещей. Можем ли мы использовать Solidity в EVM? Должны ли мы взять обычный язык общего назначения, такой как WASM или JVM, и использовать его для Libra? Или мы должны создать свой собственный?
Решение создать что-то свое было основано на исследовании существующих смарт-контрактов, понимании того, что пытались сделать программисты, и где те или иные языки помогли им, а где подвели. Мой вывод состоит в том, что во многих случаях существующие языки смарт-контрактов их подводят.
Это видно из плохих показателей безопасности Solidity, но, что более важно, эти смарт-контракты не являются очень традиционными типами программ. Solidity — это не язык, созданный для того, что люди делают сейчас. Я не критикую его, потому что это первый язык смарт-контрактов, который еще не знает, что люди хотят с ним делать. Как только вы увидите, что люди пытаются с ним сделать, я думаю, станет ясно, что вам нужен другой набор абстракций и инструментов программирования, которых нет в языке Solidity.
Так что эти смарт-контракты очень просты, они в основном делают две вещи. Они определяют типы активов, в том числе правила, когда активы могут быть переданы, что вы можете с ними делать, кто может их читать и кто может писать на них**. **** И проверьте политику управления доступом, чтобы определить, кто владеет активом, кому разрешено его использовать и кому разрешено с ним работать. **Все вращается вокруг активов, и вы хотите, чтобы эти активы имели те же атрибуты, что и физические активы. Если я что-то передам тебе, то это должно быть у тебя, а у меня больше не будет.
**В смарт-контрактах есть понятие права собственности и передачи права собственности, но на компьютере все это просто биты и байты, которые можно свободно копировать. ** И знаете, этих понятий не существует в реальном мире. Итак, вам нужен язык, который дает вам хорошие абстракции о собственности и гомогенизации. Так же, как в реальном мире, но без принуждения программистов изобретать его заново. Вам нужны базовые гарантии безопасности.
Это то, что делает Move и почему мы создали этот новый язык. Эти задачи являются фундаментальными для программирования смарт-контрактов. Их трудно воссоздать на других языках, включая существующие языки смарт-контрактов, и мы хотим спроектировать весь язык вокруг предоставления этих основных функций, чтобы программисты могли безопасно и эффективно писать код без необходимости писать какой-то код каждый раз, когда им нужно заново изобретать колесо.
**Q3、****Суй использует вариант движения под названием Суй-движение. Чем были вызваны эти изменения? Какие функции Sui Move идеально подходят для создания продуктов в Web3? **
Эти изменения были вызваны несколькими факторами, одним из которых была цель первоначального проекта Libra по созданию совместимой платежной сети. Итак, мы попытались спроектировать Move (как язык общего назначения. Но мы также сделали некоторые вещи сознательно, потому что Libra хочет иметь ограничения. Одна из важных вещей заключается в том, что они не хотят, чтобы люди могли отправлять определенные активы на в любом месте. Они хотят, чтобы люди явно создавали учетную запись и устанавливали некоторые правила при создании учетной записи, например, владелец учетной записи должен пройти проверку KYC. Или за создание учетной записи может взиматься плата, или это может быть только создано небольшим человеком с разрешением на создание учетной записи. Некоторые люди создают учетные записи. Поскольку вся цель Весов состоит в том, чтобы производить соответствующие платежи и совместимые смарт-контракты, существуют эти ограничения. Но в более общем мире Web3 все наоборот. не хотите быть совместимым на базовом уровне, Это концепция смарт-контрактов. Вы хотите, чтобы все было как можно более бесплатным, вполне возможно отправить что-то на любой адрес. Тогда вам не следует создавать явную учетную запись, потому что это заблокирует различные варианты использования, это важный фактор.
Еще один фактор заключается в том, что, хотя мы сосредоточились на активах в Move, в то время в Libra мы не думали о том, как перенести активы в саму транзакцию. Таким образом, когда вы переходите на уровень транзакций, у вас все еще есть этот API, где вы вводите числа, логические значения и вещи, которые не являются активами, а затем в Move вы используете эти числа для снятия активов со счетов и других действий. Оказывается, большая часть кода, который вы запускаете, — это неприятная бухгалтерия по удалению этого, удалению этого, удалению чего-то еще, и хорошо, у меня есть все активы, которые я хочу. Вот они, в моей студии, и теперь я могу начать делать что-то значимое. А затем, в конце процесса, вы можете сказать: «Хорошо, верните эти активы в этот аккаунт, верните их обратно в этот аккаунт, реорганизуйте их.
В Sui мы продумали, если каждая программа начинается и заканчивается таким образом, можем ли мы ее абстрагировать? Таким образом, логика обработки транзакции сделает это за программиста, а с точки зрения программиста он просто имеет готовые активы и сразу же приступает к интересной работе. Это **** объектно-ориентированная модель данных, существующая в Sui. ** В исходном Move у нас была модель данных на основе учетных записей, активы хранились под учетными записями, и программистам приходилось извлекать их явным образом. В Sui, когда они входят в часть транзакции Move, активы уже были получены средой выполнения Sui. Это удобнее для программистов, потому что им не нужно делать все это до и после учета, а также позволяет нам определить, можем ли мы запустить одну транзакцию параллельно с другой, не выполняя ее на самом деле.Секретный соус Суи для горизонтального масштабирования и несколько других вещей более эффективно.
Мы также проделали другую действительно интересную работу, например, использовали объектно-ориентированную модель данных для программируемых блоков транзакций. Это несколько техническая тема, которую я буду рад подробно обсудить. Но эти два фактора были основными причинами расхождения с первоначальным Move.
Q4、** Не могли бы вы поделиться дополнительной информацией о программируемых блоках транзакций и их функциях? **
Мне нравится использовать аналогию, чтобы объяснить, что другие блокчейны похожи на фуд-корт в торговом центре. Вы хотите мороженое, вы идете к киоску с мороженым, достаете кредитную карту и платите. Но если вы решите, что все еще хотите гамбургер, вы идете в стойку с гамбургерами и платите снова. Я не обжора, но если бы я хотел съесть восемь вещей, мне пришлось бы совершить восемь отдельных транзакций. ** Там, где Sui больше похож на шведский стол, каждая сделка — это больше, чем просто одна вещь. После того, как вы заплатили за шведский стол, вы можете многое сделать без дополнительных затрат. ** У вас может быть мороженое, у вас могут быть гамбургеры, вы можете все это смешать.
Чтобы сделать эту концепцию немного более конкретной, в простом случае, если вы отправляете 100 транзакций для чеканки 100 NFT, вы можете отправить транзакцию, которая чеканит 100 NFT. Такая стоимость почти такая же, как стоимость чеканки NFT. Вы также можете выполнять неоднородную упаковку транзакций, например, первая транзакция в блоке берет персонажа Марио из вашего мультиподписного кошелька, а вторая транзакция запрашивает Марио, который затем позволяет вам играть в игру. Если вы выиграете игру и получите трофей, возможно, третья сделка поместит трофей в шкаф трофеев, которым вы поделитесь с друзьями. **Что здорово, так это то, что программируемые блоки транзакций позволяют программистам писать код таким образом, что игре не нужно знать ни о кошельках с мультиподписью, ни о том, как хранится Марио, ни о вашем шкафу с трофеями или о том, как он реализован. . **
**Программируемые блоки транзакций состоят из транзакций с входными и выходными объектами. ** Если вам нужен входной объект, вы можете получить этот объект, не заботясь о том, откуда он взялся, и передать его вывод объекту, который в нем нуждается, а также не заботясь о том, куда он передается. В других блокчейнах связь более сильная, поэтому игры должны интегрироваться с мультиподписными кошельками и шкафчиками для трофеев, или все они должны реализовывать какой-то общий интерфейс и иметь более сильную связь. **Sui значительно упрощает так называемые ad-hoc комбинации. ** Например, если каналы совпадают, мы можем сделать это за одну транзакцию.
Q5、** Каковы преимущества программируемых блоков транзакций для пользователей? **
Для пользователей преимущества программируемых блоков транзакций включают более низкие затраты на газ, поскольку вы можете упаковать все операции в одну транзакцию, а не выполнять отдельные транзакции. Кроме того, требуется меньше разрешений. Если вы используете систему, которая требует утверждения транзакции, вам нужно сделать это только один раз, и тогда все это будет сделано за один раз. Другим преимуществом является атомарность, если вы хотите сделать три разные вещи и хотите, чтобы третья операция была успешной только в том случае, если первые две операции завершатся успешно, если эти операции должны быть независимыми транзакциями, то вы не можете заставить это произойти. Однако, если вы можете поместить их все в одну транзакцию, вы легко добьетесь этого.
**В6, ****Я слышал, что вы и другие говорили о разработке на 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 — отличный язык для пакета первого релиза, но для типа, который я собираюсь изменить, я собираюсь добавить некоторые поля, я собираюсь добавить некоторые функции, я собираюсь это сделать таким образом, чтобы он был целостным, но не противоречил использованию исходного пакета. Чтобы работать таким образом, чтобы пользователи доверяли, это становится очень сложной проблемой. Многое из того, что мы делаем, это смотрим на это и определяем, какие функции на уровне языка мы можем добавить, чтобы дать программистам гибкость для расширения, сохраняя при этом доверие пользователей к исходному коду.
** Мы работаем над многими функциями, связанными с этим, особенно над перечислениями. **Мы также много работаем над улучшением взаимодействия Move с интерфейсным кодом. Мы часто шутим, что типичное приложение Sui на 5% состоит из кода Move и на 95% из внешнего кода. Поэтому мы очень сосредоточены на этих 95%. Мы потратили много времени на разговоры о Move, но также много внимания уделили тому, чтобы сделать другие части более эффективными и упростить соединения. В общем, мы очень сосредоточены на том, чтобы приложение состояло из Move для большей безопасности. В то же время, как нам сделать эти 95% кода понятными как для программистов Move, так и для программистов, не использующих Move.
Посмотреть Оригинал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Отец языка Move: язык смарт-контрактов Sui Move подходит для продуктов Web3
Происхождение: Sui Network
Недавно мы поговорили с Сэмом Блэкширом, техническим директором Mysten Labs и создателем языка программирования Move, о том, почему он разработал Sui Move, новый язык программирования смарт-контрактов, о возможностях, которые Sui может расширить, и о влиянии децентрализованных технологий на создание преимуществ. получателя.
Вот содержание этого интервью:
**Вопрос 1. Во-первых, можете ли вы дать общее представление о том, что такое язык программирования, на какие качества больше всего обращают внимание разработчики при выборе языка программирования и что побуждает вас разрабатывать собственный язык программирования? **
Язык программирования — это всего лишь инструмент для удобного, безопасного, эффективного и понятного взаимодействия с компьютером, и для компьютеров это особенно важно. Мы не можем общаться с компьютерами на естественном языке, потому что весь смысл естественного языка в том, чтобы быть богатым и выразительным. Когда вы используете немного другой тон или выбираете несколько иные способы выражения слов, ваше предложение или абзац могут иметь совершенно другое значение.
**В языках программирования самое главное — иметь точно определенную семантику. **Когда вы пишете программу, вы знаете, что она будет делать. Если вы внесете в него небольшие изменения, вы знаете, куда пойдут эти изменения. Это должно поддерживаться на нескольких уровнях, например, вы можете писать код на исходном языке, у него есть смысл, а затем он переводится в другие формы представления, тогда он также должен иметь то же значение, пока не достигнет машины. то же самое касается модулей обработки.
** Я думаю, что языки программирования по своей природе являются предметно-ориентированными или специфичными для конкретных задач, в отличие от естественных языков. ** В противном случае, используя только один язык программирования, вы можете делать все. Но причина существования нескольких языков программирования в том, что вы не можете быть хороши во всех областях. Они пытаются нацелиться на конкретные проблемные области и сосредоточиться на решении этих проблем. В качестве примера, если вы посмотрите на язык программирования Rust, который мы используем для написания блокчейна Sui и большей части другой системной работы, которую мы выполняем в Mysten, он фокусируется на написании кода, который является быстрым и производительным при сохранении безопасности. Он дает вам доступ к низкоуровневым деталям, таким как память, структуры потоков или параллелизм, но не позволяет совершать ошибки, как в предыдущих языках, таких как C или C++.
Так что история Move очень похожа на эту. Когда я его создал, я не собирался создавать новый язык. Вы упомянули ранее, что разработчики ищут в языке. Они спрашивают: «*Подходит ли этот язык для того, чего я пытаюсь достичь?». Но я думаю, что, возможно, более важно: «*У этого языка большое сообщество? Имеется ли много баз данных? Много ли их используют программисты? есть ли хорошие образовательные ресурсы? *" Это очень важно, поэтому планка для создания нового языка должна быть очень высокой, даже если сам язык лучше, но если он не имеет этих факторов, то его преимущество бессмысленно. Создать большое и динамичное сообщество с нуля очень сложно.
**Q2、****Можете ли вы рассказать больше о разработке Move? **
** Движение было создано в рамках проекта Facebook Libra. ** Моя задача в то время заключалась не в том, чтобы создать новый язык, а в том, чтобы «*Весам нужны смарт-контракты, поэтому выясните, что нам следует делать». Я смотрел на все виды вещей. Можем ли мы использовать Solidity в EVM? Должны ли мы взять обычный язык общего назначения, такой как WASM или JVM, и использовать его для Libra? Или мы должны создать свой собственный?
Решение создать что-то свое было основано на исследовании существующих смарт-контрактов, понимании того, что пытались сделать программисты, и где те или иные языки помогли им, а где подвели. Мой вывод состоит в том, что во многих случаях существующие языки смарт-контрактов их подводят.
Это видно из плохих показателей безопасности Solidity, но, что более важно, эти смарт-контракты не являются очень традиционными типами программ. Solidity — это не язык, созданный для того, что люди делают сейчас. Я не критикую его, потому что это первый язык смарт-контрактов, который еще не знает, что люди хотят с ним делать. Как только вы увидите, что люди пытаются с ним сделать, я думаю, станет ясно, что вам нужен другой набор абстракций и инструментов программирования, которых нет в языке Solidity.
Так что эти смарт-контракты очень просты, они в основном делают две вещи. Они определяют типы активов, в том числе правила, когда активы могут быть переданы, что вы можете с ними делать, кто может их читать и кто может писать на них**. **** И проверьте политику управления доступом, чтобы определить, кто владеет активом, кому разрешено его использовать и кому разрешено с ним работать. **Все вращается вокруг активов, и вы хотите, чтобы эти активы имели те же атрибуты, что и физические активы. Если я что-то передам тебе, то это должно быть у тебя, а у меня больше не будет.
**В смарт-контрактах есть понятие права собственности и передачи права собственности, но на компьютере все это просто биты и байты, которые можно свободно копировать. ** И знаете, этих понятий не существует в реальном мире. Итак, вам нужен язык, который дает вам хорошие абстракции о собственности и гомогенизации. Так же, как в реальном мире, но без принуждения программистов изобретать его заново. Вам нужны базовые гарантии безопасности.
Это то, что делает Move и почему мы создали этот новый язык. Эти задачи являются фундаментальными для программирования смарт-контрактов. Их трудно воссоздать на других языках, включая существующие языки смарт-контрактов, и мы хотим спроектировать весь язык вокруг предоставления этих основных функций, чтобы программисты могли безопасно и эффективно писать код без необходимости писать какой-то код каждый раз, когда им нужно заново изобретать колесо.
**Q3、****Суй использует вариант движения под названием Суй-движение. Чем были вызваны эти изменения? Какие функции Sui Move идеально подходят для создания продуктов в Web3? **
Эти изменения были вызваны несколькими факторами, одним из которых была цель первоначального проекта Libra по созданию совместимой платежной сети. Итак, мы попытались спроектировать Move (как язык общего назначения. Но мы также сделали некоторые вещи сознательно, потому что Libra хочет иметь ограничения. Одна из важных вещей заключается в том, что они не хотят, чтобы люди могли отправлять определенные активы на в любом месте. Они хотят, чтобы люди явно создавали учетную запись и устанавливали некоторые правила при создании учетной записи, например, владелец учетной записи должен пройти проверку KYC. Или за создание учетной записи может взиматься плата, или это может быть только создано небольшим человеком с разрешением на создание учетной записи. Некоторые люди создают учетные записи. Поскольку вся цель Весов состоит в том, чтобы производить соответствующие платежи и совместимые смарт-контракты, существуют эти ограничения. Но в более общем мире Web3 все наоборот. не хотите быть совместимым на базовом уровне, Это концепция смарт-контрактов. Вы хотите, чтобы все было как можно более бесплатным, вполне возможно отправить что-то на любой адрес. Тогда вам не следует создавать явную учетную запись, потому что это заблокирует различные варианты использования, это важный фактор.
Еще один фактор заключается в том, что, хотя мы сосредоточились на активах в Move, в то время в Libra мы не думали о том, как перенести активы в саму транзакцию. Таким образом, когда вы переходите на уровень транзакций, у вас все еще есть этот API, где вы вводите числа, логические значения и вещи, которые не являются активами, а затем в Move вы используете эти числа для снятия активов со счетов и других действий. Оказывается, большая часть кода, который вы запускаете, — это неприятная бухгалтерия по удалению этого, удалению этого, удалению чего-то еще, и хорошо, у меня есть все активы, которые я хочу. Вот они, в моей студии, и теперь я могу начать делать что-то значимое. А затем, в конце процесса, вы можете сказать: «Хорошо, верните эти активы в этот аккаунт, верните их обратно в этот аккаунт, реорганизуйте их.
В Sui мы продумали, если каждая программа начинается и заканчивается таким образом, можем ли мы ее абстрагировать? Таким образом, логика обработки транзакции сделает это за программиста, а с точки зрения программиста он просто имеет готовые активы и сразу же приступает к интересной работе. Это **** объектно-ориентированная модель данных, существующая в Sui. ** В исходном Move у нас была модель данных на основе учетных записей, активы хранились под учетными записями, и программистам приходилось извлекать их явным образом. В Sui, когда они входят в часть транзакции Move, активы уже были получены средой выполнения Sui. Это удобнее для программистов, потому что им не нужно делать все это до и после учета, а также позволяет нам определить, можем ли мы запустить одну транзакцию параллельно с другой, не выполняя ее на самом деле.Секретный соус Суи для горизонтального масштабирования и несколько других вещей более эффективно.
Мы также проделали другую действительно интересную работу, например, использовали объектно-ориентированную модель данных для программируемых блоков транзакций. Это несколько техническая тема, которую я буду рад подробно обсудить. Но эти два фактора были основными причинами расхождения с первоначальным Move.
Q4、** Не могли бы вы поделиться дополнительной информацией о программируемых блоках транзакций и их функциях? **
Мне нравится использовать аналогию, чтобы объяснить, что другие блокчейны похожи на фуд-корт в торговом центре. Вы хотите мороженое, вы идете к киоску с мороженым, достаете кредитную карту и платите. Но если вы решите, что все еще хотите гамбургер, вы идете в стойку с гамбургерами и платите снова. Я не обжора, но если бы я хотел съесть восемь вещей, мне пришлось бы совершить восемь отдельных транзакций. ** Там, где Sui больше похож на шведский стол, каждая сделка — это больше, чем просто одна вещь. После того, как вы заплатили за шведский стол, вы можете многое сделать без дополнительных затрат. ** У вас может быть мороженое, у вас могут быть гамбургеры, вы можете все это смешать.
Чтобы сделать эту концепцию немного более конкретной, в простом случае, если вы отправляете 100 транзакций для чеканки 100 NFT, вы можете отправить транзакцию, которая чеканит 100 NFT. Такая стоимость почти такая же, как стоимость чеканки NFT. Вы также можете выполнять неоднородную упаковку транзакций, например, первая транзакция в блоке берет персонажа Марио из вашего мультиподписного кошелька, а вторая транзакция запрашивает Марио, который затем позволяет вам играть в игру. Если вы выиграете игру и получите трофей, возможно, третья сделка поместит трофей в шкаф трофеев, которым вы поделитесь с друзьями. **Что здорово, так это то, что программируемые блоки транзакций позволяют программистам писать код таким образом, что игре не нужно знать ни о кошельках с мультиподписью, ни о том, как хранится Марио, ни о вашем шкафу с трофеями или о том, как он реализован. . **
**Программируемые блоки транзакций состоят из транзакций с входными и выходными объектами. ** Если вам нужен входной объект, вы можете получить этот объект, не заботясь о том, откуда он взялся, и передать его вывод объекту, который в нем нуждается, а также не заботясь о том, куда он передается. В других блокчейнах связь более сильная, поэтому игры должны интегрироваться с мультиподписными кошельками и шкафчиками для трофеев, или все они должны реализовывать какой-то общий интерфейс и иметь более сильную связь. **Sui значительно упрощает так называемые ad-hoc комбинации. ** Например, если каналы совпадают, мы можем сделать это за одну транзакцию.
Q5、** Каковы преимущества программируемых блоков транзакций для пользователей? **
Для пользователей преимущества программируемых блоков транзакций включают более низкие затраты на газ, поскольку вы можете упаковать все операции в одну транзакцию, а не выполнять отдельные транзакции. Кроме того, требуется меньше разрешений. Если вы используете систему, которая требует утверждения транзакции, вам нужно сделать это только один раз, и тогда все это будет сделано за один раз. Другим преимуществом является атомарность, если вы хотите сделать три разные вещи и хотите, чтобы третья операция была успешной только в том случае, если первые две операции завершатся успешно, если эти операции должны быть независимыми транзакциями, то вы не можете заставить это произойти. Однако, если вы можете поместить их все в одну транзакцию, вы легко добьетесь этого.
**В6, ****Я слышал, что вы и другие говорили о разработке на 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 — отличный язык для пакета первого релиза, но для типа, который я собираюсь изменить, я собираюсь добавить некоторые поля, я собираюсь добавить некоторые функции, я собираюсь это сделать таким образом, чтобы он был целостным, но не противоречил использованию исходного пакета. Чтобы работать таким образом, чтобы пользователи доверяли, это становится очень сложной проблемой. Многое из того, что мы делаем, это смотрим на это и определяем, какие функции на уровне языка мы можем добавить, чтобы дать программистам гибкость для расширения, сохраняя при этом доверие пользователей к исходному коду.
** Мы работаем над многими функциями, связанными с этим, особенно над перечислениями. **Мы также много работаем над улучшением взаимодействия Move с интерфейсным кодом. Мы часто шутим, что типичное приложение Sui на 5% состоит из кода Move и на 95% из внешнего кода. Поэтому мы очень сосредоточены на этих 95%. Мы потратили много времени на разговоры о Move, но также много внимания уделили тому, чтобы сделать другие части более эффективными и упростить соединения. В общем, мы очень сосредоточены на том, чтобы приложение состояло из Move для большей безопасности. В то же время, как нам сделать эти 95% кода понятными как для программистов Move, так и для программистов, не использующих Move.