Углубленный диалог с главным ученым Mysten Labs: От теории к практике, как Суй решает проблему масштабируемости сети?

Недавно мы взяли интервью у Джорджа Данезиса, чтобы обсудить сложность и масштабируемость инфраструктуры Sui, а также то, как система обработки транзакций Sui обеспечивает высокопроизводительную сеть. Джордж Данезис — соучредитель и главный научный сотрудник Mysten Labs (и первоначальный сотрудник Суи), а также профессор в области разработки безопасности и конфиденциальности в UCL.

Ниже приводится содержание этого интервью:

**Q1: Вы из академической сферы, можете ли вы рассказать о своей исследовательской сфере? **

Я профессор Университетского колледжа Лондона (UCL), и мои исследования сосредоточены на безопасности и конфиденциальности в широком смысле. В начале 20-го века я провел немало исследований одноранговых и анонимных систем, многие из которых были большими распределенными системами с упором на хранение. Поскольку весь блокчейн стал более ориентированным на исполнение, особенно в лице Ethereum, я заинтересовался распределенными реестрами и блокчейнами, а также тем, как выполнять смарт-контракты. Его неразрешенный характер знаком мне по моей работе над ранними одноранговыми системами. Поэтому моя исследовательская группа в UCL решила выяснить, как создавать более производительные системы. Мы основали Chainspace, чтобы коммерциализировать некоторые из наших идей, а команду приобрела Facebook. Затем мы помогли Facebook найти решение для масштабирования блокчейна Libra/Diem. Но когда предложение не получило прогресса, я ушел и продолжил искать другие возможности для реализации концепции высокопроизводительного блокчейна.

**Q2: Вы все еще профессор, как вы думаете, в чем разница между применением и исследованием? **

На самом деле особой разницы нет. Когда мы проводим исследования, мы рассматриваем все возможности для достижения конкретной цели, например, создание высокопроизводительного блокчейна или конкретной функции. Конечно, при создании блокчейна или выборе конкретной функции для использования в реальной системе нам приходится выбирать одну из этих возможностей. Нам приходится постоянно выносить суждения о том, какие из всех этих хороших идей на самом деле наиболее полезны для людей? Что именно ищут люди? Каковы узкие места при внедрении блокчейна? Что мешает людям добиться того, чего они хотят? При построении системы вы по-прежнему рассматриваете все возможности и пытаетесь понять, что возможно из научной литературы, а затем выбираете то, что наиболее актуально. Это не просто интеллектуальный интерес, а создание ценности для пользователей.

**В3: Как вы определяете, какие проблемы нужно решить, переходя от теории к практическому применению? **

Основная проблема, которую я решаю в своих исследованиях, — это масштабирование различных функций блокчейна. Я фокусируюсь на системных аспектах блокчейна, то есть на том, как увеличить пропускную способность транзакций и уменьшить задержку. Проблема в этом отношении очевидна: всякий раз, когда мы видим, что определенный контракт на Ethereum становится очень популярным, платформа Ethereum не может выдержать такой большой объем транзакций, возникает перегрузка транзакций, а комиссии стремительно растут. Каждый раз, когда блокчейн добивался успеха, мы видели, как он обрабатывает больше транзакций, чем сейчас. Очевидно, что проблема в том, что в этих блокчейнах недостаточно возможностей для того, что люди хотят делать. Это не только в наших умах, мы видели, как это происходило снова и снова. Какое-то время это считалось достойным вызовом не только в моей группе, но и фактически все академическое сообщество работало над блокчейном, все решали эту проблему по-разному. Сейчас разработано довольно много технологий, расширяющих возможности блокчейна для решения этих проблем. Но в то время, как мы все знаем, многие люди подошли к этому по-разному.

**Q4: Сеть L2 — это предложенный людьми способ решения проблемы масштабирования. В чем разница и выгода от создания новой сети L1, такой как Sui? **

L2 — решение для масштабирования в экосистеме Ethereum. Но для разработчиков приложений работа с сетями L2 представляет собой некоторую сложность. Когда сеть L2 пытается взаимодействовать с Ethereum, должно произойти соединение, хотя это справедливо для любых отношений L2/L1. Состояние, представляющее монету, актив или другой контент в L1, должно быть отражено в L2, и наоборот. Помимо этого, L2 должен иметь какой-то механизм, чтобы L1 мог проверять все, что в нем происходит. Но это только первая часть: любой актив, существующий на L1, необходимо перенести на L2, на L2 должна произойти какая-то активность, а затем каким-то образом перенести актив обратно на L1. Это очень хлопотно.

