ERC223: как мы выбирали стандарт токена MUST

Публикация и аудит нашего первого смарт-контракта остановились, не успев начаться. Созданный в логике наиболее распространённого протокола ERC20, он должен был обеспечить проекту абсолютную совместимость со всей инфраструктурой рынка токенов - биржами, включая децентрализованные, и криптовалютными кошельками. Однако уже в ближайшей перспективе, сразу после token sale, механика токена предусматривает автоматическое сжигание монет при их использовании внутри платформы MUST. Как выяснилось, особенности протокола не позволяют реализовать такую автономную бизнес-логику на смарт-контракте.

Шорт-лист кандидатов на то, чтобы украсить гордое имя MUST, включал в себя следующие стандарты: ERC223, ERC677, ERC777 и ERC827. Если исключить десятки страниц командных обсуждений в мессенджерах, споров и выяснений с переходом на личности, мы определили несколько ключевых пунктов, определивших конечный выбор.

Главной претензией к протоколу ERC20 является то, что он допускает потерю монет при переводе на контракт, не имеющий методов снятия токенов - контракт, не запрограммированный на работу с этим стандартом заморозит всю сумму перевода навсегда. По состоянию на конец декабря пользователь github под ником Dexaran, который и предложил стандарт ERC223, обнаружил замороженные в контрактах популярные токены QTUM, EOS, GNT, STORJ, TRONIX, DGD и OMG на сумму свыше трёх миллионов долларов. Однако, должная предусмотрительность разработчиков как правило сводит вероятность таких транзакций к ничтожно малому числу - сумма потерь не идет ни в какое сравнение с общей капитализацией этих монет.

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

Наконец, третье и главное в нашем случае - распространённость контракта, поскольку MUST планирует листинг сразу после token sale. Если в том, что касается кода, можно искать компромиссы и быть хоть сколько-то гибким, то в случае, когда этот код не поддерживают биржи и кошельки, гибкость не поможет. Анализируя эти протоколы, мы выяснили, что наиболее распространённым является ERC223 - он используется в 30 живых проектах, пять из которых прошли листинг на крупных биржах, включая децентрализованные (https://github.com/ethereum/EIPs/issues/223#issuecomment-396080355). Второй по популярности альтернативный стандарт ERC677 обнаружил лишь один живой проект, активный на хотя бы раз на протяжении трёх дней.

Оценив риски, мы остановились на компромиссном варианте. Токен MUST реализован на 223-м протоколе, что одновременно решает и функциональные задачи, и не создаёт рисков для ликвидности нашей основной единицы.