Если есть проблемы с командой, DApp нельзя использовать. Многие люди сомневаются в том, что мультичейн псевдодецентрализован, а некоторые даже начинают сомневаться в том, что же происходит?

Проблемы с межсетевыми мостами поднимают вопросы о децентрализации DApps

Дело вот в чем. Днем 24 мая 0xscope написал в Твиттере, что адрес кошелька, связанный с мультичейном, перевел 3,17M MULTI в Gateio. Ранее пользователи DC сообщали, что их кроссчейн-активы долго не поступали. В сообществе ходили слухи о том, что мультичейн находился в Шанхайском офисе был арестован полицией Юньнани, а межсетевые ограничения привели к невозможности получения межсетевых активов. Этот инцидент сразу же вызвал панику в сообществе, а также цену MULTI. упал на 30%. Позже, в 0:00 посреди ночи, Брат Сунь предложил свой собственный USDD, более 3 часов сооснователь мультичейн-команды заявил, что команда работает нормально и столкнулась с форс-мажорными обстоятельствами. Многие люди задавались вопросом, что форс-мажорные обстоятельства могут представлять собой сторону слухов, что может быть правдой, потому что, как правило, предпосылкой проблем с межсетевыми мостами является то, что либо сбои, вызванные ошибками в коде, либо вызваны хакерскими атаками. команда объявит об этом напрямую. Если команда ведет себя скрытно, она может столкнуться с юридическими проблемами, поэтому достоверность слухов относительно высока.

Пока команда не отреагировала напрямую на истинные обстоятельства этого инцидента. На рынке также ведется много дискуссий, и цены на многие токены упали. Хотя позже команда мультичейн заявила, что компенсирует пользователям потерю активов, люди все равно сомневаются в децентрализации DApp. Если с командой что-то пойдет не так, смогут ли они вернуть свои деньги по контракту? Другими словами, их активы не могут нормально пересекаться между собой. Децентрализованные смарт-контракты должны выполняться автоматически. Если они контролируются людьми, децентрализация может быть напрасной.

За децентрализацией стоит управление полномочиями

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

Прежде всего, DApp, с которым мы взаимодействуем, развернут в блокчейне. Децентрализация блокчейна в основном определяется узлами. Чем более рассредоточены узлы, тем сильнее децентрализация. Если узлы вступают в сговор с целью совершить зло. делать зло, тогда это не называется децентрализацией, и DApp опирается на блокчейн, который подобен дому на земле, а разрешения — как ключи от дома. В принципе, кошелек, который развертывает DApp, имеет права управления над DApp. что является высшим авторитетом. Обычно у разработчиков DApp есть три стратегии:

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

2. После резервирования разрешений откажитесь от разрешений. Как правило, это относится к контрактам на выпуск валюты, особенно к пулу ликвидности LP. Некоторые контракты на выпуск валюты предусматривают общий верхний предел на ранних этапах развертывания, в то время как другие могут не предусматривать верхний предел или нет. Верхний предел может быть изменен разработчиком, в результате чего люди не доверяют токену. Поэтому обычной практикой является потеря разрешения или изменение владельца разрешения на адрес черной дыры. Например, если lp пула AMM. отправляется на кошелек «все-0», затем пул lp. Никто не может получить средства или изменить разрешения для кошелька «все-0». Тогда, за исключением кошелька «все-0», никакой другой кошелек не может быть изменен. 0 называется адресом черной дыры, и его закрытый ключ никому не доступен. Да, поэтому эта операция имеет тот же эффект, что и жесткое кодирование разрешений.

Конечно, как только закрытый ключ адреса all-0 будет взломан, это будет другое дело, но эта вероятность в настоящее время очень мала и практически невозможна. Как правило, разработчики резервируют разрешения при первом развертывании и пробном запуске контракта. После того, как контракт был протестирован рынком и не имеет лазеек или прошел аудит, они могут рассмотреть возможность отказа от разрешений, поскольку этот метод может быть подвергнут сомнению. сообществом, поэтому используемых предметов будет относительно мало.

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

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

Вообще говоря, чем сложнее DApp, тем сложнее добиться настоящей децентрализации. Если оно выполняет только самые простые функции, можно быть полностью децентрализованным. Сложность, децентрализация и безопасность вряд ли будут сосуществовать одновременно. Сложность уже определила функциональные требования в начале проектирования DApp, и безопасность нельзя недооценивать. Поэтому степенью децентрализации можно только пожертвовать. Контрактные разрешения, но передайте их управлению с несколькими подписями, тем самым вводя еще одну форму децентрализации. Однако, если управление с несколькими подписями не идеально и слишком централизовано, возникнут определенные проблемы.

Для вышеупомянутой формы решения на самом деле нет. Вы можете предоставить пользователям каналы извлечения активов, добавив такие функции, как переключатели восстановления активов. Это облегчит возникновение таких проблем, как аномалии, которые невозможно восстановить в ходе межцепочного процесса. По сути, в случае возникновения проблемы с контрактом пользователи могут подать требования о восстановлении через узел восстановления, тем самым избегая таких рисков, как FTX, и гарантируя, что они смогут получить их обратно самостоятельно. -сервис как можно скорее. Активы и DApps также постоянно совершенствуются и развиваются в этом процессе, что в конечном итоге способствует популярности децентрализации.