Подписание транзакций

Что такое подписание транзакции?

Подписание транзакции — это криптографический процесс подтверждения блокчейн-транзакции с помощью приватного ключа.

В криптовалюте подписание подтверждает, что человек или кошелек, контролирующий приватный ключ, авторизовал конкретную транзакцию.

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

В официальной документации Ethereum об аккаунтах указано, что приватный ключ необходим для подписания сообщений и транзакций, а полученная подпись может подтверждать авторство.

Подписание транзакции не раскрывает приватный ключ.

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

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

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

Затем блокчейн проверяет, соответствует ли подпись аккаунту или адресу, который пытается потратить средства либо выполнить действие.

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

Почему подписание транзакций важно

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

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

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

Поэтому этап подписания чрезвычайно важен.

Действительная подпись может авторизовать перевод токенов, продажу NFT, разрешение DeFi, действие в стейкинге, голосование по управлению, перевод через мост, вызов смарт-контракта или делегирование кошелька.

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

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

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

Следовательно, подписание транзакций одновременно является функцией безопасности и важной точкой пользовательского риска.

Безопасное использование криптовалюты зависит от понимания того, что именно подписывается до подтверждения.

Как работает подписание транзакций

Сначала кошелек формирует данные транзакции на основе действия, которое хочет выполнить пользователь.

Эти данные могут включать отправителя, получателя, сумму, комиссию, nonce, ID цепи, адрес контракта, вызов функции и другие поля в зависимости от блокчейна.

Затем кошелек подготавливает данные в формате, требуемом данным блокчейном.

В процессе подписания создается криптографическая подпись для данных транзакции.

Подписанная транзакция включает как исходные данные транзакции, так и подпись.

Затем транзакцию можно отправить в одноранговую сеть или на RPC-эндпоинт.

Узлы проверяют, действительна ли подпись для заявленного отправителя.

Узлы также проверяют, достаточно ли у отправителя средств, действителен ли nonce или порядковый номер, достаточна ли комиссия и соответствует ли транзакция правилам протокола.

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

Подпись превращает подготовленную транзакцию в авторизованную транзакцию.

Приватные и публичные ключи

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

Публичный ключ математически связан с приватным ключом и может помочь подтвердить действительность подписи.

Адрес блокчейна обычно выводится из публичного ключа либо из скрипта или структуры аккаунта, связанных с владением ключом.

Приватный ключ должен навсегда оставаться секретным.

Публичным ключом или адресом можно делиться, чтобы другие пользователи могли проверять подписи или отправлять средства.

В официальной документации Bitcoin о кошельках объясняется, что программы-кошельки создают публичные ключи для получения сатоши и используют соответствующие приватные ключи для их расходования.

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

При потере приватного ключа пользователь может потерять доступ к средствам.

При краже приватного ключа злоумышленник может получить возможность подписывать транзакции и переводить средства.

Подписание транзакций безопасно только при безопасной генерации, хранении и использовании приватных ключей.

Цифровые подписи

Цифровая подпись подтверждает, что транзакция была авторизована владельцем корректного приватного ключа.

Подпись также помогает защитить транзакцию от изменений после подписания.

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

Это означает, что подписываемые данные так же важны, как и сама подпись.

Пользователь подписывает не расплывчатое намерение вроде «отправить немного криптовалюты».

Пользователь подписывает конкретные данные транзакции с определенными параметрами.

Именно поэтому интерфейсы кошельков должны показывать понятную информацию о подписании до подтверждения.

Подпись полезна, поскольку другие участники сети могут проверить ее, не зная приватного ключа.

Это обеспечивает децентрализованную валидацию без центрального сервера авторизации.

Цифровые подписи являются практической основой владения криптовалютой.

Подписание транзакций в Ethereum

Подписание транзакции Ethereum подтверждает транзакцию из внешнего аккаунта или в рамках другого поддерживаемого процесса работы с аккаунтом.

В официальной документации Ethereum о транзакциях объясняется, что транзакция — это криптографически подписанная инструкция от аккаунта.

Данные транзакции Ethereum могут включать nonce, получателя, value, входные данные, лимит газа, поля комиссии, ID цепи и поля подписи.

