Начать статью о сводном обзоре с таких тем, как «Что такое накопительный пакет» или «Зачем нам нужен накопительный пакет» — это все равно, что убить дядю Бена или расстрелять маму и папу Уэйна в каждой версии фильмов «Человек-паук» и «Бэтмен». То же самое, что и папа. Если вы читаете эту статью, я предполагаю, что у вас уже есть базовое понимание вышеуказанных вопросов. Здесь мы пропускаем дебаты между цепочкой приложений и объединением приложений и сразу переходим к теме.
Рост накопительных пакетов для конкретных приложений****Универсальные накопительные пакеты разочаровывают
Universal Rollup похожа на школьную систему в Индии (я уверен, что они имеют схожие характеристики с другими школьными системами, но у меня есть только непосредственный опыт работы с ней).
Спортсменам, певцам, математикам, мыслителям и экономистам необходимо пройти один и тот же процесс, чтобы получить проходной балл. Система не «предвзята» по отношению к какой-либо конкретной группе, но и не «справедлива» по отношению ко всем. Но эй, мы подружились! (Это будет важно позже).
Аналогично, для приложений в универсальном накопительном пакете узким местом является сама среда выполнения, поскольку накопительный пакет не может удовлетворить потребности каждого приложения в отдельности. Для каждого приложения может потребоваться разный тип оптимизации, и любые индивидуальные улучшения могут быть для них не оправданы. Однако если вы просто экспериментируете и хотите получить примерное представление, это наиболее удобный вариант. Кроме того, для некоторых приложений, например, для обычных студентов, это может быть правильным решением!
Сборный пакет для конкретного приложения сбивает с толку
Что ж, мой ребенок слишком спортивен для государственной школы, и ему нужна специальная подготовка. Нужно ли отдавать его в спортивную школу или стоит нанять личного тренера…
Сборку сложно четко классифицировать****Давайте сыграем в игру
Ниже приведены 8 конкретных накопительных пакетов приложений. Однако один элемент в каждой группе на самом деле не принадлежит этой группе. Можете ли вы сказать, какой именно?
Специфика приложения становится запутанным термином. Существуют определенные накопительные пакеты приложений, которые позволяют развертывать контракты поверх самих себя; существуют также некоторые специальные накопительные пакеты приложений, которые допускают развертывание контрактов, поскольку их виртуальные машины поддерживают это, но будут определенные ограничения; У них есть закрытые виртуальные машины или виртуальные машины отсутствуют. машины вообще и не поддерживают другие типы разработки.
Справедливо ли классифицировать их вместе?
Ответы на приведенное выше упражнение:
Группа 1: Celo — необычный вариант, поскольку он позволяет другим разработчикам создавать приложения, а другие разработчики могут использовать эти приложения напрямую. Другими проектами, которые следует рассмотреть в группе 1, являются Fuel-v1, Aevo, RhinoFi и т. д.
Группа 2: Loopring — странный выбор, поскольку это единственный специально созданный накопительный пакет, который можно использовать «из коробки», в то время как остальные представляют собой сети, оптимизированные для определенных функций, таких как конфиденциальность, NFT и TPS для развернутых на нем приложений. Эти функции может передаваться по наследству. Другими проектами, которые можно отнести к группе 2, являются «Кинто», «Крома», «Сеть общественных благ» и др.
Проблемы с развертыванием контрактов на модифицированных виртуальных машинах общего назначения
Эти виртуальные машины, на которых вы развертываете смарт-контракты, представляют собой не что иное, как полные по Тьюрингу конечные автоматы. Контракты, которые вы на них развертываете, только изменяют само состояние, но на самом деле не влияют на основные правила перехода состояний виртуальной машины. Rollup — это, по сути, виртуальная машина, на которой находится ваша бизнес-логика.
Ваша бизнес-логика отделена от функций перехода состояний Rollup.
Я также называю это «парадигмой смарт-контрактов для создания приложений», потому что вы развертываете дополнительную логику поверх виртуальной машины. Rollup не занимается «напрямую» проверкой логики приложения. Виртуальная машина — это накопительный пакет, а не ваше приложение.
Конечно, вы являетесь единственным владельцем виртуальной машины, ваше приложение — единственным гражданином, и вы можете постоянно улучшать саму базу, чтобы сделать ее подходящей для вашего приложения. Вы можете продолжать совершенствовать функцию перехода состояний (STF) и добавлять/удалять коды операций для повышения производительности приложения, но приложение остается независимым и ограничивается самой виртуальной машиной.
Как Lamborghini Urus, тянущий Lamborghini Huracan.
Отдельное приложение для конкретного приложения Rollup может работать лучше. Что, если вы продолжите улучшать STF так, что его область действия будет становиться все меньше и меньше, чтобы соответствовать бизнес-логике вашего приложения? В конце концов, когда вы станете сильнее, STF сойдутся в точке, где бизнес-логика и STF перекроются, и в этот момент вы поймете... о, подождите минутку!
Рождение микро-агрегата
Таким образом, Micro-Rollup — это не что иное, как Rollup, в котором функцией перехода состояния приложения является сама бизнес-логика.
Приложение становится накопительным, состоянием можно управлять любым возможным способом в любой среде выполнения, а правила перехода состояний можно применять непосредственно во время выполнения приложения. Приложение можно настроить без каких-либо ограничений. Доказательства привязаны к вашей бизнес-логике, а не к машине, что делает ваше приложение легким.
Micro-Rollup не имеет ограничений с точки зрения опыта разработчиков. Вы можете создавать их, используя любые инструменты, которые вам нравятся, поскольку они не ограничиваются виртуальными машинами. Они выглядят как серверные приложения Web2, но периодически публикуют доказательства транзакций на уровне L1. Я думаю, что это станет основным фактором, который побудит разработчиков Web2 перейти в пространство Web3.
На самом деле лучшим примером может быть Rimac Nevera, поскольку он быстрее и электрический, поэтому, вероятно, дешевле в эксплуатации.
Единственным недостатком этого подхода является индивидуальный механизм проверки для каждого отдельного приложения. Если логику приложения можно скомпилировать в общий посредник, то доказательство публичного посредника избавит от необходимости проверять каждое приложение индивидуально, но я лично считаю, что это просто компромисс между эффективностью и более быстрой разработкой.
Существуют способы решить эту проблему без использования уровня выполнения с участием виртуальной машины. Что, если бы существовал инструмент, позволяющий разработчикам делать это?
В этом заключается миссия Stackr Labs: мы создаем среду Micro-Rollup и SDK, чтобы каждый мог создавать свои приложения на любом языке без ограничений, точно так же, как и при создании серверных приложений Web2. Процедура та же самая. Делая разработку Micro-Rollup такой же простой, как написание и развертывание смарт-контрактов, не говоря уже о модульности, увеличивается возможность разработчиков выбирать любую экосистему.
**Так реален ли микро-роллап? **
Это всегда было так же реально, как и сам Rollup.
Такие приложения, как Loopring, dYdX и Fuel-v1, уже существуют или существуют уже давно. Это высокооптимизированные накопительные пакеты со специальной логикой, работающей специально для конкретного случая использования. Первое конкретное приложение Rollup, о котором я знаю и над которым лично работал, не основанное на виртуальной машине, — это Hubble Optimistic Rollup, трехлетний проект, который одно время служил базовой инфраструктурой для токена Worldcoin.
В настоящее время становится все более важным различать эти термины.
Варианты использования микро-роллапов безграничны:
Потребительские товары, такие как игры, биржи и рынки NFT.
Цепочку приложений можно преобразовать в совокупность приложений.
Вы даже можете создавать новые типы виртуальных машин, поддерживающие уникальные варианты использования, открывая двери для инноваций в сфере виртуальных машин.
в заключение
В структурном дереве, которое я показывал ранее, отсутствовали элементы для пользовательского конечного автомата.
Кроме того, развертывание одного протокола с использованием объединения на основе виртуальных машин или EVM неэффективно для автономных приложений. Он подходит для приложений, которые уже имеют большое количество смарт-контрактов и запускают свои протоколы в цепочке, подобной EVM, но не для «приложений, которые хотят большего» и хотят избавиться от ограничений VM.
Итак, если мы обрежем дерево, окончательное дерево будет выглядеть вот так. Вот почему я думаю, что App-Rollup, Micro-Rollup или RollApp в ближайшем будущем будут называться App.
Таким образом, Micro Rollup = приложение в накопительном пакете. Приложение как накопительный пакет.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Является ли Micro-Rollup следующей волной?
Автор: KAUTUK, разработчик Stackr. Составитель: Луффи, Foresight News.
Начать статью о сводном обзоре с таких тем, как «Что такое накопительный пакет» или «Зачем нам нужен накопительный пакет» — это все равно, что убить дядю Бена или расстрелять маму и папу Уэйна в каждой версии фильмов «Человек-паук» и «Бэтмен». То же самое, что и папа. Если вы читаете эту статью, я предполагаю, что у вас уже есть базовое понимание вышеуказанных вопросов. Здесь мы пропускаем дебаты между цепочкой приложений и объединением приложений и сразу переходим к теме.
Рост накопительных пакетов для конкретных приложений****Универсальные накопительные пакеты разочаровывают
Universal Rollup похожа на школьную систему в Индии (я уверен, что они имеют схожие характеристики с другими школьными системами, но у меня есть только непосредственный опыт работы с ней).
Спортсменам, певцам, математикам, мыслителям и экономистам необходимо пройти один и тот же процесс, чтобы получить проходной балл. Система не «предвзята» по отношению к какой-либо конкретной группе, но и не «справедлива» по отношению ко всем. Но эй, мы подружились! (Это будет важно позже).
Аналогично, для приложений в универсальном накопительном пакете узким местом является сама среда выполнения, поскольку накопительный пакет не может удовлетворить потребности каждого приложения в отдельности. Для каждого приложения может потребоваться разный тип оптимизации, и любые индивидуальные улучшения могут быть для них не оправданы. Однако если вы просто экспериментируете и хотите получить примерное представление, это наиболее удобный вариант. Кроме того, для некоторых приложений, например, для обычных студентов, это может быть правильным решением!
Сборный пакет для конкретного приложения сбивает с толку
Что ж, мой ребенок слишком спортивен для государственной школы, и ему нужна специальная подготовка. Нужно ли отдавать его в спортивную школу или стоит нанять личного тренера…
Сборку сложно четко классифицировать****Давайте сыграем в игру
Ниже приведены 8 конкретных накопительных пакетов приложений. Однако один элемент в каждой группе на самом деле не принадлежит этой группе. Можете ли вы сказать, какой именно?
Специфика приложения становится запутанным термином. Существуют определенные накопительные пакеты приложений, которые позволяют развертывать контракты поверх самих себя; существуют также некоторые специальные накопительные пакеты приложений, которые допускают развертывание контрактов, поскольку их виртуальные машины поддерживают это, но будут определенные ограничения; У них есть закрытые виртуальные машины или виртуальные машины отсутствуют. машины вообще и не поддерживают другие типы разработки.
Справедливо ли классифицировать их вместе?
Ответы на приведенное выше упражнение:
Группа 1: Celo — необычный вариант, поскольку он позволяет другим разработчикам создавать приложения, а другие разработчики могут использовать эти приложения напрямую. Другими проектами, которые следует рассмотреть в группе 1, являются Fuel-v1, Aevo, RhinoFi и т. д.
Группа 2: Loopring — странный выбор, поскольку это единственный специально созданный накопительный пакет, который можно использовать «из коробки», в то время как остальные представляют собой сети, оптимизированные для определенных функций, таких как конфиденциальность, NFT и TPS для развернутых на нем приложений. Эти функции может передаваться по наследству. Другими проектами, которые можно отнести к группе 2, являются «Кинто», «Крома», «Сеть общественных благ» и др.
Проблемы с развертыванием контрактов на модифицированных виртуальных машинах общего назначения
Эти виртуальные машины, на которых вы развертываете смарт-контракты, представляют собой не что иное, как полные по Тьюрингу конечные автоматы. Контракты, которые вы на них развертываете, только изменяют само состояние, но на самом деле не влияют на основные правила перехода состояний виртуальной машины. Rollup — это, по сути, виртуальная машина, на которой находится ваша бизнес-логика.
Ваша бизнес-логика отделена от функций перехода состояний Rollup.
Я также называю это «парадигмой смарт-контрактов для создания приложений», потому что вы развертываете дополнительную логику поверх виртуальной машины. Rollup не занимается «напрямую» проверкой логики приложения. Виртуальная машина — это накопительный пакет, а не ваше приложение.
Конечно, вы являетесь единственным владельцем виртуальной машины, ваше приложение — единственным гражданином, и вы можете постоянно улучшать саму базу, чтобы сделать ее подходящей для вашего приложения. Вы можете продолжать совершенствовать функцию перехода состояний (STF) и добавлять/удалять коды операций для повышения производительности приложения, но приложение остается независимым и ограничивается самой виртуальной машиной.
Как Lamborghini Urus, тянущий Lamborghini Huracan.
Отдельное приложение для конкретного приложения Rollup может работать лучше. Что, если вы продолжите улучшать STF так, что его область действия будет становиться все меньше и меньше, чтобы соответствовать бизнес-логике вашего приложения? В конце концов, когда вы станете сильнее, STF сойдутся в точке, где бизнес-логика и STF перекроются, и в этот момент вы поймете... о, подождите минутку!
Рождение микро-агрегата
Таким образом, Micro-Rollup — это не что иное, как Rollup, в котором функцией перехода состояния приложения является сама бизнес-логика.
Приложение становится накопительным, состоянием можно управлять любым возможным способом в любой среде выполнения, а правила перехода состояний можно применять непосредственно во время выполнения приложения. Приложение можно настроить без каких-либо ограничений. Доказательства привязаны к вашей бизнес-логике, а не к машине, что делает ваше приложение легким.
Micro-Rollup не имеет ограничений с точки зрения опыта разработчиков. Вы можете создавать их, используя любые инструменты, которые вам нравятся, поскольку они не ограничиваются виртуальными машинами. Они выглядят как серверные приложения Web2, но периодически публикуют доказательства транзакций на уровне L1. Я думаю, что это станет основным фактором, который побудит разработчиков Web2 перейти в пространство Web3.
На самом деле лучшим примером может быть Rimac Nevera, поскольку он быстрее и электрический, поэтому, вероятно, дешевле в эксплуатации.
Единственным недостатком этого подхода является индивидуальный механизм проверки для каждого отдельного приложения. Если логику приложения можно скомпилировать в общий посредник, то доказательство публичного посредника избавит от необходимости проверять каждое приложение индивидуально, но я лично считаю, что это просто компромисс между эффективностью и более быстрой разработкой.
Существуют способы решить эту проблему без использования уровня выполнения с участием виртуальной машины. Что, если бы существовал инструмент, позволяющий разработчикам делать это?
В этом заключается миссия Stackr Labs: мы создаем среду Micro-Rollup и SDK, чтобы каждый мог создавать свои приложения на любом языке без ограничений, точно так же, как и при создании серверных приложений Web2. Процедура та же самая. Делая разработку Micro-Rollup такой же простой, как написание и развертывание смарт-контрактов, не говоря уже о модульности, увеличивается возможность разработчиков выбирать любую экосистему.
**Так реален ли микро-роллап? **
Это всегда было так же реально, как и сам Rollup.
Такие приложения, как Loopring, dYdX и Fuel-v1, уже существуют или существуют уже давно. Это высокооптимизированные накопительные пакеты со специальной логикой, работающей специально для конкретного случая использования. Первое конкретное приложение Rollup, о котором я знаю и над которым лично работал, не основанное на виртуальной машине, — это Hubble Optimistic Rollup, трехлетний проект, который одно время служил базовой инфраструктурой для токена Worldcoin.
В настоящее время становится все более важным различать эти термины.
Варианты использования микро-роллапов безграничны:
в заключение
В структурном дереве, которое я показывал ранее, отсутствовали элементы для пользовательского конечного автомата.
Кроме того, развертывание одного протокола с использованием объединения на основе виртуальных машин или EVM неэффективно для автономных приложений. Он подходит для приложений, которые уже имеют большое количество смарт-контрактов и запускают свои протоколы в цепочке, подобной EVM, но не для «приложений, которые хотят большего» и хотят избавиться от ограничений VM.
Итак, если мы обрежем дерево, окончательное дерево будет выглядеть вот так. Вот почему я думаю, что App-Rollup, Micro-Rollup или RollApp в ближайшем будущем будут называться App.
Таким образом, Micro Rollup = приложение в накопительном пакете. Приложение как накопительный пакет.