Как перевести предмет между кошельками с мобильного кошелька

Перевести предмет между кошельками с мобильного кошелька технически одинаково и для чужого адреса, и для собственного: вызывается функция контракта коллекции, запись о владении меняет адрес. Разница в подготовке. Продажи нет, значит и роялти не возникает. Но сеть не знает, что второй адрес ваш, поэтому опечатка необратима так же, как при отправке постороннему. Главная работа делается до подписи: подтвердить владение вторым адресом и прочесть усечённые поля окна.

Что происходит с сегментом сейчас

Предметы живут по двум стандартам. ERC-721 имеет статус Final и создан 24 января 2018 года: один идентификатор — один неделимый предмет. ERC-1155 тоже Final, создан 17 июня 2018 года, и допускает, чтобы один контракт держал и неделимые предметы, и делимые балансы под разными идентификаторами. Мобильный кошелёк показывает их по-разному, и это первое, что стоит опознать перед отправкой.

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

Как перевести предмет между кошельками с мобильного кошелька: отличие от отправки другому

Отличий три, и ни одно не делает операцию безопаснее. Разберём по порядку.

Первое — экономическое. Роялти при переводе себе не возникает, и это прямо следует из стандарта: ERC-2981 в статусе Final от 15 сентября 2020 года указывает, что выплата роялти добровольна, поскольку функции переноса включают перемещение предметов между кошельками и их исполнение не всегда означает продажу. Там же сказано прямее: невозможно знать, какие переводы вызваны продажей, а какие — консолидацией собственных кошельков. Отсюда вывод для расчёта: перевод себе не создаёт ни обязательства по роялти, ни подтверждения цены предмета.

Второе — техническое. Площадки в операции нет, расчёта нет, посредника нет: вызывается функция контракта. В ERC-721 это transferFrom и две версии safeTransferFrom, одна из которых принимает дополнительные данные. Безопасная версия после переноса проверяет, является ли получатель контрактом, и если да — вызывает у него onERC721Received, ожидая строго определённое возвращаемое значение. Обычный transferFrom такой проверки не делает. Перенос на нулевой адрес стандарт запрещает.

Третье — доказательное, и оно же самое неприятное. Сеть не различает ваши адреса и чужие. Ключ есть — предмет ваш. Ключа нет — предмета нет. Фраза «это же мой кошелёк» не имеет силы: если ключа к адресу у вас нет, предмет недоступен, и отменить перенос нельзя ничем.

Как подтвердить принадлежность второго адреса

Три проверки, по возрастанию надёжности. Делаются один раз на кошелёк и запоминаются навсегда.

Проверка контрольной суммы идёт первой. ERC-55 в статусе Final от 14 января 2016 года описывает запись адреса смешанным регистром: регистр каждой буквы определяется битом хеша. Стандарт приводит цифры — в среднем 15 контрольных бит на адрес и вероятность 0,0247%, что случайно опечатанный адрес пройдёт проверку; это примерно в 50 раз лучше прежней схемы ICAP. Если кошелёк показывает адрес целиком строчными буквами, контрольной суммы в нём нет.

Подпись сообщения — вторая проверка и единственная, которая доказывает владение ключом, а не знание адреса. Откройте второй кошелёк, подпишите произвольную строку, сверьте восстановленный адрес. Стандарт EIP-712 в статусе Final от 12 сентября 2017 года появился ровно из этой проблемы: подписываемое сообщение показывалось пользователю непрозрачной шестнадцатеричной строкой без контекста. Домен подписи содержит имя, версию, идентификатор сети и адрес проверяющего контракта — набор, который не даёт повторно применить подпись ни в другом приложении, ни в другой сети.

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

Издержки: комиссии, роялти, газ

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

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

Пошаговый сценарий с телефона

1. Опознайте стандарт предмета и адрес его контракта. От стандарта зависит, пойдёт перенос одним вызовом или несколькими.
2. Подпишите на втором кошельке произвольное сообщение и сверьте восстановленный адрес с тем, на который собираетесь отправлять.
3. Сверьте адрес получателя целиком, по средним знакам, а не по первым и последним. Убедитесь, что сеть в окне та же, в которой живёт предмет.
4. Отправьте на второй адрес минимальную сумму нативной монеты и верните её обратно, чтобы проверить способность подписывать операции.
5. Подтвердите перенос предмета, предварительно раскрыв в окне скрытые поля: адрес контракта, идентификатор, метод вызова.
6. Проверьте по обозревателю, что владение числится за новым адресом, и зафиксируйте идентификатор операции у себя.

Что видно в окне подтверждения на малом экране

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

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

Риски и мошеннические схемы сегмента

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

Третий сценарий — одинаковая строка адреса в разных сетях. Адрес существует, но предмет уехал не туда, где вы его ждёте, и доступ зависит от того, контролируете ли вы тот же ключ в другой сети. Четвёртый — подпись не того действия: на малом экране разрешение для сторонней стороны и перенос предмета выглядят похоже, а последствия разные. Правило короткое по форме и неудобное в исполнении: не подписывайте ничего, пока не раскрыли все скрытые поля.

До переноса имеет смысл пересчитать, что вообще лежит на адресе: часть записей появляется там без вашего участия, и логика их появления разобрана в материале о том, как участвовать в бесплатной раздаче предметов. Полезно и помнить, что модель владения бывает устроена иначе: разбор про Bitcoin Ordinals и цифровые артефакты на базовом слое показывает вариант, где предмет не отделён от самой монеты, и перенос там подчиняется другим правилам.

Итог

• Стандарт предмета и адрес контракта опознаны до начала операции.
• Владение вторым адресом подтверждено подписью сообщения, а не записью в заметках.
• Адрес получателя сверен по средним знакам, а не по первым и последним четырём.
• Сеть в окне подтверждения совпадает с сетью, в которой живёт предмет.
• На втором адресе есть нативная монета для оплаты будущих операций.
• Скрытые поля окна раскрыты: адрес контракта, идентификатор, метод вызова.
• Идентификатор операции сохранён, запись о владении проверена по обозревателю.

Частые вопросы