2 записи с тегом "Blockchain"

TL;DR​

Ethereum получил два мощных примитива, которые выводят пользовательский опыт за рамки сид-фраз и сохраняемых в закладках dApp, приближая его к «кликабельным ончейн-взаимодействиям».

• ERC-4337 привносит абстракцию аккаунта в современный Ethereum без изменений основного протокола. Это делает такие функции, как смарт-контрактные аккаунты, спонсирование газа, пакетные вызовы и аутентификация в стиле passkey, нативными для кошельков.
• ERC-4804 представляет web3:// URL-адреса — удобочитаемые ссылки, которые напрямую разрешаются в вызовы контрактов на чтение и могут даже отображать ончейн HTML или SVG, и всё это без традиционного веб-сервера в качестве посредника. Думайте об этом как об «HTTP для EVM».

При совместном использовании ERC-4337 обрабатывает действия, а ERC-4804 — адреса. Эта комбинация позволяет вам делиться ссылкой, которая проверяемо получает свой пользовательский интерфейс из смарт-контракта. Когда пользователь готов действовать, управление передается смарт-аккаунту, который может спонсировать газ и объединять несколько шагов в один бесшовный клик.

---

Почему это важно сейчас​

Это не просто теоретическое будущее; эти технологии уже действуют и набирают значительную популярность. ERC-4337 уже масштабирован и проверен на практике. Канонический контракт EntryPoint был развернут в основной сети Ethereum 1 марта 2023 года и с тех пор обеспечил работу десятков миллионов смарт-контрактных аккаунтов и обработал более 100 миллионов пользовательских операций.

Одновременно с этим основной протокол сближается с этими идеями. Обновление Pectra, выпущенное в мае 2025 года, включало EIP-7702, которое позволяет стандартным внешним аккаунтам (EOA) временно вести себя как смарт-аккаунты. Это дополняет ERC-4337, облегчая переход для существующих пользователей, а не заменяя стандарт.

В отношении адресации, web3:// теперь формализован. ERC-4804 точно определяет, как URL преобразуется в вызов EVM, а web3 был внесен IANA в список временных схем URI. Инструменты и шлюзы, необходимые для практического использования этих URL, теперь доступны, превращая ончейн-данные в общие, ссылочные ресурсы.

---

Введение: ERC-4337 на одной странице​

По своей сути, ERC-4337 вводит параллельный транзакционный путь в Ethereum, созданный для гибкости. Вместо традиционных транзакций пользователи отправляют объекты UserOperation в альтернативный мемпул. Эти объекты описывают, что аккаунт хочет сделать. Специализированные узлы, называемые «Bundlers» (сборщиками), подхватывают эти операции и выполняют их через глобальный контракт EntryPoint.

Это обеспечивает три ключевых компонента:

1. Смарт-контрактные аккаунты (SCA): Эти аккаунты содержат собственную логику. Они определяют, что делает транзакцию действительной, позволяя использовать пользовательские схемы подписи (например, passkeys или мультиподпись), сессионные ключи для игр, лимиты расходов и механизмы социального восстановления. Аккаунт, а не сеть, обеспечивает соблюдение правил.
2. Пеймастеры (Paymasters): Эти специальные контракты могут спонсировать комиссии за газ для пользователей или позволять им платить токенами ERC-20. Это ключ к обеспечению истинного онбординга «без ETH в кошельке» и созданию опыта в один клик путем объединения нескольких вызовов в одну операцию.
3. Безопасность от DoS и правила: Публичный мемпул ERC-4337 защищен стандартизированными правилами внецепочечной валидации (определенными в ERC-7562), которые предотвращают трату ресурсов Bundlers на операции, обреченные на провал. Хотя альтернативные мемпулы могут существовать для специализированных случаев использования, эти общие правила поддерживают согласованность и безопасность экосистемы.

Мысленная модель: ERC-4337 превращает кошельки в программируемые приложения. Вместо простого подписания необработанных транзакций пользователи отправляют «намерения», которые код их аккаунта проверяет, а контракт EntryPoint выполняет — безопасно и атомарно.

---

Введение: ERC-4804 на одной странице​

ERC-4804 обеспечивает простое, прямое сопоставление URL-адреса web3:// с вызовом EVM только для чтения. Грамматика URL интуитивно понятна: web3://<имя-или-адрес>[:chainId]/<метод>/<arg0>?returns=(типы). Имена могут быть разрешены через такие системы, как ENS, а аргументы автоматически типизируются на основе ABI контракта.