Для взаимозаменяемых активов, таких как токены, это соединение проходит относительно гладко, поскольку у людей есть две учетные записи и связующее программное обеспечение. Но для более общих активов это работает не так хорошо. Чтобы реально использовать сеть L2 на Ethereum для разработки более сложных приложений, чем токены, вам необходимо иметь смарт-контракты с обеих сторон: один для чеканки (mint), а другой для сжигания (burn). Им приходится переключаться между двумя разными экосистемами, что является индивидуальным действием для каждого контракта. Вы не можете просто сказать: я собираюсь создать сеть L2, забрать все активы, сделать то, что хочу, и вернуть их обратно, такой концепции не существует. Это ручной процесс и очень подвержен ошибкам. Так что это не очень хороший опыт. Представьте, что у вас есть активы в нескольких разных сетях L2, и у вас есть специальные смарт-контракты в разных сетях L2. Каждый раз, когда вы хотите работать с каким-либо состоянием, находящимся в другой сети L2, вам необходимо выполнить мостик обратно к L1, а затем обратно к L2. Невозможно просто сказать: я только что сделал что-то в этом блокчейне, а потом собираюсь сделать что-то еще в другом блокчейне, и мне не нужно думать о том, на каком L1 или L2 это находится. Все это здесь, и прямо сейчас оно у меня в руках, и я готов совершать больше транзакций в любом штате, который захочу посетить. Вот почему распространение состояния по сети L2 — плохой опыт. Перемещение активов между разными цепочками сложно и очевидно для пользователей. Вот почему сети L2 никогда меня не интересовали.

Другой пример — Cosmos, у которого очень интересная экосистема, использующая другой подход масштабирования за счет использования разных блокчейнов для разных приложений. Мы можем иметь разные скорости транзакций в разных цепочках и соединять активы между цепочками, когда нам нужно работать между разными приложениями, но это также сталкивается с одной и той же проблемой. Каждый раз, когда вы хотите использовать другое приложение, вам сначала нужно выполнить операцию моста, которая тонкая и очевидна для пользователя, а затем вы можете использовать это приложение и вернуться обратно. Вы обнаружите, что тратите больше времени на перемещение активов из одной сети в другую, чем на то, что вы действительно хотите сделать.

На Sui наше решение — построить большую базу данных, которая, по сути, содержит все состояние, реплицируемое валидаторами. После завершения транзакции все состояние в той же базе данных можно использовать для выполнения следующей транзакции, и пользователям не придется постоянно перемещать состояния активов между уровнями L1 и L2.

**В5: Sui Lutris является основой протокола Sui. Каковы его ключевые инновации, которые позволяют Sui иметь высокую пропускную способность и низкую задержку? **

Sui Lutris состоит из двух ключевых идей: (1) для многих операций в блокчейне консенсус на самом деле не требуется; (2) когда вам действительно нужен консенсус, существует метод с очень высокой пропускной способностью, который объединит эти два метода. Sui Lutris является ядром распределенной системы Sui, гарантируя, что два разных узла проверки, следующие протоколу, никогда не будут находиться в несогласованном состоянии при проведении транзакций в распределенной сети. Не бывает ситуации, когда один валидатор думает, что вы потратили монету и отправили ее Алисе, а другой валидатор думает, что та же монета на самом деле была отправлена Бобу.

🌟 Самостоятельная Выдра:

Два разных пути: один не требует консенсуса (быстрый путь), а другой требует консенсуса (путь консенсуса). Когда объект, которым вы хотите манипулировать, принадлежит только вам, например, ваш собственный персонаж NFT и шляпа, которую вы хотите объединить, чтобы ваш персонаж мог носить шляпу, теоретически никто другой не должен иметь возможности манипулировать ими. В этих случаях Sui использует быстрый путь, что означает, что вы можете манипулировать своими собственными объектами, вы получаете завершенность транзакции, не дожидаясь консенсуса, транзакция гарантированно произойдет, и шляпа лежит на вашей голове NFT.

