После долгожданного слияния Ethereum наступило идеальное время подумать о том, как мы можем улучшить смарт-контракты. По сути, приложения, работающие на блокчейне, смарт-контракты являются жизненно важным компонентом наших Web3-приложений. Но взаимодействие с ними остается довольно опасным, особенно для не разработчиков. Многие инциденты, в которых пользователи теряют свои криптоактивы, вызваны ошибками или вредоносными смарт-контрактами.
Как разработчик приложений Web3, я часто думаю об этой проблеме, особенно когда волны новых пользователей продолжают подключаться к различным блокчейн-приложениям. Чтобы полностью доверять смарт-контракту, потребитель должен точно знать, что он будет делать при совершении транзакции - ведь в отличие от мира Web2, здесь нет горячей линии поддержки клиентов, куда можно позвонить и вернуть средства, если что-то пойдет не так. Но в настоящее время практически невозможно узнать, является ли смарт-контракт безопасным или заслуживающим доверия.
Одно из решений - сделать сами кошельки более умными. Например, что если бы кошельки могли сказать нам, безопасен ли смарт-контракт для взаимодействия с ним? Вероятно, невозможно знать это со 100% уверенностью, но кошельки могли бы, как минимум, агрегировать и отображать многие сигналы, которые уже ищут разработчики. Это сделало бы процесс более простым и безопасным, особенно для тех, кто не занимается разработкой.
Здесь мы подробнее рассмотрим преимущества и недостатки смарт-контрактов, почему сейчас они кажутся Диким Западом, и как мы можем улучшить UX для их использования.
Обещание и опасность смарт-контрактов
Для разработчиков использование смарт-контракта в качестве бэкенда для их приложений имеет огромный потенциал. Это также повышает вероятность ошибок и эксплойтов. Это здорово, что смарт-контракты могут быть созданы разработчиками, не спрашивая ни у кого разрешения, но это также может подвергнуть пользователей значительному риску. Сейчас мы имеем приложения, совершающие сделки на сотни миллионов долларов без каких-либо гарантий безопасности. В нынешней ситуации мы просто должны верить в то, что эти приложения не содержат ошибок и выполняют то, что обещают.
Многие люди, не являющиеся разработчиками, даже не знают о проблемах безопасности и не принимают соответствующих мер предосторожности при работе с приложениями на основе блокчейна. Обычный пользователь может подписать транзакцию, думая, что она выполнит одно действие, а потом обнаружить, что смарт-контракт делает совсем другое. Именно поэтому вредоносные смарт-контракты являются основным вектором атаки для плохих игроков.
Почему смарт-контракты - это Дикий Запад?
Когда приложение Web3 выполняет вызов смарт-контракта, вы не знаете точно, что будет делать транзакция, пока вы ее не выполните. Будет ли она майнить ваш неиграбельный токен (NFT) или отправит ваши деньги и токены хакеру? Эта непредсказуемость, конечно, относится к любому онлайн-приложению, а не только к Web3-приложениям; предсказать, что сделает код, очень сложно. Но в мире Web3 это более серьезная проблема, поскольку большинство этих приложений по своей природе имеют высокие ставки (они созданы для работы с вашими деньгами), а защита потребителей так мала.
App Store в значительной степени безопасен благодаря процессу проверки Apple, но в Web3 этого нет. Если приложение для iOS начнет воровать деньги пользователей, Apple сразу же удалит его, чтобы уменьшить потери, и отзовет аккаунт его создателя.
Вредоносные смарт-контракты, с другой стороны, не могут быть уничтожены никем. Также нет возможности вернуть украденные активы. Если вредоносный контракт опустошит ваш кошелек, вы не сможете просто оспорить транзакцию в компании, обслуживающей вашу кредитную карту. Если разработчик анонимен, как это обычно бывает с вредоносными контрактами, то зачастую даже нет возможности подать иск в суд.
С точки зрения разработчика, гораздо лучше, если код смарт-контракта будет с открытым исходным кодом. Популярные смарт-контракты обычно публикуют свой исходный код - это огромное улучшение по сравнению с Web2-приложениями. Но даже в этом случае легко пропустить то, что происходит на самом деле. Также может быть очень сложно предсказать, как код будет работать во всех сценариях. (Вспомните эту длинную, пугающую ветку в Twitter опытного разработчика, который чуть не попался на сложную фишинговую аферу, даже прочитав соответствующие контракты. Только при повторном внимательном изучении он заметил эксплойт).
Эти проблемы усугубляются тем, что при взаимодействии с умными контрактами люди часто вынуждены действовать быстро. Возьмем, к примеру, распродажу NFT, продвигаемую влиятельными людьми: Потребители будут беспокоиться о том, что коллекция быстро распродастся, поэтому они часто будут стараться совершить сделку как можно быстрее, игнорируя любые красные флажки, с которыми они могут столкнуться по пути.
Короче говоря, те же самые функции, которые делают смарт-контракты мощными для разработчиков - такие как публикация без разрешения и программируемые деньги - делают их довольно опасными для потребителей.
Я не думаю, что эта система имеет фундаментальные недостатки. Но у разработчиков Web3, таких как я, есть масса возможностей обеспечить более надежные ограждения для потребителей, использующих кошельки и смарт-контракты уже сегодня.
UX кошельков и смарт-контрактов сегодня
Во многих отношениях кошельки, подобные MetaMask, как будто созданы для разработчиков. Они отображают множество глубоких технических деталей и тонкостей блокчейна, полезных при создании приложений.
Проблема в том, что не разработчики также используют MetaMask - не понимая, что все это значит. Никто не ожидал, что Web3 так быстро станет мейнстримом, а кошельки еще не успели удовлетворить потребности своей новой пользовательской базы.
MetaMask уже проделала большую работу по ребрендингу "мнемонической фразы" в "секретную фразу", чтобы потребители не могли невольно поделиться ею с хакерами. Тем не менее, есть еще много возможностей для улучшения.
Давайте посмотрим на пользовательский интерфейс (UI) MetaMask, а затем на несколько созданных мной макетов, описывающих некоторые потенциальные улучшения, которые могли бы направить потребителей в "яму успеха". (Кстати, MetaMask здесь служит в качестве образца, поскольку он широко используется в мире Web3, но эти идеи пользовательского интерфейса также применимы практически к любому приложению для кошельков). Некоторые из этих изменений дизайна могут быть реализованы уже сегодня, в то время как другие могут потребовать технических достижений со стороны смарт-контрактов.
На изображении ниже показано, как выглядит текущее окно транзакции смарт-контракта MetaMask.
Мы видим адрес смарт-контракта, с которым взаимодействуем, веб-сайт, инициировавший транзакцию, а также множество подробностей о средствах, которые мы отправляем на контракт. Однако нет никаких указаний на то, что делает этот контракт, или каких-либо признаков того, что с ним безопасно взаимодействовать.
Потенциальные решения для улучшения смарт-контрактов
Мы бы хотели видеть здесь сигналы, которые помогут нам, конечным пользователям, определить, доверяем мы этой транзакции смарт-контракта или нет. В качестве аналогии вспомните маленький зеленый или красный замочек в адресной строке современных веб-браузеров, который показывает, зашифровано ли соединение или нет. Этот цветовой индикатор помогает неопытным пользователям избежать потенциальных опасностей, в то время как опытные пользователи могут легко игнорировать его по своему усмотрению.
В качестве наглядного примера, вот два быстрых макета дизайна пользовательского опыта (UX) транзакций MetaMask - один, который, скорее всего, будет безопасным, а другой - менее уверенным.
- Публикуется ли исходный код контракта? Контракты с открытым исходным кодом обычно вызывают больше доверия, поскольку любой разработчик может прочитать их, чтобы найти ошибки и вредоносный код. MetaMask уже включает различные ссылки на Etherscan, так что это было бы простым и удобным сигналом для добавления.
- Оценка аудита. Аудит третьей стороной - это еще один сигнал, который может определить надежность. Основной вопрос реализации здесь заключается в том, как определить этот показатель. Существуют ли уже какие-либо принятые стандарты для этого? Если нет, то простым способом может быть использование Etherscan, который поддерживает загрузку аудитов. MetaMask, в данном примере, может также вести свой собственный список аудиторов или полагаться на список третьих лиц. (Насколько я могу судить, MetaMask уже делает это для NFT API и обнаружения токенов). В будущем легко представить себе децентрализованную автономную организацию для определения оценок аудита более децентрализованным способом.
- Что может сделать эта транзакция? Может ли она вызывать внешние контракты, и если да, то какие? Это будет очень сложно определить в совершенстве, но интересно, будет ли осуществима простая версия для контрактов с открытым исходным кодом? Уже существует множество автоматических сканеров уязвимостей смарт-контрактов. Если это невозможно для Solidity, интересно, сможем ли мы разработать язык программирования смарт-контрактов, позволяющий проводить статический анализ такого уровня. Возможно, отдельные функции могли бы объявлять необходимые им разрешения, а компилятор мог бы гарантировать их соответствие.
- Советы по безопасности и обучение. Если смарт-контракт не имеет большого количества сигналов, свидетельствующих о его надежности (см. макет выше справа), пользовательский интерфейс может рекомендовать соответствующий набор мер предосторожности, например, проверить правильность адреса контракта и использовать другую учетную запись. Эти предложения выделены оранжевым цветом, а не красным, поскольку отсутствие сигналов не обязательно опасно; здесь мы просто рекомендуем пользователям быть более осторожными в своих дальнейших действиях.
Как и многие существующие функции в MetaMask, эти предлагаемые функции могут быть отключены в настройках.
На пути к более безопасному будущему
В будущем, вероятно, появится множество инструментов, ориентированных на безопасность, построенных на примитивных компонентах, которые предоставляет блокчейн. Например, вполне вероятно, что мы увидим, как страховые протоколы, защищающие пользователей от ошибочных смарт-контрактов, станут обычным явлением. (Такие протоколы уже существуют, но они все еще довольно нишевые).
Тем не менее, потребители уже используют приложения Web3, даже в эти ранние дни, поэтому я бы хотел, чтобы сообщество разработчиков добавило больше защиты для них сейчас. Некоторые простые усовершенствования кошельков могли бы сыграть большую роль. Некоторые из вышеупомянутых идей помогут защитить неопытных пользователей и одновременно упростить процесс транзакций для ветеранов Web3.
С моей точки зрения, все, что выходит за рамки торговли криптоактивами на Coinbase (или в других крупных компаниях), все еще слишком рискованно для среднего потребителя. Когда друзья и родственники спрашивают о создании собственного криптокошелька для использования приложений Web3 (давайте посмотрим правде в глаза - обычно для покупки NFT), всегда начинайте с предупреждения о рисках. Это отпугивает некоторых из них, но более решительные люди все равно хотят их использовать. Когда наши кошельки станут умнее, мы сможем гораздо лучше чувствовать себя при привлечении следующей волны новых пользователей к Web3.
Девин Эббот - основатель компании Deco, стартапа, приобретенного Airbnb. Он специализируется на инструментах проектирования и разработки, приложениях React и Web3, в последнее время работал в компании The Graph.
Данная статья предназначена для общего ознакомления и не является и не должна восприниматься как юридическая или инвестиционная консультация. Взгляды, мысли и мнения, выраженные здесь, принадлежат только автору и не обязательно отражают или представляют взгляды и мнения Cointelegraph.
Источник