Вот пара примеров:

• web3://uniswap.eth/ вызовет контракт по адресу uniswap.eth с пустыми данными вызова (calldata).
• web3://.../balanceOf/vitalik.eth?returns=(uint256) ABI-кодирует вызов функции balanceOf с адресом Виталика и возвращает правильно типизированный JSON-результат.

Важно отметить, что этот стандарт в настоящее время предназначен для вызовов только для чтения (эквивалентно функциям view в Solidity). Любое действие, изменяющее состояние, по-прежнему требует транзакции — именно здесь вступают в игру ERC-4337 или EIP-7702. С регистрацией web3 в качестве временной схемы URI в IANA, путь для нативной поддержки браузерами и клиентами открыт, хотя пока это часто зависит от расширений или шлюзов.

Мысленная модель: ERC-4804 превращает ончейн-ресурсы в ссылочные веб-объекты. «Поделиться этим представлением контракта как URL» становится таким же естественным, как поделиться ссылкой на дашборд.

---

Вместе: «Кликабельные ончейн-взаимодействия»​

Объединение этих двух стандартов открывает мощный новый шаблон для создания децентрализованных приложений сегодня.

Во-первых, вы предоставляете проверяемый пользовательский интерфейс через web3://. Вместо размещения вашего фронтенда на централизованном сервере, таком как S3, вы можете хранить минимальный HTML или SVG-интерфейс непосредственно в блокчейне. Ссылка типа web3://app.eth/render позволяет клиенту разрешить URL и отобразить пользовательский интерфейс непосредственно из контракта, гарантируя, что пользователь видит именно то, что диктует код.

Из этого проверяемого интерфейса вы можете запустить действие в один клик через ERC-4337. Кнопка «Mint» (Выпустить) или «Subscribe» (Подписаться) может скомпилировать UserOperation, которую спонсирует пеймастер. Пользователь подтверждает действие с помощью passkey или простого биометрического запроса, и контракт EntryPoint выполняет пакетный вызов, который развертывает его смарт-аккаунт (если это его первый раз) и завершает желаемое действие за один атомарный шаг.

Это создает бесшовную передачу по глубокой ссылке. Пользовательский интерфейс может встраивать ссылки, основанные на намерениях, которые обрабатываются непосредственно кошельком пользователя, устраняя необходимость отправлять их на внешний сайт, которому они могут не доверять. Содержимое — это контракт, а действие — это аккаунт.

Это открывает:

• Безгазовые пробные версии и онбординг «просто работает»: Новым пользователям не нужно приобретать ETH, чтобы начать. Ваше приложение может спонсировать их первые несколько взаимодействий, значительно снижая трение.
• Общее состояние: Ссылка web3:// — это запрос к состоянию блокчейна. Это идеально подходит для дашбордов, доказательств владения или любого контента, который должен быть проверяемо защищен от подделки.
• Потоки, удобные для агентов: Агенты ИИ могут получать проверяемое состояние через URL-адреса web3:// и отправлять транзакционные намерения через ERC-4337, используя ограниченные сессионные ключи, и всё это без хрупкого парсинга экрана или небезопасной обработки приватных ключей.

---

Заметки по дизайну для разработчиков​

При реализации этих стандартов необходимо рассмотреть несколько архитектурных решений. Для ERC-4337 разумно начать с минимальных шаблонов смарт-контрактных аккаунтов и добавлять возможности через защищенные модули, чтобы сохранить основную логику валидации простой и безопасной. Ваша политика пеймастера должна быть надежной, с четкими ограничениями на спонсируемый газ и белыми списками для одобренных методов, чтобы предотвратить атаки типа griefing.

Для ERC-4804 отдавайте приоритет удобочитаемым ссылкам, используя имена ENS. Явно указывайте chainId, чтобы избежать двусмысленности, и включайте параметр returns=(…) для обеспечения того, чтобы клиенты получали типизированные, предсказуемые ответы. Хотя вы можете отображать полные пользовательские интерфейсы, часто лучше сохранять ончейн HTML/SVG минимальными, используя их в качестве проверяемых оболочек, которые могут получать более тяжелые активы из децентрализованного хранилища, такого как IPFS.

