Ошибка Ethereum возвращает смарт-контракты на чертежную доску

Ошибки — это обычная часть программного обеспечения, но в Ethereum они могут быть особенно опасны.

Возможно, именно такой вывод можно сделать из ошибки в языке программирования Ethereum , обнаруженной на этой неделе и влияющей на определенный стиль смарт-контрактов. Из-за особенностей работы Ethereum (он обещает, что приложения будут работать точно так, как запрограммировано) большинство затронутых контрактов T могут быть удалены или изменены.

Короче говоря, владельцы децентрализованных смарт-контрактов (тех, которые T могут быть обновлены ONE владельцем) T могут ничего сделать, чтобы исправить ошибку.

Через два дня послеотчет об ошибке был выпущен, разработчики выпустили исправление в Solidity версии 0.4.4. Но ошибка затрагивает некоторые адреса и типы данных в этих контрактах, так что их по-прежнему T изменить при обновлении.

Хорошей новостью является то, что ошибка, возможно, не затронула многие смарт-контракты.

Создатель Solidity Кристиан Райтвиснер рассказал CoinDesk, что он провел «полуавтоматический» анализ каждой программы Ethereum , перечисленной популярным обозревателем блоков, и обнаружил, что из 12 000 контрактов только четыре были пригодны для эксплуатации.

Райтвиснер сказал, что ни один из этих контрактов не содержит эфира, поскольку они, вероятно, использовались в целях тестирования. Но стоит отметить, что не все контракты отображаются на Etherscan, выбранном обозревателе блоков. (Всего более 200 000 контрактов, поэтому трудно сказать, насколько безопасны оставшиеся фонды контрактов).

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

Например, ONE наблюдатель в социальных сетях сказал: утверждалчто это может быть «кротовиной на склоне большой горы» подобных проблем.

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

Аспирант Национального университета Сингапура Лой Луу заявил, что для Ethereum было бы лучше, если бы пользователи научились развертывать безопасные смарт-контракты трудным путем, децентрализованным образом.

Луу сказал:

«Лично я T думаю, что это хорошая идея. По сути, это противоречит всему, для чего предназначены смарт-контракты. Если Ethereum — это бета-сеть, пусть смарт-контракты потерпят неудачу, пусть люди Словарь уроки».

Но хотя комментарии Луу говорят о том, что, возможно, не стоит делать все контракты обновляемыми, есть несколько способов подготовиться к возможным будущим ошибкам, особенно пока Ethereum все еще является новой Технологии.

Устранение проблемы

Программы, написанные на более высоком уровне ethereum, на простых для чтения языках, таких как Solidity или Serpent, компилируются в код на уровне байтов, прежде чем они добавляются в блокчейн. Проблема здесь была в Технологии , выполняющей компиляцию.

Чтобы решить эту проблему, Райтвайсснеррекомендуется что разработчики делают две вещи. Во-ONE, при компиляции нового контракта разработчикам необходимо обновиться до новой версии Solidity, чтобы избежать ошибки.

Второй способ избежать проблемы — более любопытный пример, поскольку он требует обновления или прекращения финансирования уже развернутых смарт-контрактов — то, чего вы, возможно, не ожидаете от Ethereum.

Райтвиснер подробно остановился на этом совете, объяснив, что существует два типа контрактов: централизованно контролируемые и децентрализованные, где ни у ONE нет «особых привилегий».

Первый тип, вероятно, предлагает некий механизм модернизации или способ изъятия средств из контракта.

Второй тип сложнее. С другой стороны, поскольку не требующие доверия смарт-контракты Ethereum T удалить или изменить после их развертывания, разработчики T могут сделать многого, если они T использовали централизованный смарт-контракт с самого начала.

Однако Райтвиснер отметил, что разработчики могут защитить себя от будущих проблем (например, с Solidity), выполнив несколько действий.

«Моя рекомендация для таких контрактов — либо KEEP их краткосрочными, чтобы потенциальные негативные последствия были незначительными, либо проводить надлежащий формальный анализ байт-кода контракта. В настоящее время мы разрабатываем инструменты, которые помогут в этом», — сказал он.

Контракты с возможностью обновления

Однако есть несколько способов обойти это.

Руководитель отдела внешних связей Ethereum Foundation Хадсон Джеймсон описал способ обновления смарт-контрактов, которые потенциально могут быть децентрализованы, утверждая, что добавление способа обновления живого кода является необходимостью.

«Наши разработчики в целом считают, что на этом раннем этапе важно иметь в коде отказоустойчивые механизмы, чтобы можно было безопасно деактивировать или обновлять контракты, имеющие большую ценность», — сказал он.

Джеймсон описал некоторые потенциальные «отказоустойчивые» смарт-контракты, где владельцы могут обновлять свои контракты даже после их развертывания на Ethereum, или где смарт-контракты могут обнаруживать, когда происходит что-то подозрительное.

Он сказал, что они T обязательно должны быть централизованными или находиться под контролем ONE владельца. Например, у вас может быть смарт-контракт, который устанавливает ограничение на то, сколько актива можно снять за один раз.

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

Он описал несколько других методов, включая обнаружение взлома, выключатели отключения и транзакции с несколькими подписями, когда для выдачи эфира транзакцию должны подписать ONE человек.

С нетерпением жду

Смарт-контракты на Ethereum Classic (группа, которая отделилась от Ethereum из-за идеологических разногласий) также затронуты этой ошибкой, поскольку ее блокчейн использует тот же набор инструментов.

Однако, по словам ведущего организатора Арвикко, разработчики изучают другой долгосрочный способ разработки языка программирования, более устойчивый к ошибкам.

«ONE из возможных путей — перевести разработку языка смарт-контрактов из объектно-процедурной в функциональную парадигму», — сказал он.

Каким бы ни было возможное решение, обсуждение подразумевает, что разработчикам Ethereum пока T следует ожидать, что их смарт-контракты будут работать без потенциально опасных последствий, которые могут быть очевидны или не очевидны тем, кто уже развернул код в сети.

Что касается Solidity, то еще одна неустранимая ошибка может потенциально повлиять на другие смарт-контракты в будущем.

Райтвиснер отметил, что компилятор всегда может внести ошибку, и вполне возможно, что Solidity или Serpent (другой язык смарт-контрактов Ethereum) имеют другие необнаруженные недостатки.

Однако он отметил, что за более чем два года разработки это первая серьезная ошибка, обнаруженная в языке смарт-контрактов.

Изображение конструкциичерез Shutterstock