Nonce помогает упорядочивать транзакции одного аккаунта и не позволяет одной и той же транзакции многократно приниматься в одной последовательности аккаунта.

Поля газа определяют, сколько пользователь готов заплатить за выполнение и включение транзакции.

Поле данных может быть пустым для простого перевода ETH либо содержать данные вызова смарт-контракта.

Перевод токенов в Ethereum обычно представляет собой вызов токен-контракта, а не простое перемещение нативного ETH.

Это означает, что пользователь может подписать транзакцию с вызовом

, , , или другой функции контракта.

Таким образом, подписание в Ethereum может авторизовать простые платежи или сложные действия со смарт-контрактами.

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

Подписание транзакций в Bitcoin

Подписание транзакций Bitcoin отличается от сетей на основе аккаунтов, поскольку Bitcoin использует модель UTXO.

UTXO — это неизрасходованный выход транзакции, который можно использовать как вход в будущей транзакции.

В официальной документации Bitcoin о транзакциях объясняется, что транзакции позволяют пользователям расходовать сатоши и строятся из компонентов, поддерживающих простые и сложные платежи.

В Bitcoin подпись подтверждает, что отправитель вправе разблокировать определенные выходы.

Транзакция Bitcoin может содержать несколько входов, и для каждого входа могут требоваться собственные данные разблокировки или данные свидетеля.

Это означает, что кошелек Bitcoin может подписывать несколько частей транзакции, если она расходует несколько UTXO.

Подписи Bitcoin проверяются относительно условий блокировки расходуемых выходов.

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

Эта архитектура отличается от модели nonce аккаунтов Ethereum, однако основной принцип схож.

Приватный ключ или политика подписания должны авторизовать перемещение ценности.

Подписание транзакций в Solana

Для подписания транзакций Solana используются подписи аккаунтов, которые авторизуют инструкции транзакции.

В официальной документации Solana о транзакциях указано, что транзакция включает одну или несколько инструкций, подписи аккаунтов, авторизующих изменения, и недавний хеш блока.

Транзакции Solana могут требовать более одного подписанта, если инструкции должны быть авторизованы несколькими аккаунтами.

Solana обрабатывает инструкции в транзакции совместно.

Если одна инструкция завершается ошибкой, завершается ошибкой вся транзакция, а изменения состояния отменяются.

В официальной документации о структуре транзакций Solana объясняется, что первая подпись в массиве принадлежит плательщику комиссии и также служит ID транзакции.

Поэтому пользователи Solana часто видят слово «подпись» там, где в других экосистемах используется хеш транзакции или ID транзакции.

Пользователям следует понимать терминологию конкретной сети при проверке статуса транзакции.

Подпись транзакции Solana может идентифицировать транзакцию в сети.

Принцип подписания общий для всех сетей, однако каждая сеть по-разному структурирует транзакции.

Подписание транзакций и подписание сообщений

Подписание транзакций и подписание сообщений связаны, но отличаются друг от друга.

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

Подписание сообщения подтверждает контроль над адресом кошелька без обязательной отправки ончейн-транзакции.

Сайт может попросить пользователя подписать сообщение для входа, подтверждения владения кошельком или принятия условий.

Подписание сообщений может быть полезным, поскольку оно может не требовать комиссии за газ и не перемещать средства напрямую.

Однако подписание сообщений также может быть рискованным, если сообщение предоставляет разрешения, авторизует сделку, подписывает ордер или делегирует полномочия.

Официальный стандарт EIP-712 определяет метод хеширования и подписания типизированных структурированных данных вместо подписания только необработанных байтовых строк.

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

Для Bitcoin BIP-322 определяет универсальные форматы подписания сообщений для подтверждения контроля над адресами Bitcoin.

Подписанное сообщение не становится автоматически безопасным только потому, что не отправляет транзакцию в сеть.

Что именно подписывают пользователи

Пользователи подписывают структурированные данные, которые зависят от блокчейна и типа действия.

Для простого перевода нативной монеты подписываемые данные могут включать адрес назначения, сумму, комиссию, nonce или данные последовательности и информацию о цепи.

