Будучи открытой и программируемой блокчейн-платформой, Ethereum представляет собой не только инфраструктуру цифровой валюты, но и предоставляет разработчикам среду для создания децентрализованных приложений (DAPP) и смарт-контрактов. Благодаря своей гибкости и масштабируемости Ethereum стал ключевым игроком в экосистеме криптовалют и привлекает разработчиков и пользователей по всему миру.
В содержании последнего выпуска Cregis Research мы обсудили ценность абстракции аккаунта (AA), поэтому мы расширили сложную тему: в июне V God, основатель Ethereum, указал в своем блоге, что Ethereum в настоящее время сталкивается с некоторые важные проблемы и проблемы, эти проблемы необходимо решить, чтобы способствовать дальнейшему развитию Ethereum, иначе Ethereum потерпит неудачу, поэтому три направления трансформации: кошелек смарт-контракта, защита конфиденциальности и расширение уровня 2. После успешной трансформации Ethereum улучшится с точки зрения производительности, взаимодействия с пользователем и защиты конфиденциальности.
Конечно, эти сдвиги также несут с собой новые вызовы. Проблемы и значение кошельков смарт-контрактов (CA) были четко проанализированы в предыдущем выпуске. Cregis Research резюмировала некоторые из оставшихся вопросов и выбрала несколько ключевых моментов, тесно связанных с вашим повседневным опытом, и пересмотрела точку зрения V God полмесяца назад.
Новые проблемы, вызванные тремя преобразованиями Ethereum
2. Почему Ethereum должен измениться?
Основная причина, по которой Ethereum необходимо изменить, связана с проблемами масштабируемости, безопасности и защиты конфиденциальности.
Прежде всего, давайте рассмотрим обсуждение в последнем выпуске Cregis Research: Cregis Research: The Archeology of Ethereum Account Structure and the Value of Account Abstraction, в котором говорилось: Ethereum, работающий в децентрализованной среде, по-прежнему сталкивается с самой большой проблемой: линейной. Среда Невозможно выполнять транзакции с высокой степенью параллелизма и компиляцию сложного кода, что является проблемой масштабируемости.
Из-за текущих ограниченных возможностей обработки транзакций Ethereum стоимость транзакций может стать высокой при увеличении сетевого трафика. Эта высокая стоимость транзакций препятствует популяризации Ethereum на основном рынке, поэтому Ethereum необходимо увеличить свою вычислительную мощность и снизить транзакционные издержки за счет расширения L2, такого как накопительные пакеты.
Во-вторых, безопасность кошелька также является важным вопросом. Кошельки EOA (представленные различными подключаемыми кошельками), которые генерируют пары открытого и закрытого ключей исключительно с помощью seed-фраз, крадут бесконечным потоком. хакеров, отдельные пользователи предъявляют все более строгие требования к безопасности активов и в то же время не желают жертвовать пользовательским опытом (корпоративные пользователи выберут полностью самостоятельное решение MPC для защиты активов и готовы пожертвовать удобством on-chain взаимодействие), что требует от Ethereum изменения безопасности кошелька и продвижения кошельков со смарт-контрактами. Последние отраслевые стандарты безопасности (такие как EIP-4337) обеспечивают более надежную безопасность и удобство для отдельных пользователей.
Наконец, защита конфиденциальности является еще одной ключевой проблемой. Все транзакции в Ethereum L1 являются общедоступными, потому что EOA привязан к активам; будь то обычные индивидуальные пользователи, гигантские киты или корпоративные учреждения, они в настоящее время могут страдать от проблем, связанных с пометкой и отслеживанием адресов активов. Таким образом, Ethereum нуждается в дальнейшем совершенствовании для реализации расчетов конфиденциальности без злонамеренных действий, чтобы гарантировать, что не только активы в цепочке, но и информация DID, такая как идентификационные данные и кредитные системы в цепочке, могут быть защищены в будущем. что преступники не могут избежать отслеживания и беспрепятственно обналичить деньги.
Три, самые важные 3 вопроса (обобщены и дополнены комментариями Cregis Research)
Как пользователи управляют несколькими адресами кошельков
По сравнению с Web 3.0, Web 2.0 имеет то же преимущество, которое все еще остается: пользователи могут использовать социальную функцию (адрес электронной почты, номер мобильного телефона и т. д.) для создания различных учетных записей приложений, хотя в мире Web 3.0 общедоступные адреса сети с одним и тем же механизмом консенсуса (например: BSC, ERC-20, TRC-20), но с появлением плана расширения L 2 пользователи будут иметь несколько совершенно разных адресов L 2, а также разные Layer 1 и Layer 2 могут использовать разные языки программирования и промежуточные компоненты, что приводит к проблемам с резервированием адресов; и до многоцепочечной мостовой среды, представленной Polkadot, или мультицепочечной среды общего назначения L2, упомянутой в будущем видении Cregis, пользователи также могут необходимо управлять несколькими адресами разнородных цепочек, что усложняет управление адресами.
Наконец, предложение о скрытых адресах для защиты конфиденциальности, если оно будет широко использоваться, позволит пользователям иметь больше адресов для повышения их защиты конфиденциальности. Поэтому становится сложнее зарезервировать адрес.
Как пользователи реализуют невидимый платеж? (особенно в многоадресной среде)
Предполагая, что L2 в экосистеме Ethereum будет развиваться, как ожидается, в будущем, даже если большинство нативных активов будут токенами ERC-20, пользователи могут иметь несколько адресов L2, и выбор правильного адреса для отправки активов или оплаты становится более сложным. Традиционно пользователям нужно было знать только адрес другой стороны для отправки платежа, но теперь им нужно знать сети уровня 2 и соответствующие адреса, принятые другой стороной, и требуются дополнительные шаги, чтобы гарантировать, что средства будут отправлены в правильное место назначения.
Проблема скрытых платежей с несколькими учетными записями в среде L 2
Хотя контрактная учетная запись (CA), построенная с использованием смарт-контрактов, может легко решить проблему адресации, она не может напрямую выполнять функцию защиты конфиденциальности.
Виталик предложил решение для защиты конфиденциальности на заре Ethereum: скрытый адрес. Скрытые адреса могут помочь вам сохранить конфиденциальность при проведении транзакций в цифровой валюте без отслеживания посторонними.Далее Cregis поделится некоторыми шагами для решения проблем конфиденциальности:
(Полный рабочий процесс скрытого адреса)
Скрытый адрес — это адрес, который может быть создан либо отправителем, либо получателем платежа, но контролируется только получателем платежа. Такой адрес может улучшить конфиденциальность Ethereum в различных сценариях. В этом режиме Боб (получатель платежа) генерирует ключ потребления и использует этот ключ для создания невидимого мета-адреса: B, h = hash(x). Он передает этот метаадрес Алисе (плательщику). Алиса может выполнить вычисление этого метаадреса, сгенерировав скрытый адрес, принадлежащий Алисе Бобу: b-1. Затем она может отправить любые активы, которые она хочет, на этот адрес, и Боб будет иметь полный контроль над ними.
Процесс генерации скрытого адреса должен работать с функцией эллиптической кривой: Боб генерирует ключ m и вычисляет M = G * m, где G — общедоступная точка генерации эллиптической кривой. Алиса генерирует временный ключ r и публикует временный открытый ключ R = G * r. Алиса может вычислить общий секрет S = M * r, а Боб может вычислить тот же самый общий секрет S = m * R.
После генерации скрытого адреса Боба: b-1, когда необходимо торговать с Алисой, Алиса генерирует значение: c и публикует зашифрованные данные c, которые может расшифровать только Боб; при выполнении транзакции она проверяется доказательство с нулевым разглашением: Боб предоставляет Значение x, предоставленное Алисой, и значение c, предоставленное Алисой, могут сделать k=хэш(хэш(х), с), и транзакция будет завершена после проверки правильности. Поскольку исходный адрес Боба не раскрывается во время этого процесса, предоставляется только зашифрованное значение x, а доказательство с нулевым разглашением отвечает только за проверку содержимого k и не показывает отношения между B и b-1.
Как продукт-кошелек одновременно защищает активы и конфиденциальность пользователя?
В традиционной сетевой среде кошельки в первую очередь связаны с защитой закрытых ключей, но в мире ZKP (Zero-Knowledge Proof) кошельки должны защищать как учетные данные для аутентификации, так и данные пользователя. Примером может служить ZKpass, система идентификации, основанная на ZK-SNARK и MPC, которая позволяет пользователям генерировать базовые доказательства для проверки личности и в то же время делает процесс проверки личности без предоставления какой-либо реальной информации через MPC.
Однако, поскольку зашифрованный тег данных (ключевой фрагмент) сам по себе заменяет закрытый ключ EOA, хранение зашифрованного тега данных становится более проблематичным, поскольку пользователям приходится выбирать между локальным хранением данных или доверием к третьей стороне. хранить зашифрованную копию. В то же время кошельки, которые поддерживают социальное восстановление, должны управлять восстановлением активов и восстановлением ключа шифрования, чтобы обеспечить баланс между безопасностью и удобством использования. Поэтому в обозримом будущем стратегии безопасности кошельков корпоративного уровня и личных кошельков будут иметь совершенно разную направленность.Взяв в качестве примера кошельки корпоративного уровня, пользователи кошельков корпоративного уровня нуждаются в самой строгой среде безопасности для защиты средств. высока вероятность отказа: 1. Контрактные кошельки, которые могут иметь человеческие уязвимости; 2. Смешанные кошельки MPC с рисками третьих лиц, выбирайте приватизированные кошельки MPC с тем же уровнем безопасности, что и аппаратные кошельки; В некоторых сценариях, потому что вы всегда хотите чтобы получить лучший пользовательский опыт, вы можете выбрать продукт с некоторыми централизованными операциями.
Кроме того, адрес блокчейна не соответствует требованиям аутентификации в экологии, поэтому решения ENS (доменное имя блокчейна) и SBT (токен привязки души) постепенно принимаются общественностью, но все еще есть проблемы, которые не решены. : первый Трудно решить проблему дублирующихся имен, вызванных традиционным миром Хотя последний не имеет проблемы дублирующихся имен, не существует достаточного количества экологических приложений, чтобы в полной мере использовать функции DID, переносимые им, и даже можно сказать, что текущие сценарии приложений очень тонкие.
4. Резюме
Думаю, все уже понимают, что кошелек — это лишь важная часть темы [преобразования Эфириума], которая бушует в мировом валютном кругу уже почти 3 месяца. Амбиция V God состоит не только в том, чтобы реализовать амбицию «Эфириум дополняет недостатки Биткойна», но и в надежде, что Эфириум действительно сможет создать мир, в который может войти каждый, тесно связанный с реальным миром и сохраняющий концепцию децентрализация.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Наблюдение Cregis Research: новые проблемы, вызванные тремя преобразованиями Ethereum
Введение
В содержании последнего выпуска Cregis Research мы обсудили ценность абстракции аккаунта (AA), поэтому мы расширили сложную тему: в июне V God, основатель Ethereum, указал в своем блоге, что Ethereum в настоящее время сталкивается с некоторые важные проблемы и проблемы, эти проблемы необходимо решить, чтобы способствовать дальнейшему развитию Ethereum, иначе Ethereum потерпит неудачу, поэтому три направления трансформации: кошелек смарт-контракта, защита конфиденциальности и расширение уровня 2. После успешной трансформации Ethereum улучшится с точки зрения производительности, взаимодействия с пользователем и защиты конфиденциальности.
Конечно, эти сдвиги также несут с собой новые вызовы. Проблемы и значение кошельков смарт-контрактов (CA) были четко проанализированы в предыдущем выпуске. Cregis Research резюмировала некоторые из оставшихся вопросов и выбрала несколько ключевых моментов, тесно связанных с вашим повседневным опытом, и пересмотрела точку зрения V God полмесяца назад.
Новые проблемы, вызванные тремя преобразованиями Ethereum
2. Почему Ethereum должен измениться?
Основная причина, по которой Ethereum необходимо изменить, связана с проблемами масштабируемости, безопасности и защиты конфиденциальности.
Прежде всего, давайте рассмотрим обсуждение в последнем выпуске Cregis Research: Cregis Research: The Archeology of Ethereum Account Structure and the Value of Account Abstraction, в котором говорилось: Ethereum, работающий в децентрализованной среде, по-прежнему сталкивается с самой большой проблемой: линейной. Среда Невозможно выполнять транзакции с высокой степенью параллелизма и компиляцию сложного кода, что является проблемой масштабируемости.
Из-за текущих ограниченных возможностей обработки транзакций Ethereum стоимость транзакций может стать высокой при увеличении сетевого трафика. Эта высокая стоимость транзакций препятствует популяризации Ethereum на основном рынке, поэтому Ethereum необходимо увеличить свою вычислительную мощность и снизить транзакционные издержки за счет расширения L2, такого как накопительные пакеты.
Во-вторых, безопасность кошелька также является важным вопросом. Кошельки EOA (представленные различными подключаемыми кошельками), которые генерируют пары открытого и закрытого ключей исключительно с помощью seed-фраз, крадут бесконечным потоком. хакеров, отдельные пользователи предъявляют все более строгие требования к безопасности активов и в то же время не желают жертвовать пользовательским опытом (корпоративные пользователи выберут полностью самостоятельное решение MPC для защиты активов и готовы пожертвовать удобством on-chain взаимодействие), что требует от Ethereum изменения безопасности кошелька и продвижения кошельков со смарт-контрактами. Последние отраслевые стандарты безопасности (такие как EIP-4337) обеспечивают более надежную безопасность и удобство для отдельных пользователей.
Наконец, защита конфиденциальности является еще одной ключевой проблемой. Все транзакции в Ethereum L1 являются общедоступными, потому что EOA привязан к активам; будь то обычные индивидуальные пользователи, гигантские киты или корпоративные учреждения, они в настоящее время могут страдать от проблем, связанных с пометкой и отслеживанием адресов активов. Таким образом, Ethereum нуждается в дальнейшем совершенствовании для реализации расчетов конфиденциальности без злонамеренных действий, чтобы гарантировать, что не только активы в цепочке, но и информация DID, такая как идентификационные данные и кредитные системы в цепочке, могут быть защищены в будущем. что преступники не могут избежать отслеживания и беспрепятственно обналичить деньги.
Три, самые важные 3 вопроса (обобщены и дополнены комментариями Cregis Research)
Как пользователи управляют несколькими адресами кошельков
По сравнению с Web 3.0, Web 2.0 имеет то же преимущество, которое все еще остается: пользователи могут использовать социальную функцию (адрес электронной почты, номер мобильного телефона и т. д.) для создания различных учетных записей приложений, хотя в мире Web 3.0 общедоступные адреса сети с одним и тем же механизмом консенсуса (например: BSC, ERC-20, TRC-20), но с появлением плана расширения L 2 пользователи будут иметь несколько совершенно разных адресов L 2, а также разные Layer 1 и Layer 2 могут использовать разные языки программирования и промежуточные компоненты, что приводит к проблемам с резервированием адресов; и до многоцепочечной мостовой среды, представленной Polkadot, или мультицепочечной среды общего назначения L2, упомянутой в будущем видении Cregis, пользователи также могут необходимо управлять несколькими адресами разнородных цепочек, что усложняет управление адресами.
Наконец, предложение о скрытых адресах для защиты конфиденциальности, если оно будет широко использоваться, позволит пользователям иметь больше адресов для повышения их защиты конфиденциальности. Поэтому становится сложнее зарезервировать адрес.
Как пользователи реализуют невидимый платеж? (особенно в многоадресной среде)
Предполагая, что L2 в экосистеме Ethereum будет развиваться, как ожидается, в будущем, даже если большинство нативных активов будут токенами ERC-20, пользователи могут иметь несколько адресов L2, и выбор правильного адреса для отправки активов или оплаты становится более сложным. Традиционно пользователям нужно было знать только адрес другой стороны для отправки платежа, но теперь им нужно знать сети уровня 2 и соответствующие адреса, принятые другой стороной, и требуются дополнительные шаги, чтобы гарантировать, что средства будут отправлены в правильное место назначения.
Проблема скрытых платежей с несколькими учетными записями в среде L 2
Хотя контрактная учетная запись (CA), построенная с использованием смарт-контрактов, может легко решить проблему адресации, она не может напрямую выполнять функцию защиты конфиденциальности.
Виталик предложил решение для защиты конфиденциальности на заре Ethereum: скрытый адрес. Скрытые адреса могут помочь вам сохранить конфиденциальность при проведении транзакций в цифровой валюте без отслеживания посторонними.Далее Cregis поделится некоторыми шагами для решения проблем конфиденциальности:
(Полный рабочий процесс скрытого адреса)
Скрытый адрес — это адрес, который может быть создан либо отправителем, либо получателем платежа, но контролируется только получателем платежа. Такой адрес может улучшить конфиденциальность Ethereum в различных сценариях. В этом режиме Боб (получатель платежа) генерирует ключ потребления и использует этот ключ для создания невидимого мета-адреса: B, h = hash(x). Он передает этот метаадрес Алисе (плательщику). Алиса может выполнить вычисление этого метаадреса, сгенерировав скрытый адрес, принадлежащий Алисе Бобу: b-1. Затем она может отправить любые активы, которые она хочет, на этот адрес, и Боб будет иметь полный контроль над ними.
Процесс генерации скрытого адреса должен работать с функцией эллиптической кривой: Боб генерирует ключ m и вычисляет M = G * m, где G — общедоступная точка генерации эллиптической кривой. Алиса генерирует временный ключ r и публикует временный открытый ключ R = G * r. Алиса может вычислить общий секрет S = M * r, а Боб может вычислить тот же самый общий секрет S = m * R.
После генерации скрытого адреса Боба: b-1, когда необходимо торговать с Алисой, Алиса генерирует значение: c и публикует зашифрованные данные c, которые может расшифровать только Боб; при выполнении транзакции она проверяется доказательство с нулевым разглашением: Боб предоставляет Значение x, предоставленное Алисой, и значение c, предоставленное Алисой, могут сделать k=хэш(хэш(х), с), и транзакция будет завершена после проверки правильности. Поскольку исходный адрес Боба не раскрывается во время этого процесса, предоставляется только зашифрованное значение x, а доказательство с нулевым разглашением отвечает только за проверку содержимого k и не показывает отношения между B и b-1.
Как продукт-кошелек одновременно защищает активы и конфиденциальность пользователя?
В традиционной сетевой среде кошельки в первую очередь связаны с защитой закрытых ключей, но в мире ZKP (Zero-Knowledge Proof) кошельки должны защищать как учетные данные для аутентификации, так и данные пользователя. Примером может служить ZKpass, система идентификации, основанная на ZK-SNARK и MPC, которая позволяет пользователям генерировать базовые доказательства для проверки личности и в то же время делает процесс проверки личности без предоставления какой-либо реальной информации через MPC.
Однако, поскольку зашифрованный тег данных (ключевой фрагмент) сам по себе заменяет закрытый ключ EOA, хранение зашифрованного тега данных становится более проблематичным, поскольку пользователям приходится выбирать между локальным хранением данных или доверием к третьей стороне. хранить зашифрованную копию. В то же время кошельки, которые поддерживают социальное восстановление, должны управлять восстановлением активов и восстановлением ключа шифрования, чтобы обеспечить баланс между безопасностью и удобством использования. Поэтому в обозримом будущем стратегии безопасности кошельков корпоративного уровня и личных кошельков будут иметь совершенно разную направленность.Взяв в качестве примера кошельки корпоративного уровня, пользователи кошельков корпоративного уровня нуждаются в самой строгой среде безопасности для защиты средств. высока вероятность отказа: 1. Контрактные кошельки, которые могут иметь человеческие уязвимости; 2. Смешанные кошельки MPC с рисками третьих лиц, выбирайте приватизированные кошельки MPC с тем же уровнем безопасности, что и аппаратные кошельки; В некоторых сценариях, потому что вы всегда хотите чтобы получить лучший пользовательский опыт, вы можете выбрать продукт с некоторыми централизованными операциями.
Кроме того, адрес блокчейна не соответствует требованиям аутентификации в экологии, поэтому решения ENS (доменное имя блокчейна) и SBT (токен привязки души) постепенно принимаются общественностью, но все еще есть проблемы, которые не решены. : первый Трудно решить проблему дублирующихся имен, вызванных традиционным миром Хотя последний не имеет проблемы дублирующихся имен, не существует достаточного количества экологических приложений, чтобы в полной мере использовать функции DID, переносимые им, и даже можно сказать, что текущие сценарии приложений очень тонкие.
4. Резюме
Думаю, все уже понимают, что кошелек — это лишь важная часть темы [преобразования Эфириума], которая бушует в мировом валютном кругу уже почти 3 месяца. Амбиция V God состоит не только в том, чтобы реализовать амбицию «Эфириум дополняет недостатки Биткойна», но и в надежде, что Эфириум действительно сможет создать мир, в который может войти каждый, тесно связанный с реальным миром и сохраняющий концепцию децентрализация.