Насколько я понимаю, типичная архитектура для приложения Ethereum состоит в том, чтобы иметь смарт-контракт, выступающий в качестве бэкэнда для централизованного внешнего интерфейса без сохранения состояния, который работает на одном сервере.
Не представляет ли это довольно вопиющую угрозу безопасности? Если внешнее приложение взломано, все действия пользователей могут быть перенаправлены на то, чего хочет злоумышленник (т. е. вместо отправки эфира на полезный смарт-контракт, он отправляется в кошелек злоумышленника).
Есть ли способ децентрализованно разместить внешнее приложение?
Это действительно представляет явную угрозу безопасности. Теоретически пользователь просматривает свою транзакцию в MetaMask и т. д. перед отправкой, поэтому ему не нужно доверять децентрализованному приложению, но на практике данные, которые вы просматриваете, представляют собой загадочный адрес контракта и непостижимую массу шестнадцатеричных данных, а также контекст для этих данных. — например, у какого котенка какой идентификатор — исходит из децентрализованного приложения, поэтому мошеннический интерфейс может легко обманом заставить пользователей отправлять разные транзакции вместо тех, которые они намеревались.
Проблема, вероятно, может быть решена путем передачи данных с адресацией по контенту из IPFS или Swarm, обслуживаемых расширением браузера, и использования контракта именования, который обеспечивает процесс развертывания — например, размещение кода для проверки перед развертыванием — для управления тем, какой код может быть показан пользователю. пользователя для данного имени приложения. Однако эти системы сложно проектировать, и пока нет практического решения, которое могли бы легко развернуть разработчики децентрализованных приложений.
Обычно целью внешнего интерфейса для Ethereum DApp является предоставление «красивого» метода вызова функций, которые находятся в загруженном смарт-контракте. Конечно, хакер может изменить адрес смарт-контракта, с которым взаимодействует пользователь (но пользователь всегда может видеть, куда идут его транзакции). Вы можете разместить децентрализованный интерфейс с IPFS https://ipfs.io
Самое замечательное в использовании децентрализованного бэкенда и таких инструментов, как EtherScan, заключается в том, что мы всегда можем увидеть, куда и кому идет наш эфир с относительной простотой.
Если бы интерфейс действительно был взломан и хакер изменил адрес контракта, пользователь мог бы увидеть, что его транзакции не идут по адресу, который должен быть (подумайте об этом, как если бы вы знали адрес улицы вашего друга, кто-то украл их телефон и сообщает вам, чтобы вы пришли на другой адрес с намерением вас ограбить, вы будете опасаться идти по этому адресу, так как вы никогда не были там раньше, и нет никаких причин относительно почему). Вы также сможете просмотреть количество транзакций по контракту (полезно только в том случае, если он недавно был повышен). Я думаю, что это незначительная проблема, и ее можно решить с помощью IPFS (однако это может быть медленным).
Чтобы дать общее представление о том, что хакеру придется сделать, чтобы злонамеренно получить эфир от пользователей, он тоже должен это сделать;
Да, это правильно, поэтому вы можете размещать свои децентрализованные приложения на IPFS+IPNS (после сборки с помощью чего-то вроде веб-пакета).
Та же логика верна и для оракулов, это централизованные точки отказа.
джазовая дыра
джазовая дыра
Эдмунд Эдгар