Для перевода токенов подписываемые данные могут включать вызов смарт-контракта для перемещения токенов.

Для разрешения подписываемые данные могут авторизовать контракт на последующее расходование токенов.

Для DeFi-сделки подписываемые данные могут включать информацию о маршруте свопа, лимиты проскальзывания, сроки и разрешения на токены.

Для листинга NFT подписываемые данные могут авторизовать ордер в стиле маркетплейса или разрешение на перевод.

Для делегирования аккаунта подписываемые данные могут разрешать другому контракту или механизму аккаунта действовать с особыми полномочиями.

Пользовательский интерфейс часто скрывает эту сложность за одной кнопкой подтверждения.

Это может быть опасно, если запрос кошелька непонятен.

Наиболее осторожные пользователи перед подтверждением спрашивают, какие именно полномочия создает подпись.

Защита от повторного воспроизведения

Защита от повторного воспроизведения предотвращает повторное использование действительной подписи в неподходящем контексте.

Без такой защиты транзакцию, подписанную для одной цепи или ситуации, можно было бы скопировать и отправить в другое место, если там принимаются такие данные.

Стандарт защиты от повторного воспроизведения Ethereum EIP-155 добавил ID цепи в подписание транзакций, чтобы транзакция одной цепи не работала в другой совместимой цепи с другим ID цепи.

Это важно, поскольку многие сети могут использовать похожие форматы адресов и структуры транзакций.

Подпись должна быть привязана к правильной цепи и контексту транзакции.

Современные запросы кошельков часто показывают сеть перед подписанием, поскольку контекст сети имеет значение.

Пользователям следует отклонять запросы на подписание с неожиданно указанной цепью.

Разработчикам следует включать идентификаторы цепи, nonce, сроки, домены и адреса контрактов там, где это уместно.

Защита от повторного воспроизведения — это не только техническая деталь.

Она защищает пользователей от использования подписей за пределами их предполагаемого назначения.

Nonce и порядок транзакций

Nonce — это число, которое помогает предотвращать повторное выполнение транзакций и упорядочивать транзакции одного аккаунта.

В Ethereum каждая транзакция из внешнего аккаунта использует nonce.

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

Именно поэтому пользователь может заменить ожидающую транзакцию при ее ускорении или отмене.

Такая замена не является магией.

Это другая подписанная транзакция с тем же nonce, но с иными условиями комиссии или параметрами действия.

Пользователям следует соблюдать осторожность при замене транзакций, поскольку они по-прежнему подписывают реальные данные транзакции.

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

Ошибки nonce могут привести к зависшим транзакциям, неудачным отправкам в сеть или непреднамеренным заменам.

Подпись вместе с корректным nonce помогает сети определить предполагаемую последовательность транзакций.

Газ, комиссии и подписанные транзакции

Подписание транзакции обычно включает данные, связанные с комиссией.

В Ethereum подписанные транзакции содержат поля газа и комиссии, определяющие сумму, которую отправитель готов заплатить.

В Bitcoin комиссии за транзакции связаны с размером транзакции и ставкой комиссии.

В Solana плательщик комиссии подписывает транзакцию и оплачивает базовую и любую приоритетную комиссию.

Комиссии важны, поскольку пользователь может подписать действительную транзакцию, которая никогда не подтвердится, если комиссия слишком низкая для текущих условий сети.

Комиссии также важны, поскольку вредоносный интерфейс может скрыть дорогостоящую транзакцию за запутанным запросом.

Перед подписанием пользователям следует проверять как перемещение актива, так и комиссию.

Разработчикам следует четко отображать оценку комиссий и обновлять ее при изменении условий сети.

Аппаратные кошельки и приложения-кошельки должны позволять легко понять, за что платит пользователь.

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

Подписание с аппаратным кошельком

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

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

Это снижает риск того, что вредоносное ПО на компьютере сможет напрямую похитить приватные ключи.

Это также предоставляет пользователю доверенный экран для проверки адресов, сумм и деталей транзакции.

Однако аппаратные кошельки не делают безопасной каждую подпись.

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

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

Аппаратные кошельки наиболее полезны для долгосрочного хранения, крупных балансов и тщательной проверки транзакций.

