На днях мы провели интервью с известным экспертом в области Блокчейн, чтобы обсудить сложность и масштабируемость инфраструктуры Sui, а также то, как система обработки транзакций Sui способствует созданию высокопроизводительной сети. Этот эксперт является профессором в области безопасности и конфиденциальности в одном из известных университетов.
Следующее содержание интервью:
В1: Вы из академической сферы, можете рассказать о ваших исследовательских приоритетах?
Я профессор известного университета, моя исследовательская работа в общем называется безопасностью и конфиденциальностью. В начале 20 века я провел достаточно много исследований в области пиринговых и анонимных систем, многие из которых представляют собой крупные распределенные системы, ориентированные на хранение. Когда весь Блокчейн стал более ориентирован на исполнение, особенно с учетом Ethereum, я заинтересовался распределенными реестрами и Блокчейном, а также тем, как исполнять смарт-контракты. Я был хорошо знаком с их безлицензионными характеристиками из своей ранней работы с пиринговыми системами. Таким образом, моя исследовательская группа в университете начала изучать, как построить более производительные системы. Мы основали компанию, чтобы коммерциализировать некоторые наши идеи, и позже команда была куплена одной крупной технологической компанией. Затем мы помогли этой компании предложить решения для масштабирования Блокчейна. Но когда решения не достигли прогресса, я ушел, продолжая искать другие возможности для реализации идеи высокопроизводительного Блокчейна.
В2: Вы все еще профессор, как вы считаете, в чем разница между приложением и исследованием?
На самом деле нет особой разницы. Когда мы проводим исследование, мы учитываем все возможности для достижения конкретной цели, например, построение высокопроизводительного Блокчейн или определенной функции. Конечно, при построении Блокчейн или выборе конкретной функции для использования в реальной системе, мы должны выбрать один из возможных вариантов. Мы должны постоянно принимать решения, какой из всех этих хороших идей на самом деле наиболее полезен для людей? Что люди ищут? Какие препятствия существуют для принятия Блокчейн? Что мешает людям реализовать то, что они хотят сделать? При построении системы вы все равно будете рассматривать все возможности и пытаться понять возможные ситуации из академической литературы, а затем выбирать наиболее актуальные. Это не просто интерес к знаниям, но и создание ценности для пользователей.
Вопрос 3: Как вы определаете, какие проблемы нужно решать, переходя от теории к практическому применению?
Основная проблема, которую я решаю в своем исследовании, заключается в том, как расширить различные функции Блокчейна. Я сосредотачиваюсь на системных аспектах Блокчейна, таких как, как увеличить пропускную способность транзакций и снизить задержку. Проблемы в этой области очевидны: каждый раз, когда мы видим, что какой-то контракт на Эфириуме становится очень популярным, платформа Эфириум не может справиться с таким большим объемом транзакций, происходят задержки в транзакциях, рост комиссий. Каждый раз, когда Блокчейн добивается успеха, мы видим, что объем транзакций, который он может обрабатывать, превышает существующие возможности. Поэтому очевидно, что проблема заключается в недостаточной мощности для удовлетворения того, что люди хотят делать на этих Блокчейнах. Это не просто наши мысли; мы снова и снова видим, как это происходит. На протяжении некоторого времени это считалось ценным вызовом, исследованием не только в моей команде, но на самом деле во всей академической среде, которая изучает Блокчейн, и все ищут разные способы решения этой проблемы. В настоящее время уже разработано достаточно много технологий для расширения возможностей Блокчейна, чтобы справиться с этими вызовами. Но в то время было известно, что многие люди решают это разными способами.
Q4: L2-сети являются способом решения проблемы масштабируемости, предложенным людьми. Каковы различия и преимущества по сравнению с созданием новых L1-сетей, таких как Sui?
L2 является решением для масштабирования в экосистеме Ethereum. Однако для разработчиков приложений использование сети L2 может быть несколько затруднительным. Когда сеть L2 пытается взаимодействовать с Ethereum, необходимо проводить мостовые операции, хотя это касается любых отношений L2/L1. Состояние, представляющее монету, актив или что-либо еще в L1, должно быть отражено в L2 и наоборот. Кроме того, L2 должна иметь некоторые механизмы, чтобы L1 могла проверять все, что происходит внутри. Но это лишь первая часть, а именно любые активы, существующие в L1, необходимо перенести в L2, должны произойти некоторые действия на L2, а затем активы должны быть возвращены в L1 каким-то образом. Это довольно хлопотно.
Что касается токенов как заменяемых активов, то данная мостовая операция проходит довольно успешно, поскольку у людей есть два аккаунта и промежуточное программное обеспечение для мостов. Однако для более общих активов это не так эффективно. Чтобы фактически использовать L2 сеть на Ethereum для разработки более сложных приложений, чем токены, вам нужны смарт-контракты с обеих сторон: один для выпуска, другой для уничтожения. Они должны перемещаться между двумя различными экосистемами, что является индивидуальной операцией для каждого контракта. Вы не можете просто сказать: «Я создам L2 сеть, затем заберу все активы и буду делать с ними, что хочу, а потом верну их обратно» — такой концепции не существует. Это ручной процесс, который очень легко ошибиться. Поэтому это не очень хороший опыт. Представьте, что у вас есть активы на нескольких различных L2 сетях, и на каждой из этих L2 сетей есть свои индивидуальные смарт-контракты. Каждый раз, когда вы хотите выполнить операцию с состоянием, находящимся на другой L2 сети, вам необходимо пройти через мост обратно к L1, а затем снова вернуться к L2. Вы не можете просто сказать: «Я только что сделал что-то на этой блокчейн-сети, а теперь я хочу сделать что-то другое на другой блокчейн-сети, и мне не нужно беспокоиться о том, в какой L1 или L2 это происходит». Всё здесь, у меня это в руках, и я готов совершать больше транзакций с любым состоянием, к которому хочу получить доступ. Вот почему опыт распределения состояния между L2 сетями плохой. Перемещение активов между различными цепями очень сложно и очевидно для пользователей. Вот почему L2 сети никогда по-настоящему не вызывали у меня интереса.
Еще один пример — Cosmos, который имеет очень интересную экосистему и использует другой подход к масштабированию, а именно использование разных Блоков для различных приложений. Мы можем проводить разные сделки на разных цепочках с разной скоростью, когда необходимо осуществлять операции между разными приложениями, можно мостить активы между цепочками, но это также сталкивается с той же проблемой. Каждый раз, когда вы хотите использовать разные приложения, вам сначала нужно провести операцию мостирования, что является тонким и очевидным моментом для пользователей, а затем вы можете использовать это приложение и мостить обратно. Вы обнаружите, что тратите больше времени на перенос активов с одной цепочки на другую, чем на то, что вы действительно хотите сделать.
На Sui наша схема заключается в создании крупной базы данных, которая на самом деле содержит все состояния, реплицируемые проверенными узлами. Как только вы завершаете транзакцию, все состояния в одной и той же базе данных могут быть использованы для выполнения следующей транзакции, и пользователям не нужно постоянно перемещать состояние активов между L1 и L2.
Q5: Sui Lutris является основой протокола Sui, какое его ключевое новшество позволяет Sui обладать высокой пропускной способностью и низкой задержкой?
Sui Lutris состоит из двух ключевых идей: (1) для многих операций в Блокчейне на самом деле не требуется консенсус; (2) когда вам действительно нужен консенсус, существует метод с очень высокой пропускной способностью, который сочетает эти два подхода. Sui Lutris является ядром распределенной системы Sui, обеспечивая, чтобы при выполнении транзакций в распределенной сети два разных узла верификации, следуя протоколу, никогда не находились в несогласованном состоянии. Таким образом, не возникнет ситуации, когда один узел верификации считает, что вы потратили один coin и отправили его Алисе, в то время как другой узел верификации считает, что тот же coin на самом деле отправлен Бобу.
Два разных пути: один не требует консенсуса (быстрый путь), другой требует консенсуса (путь консенсуса). Когда объектом, с которым вы хотите работать, является только ваш собственный объект, например, ваш собственный NFT персонаж и шляпа, которую вы хотите с ним объединить, чтобы ваш персонаж мог носить шляпу, теоретически другие не должны с ними взаимодействовать. В этих случаях Sui использует быстрый путь, который означает, что вы можете управлять своими объектами, вы можете получить окончательность транзакции без ожидания консенсуса, гарантируя, что транзакция произойдет, и шляпа окажется на голове вашего NFT.
Но в некоторых случаях сделки касаются не только объектов, принадлежащих вам, но и объектов, которыми делятся многие люди. Например, если есть аукцион, продающий маленькие шляпки, этот тип аукциона в Sui представлен как общий объект. Люди могут делать ставки, и тот, кто предложит наивысшую цену, выигрывает шляпку. Этот аукцион является объектом, который не принадлежит отдельному субъекту, каждый должен иметь возможность делать ставки, делиться и обновлять информацию о последних ставках, и такие операции требуют дополнительного консенсуса. Sui Lutris позволяет вам иметь общие объекты и проводить с ними сделки, что позволяет вам владеть другими объектами, изменять состояние общего объекта или создавать новые общие объекты. Он позволяет сосуществовать двум путям и взаимодействовать между индивидуальными объектами, принадлежащими конкретным лицам, и общими объектами, которыми делятся несколько человек.
Эти два разных пути имеют разные преимущества. Быстрый путь к эксклюзивным объектам имеет очень низкую задержку, время меньше одной секунды, что очень быстро, и его можно широко масштабировать. Задержка консенсусного пути, напротив, выше, обычно превышает одну секунду, а емкость также довольно велика, но, по сравнению с первым путем, его сложнее масштабировать. На Sui те, кто действительно продвигает приложения на цепочке с миллионами транзакций каждый день, обычно используют первый путь и в значительной степени структурируют свои приложения так, чтобы выполнять большинство транзакций преимущественно с эксклюзивными объектами, а не с общими транзакциями. С другой стороны, протоколы, выполняющие сложные задачи (например, DeFi), обычно используют второй тип транзакций, потому что они должны объединять предложения или ликвидность от многих различных людей для выполнения операций.
Вопрос 6: Могут ли разработчики приложений на Sui создавать свои приложения для использования быстрого пути?
Да, совершенно верно. Я считаю, что это основная работа дизайнеров расширенных приложений. Разработчики смарт-контрактов могут полностью контролировать, являются ли объекты, с которыми они работают в контракте, на данный момент единственными собственниками или общими объектами. Один из приемов расширения приложений в Sui заключается в том, чтобы убедиться, что большинство операций в основном выполняются на единственных объектах, так как Sui может управлять многими операциями, которые вам нужны, с очень низкой задержкой, что является отличным опытом. Операции, необходимые для игр, должны выполняться в этой категории, в отличие от операций, которые требуют медиации через общее состояние и общие объекты, задержка которых очень низка. Как только вы нажимаете, транзакция может быть немедленно завершена в сети.
Разработчики смарт-контрактов имеют полный контроль над этим, они в основном могут точно указать, какие транзакции относятся к каждой категории. Конечно, первая версия контракта может рассматривать все как общие состояния, и все будет проходить через пути консенсуса с высокой задержкой, но по мере необходимости расширения разработчики должны учитывать, в какой степени это можно сделать без этих частей.
Q7: Какую роль играют программируемые транзакционные блоки в этом?
Программируемые交易区块 могут работать на быстром или консенсусном пути. Если программируемый交易区块 касается только ваших эксклюзивных объектов, это означает, что вы можете выполнить несколько операций в одном блоке на цепи. Например, предположим, что вы - приложение для торговой платформы, где многие люди покупают и продают различные coins, вы можете провести одну сделку на цепи, концептуально соответствующую тому, что покупают и продают люди. Но поскольку вы являетесь биржей, все они принадлежат вам, поэтому вы можете одновременно урегулировать тысячу сделок, что является быстрым путем. С другой стороны, если некоторые объекты в программируемом交易区块 являются общими, это переходит в консенсусный путь, где задержка будет немного выше, не менее одной секунды, а несколько секунд.
Q8: Прошло более 100 дней с момента запуска основной сети, подтвердили ли результаты Sui ваши исследовательские теории? Есть ли что-то, что вас удивило?
Несколько вещей подтвердили дизайн Sui, но есть и некоторые вещи, которые заставляют задуматься. Одна из них заключается в том, что в моменты особенно высокой активности объем транзакций ежедневно превышал 60 миллионов, причем большая часть транзакций осуществлялась по быстрому пути. Sui Lutris очень масштабируем и имеет очень низкую задержку. До этого момента было неясно, будут ли кто-либо использовать этот путь, но когда требуется большое количество транзакций и низкая задержка, он был использован и очень эффективно! Это легко увидеть, это именно этот подход. В те дни объем транзакций Sui превышал все остальные.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
20 Лайков
Награда
20
5
Поделиться
комментарий
0/400
DefiEngineerJack
· 07-14 08:05
на самом деле, eth как игрушка по сравнению с параллельным выполнением sui
Посмотреть ОригиналОтветить0
ProposalDetective
· 07-13 03:33
Снова вижу старого знакомого, это не был ли большой бык из лаборатории протоколов?
Посмотреть ОригиналОтветить0
ProbablyNothing
· 07-13 03:33
Есть перспектива, действуй решительно.
Посмотреть ОригиналОтветить0
TokenDustCollector
· 07-13 03:10
Sui тоже так закручивается
Посмотреть ОригиналОтветить0
Hash_Bandit
· 07-13 03:07
мех... еще один академик говорит о масштабируемости. видел этот фильм раньше, в 2017 году, если честно.
Основатель Sui разбирает архитектуру высокопроизводительного Блокчейн: преимущества быстрого пути и пути Соглашения
На днях мы провели интервью с известным экспертом в области Блокчейн, чтобы обсудить сложность и масштабируемость инфраструктуры Sui, а также то, как система обработки транзакций Sui способствует созданию высокопроизводительной сети. Этот эксперт является профессором в области безопасности и конфиденциальности в одном из известных университетов.
Следующее содержание интервью:
В1: Вы из академической сферы, можете рассказать о ваших исследовательских приоритетах?
Я профессор известного университета, моя исследовательская работа в общем называется безопасностью и конфиденциальностью. В начале 20 века я провел достаточно много исследований в области пиринговых и анонимных систем, многие из которых представляют собой крупные распределенные системы, ориентированные на хранение. Когда весь Блокчейн стал более ориентирован на исполнение, особенно с учетом Ethereum, я заинтересовался распределенными реестрами и Блокчейном, а также тем, как исполнять смарт-контракты. Я был хорошо знаком с их безлицензионными характеристиками из своей ранней работы с пиринговыми системами. Таким образом, моя исследовательская группа в университете начала изучать, как построить более производительные системы. Мы основали компанию, чтобы коммерциализировать некоторые наши идеи, и позже команда была куплена одной крупной технологической компанией. Затем мы помогли этой компании предложить решения для масштабирования Блокчейна. Но когда решения не достигли прогресса, я ушел, продолжая искать другие возможности для реализации идеи высокопроизводительного Блокчейна.
В2: Вы все еще профессор, как вы считаете, в чем разница между приложением и исследованием?
На самом деле нет особой разницы. Когда мы проводим исследование, мы учитываем все возможности для достижения конкретной цели, например, построение высокопроизводительного Блокчейн или определенной функции. Конечно, при построении Блокчейн или выборе конкретной функции для использования в реальной системе, мы должны выбрать один из возможных вариантов. Мы должны постоянно принимать решения, какой из всех этих хороших идей на самом деле наиболее полезен для людей? Что люди ищут? Какие препятствия существуют для принятия Блокчейн? Что мешает людям реализовать то, что они хотят сделать? При построении системы вы все равно будете рассматривать все возможности и пытаться понять возможные ситуации из академической литературы, а затем выбирать наиболее актуальные. Это не просто интерес к знаниям, но и создание ценности для пользователей.
Вопрос 3: Как вы определаете, какие проблемы нужно решать, переходя от теории к практическому применению?
Основная проблема, которую я решаю в своем исследовании, заключается в том, как расширить различные функции Блокчейна. Я сосредотачиваюсь на системных аспектах Блокчейна, таких как, как увеличить пропускную способность транзакций и снизить задержку. Проблемы в этой области очевидны: каждый раз, когда мы видим, что какой-то контракт на Эфириуме становится очень популярным, платформа Эфириум не может справиться с таким большим объемом транзакций, происходят задержки в транзакциях, рост комиссий. Каждый раз, когда Блокчейн добивается успеха, мы видим, что объем транзакций, который он может обрабатывать, превышает существующие возможности. Поэтому очевидно, что проблема заключается в недостаточной мощности для удовлетворения того, что люди хотят делать на этих Блокчейнах. Это не просто наши мысли; мы снова и снова видим, как это происходит. На протяжении некоторого времени это считалось ценным вызовом, исследованием не только в моей команде, но на самом деле во всей академической среде, которая изучает Блокчейн, и все ищут разные способы решения этой проблемы. В настоящее время уже разработано достаточно много технологий для расширения возможностей Блокчейна, чтобы справиться с этими вызовами. Но в то время было известно, что многие люди решают это разными способами.
Q4: L2-сети являются способом решения проблемы масштабируемости, предложенным людьми. Каковы различия и преимущества по сравнению с созданием новых L1-сетей, таких как Sui?
L2 является решением для масштабирования в экосистеме Ethereum. Однако для разработчиков приложений использование сети L2 может быть несколько затруднительным. Когда сеть L2 пытается взаимодействовать с Ethereum, необходимо проводить мостовые операции, хотя это касается любых отношений L2/L1. Состояние, представляющее монету, актив или что-либо еще в L1, должно быть отражено в L2 и наоборот. Кроме того, L2 должна иметь некоторые механизмы, чтобы L1 могла проверять все, что происходит внутри. Но это лишь первая часть, а именно любые активы, существующие в L1, необходимо перенести в L2, должны произойти некоторые действия на L2, а затем активы должны быть возвращены в L1 каким-то образом. Это довольно хлопотно.
Что касается токенов как заменяемых активов, то данная мостовая операция проходит довольно успешно, поскольку у людей есть два аккаунта и промежуточное программное обеспечение для мостов. Однако для более общих активов это не так эффективно. Чтобы фактически использовать L2 сеть на Ethereum для разработки более сложных приложений, чем токены, вам нужны смарт-контракты с обеих сторон: один для выпуска, другой для уничтожения. Они должны перемещаться между двумя различными экосистемами, что является индивидуальной операцией для каждого контракта. Вы не можете просто сказать: «Я создам L2 сеть, затем заберу все активы и буду делать с ними, что хочу, а потом верну их обратно» — такой концепции не существует. Это ручной процесс, который очень легко ошибиться. Поэтому это не очень хороший опыт. Представьте, что у вас есть активы на нескольких различных L2 сетях, и на каждой из этих L2 сетей есть свои индивидуальные смарт-контракты. Каждый раз, когда вы хотите выполнить операцию с состоянием, находящимся на другой L2 сети, вам необходимо пройти через мост обратно к L1, а затем снова вернуться к L2. Вы не можете просто сказать: «Я только что сделал что-то на этой блокчейн-сети, а теперь я хочу сделать что-то другое на другой блокчейн-сети, и мне не нужно беспокоиться о том, в какой L1 или L2 это происходит». Всё здесь, у меня это в руках, и я готов совершать больше транзакций с любым состоянием, к которому хочу получить доступ. Вот почему опыт распределения состояния между L2 сетями плохой. Перемещение активов между различными цепями очень сложно и очевидно для пользователей. Вот почему L2 сети никогда по-настоящему не вызывали у меня интереса.
Еще один пример — Cosmos, который имеет очень интересную экосистему и использует другой подход к масштабированию, а именно использование разных Блоков для различных приложений. Мы можем проводить разные сделки на разных цепочках с разной скоростью, когда необходимо осуществлять операции между разными приложениями, можно мостить активы между цепочками, но это также сталкивается с той же проблемой. Каждый раз, когда вы хотите использовать разные приложения, вам сначала нужно провести операцию мостирования, что является тонким и очевидным моментом для пользователей, а затем вы можете использовать это приложение и мостить обратно. Вы обнаружите, что тратите больше времени на перенос активов с одной цепочки на другую, чем на то, что вы действительно хотите сделать.
На Sui наша схема заключается в создании крупной базы данных, которая на самом деле содержит все состояния, реплицируемые проверенными узлами. Как только вы завершаете транзакцию, все состояния в одной и той же базе данных могут быть использованы для выполнения следующей транзакции, и пользователям не нужно постоянно перемещать состояние активов между L1 и L2.
Q5: Sui Lutris является основой протокола Sui, какое его ключевое новшество позволяет Sui обладать высокой пропускной способностью и низкой задержкой?
Sui Lutris состоит из двух ключевых идей: (1) для многих операций в Блокчейне на самом деле не требуется консенсус; (2) когда вам действительно нужен консенсус, существует метод с очень высокой пропускной способностью, который сочетает эти два подхода. Sui Lutris является ядром распределенной системы Sui, обеспечивая, чтобы при выполнении транзакций в распределенной сети два разных узла верификации, следуя протоколу, никогда не находились в несогласованном состоянии. Таким образом, не возникнет ситуации, когда один узел верификации считает, что вы потратили один coin и отправили его Алисе, в то время как другой узел верификации считает, что тот же coin на самом деле отправлен Бобу.
Два разных пути: один не требует консенсуса (быстрый путь), другой требует консенсуса (путь консенсуса). Когда объектом, с которым вы хотите работать, является только ваш собственный объект, например, ваш собственный NFT персонаж и шляпа, которую вы хотите с ним объединить, чтобы ваш персонаж мог носить шляпу, теоретически другие не должны с ними взаимодействовать. В этих случаях Sui использует быстрый путь, который означает, что вы можете управлять своими объектами, вы можете получить окончательность транзакции без ожидания консенсуса, гарантируя, что транзакция произойдет, и шляпа окажется на голове вашего NFT.
Но в некоторых случаях сделки касаются не только объектов, принадлежащих вам, но и объектов, которыми делятся многие люди. Например, если есть аукцион, продающий маленькие шляпки, этот тип аукциона в Sui представлен как общий объект. Люди могут делать ставки, и тот, кто предложит наивысшую цену, выигрывает шляпку. Этот аукцион является объектом, который не принадлежит отдельному субъекту, каждый должен иметь возможность делать ставки, делиться и обновлять информацию о последних ставках, и такие операции требуют дополнительного консенсуса. Sui Lutris позволяет вам иметь общие объекты и проводить с ними сделки, что позволяет вам владеть другими объектами, изменять состояние общего объекта или создавать новые общие объекты. Он позволяет сосуществовать двум путям и взаимодействовать между индивидуальными объектами, принадлежащими конкретным лицам, и общими объектами, которыми делятся несколько человек.
Эти два разных пути имеют разные преимущества. Быстрый путь к эксклюзивным объектам имеет очень низкую задержку, время меньше одной секунды, что очень быстро, и его можно широко масштабировать. Задержка консенсусного пути, напротив, выше, обычно превышает одну секунду, а емкость также довольно велика, но, по сравнению с первым путем, его сложнее масштабировать. На Sui те, кто действительно продвигает приложения на цепочке с миллионами транзакций каждый день, обычно используют первый путь и в значительной степени структурируют свои приложения так, чтобы выполнять большинство транзакций преимущественно с эксклюзивными объектами, а не с общими транзакциями. С другой стороны, протоколы, выполняющие сложные задачи (например, DeFi), обычно используют второй тип транзакций, потому что они должны объединять предложения или ликвидность от многих различных людей для выполнения операций.
Вопрос 6: Могут ли разработчики приложений на Sui создавать свои приложения для использования быстрого пути?
Да, совершенно верно. Я считаю, что это основная работа дизайнеров расширенных приложений. Разработчики смарт-контрактов могут полностью контролировать, являются ли объекты, с которыми они работают в контракте, на данный момент единственными собственниками или общими объектами. Один из приемов расширения приложений в Sui заключается в том, чтобы убедиться, что большинство операций в основном выполняются на единственных объектах, так как Sui может управлять многими операциями, которые вам нужны, с очень низкой задержкой, что является отличным опытом. Операции, необходимые для игр, должны выполняться в этой категории, в отличие от операций, которые требуют медиации через общее состояние и общие объекты, задержка которых очень низка. Как только вы нажимаете, транзакция может быть немедленно завершена в сети.
Разработчики смарт-контрактов имеют полный контроль над этим, они в основном могут точно указать, какие транзакции относятся к каждой категории. Конечно, первая версия контракта может рассматривать все как общие состояния, и все будет проходить через пути консенсуса с высокой задержкой, но по мере необходимости расширения разработчики должны учитывать, в какой степени это можно сделать без этих частей.
Q7: Какую роль играют программируемые транзакционные блоки в этом?
Программируемые交易区块 могут работать на быстром или консенсусном пути. Если программируемый交易区块 касается только ваших эксклюзивных объектов, это означает, что вы можете выполнить несколько операций в одном блоке на цепи. Например, предположим, что вы - приложение для торговой платформы, где многие люди покупают и продают различные coins, вы можете провести одну сделку на цепи, концептуально соответствующую тому, что покупают и продают люди. Но поскольку вы являетесь биржей, все они принадлежат вам, поэтому вы можете одновременно урегулировать тысячу сделок, что является быстрым путем. С другой стороны, если некоторые объекты в программируемом交易区块 являются общими, это переходит в консенсусный путь, где задержка будет немного выше, не менее одной секунды, а несколько секунд.
Q8: Прошло более 100 дней с момента запуска основной сети, подтвердили ли результаты Sui ваши исследовательские теории? Есть ли что-то, что вас удивило?
Несколько вещей подтвердили дизайн Sui, но есть и некоторые вещи, которые заставляют задуматься. Одна из них заключается в том, что в моменты особенно высокой активности объем транзакций ежедневно превышал 60 миллионов, причем большая часть транзакций осуществлялась по быстрому пути. Sui Lutris очень масштабируем и имеет очень низкую задержку. До этого момента было неясно, будут ли кто-либо использовать этот путь, но когда требуется большое количество транзакций и низкая задержка, он был использован и очень эффективно! Это легко увидеть, это именно этот подход. В те дни объем транзакций Sui превышал все остальные.