Наконец, помните, что EIP-7702 и ERC-4337 работают вместе, а не друг против друга. С EIP-7702, который теперь активен в обновлении Pectra, существующие пользователи EOA могут делегировать действия логике контракта без развертывания полноценного смарт-аккаунта. Инструментарий в экосистеме абстракции аккаунтов уже настраивается для поддержки этого, сглаживая путь миграции для всех.

---

Безопасность, реальность и ограничения​

Хотя эти системы мощны, у них есть компромиссы. Контракт EntryPoint по своей сути является центральной точкой отказа; он упрощает модель безопасности, но также концентрирует риски. Всегда придерживайтесь проверенных, канонических версий. Правила валидации мемпула из ERC-7562 — это социальное соглашение, а не правило, принудительно исполняемое в блокчейне, поэтому не стоит предполагать, что каждый альтернативный мемпул предлагает одинаковую устойчивость к цензуре или защиту от DoS-атак.

Кроме того, web3:// всё ещё находится на стадии развития. Он остается стандартом только для чтения, и любая операция записи требует транзакции. Хотя сам протокол децентрализован, шлюзы и клиенты, которые разрешают эти URL, всё ещё могут быть потенциальными точками отказа или цензуры. Истинная «неблокируемость» будет зависеть от широкой нативной поддержки клиентов.

---

Конкретный план​

Представьте, что вы хотите создать членский клуб на базе NFT с общим, проверяемым пользовательским интерфейсом и процессом присоединения в один клик. Вот как вы могли бы запустить его в этом квартале:

1. Поделитесь пользовательским интерфейсом: Распространите ссылку типа web3://club.eth/home. Когда пользователь открывает её, его клиент разрешает URL, вызывает контракт и отображает ончейн-интерфейс, который показывает текущий список разрешенных участников и цену минта.
2. Присоединение в один клик: Пользователь нажимает кнопку «Присоединиться». Его кошелек компилирует UserOperation ERC-4337, которую спонсирует ваш пеймастер. Эта единственная операция объединяет три вызова: развертывание смарт-аккаунта пользователя (если у него его нет), оплату комиссии за минт и регистрацию данных его профиля.
3. Проверяемый чек: После подтверждения транзакции пользователю отображается вид подтверждения, который является просто еще одной ссылкой web3://, например web3://club.eth/receipt/<tokenId>, создавая постоянную ончейн-ссылку на доказательство его членства.

---

Большая картина​

Эти два стандарта сигнализируют о фундаментальном сдвиге в том, как мы строим на Ethereum. Аккаунты становятся программным обеспечением. ERC-4337 и EIP-7702 превращают «UX кошелька» в пространство для реальных продуктовых инноваций, выводя нас за рамки лекций об управлении ключами. В то же время, ссылки становятся запросами. ERC-4804 восстанавливает URL как примитив для адресации проверяемых фактов в блокчейне, а не просто фронтендов, которые их проксируют.

Вместе они сокращают разрыв между тем, что пользователи нажимают, и тем, что делают контракты. Этот разрыв когда-то заполнялся централизованными веб-серверами и предположениями о доверии. Теперь его можно заполнить проверяемыми путями кода и открытыми, безразрешительными мемпулами.

Если вы создаете потребительские криптоприложения, это ваш шанс сделать первую минуту пользователя восхитительной. Поделитесь ссылкой, отобразите правду, спонсируйте первое действие и держите своих пользователей в проверяемом цикле. Пути проложены — теперь пришло время создавать впечатления.

1. Overview of TEE Technology​

Definition and Architecture: A Trusted Execution Environment (TEE) is a secure area of a processor that protects the code and data loaded inside it with respect to confidentiality and integrity. In practical terms, a TEE acts as an isolated “enclave” within the CPU – a kind of black box where sensitive computations can run shielded from the rest of the system. Code running inside a TEE enclave is protected so that even a compromised operating system or hypervisor cannot read or tamper with the enclave’s data or code. Key security properties provided by TEEs include:

• Isolation: The enclave’s memory is isolated from other processes and even the OS kernel. Even if an attacker gains full admin privileges on the machine, they cannot directly inspect or modify enclave memory.
• Integrity: The hardware ensures that code executing in the TEE cannot be altered by external attacks. Any tampering of the enclave code or runtime state will be detected, preventing compromised results.
• Confidentiality: Data inside the enclave remains encrypted in memory and is only decrypted for use within the CPU, so secret data is not exposed in plain text to the outside world.
• Remote Attestation: The TEE can produce cryptographic proofs (attestations) to convince a remote party that it is genuine and that specific trusted code is running inside it. This means users can verify that an enclave is in a trustworthy state (e.g. running expected code on genuine hardware) before provisioning it with secret data.