Они не заменяют понимание разрешений, вызовов контрактов и риска фишинга.

Устройство защищает ключ, но пользователь должен защищать свое решение о подписании.

Подписание с горячим кошельком

Горячий кошелек подписывает транзакции с устройства, подключенного к интернету.

К таким кошелькам относятся браузерные, мобильные, настольные кошельки и кошельки в приложениях.

Горячие кошельки удобны, поскольку упрощают частые транзакции.

Они также сильнее подвержены рискам вредоносного ПО, фишинга, вредоносных расширений браузера и компрометации устройства.

Горячий кошелек может хранить приватные ключи или ключевой материал на телефоне либо компьютере.

При компрометации такого устройства злоумышленники могут получить возможность подписывать транзакции или похищать секреты кошелька.

По возможности пользователям следует хранить в горячих кошельках только практичные для расходов суммы.

Для более крупных активов следует использовать аппаратные кошельки или более надежные схемы хранения.

Также следует разделять кошельки для повседневной активности и долгосрочного хранения.

При подписании криптовалютных транзакций удобство и безопасность часто противоречат друг другу.

Мультиподписное подписание транзакций

Мультиподписное подписание транзакций требует авторизации транзакции более чем одним ключом или подписантом.

В Bitcoin расходование средств с мультиподписью может требовать заданного количества подписей из большего набора ключей.

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

Мультисиг может снизить риск отказа одного ключа.

Например, для перевода средств из казначейства могут требоваться три подписи из пяти подписантов.

Это может защитить от одного украденного ключа, одного потерянного устройства или одного недобросовестного оператора.

Однако мультисиг добавляет сложность координации и операций.

Подписанты должны понимать, что именно они подтверждают.

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

Мультисиг-система настолько надежна, насколько надежны ее процесс подписания и дисциплина управления.

Подписание в кошельках на смарт-контрактах

Кошелек на смарт-контракте использует логику контракта, чтобы определить, авторизована ли транзакция или операция.

Это может поддерживать мультисиг-подтверждения, лимиты расходов, сессионные ключи, социальное восстановление, paymaster-механизмы и пакетные действия.

Кошельки на смарт-контрактах могут по-прежнему использовать подписи, но подпись проверяется логикой контракта, а не только базовыми правилами аккаунта.

При качественной реализации это может улучшить удобство и безопасность.

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

Пользователям следует понимать, кто может обновлять или контролировать кошелек на смарт-контракте.

Им следует регулярно проверять модули, делегатов, сессионные ключи и разрешения.

Разработчики должны делать запросы авторизации понятными и избегать скрытых полномочий.

Кошельки на смарт-контрактах делают подписание более гибким, но также усложняют значение подписи.

Пользователь может подписывать операцию, которую контрактный кошелек позднее выполнит по определенным правилам.

EIP-7702 и подписание делегирования

Новые функции аккаунтов Ethereum делают понимание подписания транзакций еще более важным.

В официальной документации Ethereum о транзакциях указано, что транзакции типа 4 были введены вместе с EIP-7702 в рамках обновления Ethereum Pectra.

В официальном руководстве Ethereum по EIP-7702 объясняется, что EIP-7702 позволяет внешним аккаунтам временно вести себя как аккаунты смарт-контрактов, устанавливая указатель на развернутый код с помощью нового типа транзакции.

Это может активировать полезные функции, такие как пакетирование, спонсирование и обновления в стиле аккаунтов.

Это также может сделать запросы на подписание более чувствительными, поскольку делегирование способно изменить поведение аккаунта.

Подпись в стиле делегирования может авторизовать больше, чем один простой перевод.

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

Подписывать такие запросы следует только от доверенных приложений и после понимания их охвата.

Кошельки должны ясно объяснять, что делает делегирование и как его отозвать.

По мере развития функций аккаунтов безопасное подписание требует большего, чем проверка адреса получателя.

Слепое подписание

Слепое подписание означает подтверждение транзакции или сообщения без понимания удобочитаемого значения данных.

Это может происходить, когда кошелек не может четко декодировать данные вызова контракта.

Это также возможно, когда аппаратный кошелек отображает только хеш или непонятные поля.

