Видя, что Particle Network недавно выпустила абстракцию полной цепочки учетных записей, кажется, что ей нужно наложить «средний уровень» поверх существующих стандартов ERC4337, зачем вам это делать? Если вы знакомы с текущим статус-кво абстракции аккаунта, то нетрудно прийти к ответу:
В настоящее время каждая эквивалентная цепочка EVM, включая цепочку приложений уровня 1, уровня 2 и уровня 3, имеет совершенно другой подход, и этот вид абстракции основан на цепочке, а не ориентирован на пользователя;
• Для того, чтобы по-настоящему реализовать ориентированность на пользователя, например, позволить пользователю соединять все связанные цепочки на основе одной записи и одного адреса, чтобы достичь более согласованного и глобального интерактивного опыта, роль «среднего уровня», которая может определять единую спецификацию и стандарты реализации намерений, стала обязательной;
Почему нынешняя рыночная практика «абстракции счета» слишком разделена? Как технически реализована полная абстракция учетной записи Particle Network? Как далеко продвинулось достижение массового внедрения абстрактного трека, ориентированного на намерение? Разберем их по порядку:
Абстракция аккаунта АА-решения унифицированы на «инженерном» уровне, а практический уровень многогранен
С точки зрения технической простоты, абстракция аккаунта — это последовательность намерений, которые пользователи запихивают в пул памяти UserOP, а сборщик упаковывает их и отправляет на исполнение в контракт Entrypoint, где пакетные транзакции могут обрабатываться через агрегацию подписей Aggregator, а детали оплаты газа обрабатываются Paymaster.
Это набор стандартов, определенных ERC4337, и логика реализации бэкенда также унифицирована, но по сути это абстракция цепочки EVM, и фронтенд, который соединяет пользователей, не обязательно «унифицирован».
Например, zkSync использует EOA-адреса для привязки учетных записей, и все, что видят пользователи, — это передаваемый теневой адрес, и фронтенд вряд ли чувствует существование учетных записей AA. Starknet, с другой стороны, представляет собой обновляемую контрактную учетную запись, и пользователям необходимо постоянно обновлять контракт, чтобы обновить функцию учетной записи. Кроме того, Argent использует механизм социального восстановления механизма Guardian, а схема абстракции учетной записи Unipass, как правило, применяется в гетерогенных многоцепочечных приложениях в средах, отличных от EVM.
Подождите, такого рода несогласованность на входе кажется своего рода персонализацией, но она, несомненно, повышает порог для пользователей. Абстракция приходит и уходит, почему порог выше в «ориентированном на пользователя»? Это проявляется в том, что пользователь не может взаимодействовать только с одной цепочкой в многоцепочечной и многоуровневой среде Layer2, а стоимость обучения генерируется из воздуха при охвате нескольких кошельков и нескольких цепочек; Пользователь генерирует несколько разных адресов контрактов в разных цепочках EVM, что создает проблемы для унифицированного управления активами.
Как такая фрагментированная многоцепочечная ERC4337 стандартная инженерная реализация может привести к массовому внедрению, ориентированному на пользователя?
В чем сложность логики абстрактной практики единых счетов? Возьмем, к примеру, абстракцию полной цепочки учетных записей
Как упоминалось ранее, абстракция текущего счета основана только на цепочке EVM, но адрес EOA все еще может быть унифицирован с цепочкой EVM, почему?
Поскольку адреса EOA являются производными от вычислений с открытым ключом, до тех пор, пока алгоритмы разных цепочек одинаковы, а закрытый ключ одинаков, производный адрес также остается прежним. Однако адрес контракта вычисляется из адреса создателя и одноразового номера, а адрес контракта отличается из-за разных одноразовых номеров в каждой цепочке. Один из возможных подходов заключается в том, чтобы использовать подход реестра для сопоставления одного и того же адреса между разными цепочками, но существует риск централизации.
С другой стороны, абстрактная структурная диаграмма Particle Network всей цепочки, она пытается взять на себя роль «диспетчерского центра» с нативным фреймворком децентрализованной цепочки, и каждая новая цепочка с новым адресом будет генерироваться генеральным контрактом диспетчерского центра, а суб-Deploy Contract будет единообразно связан с Deploy Contract для унифицированной работы, включая развертывание и обновление, все аспекты будут единообразно запланированы генеральным контрактом.
Единственная трудность в этом заключается в плавности мгновенной коммуникации между гетерогенными цепочками, что требует от «среднего уровня» выступать в качестве эффективного средства связи, которое может достичь унифицированного планирования, распределяя контракты на каждом узле цепи, а схема практики аналогична кроссчейн-решению LayerZero.
Этот подход, по крайней мере, преодолевает ограничения атрибутов цепочек EVM, так что любой мультичейн, поддерживающий взаимодействие гетерогенных цепочек контрактов и схему EIP-4337, будет включен в многоцепочечную систему. Полная абстракция аккаунта может быть реализована в больших масштабах.
Тем не менее, цепочки, не относящиеся к EVM, такие как Aptos и Sui, в настоящее время не могут соединяться аналогичным образом последовательно. Это достаточно большой рынок в то время, когда экосистема Ethereum абсолютно доминирует в категориях Layer, Layer 2 и Layer 3.
Какую фантазию могут дать другие модульные абстрактные сервисы в «среднем слое»?
Конечно, для того, чтобы действительно достичь полного спектра «ориентированной на пользователя» абстракции, абстракция полной цепочки учетных записей — это только начало. В дополнение к абстрагированию самого аккаунта для улучшения опыта, диспетчерский центр «среднего уровня» также может попытаться выполнить другую абстрактную работу:
Передача кроссчейн-активов и унифицированный расчетный уровень позволяют пользователям осуществлять управление активами и обращение децентрализованным образом между различными цепочками, снижая возможное проскальзывание фрикционного потребления кроссчейнов.
Кроссчейн DID унифицирует конкатенацию идентификации и кредита, со средним уровнем в качестве «центра аутентификации», для реализации обмена идентификацией и синхронизации данных между несколькими цепочками, а затем получения «кредита», который может быть применен в цепочках, снижения кроссплатформенного порога для пользователей и в то же время разрыва разделения данных между цепочками и реальной реализации интерактивного опыта стандарта «идентификации»;
Внедрить единое децентрализованное решение Solver, лучше всего объединить эти разрозненные Solver в диспетчерский центр супер Solver, например, пользователи могут подключиться к UniswapX и Cowswap и Flashbot's SUAVE и другим решениям Solver на одной платформе и создать Solver, который удобен для потенциальных участников Solver, таких как маркет-мейкеры, институциональные трейдеры и специалисты по арбитражу. Потому что без среднего уровня для планирования нет никаких сомнений в том, что эти Решатели все равно будут существовать фрагментарно между цепочками.
Вы можете понять, что исходя из предпосылки, что в экосистеме EVM существуют различные стандартные разделения, ERC4337 определяет правила связи, и коммуникация по-прежнему зависит от IBC, который выступает в качестве «среднего уровня» для появления.
И не стоит недооценивать ценность такого рода ИНФРА среднего уровня, потому что она, вероятно, станет необходимым дополнением для абстракции учетных записей, чтобы отойти от уровня инженерной абстракции и перейти к крупномасштабной популяризации.
Как максимизировать ценность стандарта ERC4337, как унифицировать продукты и стандарты протоколов различных кошельков, цепочек и других строителей в треке, и как по-настоящему сгладить разрыв между пользовательским опытом Web2 и нативными характеристиками цепочки Web3, основанными на ориентированности на пользователя, — все это темы, которые необходимо преодолеть.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Почему нынешняя «абстракция учетной записи» слишком разделена, и как перейти к единой «ориентированной на пользователя» абстракции?
Автор: Haotian
Видя, что Particle Network недавно выпустила абстракцию полной цепочки учетных записей, кажется, что ей нужно наложить «средний уровень» поверх существующих стандартов ERC4337, зачем вам это делать? Если вы знакомы с текущим статус-кво абстракции аккаунта, то нетрудно прийти к ответу:
Почему нынешняя рыночная практика «абстракции счета» слишком разделена? Как технически реализована полная абстракция учетной записи Particle Network? Как далеко продвинулось достижение массового внедрения абстрактного трека, ориентированного на намерение? Разберем их по порядку:
Абстракция аккаунта АА-решения унифицированы на «инженерном» уровне, а практический уровень многогранен
С точки зрения технической простоты, абстракция аккаунта — это последовательность намерений, которые пользователи запихивают в пул памяти UserOP, а сборщик упаковывает их и отправляет на исполнение в контракт Entrypoint, где пакетные транзакции могут обрабатываться через агрегацию подписей Aggregator, а детали оплаты газа обрабатываются Paymaster.
Это набор стандартов, определенных ERC4337, и логика реализации бэкенда также унифицирована, но по сути это абстракция цепочки EVM, и фронтенд, который соединяет пользователей, не обязательно «унифицирован».
Например, zkSync использует EOA-адреса для привязки учетных записей, и все, что видят пользователи, — это передаваемый теневой адрес, и фронтенд вряд ли чувствует существование учетных записей AA. Starknet, с другой стороны, представляет собой обновляемую контрактную учетную запись, и пользователям необходимо постоянно обновлять контракт, чтобы обновить функцию учетной записи. Кроме того, Argent использует механизм социального восстановления механизма Guardian, а схема абстракции учетной записи Unipass, как правило, применяется в гетерогенных многоцепочечных приложениях в средах, отличных от EVM.
Подождите, такого рода несогласованность на входе кажется своего рода персонализацией, но она, несомненно, повышает порог для пользователей. Абстракция приходит и уходит, почему порог выше в «ориентированном на пользователя»? Это проявляется в том, что пользователь не может взаимодействовать только с одной цепочкой в многоцепочечной и многоуровневой среде Layer2, а стоимость обучения генерируется из воздуха при охвате нескольких кошельков и нескольких цепочек; Пользователь генерирует несколько разных адресов контрактов в разных цепочках EVM, что создает проблемы для унифицированного управления активами.
Как такая фрагментированная многоцепочечная ERC4337 стандартная инженерная реализация может привести к массовому внедрению, ориентированному на пользователя?
В чем сложность логики абстрактной практики единых счетов? Возьмем, к примеру, абстракцию полной цепочки учетных записей
Как упоминалось ранее, абстракция текущего счета основана только на цепочке EVM, но адрес EOA все еще может быть унифицирован с цепочкой EVM, почему?
Поскольку адреса EOA являются производными от вычислений с открытым ключом, до тех пор, пока алгоритмы разных цепочек одинаковы, а закрытый ключ одинаков, производный адрес также остается прежним. Однако адрес контракта вычисляется из адреса создателя и одноразового номера, а адрес контракта отличается из-за разных одноразовых номеров в каждой цепочке. Один из возможных подходов заключается в том, чтобы использовать подход реестра для сопоставления одного и того же адреса между разными цепочками, но существует риск централизации.
С другой стороны, абстрактная структурная диаграмма Particle Network всей цепочки, она пытается взять на себя роль «диспетчерского центра» с нативным фреймворком децентрализованной цепочки, и каждая новая цепочка с новым адресом будет генерироваться генеральным контрактом диспетчерского центра, а суб-Deploy Contract будет единообразно связан с Deploy Contract для унифицированной работы, включая развертывание и обновление, все аспекты будут единообразно запланированы генеральным контрактом.
Единственная трудность в этом заключается в плавности мгновенной коммуникации между гетерогенными цепочками, что требует от «среднего уровня» выступать в качестве эффективного средства связи, которое может достичь унифицированного планирования, распределяя контракты на каждом узле цепи, а схема практики аналогична кроссчейн-решению LayerZero.
Этот подход, по крайней мере, преодолевает ограничения атрибутов цепочек EVM, так что любой мультичейн, поддерживающий взаимодействие гетерогенных цепочек контрактов и схему EIP-4337, будет включен в многоцепочечную систему. Полная абстракция аккаунта может быть реализована в больших масштабах.
Тем не менее, цепочки, не относящиеся к EVM, такие как Aptos и Sui, в настоящее время не могут соединяться аналогичным образом последовательно. Это достаточно большой рынок в то время, когда экосистема Ethereum абсолютно доминирует в категориях Layer, Layer 2 и Layer 3.
Какую фантазию могут дать другие модульные абстрактные сервисы в «среднем слое»?
Конечно, для того, чтобы действительно достичь полного спектра «ориентированной на пользователя» абстракции, абстракция полной цепочки учетных записей — это только начало. В дополнение к абстрагированию самого аккаунта для улучшения опыта, диспетчерский центр «среднего уровня» также может попытаться выполнить другую абстрактную работу:
Передача кроссчейн-активов и унифицированный расчетный уровень позволяют пользователям осуществлять управление активами и обращение децентрализованным образом между различными цепочками, снижая возможное проскальзывание фрикционного потребления кроссчейнов.
Кроссчейн DID унифицирует конкатенацию идентификации и кредита, со средним уровнем в качестве «центра аутентификации», для реализации обмена идентификацией и синхронизации данных между несколькими цепочками, а затем получения «кредита», который может быть применен в цепочках, снижения кроссплатформенного порога для пользователей и в то же время разрыва разделения данных между цепочками и реальной реализации интерактивного опыта стандарта «идентификации»;
Внедрить единое децентрализованное решение Solver, лучше всего объединить эти разрозненные Solver в диспетчерский центр супер Solver, например, пользователи могут подключиться к UniswapX и Cowswap и Flashbot's SUAVE и другим решениям Solver на одной платформе и создать Solver, который удобен для потенциальных участников Solver, таких как маркет-мейкеры, институциональные трейдеры и специалисты по арбитражу. Потому что без среднего уровня для планирования нет никаких сомнений в том, что эти Решатели все равно будут существовать фрагментарно между цепочками.
Вы можете понять, что исходя из предпосылки, что в экосистеме EVM существуют различные стандартные разделения, ERC4337 определяет правила связи, и коммуникация по-прежнему зависит от IBC, который выступает в качестве «среднего уровня» для появления.
И не стоит недооценивать ценность такого рода ИНФРА среднего уровня, потому что она, вероятно, станет необходимым дополнением для абстракции учетных записей, чтобы отойти от уровня инженерной абстракции и перейти к крупномасштабной популяризации.
Как максимизировать ценность стандарта ERC4337, как унифицировать продукты и стандарты протоколов различных кошельков, цепочек и других строителей в треке, и как по-настоящему сгладить разрыв между пользовательским опытом Web2 и нативными характеристиками цепочки Web3, основанными на ориентированности на пользователя, — все это темы, которые необходимо преодолеть.