🏀 Пояснительная записка насчет покупок НФТ

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

Я сейчас затаймстемпил скриншота обсуждения от 28 апреля (sha256: 1ace43ae5ab1ea064ada6ae11dd423ca5cb6898748374b5963612a6a23727002) на случай если у кого-то возникнет желание исказить информацию. Транзакция тут.

Подробное объяснение:

Cейчас кошелек имеет стандартное поведение, совместимое с веб-воллетом и реализацией в Ton Web.

1. Когда нажимается ссылка или сканируется QR-код, то кошелек берет адрес в той форме, в которой сканировал.
2. Если raw, то в TonWeb.Address по-умолчанию стоит isBounceable=false,
3. Далее, проверяется, если контракт uninitialized. Если да, тогда принудительно ставится флаг bounceable=false чтобы депозит прошел. Это как раз на частый случай свежесозданных кошельков, с которых еще никто не тратил. Потому что иначе невозможно задепозировать вообще - сообщение отскочит т.к. нет кода для его обработки.
4. Если контракт задеплоен, то используется флаг из адреса — такой, какой выставил хозяин контракта.

Что случилось с минтингом ARL?

По дизайну контракта продажи, первая входящая транзакция обрабатывалась успешно, а на остальные выдавалась простая ошибка. Расчет был на то, что в адресе будет флаг bounceable=true и все, кто на секунду позже заслали денег получат предсказуемый отлуп и их деньги автоматически вернутся. Однако из-за ошибки разработчиков, они на некоторое время под QR код положили адрес в raw-формате (т.е. где есть только номер аккаунта, без дополнительных флагов). Стандартное поведение TonWeb и Тонкипера при этом — выставить bounceable=false, что и было сделано.

Причем тут проверка на uninit? Нипричем, контракт был уже задеплоен и в тонкипере на шаге (3) флаг bounceable не переключался на false.

Но раз статья говорит о баунс флагах и проверке на uninit, то ниже мое мнение на этот счет.

Почему и как нужно проверять состояние контракта init/uninit?

Если не делать проверку на uninit, то нужно рассчитывать на то, что кошелек будет показывать адрес с bounceable=false пока у него незадеплоенный контракт. Этого не происходит, например, с wallet.ton.org. Причина для этого адекватная: адрес должен быть стабильный и предсказуемый. А для пользователя "просто кошелька" совершенно не важно знать что в ТОНе есть какие-то сообщения, деплои и баунсы. Ему нужно установить апп, получить денег, переслать денег. Это самая базовая из базовых функций, которая должна Просто Работать™.

Более того, допустим кошелек вначале показывает адрес bounceable=false. Его во-первых, могут сразу записать в таком виде в тетрадку и посылать всегда с таким флагом, даже после того, как контракт уже задеплоен. Во-вторых, если было безопасно посылать с bounceable=false, то почему оно станет небезопасно после деплоя? Накопленные коины до деплоя не имеют никаких следов и задеплоенный контракт не сможет понять куда какие коины нужно разложить.

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

Чего не нужно делать

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