Слепое подписание рискованно, поскольку пользователь может не знать, какие полномочия он предоставляет.

Вредоносный сайт может показывать безобидную кнопку, пока кошелек подписывает опасное разрешение или перевод актива.

Пользователям следует по возможности избегать слепого подписания.

Им следует использовать кошельки, которые четко декодируют транзакции.

Им следует проверять сайт, адрес контракта, токен, сумму, сеть и разрешения.

Следует отклонять запросы, которые невозможно понять.

Если транзакция важна и непонятна, безопаснее не подписывать ее, пока действие не будет проверено.

Подписание типизированных данных

Подписание типизированных данных облегчает понимание офчейн-подписей, присваивая структурированным полям названия и типы.

EIP-712 — наиболее известный стандарт Ethereum для подписания типизированных структурированных данных.

В официальном стандарте EIP-712 указано, что это стандарт хеширования и подписания типизированных структурированных данных вместо простых байтовых строк.

Это помогает кошелькам показывать такие сведения, как домен, получатель разрешения на расходование, сумма, срок, токен или поля ордера.

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

Однако читаемые данные не означают, что они автоматически безопасны.

Типизированное сообщение все еще может авторизовать расходование токенов, листинг на маркетплейсе, действие делегата или исполнение ордера.

Пользователям следует читать каждое поле перед подписанием.

Разработчикам следует использовать понятные названия, точные домены, ID цепей, адреса проверяющих контрактов и сроки.

Хороший дизайн типизированных данных снижает риск фишинга, но не устраняет его.

Подписи Permit

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

Процессы в стиле Permit могут улучшить пользовательский опыт, сокращая количество транзакций и расходы на газ.

Они распространены в разрешениях на токены, DeFi-свопах и интеграциях кошельков.

Однако Permit может быть опасным, поскольку пользователь может считать, что подписывает безобидное сообщение, хотя фактически разрешает расходование токенов.

Permit обычно включает такие сведения, как владелец, получатель разрешения на расходование, значение, nonce, срок и токен-контракт.

Если получатель разрешения на расходование действует злоумышленно, а Permit действителен, он может использовать его для перемещения токенов в рамках одобренного объема.

Пользователям следует относиться к подписанию Permit так же, как к разрешению на токены.

Им следует проверять адрес получателя разрешения на расходование, токен, сумму, срок и сайт.

Разработчикам следует делать запросы Permit понятными и по возможности ограничивать суммы разрешений.

Подписи Permit показывают, почему подписание сообщений может иметь финансовое значение даже без немедленной ончейн-транзакции.

Подписание транзакций и разрешения на токены

Разрешения на токены — один из важнейших рисков подписания в криптовалюте.

Когда пользователь одобряет смарт-контракт, он может разрешить этому контракту расходовать токены позднее.

Небольшое действие в DeFi может начаться с крупной транзакции разрешения.

Если контракт вредоносный, разрешение может быть использовано для вывода одобренных токенов.

Если контракт позднее будет скомпрометирован, старые разрешения могут стать опасными.

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

Им следует проверять и отзывать старые разрешения, когда они больше не нужны.

Им следует использовать отдельные кошельки для высокорисковой активности в dApp и долгосрочного хранения.

Кошельки должны четко маркировать разрешения и предупреждать, если разрешение безлимитно или необычно широко.

Подписание разрешения может быть столь же рискованным, как подписание перевода.

Подписание транзакций и NFT

Подписание NFT-транзакций может авторизовать переводы, листинги, разрешения, ставки, минтинг, сжигание или ордера маркетплейса.

NFT-мошенничество часто направлено на то, чтобы обманом заставить пользователей подписать разрешения, а не напрямую похитить приватные ключи.

Пользователь может подписать транзакцию, разрешающую контракту переместить один NFT или целую коллекцию.

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

Фальшивый сайт минтинга может попросить пользователя подписать транзакцию, которая на самом деле переводит ценные NFT.

Перед подписанием пользователям следует проверять страницы коллекций, адреса контрактов, охват разрешений и детали ордеров маркетплейса.

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