Но в некоторых случаях транзакции затрагивают не только объекты, принадлежащие вам, они используются многими людьми. Например, если существует аукцион, на котором продаются маленькие шляпы, этот тип аукциона будет представлен в Sui как общий объект. Люди могут делать ставки, и шляпу получает тот, кто предложит самую высокую цену. Этот тип аукциона представляет собой объект, который не принадлежит одному объекту. Каждый должен иметь возможность делать ставки, делиться и обновлять состояние последней ставки. Эти типы операций требуют дополнительного консенсуса. Sui Lutris позволяет вам владеть общими объектами и выполнять с ними транзакции, позволяя вам владеть другими объектами, изменять состояние общих объектов или создавать новые общие объекты. Это позволяет обоим путям сосуществовать и взаимодействовать между эксклюзивными объектами, принадлежащими конкретному человеку, или общими объектами, которыми пользуются несколько человек.

Эти два разных пути имеют разные преимущества. Быстрый путь для эксклюзивных объектов имеет чрезвычайно низкую задержку, занимает менее секунды, очень быстр и широко масштабируется. Путь консенсуса имеет более высокую задержку, обычно более секунды, и довольно высокую пропускную способность, однако его сложнее масштабировать, чем первый путь. На Sui те, кто действительно управляет ончейн-приложениями с миллионами транзакций в день, обычно используют первый путь и в значительной степени структурируют свои приложения так, чтобы наибольшее количество транзакций в основном происходило с эксклюзивными объектами, а не сделкой по долевому участию. С другой стороны, протоколы, выполняющие сложную работу (например, DeFi), часто практикуют второй тип транзакций, поскольку для выполнения операций они должны объединять заявки или ликвидность от множества разных людей.

**В6. Могут ли разработчики приложений Sui разрабатывать свои приложения так, чтобы воспользоваться преимуществами быстрого пути? **

Да, конечно. Я думаю, что это основная работа дизайнера приложений-расширений. Разработчики смарт-контрактов имеют полный контроль над тем, являются ли объекты, которыми они манипулируют в рамках контракта, эксклюзивными или общими объектами одного объекта в любой момент времени. Один из приемов масштабирования вашего приложения в Sui — убедиться, что большинство операций выполняются в основном над эксклюзивными объектами, поскольку Sui может управлять любым количеством операций с очень низкой задержкой, что является приятным опытом. Операции, необходимые для игры, должны выполняться в этой категории, и их задержка очень мала по сравнению с операциями, которые необходимо опосредовать через общее состояние и общие объекты. После нажатия транзакция может быть мгновенно завершена в сети.

Разработчик смарт-контрактов имеет полный контроль над этим и может точно указать, какие транзакции относятся к каждой категории. Конечно, первая версия контракта может рассматривать все как общее состояние, и все будет проходить через консенсусный путь с более высокой задержкой, но из-за необходимости масштабирования разработчикам необходимо учитывать, насколько далеко они могут это сделать. .

**В7: Какую роль в этом играет программируемый блок транзакций? **

Программируемые блоки транзакций могут работать как по быстрому пути, так и по пути консенсуса. Если блок программируемых транзакций включает только ваш эксклюзивный объект, это означает, что вы можете выполнять несколько операций за одну операцию в цепочке. Например, предположим, что вы представляете приложение CEX, в котором множество людей покупают и продают разные монеты. Вы можете провести транзакцию в цепочке, которая концептуально соответствует тому, что люди покупают и продают. Но поскольку вы являетесь биржей, все они принадлежат вам, поэтому одновременно можно провести тысячу транзакций, а это самый быстрый путь. С другой стороны, если некоторые объекты в программируемом блоке транзакций являются общими, то вводится путь консенсуса, и задержка будет немного выше, не меньше секунды, а несколько секунд.

**Q8: Основная сеть работает уже более 100 дней. Подтвердила ли производительность Суй вашу гипотетическую теорию исследования? Есть ли что-нибудь, что вас удивило? **