Conceptual diagram of a Trusted Execution Environment as a secure enclave “black box” for smart contract execution. Encrypted inputs (data and contract code) are decrypted and processed inside the secure enclave, and only encrypted results leave the enclave. This ensures that sensitive contract data remains confidential to everyone outside the TEE.

Under the hood, TEEs are enabled by hardware-based memory encryption and access control in the CPU. For example, when a TEE enclave is created, the CPU allocates a protected memory region for it and uses dedicated keys (burned into the hardware or managed by a secure co-processor) to encrypt/decrypt data on the fly. Any attempt by external software to read the enclave memory gets only encrypted bytes. This unique CPU-level protection allows even user-level code to define private memory regions (enclaves) that privileged malware or even a malicious system administrator cannot snoop or modify. In essence, a TEE provides a higher level of security for applications than the normal operating environment, while still being more flexible than dedicated secure elements or hardware security modules.

Key Hardware Implementations: Several hardware TEE technologies exist, each with different architectures but a similar goal of creating a secure enclave within the system:

• Intel SGX (Software Guard Extensions): Intel SGX is one of the most widely used TEE implementations. It allows applications to create enclaves at the process level, with memory encryption and access controls enforced by the CPU. Developers must partition their code into “trusted” code (inside the enclave) and “untrusted” code (normal world), using special instructions (ECALL/OCALL) to transfer data in and out of the enclave. SGX provides strong isolation for enclaves and supports remote attestation via Intel’s Attestation Service (IAS). Many blockchain projects – notably Secret Network and Oasis Network – built privacy-preserving smart contract functionality on SGX enclaves. However, SGX’s design on complex x86 architectures has led to some vulnerabilities (see §4), and Intel’s attestation introduces a centralized trust dependency.

• ARM TrustZone: TrustZone takes a different approach by dividing the processor’s entire execution environment into two worlds: a Secure World and a Normal World. Sensitive code runs in the Secure World, which has access to certain protected memory and peripherals, while the Normal World runs the regular OS and applications. Switches between worlds are controlled by the CPU. TrustZone is commonly used in mobile and IoT devices for things like secure UI, payment processing, or digital rights management. In a blockchain context, TrustZone could enable mobile-first Web3 applications by allowing private keys or sensitive logic to run in the phone’s secure enclave. However, TrustZone enclaves are typically larger-grained (at OS or VM level) and not as commonly adopted in current Web3 projects as SGX.

• AMD SEV (Secure Encrypted Virtualization): AMD’s SEV technology targets virtualized environments. Instead of requiring application-level enclaves, SEV can encrypt the memory of entire virtual machines. It uses an embedded security processor to manage cryptographic keys and to perform memory encryption so that a VM’s memory remains confidential even to the hosting hypervisor. This makes SEV well-suited for cloud or server use cases: for example, a blockchain node or off-chain worker could run inside a fully-encrypted VM, protecting its data from a malicious cloud provider. SEV’s design means less developer effort to partition code (you can run an existing application or even an entire OS in a protected VM). Newer iterations like SEV-SNP add features like tamper detection and allow VM owners to attest their VMs without relying on a centralized service. SEV is highly relevant for TEE use in cloud-based blockchain infrastructure.

Other emerging or niche TEE implementations include Intel TDX (Trust Domain Extensions, for enclave-like protection in VMs on newer Intel chips), open-source TEEs like Keystone (RISC-V), and secure enclave chips in mobile (such as Apple’s Secure Enclave, though not typically open for arbitrary code). Each TEE comes with its own development model and trust assumptions, but all share the core idea of hardware-isolated secure execution.

2. Applications of TEEs in Web3​

Trusted Execution Environments have become a powerful tool in addressing some of Web3’s hardest challenges. By providing a secure, private computation layer, TEEs enable new possibilities for blockchain applications in areas of privacy, scalability, oracle security, and integrity. Below we explore major application domains:

Privacy-Preserving Smart Contracts​