Аппаратный кошелек может помочь защитить ключ, но не может определить, безопасно ли разрешение NFT.

Безопасность подписания NFT зависит от чтения запроса и понимания предоставляемого разрешения.

Наиболее опасные подписи NFT часто выглядят как обычные.

Подписание транзакций и DeFi

Подписание транзакций DeFi часто связано со сложными вызовами смарт-контрактов.

Одно действие пользователя может включать разрешение на токены, выполнение свопа, перемещение ликвидности, внесение обеспечения, заимствование, погашение, стейкинг или перевод через мост.

Многие транзакции DeFi атомарны, то есть либо все включенные шаги выполняются успешно, либо завершается ошибкой вся транзакция.

Это может быть полезно, но также усложняет понимание запроса на подписание.

Пользователям следует проверять URL протокола, токен-контракты, ожидаемую сумму, минимально получаемую сумму, проскальзывание, срок и сумму разрешения.

Им следует осторожно относиться к незнакомым токенам и пулам.

Им следует избегать подписания транзакций по скопированным ссылкам или из личных сообщений.

При доступности им следует рассмотреть использование симуляций и предварительного просмотра транзакций.

Разработчики должны делать запросы на подписание DeFi понятными и не скрывать высокорисковые разрешения.

DeFi превращает подписание транзакции в финансовое решение, а не только техническое действие.

Подписание транзакций и мосты

Транзакции с мостами часто требуют подписания в одной цепи для блокировки, сжигания, минтинга, разблокировки или получения активов в другой цепи.

Это может включать несколько транзакций и несколько подписей.

Мост может попросить пользователя одобрить токен, внести его в контракт моста, дождаться подтверждений и получить представление актива в другой сети.

Каждый этап подписания имеет собственный риск.

Разрешение может подвергнуть токены риску.

Депозит может отправить активы в контракт.

Получение может взаимодействовать с другой цепью и другим форматом адресов.

Пользователям следует проверять URL моста, адреса контрактов, поддерживаемые маршруты, комиссии, предположения об окончательности и кошелек назначения.

По возможности им следует отправлять небольшую тестовую сумму.

Подписание для мостов добавляет кроссчейн-сложность, поэтому пользователям не следует спешить с запросами.

Подписание транзакций и фишинг

Фишинговые атаки часто пытаются заставить пользователей подписать что-то опасное.

Злоумышленник может использовать фальшивый аирдроп, фальшивый минтинг, поддельную страницу поддержки, фальшивую панель стейкинга, поддельное предупреждение кошелька или фальшивый сброс разрешений.

Целью может быть заставить пользователя подписать разрешение на токены, разрешение NFT, Permit, делегирование или прямой перевод.

Фишинг может сработать, даже если приватный ключ никогда не покидает кошелек.

Злоумышленнику достаточно, чтобы пользователь подписал неправильные данные.

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

Им не следует подключать кошельки к сайтам, которым они не доверяют.

Им следует отклонять неожиданные запросы на подписание.

Никогда не следует передавать сид-фразы, слова восстановления, приватные ключи или файлы резервных копий кошелька.

Безопасность подписания начинается еще до появления запроса кошелька.

Подписание транзакций и вредоносное ПО

Вредоносное ПО может атаковать процесс подписания транзакций несколькими способами.

Вредоносное ПО буфера обмена может заменить скопированный адрес адресом злоумышленника.

Вредоносное ПО браузера может изменять то, что отображает сайт.

Поддельное программное обеспечение кошелька может создавать вредоносные запросы транзакций.

Кейлоггеры могут похищать пароли или секреты горячих кошельков.

Атаки с наложением экрана могут скрывать реальные детали транзакции.

Вредоносное ПО удаленного доступа может управлять кошельком, пока пользователь отвлечен.

Аппаратные кошельки помогают снизить некоторые риски вредоносного ПО, поскольку приватный ключ остается на устройстве.

Однако пользователи все равно должны проверять адрес и сумму на экране доверенного устройства.

Риск вредоносного ПО — одна из причин, по которой подписание транзакций никогда не следует считать привычным действием в один клик.

Подписание транзакций и отзыв разрешений

