375 тысяч причин улучшить ERC20Поскольку монеты самых мощных платформ, таких как EOS, Basic Attention Token (BAT), и Storj, выпускаются по стандарту ERC20, глупо отрицать, что успех криптовалюты во многом зависит от интерфейса контракта.
Сообщество Ethereum четко придерживалось этого стандарта. Разработчики и финансовые рынки также реагируют на этот стандарт вполне положительно. Однако, несмотря на всеобщее признание, стандарт ERC20 имеет один существенный недостаток:
Стандарт ERC20, который описывает правила работы электронных монет (токенов), приводит к тому, что конечный пользователь теряет деньги! Это происходит потому, что стандарт позволяет отправлять монеты ERC20 на адреса, не поддерживающие ERC20-монеты.
Когда пользователь отправляет электронную монету, выпущенную по стандарту ERC20, на контракт Ethereum, который не ожидает монеты ERC20, пользователь теряет доступ к своим виртуальным активам навсегда. Только представьте, сколько на данный момент активов заблокировано из-за этой проблемы!
Эти цифры нельзя назвать малозначительными 🔸 310,067 GNT застряло в контракте Golem (в долларах это – 217 тысяч).
🔸 242 REP заблокировано в контракте Augur на общую сумму свыше $15000.
🔸 814 DGD застряло в контракте Digix DAO (это примерно $125000).
🔸 14,506 1ST навсегда увязли в контракте FirstBlood, что составляет около $12000.
Получается, что в этих контрактах на данный момент
заморожено свыше 370 тысяч долларов – просто безумные деньги! Учитывая, что число монет, выпущенных на базе ERC20, только растет, эта цифра, скорее всего, намного выше.
Кстати, список, приведенный выше, далеко не исчерпывающий – это статистика по наиболее популярным монетам на базе ERC20.
Ни один из вышеперечисленных контрактов не предназначен для получения монет ERC20. Когда пользователь отправляет токены по адресам этих контрактов, все транзакции подтверждаются сетью.
Однако принимающий контракт не распознает отправленные токены. Он просто не знает, что с ними делать, и это приводит к тому, что средства становятся заблокированными навсегда. Опять же, монеты не отвергаются, но просто игнорируются принимающим контрактом!
Большинство таких транзакций непреднамеренно совершается конечными пользователями, которые используют в контракте функцию под названием transfer function или «функция передачи» (человека в системе «человек-машина»). Она является противоположной функции автоматической передачи transferFrom, введенной ранее.
Напомним, что стандарт ERC20 использует обе функции, как Transfer, так и TransferFrom. Как оказалось, некоторые конечные пользователи используют Transfer для прямой отправки монет ERC20 в контракты, которые не ожидают поступления, и, следовательно, не распознают входящие токены.
В конце концов, несколько членов сообщества Ethereum решили заняться этим вопросом, как только стали поступать запросы на новый стандарт ERC для токенов. На GitHub обращение в обратную связь по поводу нового стандарта виртуальных монет было зарегистрировано под номером 223.
Как появился стандарт ERC223Dexaran, пользователь веб-хостинга GitHub, предложил новый ERC стандарт (ERC223) еще 5 марта 2017 года с целью исправить все несовершенства существующего на тот момент стандарта ERC20.
Вот отрывок из его обращения на GitHub под номером 223 (
https://github.com/ethereum/EIPs/issues/223), где он предлагает новый стандарт для электронных монет:
«Нижеследующее описывает стандартные функции, которые контракты, работающие с несколькими или только с одним определенным токеном, могут внедрить, чтобы предотвратить случайное отправление токенов в контракты. Транзакции в таких контрактах будут осуществляться по аналогии с транзакциями ether».
Согласно предложению Dexaran, новый стандарт криптовалютных монет приобретет две основные функции, чтобы немедленно остановить пользователей децентрализованных приложений от случайной отправки токенов на смарт-контракты, которые не готовы принимать отправляемые активы.
А именно 1. Объединение двух функций
Transfer и TransferFrom стандарта ERC20 в одну функцию под названием
Transfer с тремя параметрами (address _to, uint _value, bytes data).
2. Принимающий контракт. Если контракт принимает монеты, он должен иметь функцию
TokenFallBack, которая определит тип отправляемых монет.
Функции Transfer и TransferFrom объединяются в TransferКлючевой особенностью стандарта ERC20, которая также внесла свою лепту в возникновение общей проблемы, является то, что конечные пользователи могут ошибочно использовать одну из двух функций для отправки монет (Transfer и TransferFrom).
Новый стандарт ERC223 предлагает заменить обе функции на одну функцию под названием Transfer.
Стандарт ERC223 позволяет конечным пользователям децентрализованных приложений отправлять криптомонеты на любой Ethereum-адрес, независимо от того, является ли контракт кошельком или контрактом с такой же функцией Transfer.
Логика здесь заключается в том, что, исключив возможность для пользователей запускать функцию Transfer или TransferFrom, и объединив обе функции в одну (Transfer), конечные пользователи больше не могут использовать неправильную функцию.
Новая предложенная функция Transfer имеет три параметра (предыдущая имела только два), но главное то, что эта функция может вызывать функцию TokenFallback у принимающего адреса. Без трех указанных параметров, функция Transfer не способна компилировать.
Если получающий адрес не содержит функцию TokenFallback, транзакция с функцией Transfer не состоится, и монеты не будут отправлены.
Функция TokenfallbackУ платформы Ethereum есть модификатор контрактов payable, используемый для того (
http://solidity.readthedocs.io/en/develop/contracts.html), чтобы подготовить контракт к получению эфиров.
Это означает, что контракт теперь сможет принять цифровую валюту. Если у контракта нет модификатора payable, начатая транзакция попросту отменяется и возвращается. Ничего особенного, это же Ethereum 101.
Функция tokenFallback в стандарте ERC223 работает точно так же: если модификатор payable подготавливает контракт для принятия монет Ether, то функция tokenFallback подготавливает контракт для принятия монет X (то есть, любых, которые отправляют).
В этом стандарте разработчики контрактов должны реализовать функцию tokenFallback, если они хотят, чтобы их контракты работали с определенными токенами.
Если получатель не является адресом контракта, транзакция с монетами ERC223 будет осуществляться точно так же, как и с монетами ERC20.
С другой стороны, если получателем является контракт, тогда контракт с токенами ERC223 будет сначала вызывать функцию tokenFallback в контракте-получателя. Если функция tokenFallback не обнаружится, транзакция не состоится.
Эволюция ERCХотя разработка стандарта ERC223 еще не завершена, на горизонте вырисовывается еще один стандарт ERC – ERC 721. ERC721 ориентирован на не взаимозаменяемые активы, таких как CryptoKitties, Decentraland land и даже, возможно, однодневные активы в недвижимости.
Ознакомиться с ERC 721, стандартом невзаимозаменяемого токена, можно здесь (
https://github.com/ethereum/eips/issues/721).
Подытожим. Молодое сообщество Ethereum всячески старается улучшить свою платформу на базе умных контрактов, устанавливая правильные стандарты перед растущей волной новых разработчиков.
Медленно, но верно, ошибки криптомонет стандарта ERC будут устраняться, а вопросы так и будут появляться, например, сможет ли самый последний стандарт масштабироваться?
Latest news: 
. 
. 
. 
. 
. 
. 
Shop
Bidding Open
Topic: Стандарт ERC223 – обновленная версия ERC20? (Read 1669 times)