Есть несколько вещей, которые подтверждают замысел Суи, но есть и вещи, которые дают пищу для размышлений. Во-первых, когда объем транзакций особенно велик, даже в особый момент ежедневный объем транзакций даже превышает 60 миллионов, большая часть из которых находится в быстром пути. Sui Lutris очень масштабируем и имеет очень низкую задержку. До тех пор неясно, будет ли кто-нибудь использовать этот путь, но когда требуются большие объемы транзакций и низкая задержка, он используется, и он прекрасно работает! Это легко увидеть, это метод. В те дни в Sui было больше транзакций, чем во всех других блокчейнах вместе взятых. Это интересное подтверждение того, что дизайн Суи верен.

Между тем, сообщество Суй сочло этот быстрый путь немного сложным. Поскольку владельцам объектов приходится в некоторой степени управлять порядком операций над своими объектами, иногда что-то может пойти не так. Иногда они могут даже использовать библиотеку, которая им не помогает, а сама библиотека содержит ошибки, поэтому иногда объекты блокируются. Обычно они открываются в конце дня, в конце эпохи, но это не лучший опыт. Люди, разрабатывающие смарт-контракты, могут быть напуганы этим, опасаясь возникновения ошибок, что не позволяет им в полной мере воспользоваться возможностями низкой задержки и масштабируемости. Разрабатывается целый ряд технологий, позволяющих тем, кто заблокировал объекты по ошибке, быстро разблокировать их в течение нескольких секунд. Поэтому, если вы попытаетесь использовать быстрый путь, произойдет ошибка и ваш объект будет заблокирован, вы можете немедленно использовать консенсусный путь, чтобы разблокировать его, не дожидаясь окончания эпохи.

И, как ни странно, речь идет не только о том, чтобы избежать ошибок, это позволяет разработчикам быстро выражать множество других вещей; существуют потенциальные методы, при которых некоторые объекты не принадлежат только одной стороне. Возможно, есть объект, которым мы с вами владеем совместно, потому что он общий, и обычно транзакции с этим объектом должны проходить через консенсусный путь. Однако, если бы у Суи был способ быстро разблокировать объекты, разработчики могли бы попытаться ускорить транзакции. В случае, если мы с вами совершаем транзакцию с одним и тем же объектом в одно и то же время, система будет заблокирована и не сможет решить, какая транзакция произойдет следующей, а затем Суй сможет разблокировать ее и пройти по пути консенсуса. сделать это общим и решить его. Но этого не произойдет, если люди сознательно не попытаются конкурировать. Как только Sui получит возможность разблокировать объекты, он сможет быстро перемещаться по объектам, принадлежащим нескольким людям. Это игра, которая пытается передать как можно больший объем транзакций по быстрому пути, и это одна из вещей, которая разрабатывается, чтобы помочь сообществу строителей.

**Q9: Можете ли вы рассказать подробнее, что в данный момент вызывает блокировку объекта? **

Причина, по которой не требуется консенсус, чтобы сообщить Sui последовательность операций, которые должны произойти, когда объект принадлежит вам, заключается в том, что никто другой не может работать с вашим объектом. Sui рассчитывает на то, что вы сообщите системе, что действие A произойдет первым, действие B произойдет следующим, а действие C произойдет последним. Система все еще должна проверить, что ABC видны всем в одном и том же порядке. Система реализована через распределенный протокол, который просто проверяет, все ли мы увидели ABC по очереди. Вопрос в том, допустили ли вы ошибку или ваше программное обеспечение допустило ошибку. Например, если ваш телефон контролирует ваш актив, а ваш компьютер — ваш актив, ваш телефон сообщает, что сначала произошло событие А, а компьютер говорит, что первым произошло событие Б. Вы неправильно сортируете две разные вещи. Это противоречие. В этом случае Суй сказал бы: «Ну, человек, которого я поручил рассказать мне последовательность, похоже, дал мне две противоречивые вещи, поэтому я не знаю, что делать. Я не знаю, как это исправить». Потому что Sui Эта проблема обычно решается путем консенсуса. Но здесь вы пытаетесь использовать быстрый путь. Поэтому Суй поднял руку и сказал: «Хорошо, здесь ошибка».

Первоначальное предположение заключалось в том, что это будет происходить не очень часто, но оказывается, что это происходит довольно часто, поскольку люди используют разные устройства или пытаются одновременно выполнить несколько транзакций с одним и тем же объектом. В настоящее время, когда эти объекты заблокированы, Суй ждет конца эпохи, чтобы разблокировать их, что очень тревожно. Представьте себе, что если бы ваши активы были непригодны для использования в течение дня, это могло бы стать серьезной проблемой.