Подписанную транзакцию обычно нельзя отозвать после ее ончейн-подтверждения.

Однако некоторые разрешения, созданные подписями, позднее можно уменьшить.

Разрешения на токены часто можно отозвать или снизить, отправив другую транзакцию.

Сессионные ключи иногда можно удалить через настройки кошелька.

Для делегирования могут существовать механизмы отзыва в зависимости от системы аккаунтов.

Листинги маркетплейса могут быть отменены, если дизайн маркетплейса поддерживает отмену и ордер еще не исполнен.

Пользователям следует понимать, создает ли подпись одноразовое действие или постоянное разрешение.

Им следует регулярно проверять активные разрешения и полномочия.

При подозрении на вредоносное разрешение или делегирование следует действовать быстро.

Отзыв полезен, но не может вернуть активы, уже перемещенные по действительной подписи.

Подписание транзакций и неудачные транзакции

Подписанная транзакция все равно может завершиться ошибкой.

Это может произойти, если на аккаунте недостаточно средств для комиссии.

Это может произойти из-за неправильного nonce.

Это может произойти, если не выполнено условие контракта.

Это может произойти из-за слишком высокого проскальзывания или истечения срока.

Это может произойти, если лимит газа или оценка ресурсов были слишком низкими.

Это может произойти, если пользователь подписал транзакцию в неправильной цепи.

Это может произойти, если разрешение на токены или баланс изменились до выполнения.

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

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

Подписание транзакций и конфиденциальность

Подписи транзакций могут раскрывать модели активности, связанные с адресом кошелька.

В публичных блокчейнах подписанные транзакции обычно становятся видимыми всем после отправки и подтверждения.

Наблюдатели могут анализировать адреса, суммы, время, перемещения токенов, разрешения и взаимодействия со смарт-контрактами.

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

Подписанное сообщение для входа может подтвердить сервису контроль над кошельком, а сервис может связать кошелек с профилем пользователя.

Пользователям, которым важна конфиденциальность, следует разделять кошельки по назначению.

Им следует избегать входа на ненужные сайты с помощью кошельков для долгосрочного хранения.

Им следует избегать повторного использования адресов, если архитектура цепи и кошелька поддерживает более надежные практики конфиденциальности.

Им следует понимать, что подписание транзакций часто создает публичные записи.

Надежная конфиденциальность начинается с разделения кошельков до подписания.

Рекомендации для пользователей

Проверяйте сайт или приложение перед подключением кошелька.

Проверяйте сеть перед подписанием.

Читайте тип транзакции перед подтверждением.

Подтверждайте адрес получателя и сумму.

Внимательно проверяйте суммы разрешений на токены.

Отклоняйте непонятные запросы на слепое подписание.

Используйте аппаратный кошелек для крупных балансов.

Используйте отдельные кошельки для долгосрочного хранения и высокорисковой активности в dApp.

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

Никогда не передавайте приватные ключи, сид-фразы, слова восстановления или файлы резервных копий кошелька.

Рекомендации для разработчиков

Делайте запросы на подписание понятными и удобочитаемыми.

Используйте стандарты типизированных данных, когда они улучшают понимание пользователей.

При необходимости включайте ID цепей, адреса контрактов, nonce, сроки и разделители доменов.

По возможности ограничивайте суммы разрешений.

Не просите пользователей подписывать широкие разрешения без понятного объяснения.

По возможности отображайте симуляции и предварительный просмотр транзакций.

Предупреждайте пользователей, когда подпись создает постоянные полномочия.

Тестируйте процессы подписания в разных кошельках и на разных устройствах.

Безопасно обрабатывайте неудачные подписи и отклоненные запросы.

Проектируйте процессы подписания с учетом устойчивости к фишингу.

Распространенные ошибки при работе с подписанием транзакций

Первая ошибка — считать подпись лишь подтверждением входа.

Некоторые подписи могут авторизовать реальные финансовые действия.

Вторая ошибка — считать, что аппаратный кошелек делает безопасной любую подпись.

Аппаратный кошелек защищает ключ, но все равно может подписать опасную транзакцию, если пользователь ее подтвердит.

Третья ошибка — игнорировать разрешения.

