8 апреля 2025 года основатель Ethereum Виталик выступит с основным докладом на саммите ученых Web3 2025. Золотая финансовая информация собрала содержание доклада следующим образом.
Сейчас выход из Optimism или Arbitrum требует 1 недели ожидания, что вызывает множество проблем.
Почему это важно для нас? Почему мы должны заботиться о более быстром взаимодействии между L2 и L1? Я думаю, что у меня есть две причины. Одна из них — пользовательский опыт, мы хотим, чтобы у пользователей был лучший опыт, ждать 1 неделю — это плохой опыт. Другая причина — нам нужна более интегрированная экосистема. Нам нужно сделать некоторые вещи, чтобы действительно улучшить Optimism, Arbitrum, Polygon.
Эти части мира Эфириума не являются независимыми.
На данный момент межоперабельность между L1 и L2 осуществляется очень быстро, но требует много газа. Мы начали действительно беспокоиться об этой проблеме с прошлого лета. Две вещи, которые нас интересуют, включают: специфические адреса блокчейна и предполагаемые проекты. Я надеюсь, что перенос Optimism на Arbitrum не займет недели, даже я надеюсь, что можно будет разместить Optimism в смарт-контракте.
В умных контрактах, если кто-либо сначала предоставит доказательство того, что он отправил деньги на мой любой адрес назначения через контракт, он автоматически перейдет к этому шагу. Поэтому мы надеемся найти подходящий способ максимально сократить время ожидания в одну неделю.
Почему у нас сейчас есть недельное окно для вывода средств? Потому что Rollup от Optimism требует ждать неделю, чтобы увидеть, не оспаривает ли кто-то его хэш. Если никто не оспаривает, вы можете принять хэш. Преимущество Optimism заключается в том, что используемая им технология очень осторожна, но это стоит недели ожидания.
Если мы не хотим ждать неделю, то нам необходимо создать систему, которая может полностью использовать не Optimism доказательную систему для упаковки блоков, такую как сочетание ZK+TEE+OP — это и есть предложенный нами проект.
В нормальных условиях, как только происходит L2 транзакция, состояние будет окончательно определено на L1 в течение часа, сокращая 1 час до 12 секунд, что в основном является вопросом эффективности. Итак, это первая цель. Вторая цель заключается в том, что мы хотим, чтобы L2 был бездоверительным. Мы хотим, чтобы система могла определять правильное состояние и фиксировать ошибочное состояние, даже если доверительные компоненты будут скомпрометированы. Итак, сегодня Rollup находится либо на нулевой стадии, либо на первой стадии, что означает, что они возлагают определенную степень доверия или полное доверие на некий комитет безопасности. Вы должны верить, что производитель сможет правильно их спроектировать. Вы должны верить, что производитель не будет хранить копии на ключе сайта.
Кроме того, вы должны верить, что аппаратные механизмы — это не то, что может разрушить любой, кто владеет оборудованием, вы должны верить, что они не смогут найти способ, например, с помощью лазера или инфракрасного сканирования оборудования, извлечь информацию, не повреждая визуально.
Сейчас мы не хотим полагаться на ZK во всем.
Вы распределите доверие между тремя различными механизмами, которые работают на основе очень разных типов логики. Если у нас есть такой дизайн, то вы можете сократить окончательный срок с 1 часа до 1 недели до 1 часа. Кстати, другой способ - это мое предыдущее мнение о групповых системах, я в основном делю их на два типа. Один тип - институциональное доверие, другой тип - криптографическое доверие.
Еще одно измерение – это скорость. Быстрые вещи могут быть одобрены сразу, в то время как медленным вещам нужно подождать некоторое время. Интересно, что, как и четыре вещи здесь, они в основном представляют собой четыре компонента систем доказательства, которые люди используют или обдумывают в контексте L2, верно? Если мы действительно могли бы поместить их в коробку, они идеально поместятся в 2×2.
Первый шаг, в основном, мы сократили окно времени для Devil Walk с 1 недели до 1 часа. Что это вам дает? В основном это означает, что если вы используете родной мост для прямого перевода активов, ваше время ожидания сократится с 1 недели до 1 часа. Если вы используете мост на основе намерений, то мост на основе намерений является мгновенным, но поставщики ликвидности не должны ждать 1 час, а должны ждать 1 час. Стоимость предоставления ликвидности снизилась в 168 раз. Таким образом, расходы, которые вам придется оплатить, уменьшатся до 168 раз.
L2s могут использовать lowlookahead для асинхронного чтения L1. Это функция, которая уже имеется у L2, поскольку они должны уметь обрабатывать депозиты. Мы используем то же состояние, что и для чтения депозитов, и выставляем его для L1SLOADopcode. Поддержка чтения данных о предсказателях L1, кошельков хранилищ ключей и многих других приложений является крайне ценным, поскольку одной из проблем, с которыми часто сталкиваются L2, является необходимость оплачивать огромные суммы.
Таким образом, я получил различные пользовательские приложения и специфические интеграции. Это действительно может снизить затраты, поскольку во многих случаях альтернативы смогут напрямую считывать копии приложений, которые уже существуют в одном приложении, что подходит для обработки данных. Это применимо к определенным вещам, но не подходит для того, что требует записи от кого-либо.
Кошелек для хранения ключей — это еще одна интересная идея, не так ли? Идея кошелька для хранения ключей заключается в том, что в нормальной сетевой безопасности, когда вы хотите сменить ключ, вы не хотите, чтобы ключ имел бесконечный срок службы. Neo является частью цели абстракции учетной записи, и сегодня я буду обсуждать эту цель.
Но я уже много раз говорил, что по сути это создание учетных записей с произвольной логикой, так что вы можете делать некоторые вещи, например, изменять криптографический алгоритм, изменять ключи, чтобы они имели большую устойчивость, и добавлять такие методы, как snark, которые добавляются аналогично методам восстановления. Теперь одной из задач является то, что если вы можете изменить ключ, то у вас будет сто результатов после изменений. Таким образом, вам нужно изменить записи текущего ключа в 100 местах.
Как вы решаете эту проблему? Мы решаем эту проблему, размещая записи текущего ключа на центральном смарт-контракте. Затем у вас есть копия кошелька на каждом L2, и достаточно просто прочитать L1. Это делает многие разумные и аналогичные практики секьюритизации более жизнеспособными и практичными в мире L2.
Еще одно преимущество заключается в том, что это делает рабочие процессы, которые одновременно включают L2 и L1, для разработчиков более легкими и естественными. Мы говорим не только о теории и куче совершенно независимых цепочек, но на самом деле говорим о том, что теория L1 продолжает оставаться в центре пользовательского опыта приложений и людей.
Третий шаг - это доказательство агрегирования. Ранее я упоминал, что если мы используем этот метод, основанный на двух или трех подходах, или в будущем, если мы проведем очень хорошую формальную верификацию, полагаясь только на ZK, мы сможем сократить время提交 с 1 недели до 1 часа. Почему 1 час? Почему не 12 секунд? Есть две причины, которые мы можем решить. Первая причина - это стоимость提交. Поэтому提交 доказательства в L1 требует дополнительных затрат, около 500 000 gas, и стоимость AA очень высока.
Теперь, если вы представите, что каждую единицу времени необходимо предоставить доказательство, то за год будет 2,5 миллиона единиц времени. Нам нужно будет потратить 27,5 миллиона долларов в год только для поддержания относительной стоимости, что безумно. Здесь есть кто-то, кто готов платить 27 миллионов долларов в год. Но если вы будете представлять доказательства каждую минуту, а не каждые 12 секунд, то затраты в 27 миллионов долларов в год снизятся до 5,5 миллиона долларов. Затем, если вы будете представлять доказательства каждый час, это снизится до менее 100 тысяч долларов в год. Это действительно можно контролировать. Это естественное решение - агрегирование доказательств.
Если у нас есть большое количество различных инструментов, то эти инструменты не нужно отправлять разным группам по отдельности, цепные доказательства могут быть сгруппированы, группы могут отправлять свои доказательства в агрегат, а затем агрегат может отправлять отдельный SNARK для доказательства существования других SNARK. Стоимость проверки SNARK составляет всего 500 000 единовременных затрат на газ. То, что здесь происходит, в основном то, что изображено на этой диаграмме? Правильно? По сути, у вас есть куча доказательств, и эти доказательства также указывают, какой контракт заключается. Мы находимся в блоке. Тогда у вас есть агрегированное доказательство. Агрегатные доказательства проверяются. Статистическая аттестация содержит все сведения одного агрегата в качестве общих входных данных, а затем аттестация выполняется только один раз. В этом случае этот контракт будет выполнять только один вызов для каждого объединения, и единственное, что он делает, — это для каждого свертки. Он просто загружается отдельно. Стоимость одного визита снизилась с 500 000 до менее чем 10 000 газа.
Теперь есть четвертый шаг, а именно сокращение задержки подтверждения. Подсчет подтверждения занимает больше времени и требует больше вычислительных мощностей, чем выполнение вычислений. По умолчанию это вычисление не блокируется. Вам нужно расширить его, и вы должны выполнить такие очень интенсивные вычисления.
Таким образом, результат заключается в том, что в сбалансированном состоянии, создание блока, которому требуется 5 секунд, все равно требует 500 секунд для подтверждения, верно? Это проблема. Так что вопрос в том, как мы можем решить эту проблему? Есть две идеи. Одна из них заключается в том, что мы можем использовать специализированное оборудование для улучшения этого. Некоторые компании уже занимаются этим. Если вы получите коэффициент аппаратного ускорения в 100 раз, тогда вы сможете подтверждать в реальном времени. Другой идеей является супердоказательство о неполадках. С математической точки зрения это на самом деле очень просто. В основном, вы будете разбивать вычисления на несколько шагов. Затем вы параллельно генерируете доказательства каждого шага на разных устройствах.
Если этого недостаточно, то скорость улучшения специализированного оборудования будет еще выше. При этом стоимость улучшений также будет ниже. Так что у нас много вариантов.
Если вы используете Intensive Optimism и Arbitrum, которые оба имеют гораздо более быстрые слоты, вы также можете завершить транзакцию за 2 секунды. Это будет очень дешево. Таким образом, если вы используете Intensive, вы сможете быстро переводить практически неограниченное количество эфира с низкими затратами. Это также означает, что мы можем установить более тесные связи между L1 и L2. Мы получили более интегрированный мир, и все это стало более легким и быстрым для каждого. Спасибо.
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Vatilik: Почему необходимо ускорить подтверждение L2? Как это ускорить?
Отделка: 5 бат, Golden Finance
8 апреля 2025 года основатель Ethereum Виталик выступит с основным докладом на саммите ученых Web3 2025. Золотая финансовая информация собрала содержание доклада следующим образом.
! c6IWD5wcjs585el116TgkbKAvbwA43Kqgzsvk4aS.jpeg
Сейчас выход из Optimism или Arbitrum требует 1 недели ожидания, что вызывает множество проблем.
Почему это важно для нас? Почему мы должны заботиться о более быстром взаимодействии между L2 и L1? Я думаю, что у меня есть две причины. Одна из них — пользовательский опыт, мы хотим, чтобы у пользователей был лучший опыт, ждать 1 неделю — это плохой опыт. Другая причина — нам нужна более интегрированная экосистема. Нам нужно сделать некоторые вещи, чтобы действительно улучшить Optimism, Arbitrum, Polygon.
Эти части мира Эфириума не являются независимыми.
На данный момент межоперабельность между L1 и L2 осуществляется очень быстро, но требует много газа. Мы начали действительно беспокоиться об этой проблеме с прошлого лета. Две вещи, которые нас интересуют, включают: специфические адреса блокчейна и предполагаемые проекты. Я надеюсь, что перенос Optimism на Arbitrum не займет недели, даже я надеюсь, что можно будет разместить Optimism в смарт-контракте.
В умных контрактах, если кто-либо сначала предоставит доказательство того, что он отправил деньги на мой любой адрес назначения через контракт, он автоматически перейдет к этому шагу. Поэтому мы надеемся найти подходящий способ максимально сократить время ожидания в одну неделю.
Почему у нас сейчас есть недельное окно для вывода средств? Потому что Rollup от Optimism требует ждать неделю, чтобы увидеть, не оспаривает ли кто-то его хэш. Если никто не оспаривает, вы можете принять хэш. Преимущество Optimism заключается в том, что используемая им технология очень осторожна, но это стоит недели ожидания.
Если мы не хотим ждать неделю, то нам необходимо создать систему, которая может полностью использовать не Optimism доказательную систему для упаковки блоков, такую как сочетание ZK+TEE+OP — это и есть предложенный нами проект.
! DgiWcMrcMkwxgOfjSfT9BcXQXFNajasojnfkTkPt.jpeg
В нормальных условиях, как только происходит L2 транзакция, состояние будет окончательно определено на L1 в течение часа, сокращая 1 час до 12 секунд, что в основном является вопросом эффективности. Итак, это первая цель. Вторая цель заключается в том, что мы хотим, чтобы L2 был бездоверительным. Мы хотим, чтобы система могла определять правильное состояние и фиксировать ошибочное состояние, даже если доверительные компоненты будут скомпрометированы. Итак, сегодня Rollup находится либо на нулевой стадии, либо на первой стадии, что означает, что они возлагают определенную степень доверия или полное доверие на некий комитет безопасности. Вы должны верить, что производитель сможет правильно их спроектировать. Вы должны верить, что производитель не будет хранить копии на ключе сайта.
! ncHxzOasQPGl1fjBSG8cycQLUYzCU1kQkjmpevq6.jpeg
Кроме того, вы должны верить, что аппаратные механизмы — это не то, что может разрушить любой, кто владеет оборудованием, вы должны верить, что они не смогут найти способ, например, с помощью лазера или инфракрасного сканирования оборудования, извлечь информацию, не повреждая визуально.
Сейчас мы не хотим полагаться на ZK во всем.
Вы распределите доверие между тремя различными механизмами, которые работают на основе очень разных типов логики. Если у нас есть такой дизайн, то вы можете сократить окончательный срок с 1 часа до 1 недели до 1 часа. Кстати, другой способ - это мое предыдущее мнение о групповых системах, я в основном делю их на два типа. Один тип - институциональное доверие, другой тип - криптографическое доверие.
Еще одно измерение – это скорость. Быстрые вещи могут быть одобрены сразу, в то время как медленным вещам нужно подождать некоторое время. Интересно, что, как и четыре вещи здесь, они в основном представляют собой четыре компонента систем доказательства, которые люди используют или обдумывают в контексте L2, верно? Если мы действительно могли бы поместить их в коробку, они идеально поместятся в 2×2.
Первый шаг, в основном, мы сократили окно времени для Devil Walk с 1 недели до 1 часа. Что это вам дает? В основном это означает, что если вы используете родной мост для прямого перевода активов, ваше время ожидания сократится с 1 недели до 1 часа. Если вы используете мост на основе намерений, то мост на основе намерений является мгновенным, но поставщики ликвидности не должны ждать 1 час, а должны ждать 1 час. Стоимость предоставления ликвидности снизилась в 168 раз. Таким образом, расходы, которые вам придется оплатить, уменьшатся до 168 раз.
L2s могут использовать lowlookahead для асинхронного чтения L1. Это функция, которая уже имеется у L2, поскольку они должны уметь обрабатывать депозиты. Мы используем то же состояние, что и для чтения депозитов, и выставляем его для L1SLOADopcode. Поддержка чтения данных о предсказателях L1, кошельков хранилищ ключей и многих других приложений является крайне ценным, поскольку одной из проблем, с которыми часто сталкиваются L2, является необходимость оплачивать огромные суммы.
! 4ZTnBOtkTIBfxYOBykB3r2sM9Y8960iNQpjEVHVb.jpeg
Таким образом, я получил различные пользовательские приложения и специфические интеграции. Это действительно может снизить затраты, поскольку во многих случаях альтернативы смогут напрямую считывать копии приложений, которые уже существуют в одном приложении, что подходит для обработки данных. Это применимо к определенным вещам, но не подходит для того, что требует записи от кого-либо.
Кошелек для хранения ключей — это еще одна интересная идея, не так ли? Идея кошелька для хранения ключей заключается в том, что в нормальной сетевой безопасности, когда вы хотите сменить ключ, вы не хотите, чтобы ключ имел бесконечный срок службы. Neo является частью цели абстракции учетной записи, и сегодня я буду обсуждать эту цель.
Но я уже много раз говорил, что по сути это создание учетных записей с произвольной логикой, так что вы можете делать некоторые вещи, например, изменять криптографический алгоритм, изменять ключи, чтобы они имели большую устойчивость, и добавлять такие методы, как snark, которые добавляются аналогично методам восстановления. Теперь одной из задач является то, что если вы можете изменить ключ, то у вас будет сто результатов после изменений. Таким образом, вам нужно изменить записи текущего ключа в 100 местах.
Как вы решаете эту проблему? Мы решаем эту проблему, размещая записи текущего ключа на центральном смарт-контракте. Затем у вас есть копия кошелька на каждом L2, и достаточно просто прочитать L1. Это делает многие разумные и аналогичные практики секьюритизации более жизнеспособными и практичными в мире L2.
Еще одно преимущество заключается в том, что это делает рабочие процессы, которые одновременно включают L2 и L1, для разработчиков более легкими и естественными. Мы говорим не только о теории и куче совершенно независимых цепочек, но на самом деле говорим о том, что теория L1 продолжает оставаться в центре пользовательского опыта приложений и людей.
Третий шаг - это доказательство агрегирования. Ранее я упоминал, что если мы используем этот метод, основанный на двух или трех подходах, или в будущем, если мы проведем очень хорошую формальную верификацию, полагаясь только на ZK, мы сможем сократить время提交 с 1 недели до 1 часа. Почему 1 час? Почему не 12 секунд? Есть две причины, которые мы можем решить. Первая причина - это стоимость提交. Поэтому提交 доказательства в L1 требует дополнительных затрат, около 500 000 gas, и стоимость AA очень высока.
Теперь, если вы представите, что каждую единицу времени необходимо предоставить доказательство, то за год будет 2,5 миллиона единиц времени. Нам нужно будет потратить 27,5 миллиона долларов в год только для поддержания относительной стоимости, что безумно. Здесь есть кто-то, кто готов платить 27 миллионов долларов в год. Но если вы будете представлять доказательства каждую минуту, а не каждые 12 секунд, то затраты в 27 миллионов долларов в год снизятся до 5,5 миллиона долларов. Затем, если вы будете представлять доказательства каждый час, это снизится до менее 100 тысяч долларов в год. Это действительно можно контролировать. Это естественное решение - агрегирование доказательств.
! Rbld5A07Dvj7MocDpMKcbzb1tz923MsbGM7f3LBG.jpeg
Если у нас есть большое количество различных инструментов, то эти инструменты не нужно отправлять разным группам по отдельности, цепные доказательства могут быть сгруппированы, группы могут отправлять свои доказательства в агрегат, а затем агрегат может отправлять отдельный SNARK для доказательства существования других SNARK. Стоимость проверки SNARK составляет всего 500 000 единовременных затрат на газ. То, что здесь происходит, в основном то, что изображено на этой диаграмме? Правильно? По сути, у вас есть куча доказательств, и эти доказательства также указывают, какой контракт заключается. Мы находимся в блоке. Тогда у вас есть агрегированное доказательство. Агрегатные доказательства проверяются. Статистическая аттестация содержит все сведения одного агрегата в качестве общих входных данных, а затем аттестация выполняется только один раз. В этом случае этот контракт будет выполнять только один вызов для каждого объединения, и единственное, что он делает, — это для каждого свертки. Он просто загружается отдельно. Стоимость одного визита снизилась с 500 000 до менее чем 10 000 газа.
Теперь есть четвертый шаг, а именно сокращение задержки подтверждения. Подсчет подтверждения занимает больше времени и требует больше вычислительных мощностей, чем выполнение вычислений. По умолчанию это вычисление не блокируется. Вам нужно расширить его, и вы должны выполнить такие очень интенсивные вычисления.
! VthFsqHrhyIZegJNNmzkb6wxoqmLsBlAMQL0Ttip.jpeg
Таким образом, результат заключается в том, что в сбалансированном состоянии, создание блока, которому требуется 5 секунд, все равно требует 500 секунд для подтверждения, верно? Это проблема. Так что вопрос в том, как мы можем решить эту проблему? Есть две идеи. Одна из них заключается в том, что мы можем использовать специализированное оборудование для улучшения этого. Некоторые компании уже занимаются этим. Если вы получите коэффициент аппаратного ускорения в 100 раз, тогда вы сможете подтверждать в реальном времени. Другой идеей является супердоказательство о неполадках. С математической точки зрения это на самом деле очень просто. В основном, вы будете разбивать вычисления на несколько шагов. Затем вы параллельно генерируете доказательства каждого шага на разных устройствах.
Если этого недостаточно, то скорость улучшения специализированного оборудования будет еще выше. При этом стоимость улучшений также будет ниже. Так что у нас много вариантов.
Если вы используете Intensive Optimism и Arbitrum, которые оба имеют гораздо более быстрые слоты, вы также можете завершить транзакцию за 2 секунды. Это будет очень дешево. Таким образом, если вы используете Intensive, вы сможете быстро переводить практически неограниченное количество эфира с низкими затратами. Это также означает, что мы можем установить более тесные связи между L1 и L2. Мы получили более интегрированный мир, и все это стало более легким и быстрым для каждого. Спасибо.