Явная подпись: UTXO против одобрения токенов

Любопытство

1. Почему смарт-контракт может переместить ваши токены спустя годы после того, как вы с ним взаимодействовали?
2. В чем структурная разница между подписанием транзакции и предоставлением постоянных полномочий?
3. Как формат файла делает все входы и выходы биткоин-транзакции видимыми до того, как она будет подписана?

Исследование

1. В сетях на основе EVM передача токенов регулируется стандартом ERC-20. Чтобы перевести токены из внешнего кошелька в контракт, владелец должен сначала вызвать функцию `approve`, предоставляя контракту разрешение тратить определённое количество этих токенов от его имени. Это разрешение записывается в состоянии контракта и сохраняется до тех пор, пока не будет аннулировано или исчерпано. Пользователь, который предоставил разрешение на использование 10 000 токенов для децентрализованной биржи, сохраняет это право даже после завершения обмена.
2. EIP-2612 добавил функцию `permit`, которая позволяет пользователю подписать офчейн-сообщение, устанавливающее такое разрешение, без немедленной отправки транзакции. Подпись остаётся действительной, пока её не используют или не истечёт её срок, и даёт те же права на расходование. Как только разрешение существует, тот, кто контролирует одобренный адрес-распорядитель (spender), может вывести всю разрешённую сумму вызовом `transferFrom`, даже если пользователь с тех пор не взаимодействовал с этим контрактом.
3. Этой архитектурой пользуются дрейнеры кошельков. Фишинговые сайты обманом заставляют пользователей подписать неограниченный `approve` или `permit` в пользу вредоносного адреса. После подписи у атакующего появляется постоянное право перемещать токены когда угодно. Отзыв таких разрешений требует дополнительных транзакций и оплаты газа, что создаёт трение. В итоге одна подпись может создать постоянную уязвимость, незаметную, если пользователь сам не проверяет свои действующие разрешения с помощью инструментов вроде Revoke.cash или Etherscan.
4. Модель UTXO в биткоине устроена иначе. Постоянных разрешений в ней нет. Каждая транзакция явно тратит конкретные непотраченные выходы транзакций (UTXO) и создаёт новые. Подпись разрешает перемещение конкретной монеты с конкретного адреса на конкретный адрес назначения, не оставляя после себя никаких остаточных полномочий. Если пользователь подписал транзакцию, отправляющую 1 BTC на биржу, эту подпись нельзя повторно использовать, чтобы позже отправить ещё 1 BTC.
5. BIP-174 определяет формат частично подписанной биткоин-транзакции (PSBT). До подписания PSBT содержит все входы и выходы, что позволяет программным и аппаратным кошелькам точно показать, что тратится и куда уходит. Пользователь видит полную структуру транзакции — входы, выходы, комиссии — и подписывает именно эти данные; при стандартном типе подписи она охватывает всю транзакцию целиком. Поскольку никаких скрытых разрешений не создаётся, вредоносная подпись может переместить только монеты, указанные в этой единственной транзакции, и не может оставить бэкдор для будущих переводов.
6. Обратная сторона — компонуемость. Одобрения в EVM позволяют выстраивать сложные многошаговые взаимодействия, в которых контракты управляют балансами токенов от имени пользователей в ходе нескольких действий. Явная модель биткоина требует отдельной подписи для каждого перемещения, что ограничивает возможность так же гибко делегировать полномочия смарт-контрактам. Пользователи получают безопасность за счёт прозрачности и отсутствия постоянных разрешений, но жертвуют удобством автоматизированных агентов, действующих длительно.

Ключевые факты

Упражнение девять, шесть, три, один

Проверка фактов

Даты, цифры и утверждения были проверены по приведенным ниже опубликованным источникам.

• EIP-20: Token Standard (2015)
• EIP-2612: Permit Extension for EIP-20 Signed Approvals (2020)
• BIP-174: Partially Signed Bitcoin Transaction Format (2017)
• Scam Sniffer, annual Web3 phishing reports