Разрешение может позволить контракту позднее перемещать токены.

Четвертая ошибка — подписывать в неправильной сети.

ID цепи, название сети и проверяющий контракт могут изменить значение подписи.

Пятая ошибка — доверять непонятным запросам кошелька.

Если запрос невозможно понять, пользователю не следует подписывать его, пока действие не будет проверено.

FAQ

Что такое подписание транзакции в криптовалюте?

Подписание транзакции — это процесс использования приватного ключа для создания цифровой подписи, авторизующей блокчейн-транзакцию.

Раскрывает ли подписание транзакции мой приватный ключ?

Нет, корректное подписание транзакции создает подпись без раскрытия приватного ключа.

Можно ли украсть средства, имея только подпись?

Да, если подпись авторизует перевод, разрешение, Permit, ордер или делегирование, предоставляющие злоумышленнику применимые полномочия.

Подписание сообщения — это то же самое, что подписание транзакции?

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

Почему кошелек просит меня подписать что-либо?

Кошелек запрашивает подпись, когда приложению необходимо подтверждение контроля над кошельком или авторизация транзакции, сообщения, разрешения, ордера либо действия со смарт-контрактом.

Что такое слепое подписание?

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

Опасно ли слепое подписание?

Да, слепое подписание опасно, поскольку пользователь может подтвердить перевод, разрешение или вызов контракта, не понимая его.

Что такое защита от повторного воспроизведения?

Защита от повторного воспроизведения предотвращает повторное использование действительной подписи в другой цепи или контексте, для которых она не предназначалась.

Что такое nonce при подписании транзакции?

Nonce — это число, используемое для упорядочивания транзакций и предотвращения их повторного выполнения с одного аккаунта.

Может ли подписанная транзакция завершиться ошибкой?

Да, подписанная транзакция может завершиться ошибкой из-за недостаточной комиссии, неправильного nonce, отмены контрактом, истекших сроков, проскальзывания или других правил сети.

Можно ли отменить подписанную транзакцию?

В некоторых сетях можно заменить ожидающую транзакцию, но подтвержденная транзакция обычно необратима.

Можно ли отозвать подпись?

Нельзя удалить подпись после ее создания, но можно иметь возможность отозвать разрешение или одобрение, созданное подписью, если система поддерживает отзыв.

Безопаснее ли подписание с аппаратным кошельком?

Подписание с аппаратным кошельком обычно безопаснее для защиты ключа, однако пользователи все равно должны проверять детали транзакции перед подтверждением.

Что следует проверить перед подписанием?

Следует проверить сайт, сеть, получателя, сумму, токен, адрес контракта, сумму разрешения, комиссию, срок и охват разрешений.

Какое правило является самым безопасным при подписании транзакций?

Самое безопасное правило — никогда не подписывать то, чего вы не понимаете, особенно разрешения, Permit, делегирования и запросы на слепое подписание.

Заключение

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

Он позволяет пользователям авторизовать переводы и действия со смарт-контрактами без раскрытия приватных ключей.

Действительная подпись подтверждает, что корректный ключ одобрил конкретные данные транзакции.

Разные блокчейны по-разному структурируют подписанные транзакции, но основной принцип одинаков в Bitcoin, Ethereum, Solana, TRON и многих других сетях.

Подписание транзакций важно, поскольку устраняет необходимость в централизованном органе, использующем пароли.

Оно также рискованно, поскольку действительная подпись может перемещать активы, разрешать расходование токенов, выставлять NFT на продажу, делегировать контроль над аккаунтом или взаимодействовать со сложными контрактами.

Пользователям следует считать каждый запрос на подписание важным решением в области безопасности.

Перед подтверждением им следует проверять приложение, сеть, контракт, адрес, сумму, комиссию и охват разрешений.

Разработчикам следует создавать процессы подписания, которые понятны, ограничены, защищены от повторного воспроизведения и устойчивы к фишингу.

Аппаратные кошельки, подписание типизированных данных, мультисиг, кошельки на смарт-контрактах и абстракция аккаунтов могут повысить безопасность при правильном использовании.

Ни один из этих инструментов не устраняет необходимость в тщательной проверке.

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