Так что теперь Суй нужно развиваться, чтобы предпринимать правильные действия, когда что-то заблокировано. Если сущность, которой поручено отдать правильный приказ, дает двусмысленный приказ, Суй разрешит всю ситуацию путем консенсуса. Это произойдет через несколько секунд, а не в конце эпохи.

**Q10: Большая часть ваших исследований связана с конфиденциальностью. Что вы думаете о том, как публичные блокчейны могут наилучшим образом сбалансировать прозрачность, отслеживаемость и конфиденциальность? **

В общедоступной цепочке вопрос о том, как сбалансировать прозрачность, отслеживаемость и конфиденциальность, во многом связан с приложениями, и моя точка зрения на конфиденциальность заключается в том, что то, что должно оставаться конфиденциальным, во многом зависит от самого приложения. Например, в Sui разработчикам приложений имеет смысл разрабатывать контракты, защищающие конфиденциальность их пользователей. Поскольку некоторые люди просто хотят разрабатывать игры, возможно, вопросы конфиденциальности не так уж и важны. Некоторые люди хотят осуществлять финансовые транзакции с помощью блокчейна, и конфиденциальность может вызывать больше беспокойства, но в то же время существуют и другие проблемы регулирования. Итак, позиция Суи заключается в том, что мы предоставим вам хорошую платформу, и вам необходимо обеспечить конфиденциальность на этой платформе.

Чтобы помочь людям обеспечить конфиденциальность, Sui предоставляет некоторую криптографическую поддержку, которая может быть полезна им при разработке смарт-контрактов. Одним из наиболее важных из них является возможность проверять доказательства с нулевым разглашением на Sui. Существует встроенная функция, которая проверяет одну из наиболее широко используемых и понятных схем — схему Groth16, разработанную моим коллегой Йенсом Гротом. Это означает, что, по сути, дизайнеры приложений могут проверять определенные события вне цепочки, не раскрывая, что это за события. Это фундаментальный строительный блок для создания целого класса приложений, обеспечивающих конфиденциальность, которые сохраняют некоторое состояние вне цепочки, но внутри цепочки вы можете проверить, что все, что происходит вне цепочки, правильно.

Разработчики приложений решают, какая защита конфиденциальности нужна их приложениям, и используют эту встроенную поддержку для комбинирования стратегий шифрования внутри цепочки, вне цепочки и внутри цепочки для решения проблем конфиденциальности, с которыми они могут столкнуться.

**В11: Есть ли в Sui дополнительная встроенная поддержка конфиденциальности? **

Сообщество думает о поддержке, необходимой разработчикам для написания смарт-контрактов в среде, более дружественной к конфиденциальности. Доказательство с нулевым разглашением является одним из них. Некоторые люди могут подумать, что Sui нужны более общие математические или криптографические функции в цепочке. Нам бы хотелось, чтобы разработчики смарт-контрактов предоставили отзывы о том, чего не хватает, и существует целый класс других методов, которые можно использовать для сохранения конфиденциальности, таких как многосторонние вычисления или доверенное оборудование. В этих направлениях разработаны разные блокчейны, требующие очень сложных дополнительных систем. В сообществе должно быть достаточно доказательств того, что людям нужны эти технологии, поскольку они представляют собой некоторые фундаментальные изменения в архитектуре Суи. Но если сообщество хочет двигаться в этом направлении, существует процесс предложения способов добавить защиту конфиденциальности.

**Q12: Как, по вашему мнению, будет развиваться Суй в ближайшие 6–12 месяцев? **

Это зависит от того, какие приложения люди создают на Sui, и в краткосрочной перспективе многие улучшения коснутся тех приложений, которые люди на самом деле создают. В очень долгосрочной перспективе, согласно стандартам блокчейна, от 6 до 12 месяцев можно рассматривать как очень длительный период.Мы улучшим протокол Sui Lutris, чтобы добиться более низкой задержки, упрощения протоколов и улучшения масштабирования Sui. Кроме того, это сделает экономику более эффективной, позволяя узлам валидатора работать на более ограниченном оборудовании и использовать существующее оборудование для фактического выполнения транзакций, а не выполнять криптографию или другие накладные расходы на блокчейн. Это то, что мы ожидаем увидеть.