One of the most prominent uses of TEEs in Web3 is enabling confidential smart contracts – programs that run on a blockchain but can handle private data securely. Blockchains like Ethereum are transparent by default: all transaction data and contract state are public. This transparency is problematic for use cases that require confidentiality (e.g. private financial trades, secret ballots, personal data processing). TEEs provide a solution by acting as a privacy-preserving compute enclave connected to the blockchain.

In a TEE-powered smart contract system, transaction inputs can be sent to a secure enclave on a validator or worker node, processed inside the enclave where they remain encrypted to the outside world, and then the enclave can output an encrypted or hashed result back to the chain. Only authorized parties with the decryption key (or the contract logic itself) can access the plaintext result. For example, Secret Network uses Intel SGX in its consensus nodes to execute CosmWasm smart contracts on encrypted inputs, so things like account balances, transaction amounts, or contract state can be kept hidden from the public while still being usable in computations. This has enabled secret DeFi applications – e.g. private token swaps where the amounts are confidential, or secret auctions where bids are encrypted and only revealed after auction close. Another example is Oasis Network’s Parcel and confidential ParaTime, which allow data to be tokenized and used in smart contracts under confidentiality constraints, enabling use cases like credit scoring or medical data on blockchain with privacy compliance.

Privacy-preserving smart contracts via TEEs are attractive for enterprise and institutional adoption of blockchain. Organizations can leverage smart contracts while keeping sensitive business logic and data confidential. For instance, a bank could use a TEE-enabled contract to handle loan applications or trade settlements without exposing client data on-chain, yet still benefit from the transparency and integrity of blockchain verification. This capability directly addresses regulatory privacy requirements (such as GDPR or HIPAA), allowing compliant use of blockchain in healthcare, finance, and other sensitive industries. Indeed, TEEs facilitate compliance with data protection laws by ensuring that personal data can be processed inside an enclave with only encrypted outputs leaving, satisfying regulators that data is safeguarded.

Beyond confidentiality, TEEs also help enforce fairness in smart contracts. For example, a decentralized exchange could run its matching engine inside a TEE to prevent miners or validators from seeing pending orders and unfairly front-running trades. In summary, TEEs bring a much-needed privacy layer to Web3, unlocking applications like confidential DeFi, private voting/governance, and enterprise contracts that were previously infeasible on public ledgers.

Scalability and Off-Chain Computation​

Another critical role for TEEs is improving blockchain scalability by offloading heavy computations off-chain into a secure environment. Blockchains struggle with complex or computationally intensive tasks due to performance limits and costs of on-chain execution. TEE-enabled off-chain computation allows these tasks to be done off the main chain (thus not consuming block gas or slowing down on-chain throughput) while still retaining trust guarantees about the correctness of the results. In effect, a TEE can serve as a verifiable off-chain compute accelerator for Web3.

For example, the iExec platform uses TEEs to create a decentralized cloud computing marketplace where developers can run computations off-chain and get results that are trusted by the blockchain. A dApp can request a computation (say, a complex AI model inference or a big data analysis) to be done by iExec worker nodes. These worker nodes execute the task inside an SGX enclave, producing a result along with an attestation that the correct code ran in a genuine enclave. The result is then returned on-chain, and the smart contract can verify the enclave’s attestation before accepting the output. This architecture allows heavy workloads to be handled off-chain without sacrificing trust, effectively boosting throughput. The iExec Orchestrator integration with Chainlink demonstrates this: a Chainlink oracle fetches external data, then hands off a complex computation to iExec’s TEE workers (e.g. aggregating or scoring the data), and finally the secure result is delivered on-chain. Use cases include things like decentralized insurance calculations (as iExec demonstrated), where a lot of data crunching can be done off-chain and cheaply, with only the final outcome going to the blockchain.

TEE-based off-chain computation also underpins some Layer-2 scaling solutions. Oasis Labs’ early prototype Ekiden (the precursor to Oasis Network) used SGX enclaves to run transaction execution off-chain in parallel, then commit only state roots to the main chain, effectively similar to rollup ideas but using hardware trust. By doing contract execution in TEEs, they achieved high throughput while relying on enclaves to preserve security. Another example is Sanders Network’s forthcoming Op-Succinct L2, which combines TEEs and zkSNARKs: TEEs execute transactions privately and quickly, and then zk-proofs are generated to prove the correctness of those executions to Ethereum.