Возможно, это и так… где-то в идеальном мире.
Контракты в основном выступают в качестве контролеров-посредников, снижая ценность децентрализации. Токены и умные контракты добавляют системе сложности, а потому и повышают вероятность сбоя. Поэтому они требуют наличия в себе «административных» бэкдоров.
Одной из основ (или, скорее, обещаний) криптовалют, давшей им изначальный толчок, была способность отказаться от отношений с финансовыми институтами в пост-наличном обществе и способности совершать сделки без посредника. В некотором смысле, это способ уйти от статуса-кво нынешней денежной системы.
Итак, на чем основана эта свобода?
В первую очередь, это неспособность какой-либо отдельной стороны совершать сделки с деньгами, которые им не принадлежат.
В Биткойне (и в некоторых токенизированных биткоин-системах, таких как цветные монеты) это достигается за счет того, что каждый транзактор должен иметь возможность «разблокировать» вывод предыдущей транзакции, удовлетворяя требованиям предыдущего транзактора. Чаще всего, это означает, что они должны продемонстрировать владение соответствующим закрытым ключом, подписав новую транзакцию.
Поскольку гарантии, предоставляемые такими транзакциями, повсеместно понимаются и соблюдаются участниками блокчейна, мы можем быть обосновано уверены, что никто не сможет переместить наши деньги, если у него нет наших ключей.
Эфириум, имеющий гораздо более гибкий дизайн, представил концепцию смарт-контракта, или программного кода, исполнение которого может быть инициировано транзакцией. Смарт-контракты являются базовыми блоками для децентрализованных приложений (dapps). Одним из наиболее распространенных применений для этих контрактов были так называемые «токен-контракты». Они определяют выпуск, передачу и расчет остатков для каждого отдельного токена. Столь продуманное устройство позволяет экспериментировать с «законами денежной физики».
Однако такое устройство предполагает, что фактическое владение токеном переходит от его владельца к умному контракту, что делает этот умный контракт контролером-хранителем. Он будет действовать от вашего имени, но никогда не «даст» вам сами токены. Вы не можете владеть таким токеном без контракта, на базе которого он функционирует.
Технически говоря, при активации, контракт может делать все, что угодно. Криптографическая «связь» между владением и транзакциями отсутствует. Контракт выдаёт права собственности или разрешения любого другого вида.
Конечно, программный код контракта всегда в свободном доступе и, следовательно, может быть проверен. Однако, учитывая гибкость и сложность платформы, проверить его может далеко не каждый. Было бы проще, если бы был только один контракт для аудита, но если текущая ситуация сохраниться, контрактов и токенов будет много.
Во-вторых, это неспособность кого-либо помешать вам совершить транзакцию.
Как я уже упоминал ранее, дизайн Эфириума будучи довольно лаконичным, все же является довольно гибким, и он облегчает реализацию токенов для смарт-контрактов.
За всё приходится платить. Прежде всего, за счет повторной реализации функциональности блокчейна (даже из тщательно проверенных блоков), у нас будет больше багов в коде.
Если вы посмотрите на лидирующий стандарт токенов (ERC20), то он лишь определяет интерфейс, который должен быть открыт токенными контрактами. При этом на нем лежит довольно грязная работа: он описывает фактические свойства, что поможет тестированию и гарантирует, что контракт будет делать именно то, что он должен делать.
Такое устройство понятно, если помнить об самой идее возможности экспериментировать с тем, как токен ведет себя при передаче возможностей обращения с вашими токенами — например, накладывания ограничений, запретов, лимитов и т. д. Но определенно есть необходимость и в других стандартах, которые описывали бы, как типичные токены ДОЛЖНЫ себя вести, в зависимости от своей модели. Особенно это касается самых простых.
Примером такого дополнительного стандарта будет описание поведения функции transfer в отношении влияния на возвращаемое значение функции balanceOf (как переводы влияют на баланс, математически строгим образом?) Это свойство опущено, возможно, потому, что оно столь тривиально, что лежит на поверхности. Но это означает, что мы можем только предположить, для чего предназначены эти функции. И это приводит к ошибкам.
Почему это важно?
Хотя теоретически контракты неизменны и независимы от их владельцев, на самом деле тут есть проблема. Если вы будете следовать лучшим рекомендациям по разработке смарт-контрактов, вы неизбежно придете к тому, что вам нужно иметь возможность аварийного выключения (приостановки работа контракта, если «что-то пошло не так»), а также возможности для обновления программного кода.
Несомненно, это хорошая мера для обеспечения благополучия токена. Это хорошее и благородное намерение … но это приводит нас к следующему последствию:
Владелец контракта (или тот, у кого есть секретные ключи владельца!) сможет остановить работу контракта или изменить его программный код.
В отличие от форков Биткойна, которые намного заметнее (поскольку затрагивают интересы огромного количества людей) и потребуют, по крайней мере, обновления до новой версии клиентского программного обеспечения, свойства токенов Ethereum намного проще менять, как с технологической точки зрения, так и с политической.
Что можно сделать для предотвращения нежелательного вмешательства? Можно предположить, что само право собственности на токены нужно забрать из рук отдельных владельцев и передать системе голосования. Может быть это поможет. Это определенно лучше, чем то, что кто-то в одностороннем порядке контролирует токен. Но это поднимает новые вопросы, связанные с кворумом: что, если нам нужно вмешаться в неисправный контракт как можно скорее? Сколько времени потребуется на достижение кворума? Какие изменения потребуют каких уровней кворума (50% + 1? 2/3? Единогласно?)
Итак, хотя строительные блоки Эфириума способны помочь в создании децентрализованных контрактов, нет никакого способа определить совершенно идеальный контракт, который учитывает все будущие возможности. Это означает, что кто-то должен продолжать управлять контрактом, тем самым снижая децентрализацию до таких областей, как доказуемый аудит. Однако это не означает, что у этого направления нет будущего. Скорее, важно понять эти ограничения, чтобы в конечном итоге найти пути их преодоления.