Многие говорят о безопасности, и первой реакцией являются хакеры, уязвимости, молниеносные займы и атаки на контракты. Но если вы действительно подумаете о Plasma в масштабе "сети ликвидации стабильных монет", вы обнаружите, что самые опасные инциденты в будущем могут исходить не от внешних атак, а скорее от внутренних: конфигурация прав, структура управления, изменения параметров, процессы обновления и границы между многоподписными и административными правами. Потому что, как только сеть ликвидации принимает на себя более крупные средства, ее безопасность больше не заключается в том, "есть ли дыры в контракте", а в том, "в чьих руках находятся ключевые кнопки системы, как их нажимать и можно ли спасти ситуацию, если нажать неправильно". B26 Я хочу написать именно это: когда экосистема Plasma вырастет, самая большая угроза не будет исходить от хакеров, а от системных рисков, связанных с правами и управлением — то есть "не позволяйте системе погибнуть от рук своих людей".
Сначала расскажу о очень реальном факте: продукты, связанные со стабильными монетами, часто имеют тяжелые привилегии. Система выплат должна контролировать бюджет и черный список, Vault доходов должен настраивать параметры стратегии, рынок кредитования должен настраивать модели процентных ставок и пороги расчета, прием платежей со стороны торговцев должен конфигурировать правила управления рисками и логику возврата. Как только вы хотите создать опыт на уровне платежей, привилегий избежать невозможно. Проблема в том, что чем больше привилегий, тем больше рисков; настоящие рисковые точки часто не «злонамеренные», а «ошибки в操作». Одна ошибка в параметрах, одна неудача обновления, одна ошибка в конфигурации привилегий могут вызвать цепную реакцию: заморозка средств, задержка выкупа, переполнение выплат, аномалия в логике расчетов, даже вызвать панику пользователей. Система платежей всегда больше всего боится не мелких ошибок, а «мгновенного разрушения доверия пользователя».
Таким образом, в экосистеме Plasma первым принципом управления привилегиями должно быть: минимальные привилегии + четкие границы. Любая администраторская функция, которую можно вызывать без ограничений, любые привилегии, позволяющие произвольно изменять ключевые параметры, любые контракты, которые могут быть «обновлены в любое время», станут бомбой замедленного действия, когда масштаб увеличится. Вы можете не стремиться к полной децентрализации, но вы должны сделать ключевые риски управляемыми: какие параметры можно изменить, а какие нельзя; есть ли предел для изменяемых параметров; есть ли задержка при изменении; требуется ли множественная подпись; есть ли публичные объявления; разрешено ли сообществу или пользователям заранее выйти. Чем больше это похоже на финансовую инфраструктуру, тем больше требуется такое «институциональное сдерживание».
Вторым ключевым моментом является процесс обновления. Многие проекты любят использовать «обновляемые контракты» для повышения эффективности итераций, но пользователи часто видят совершенно другой сигнал: вы можете изменить код в любое время, значит, находятся ли мои деньги в неопределенности? Для сети расчетов обновление не является техническим действием, а является действием доверия. Более зрелым способом является превращение обновления в предсказуемый процесс: публикация описания изменений, установка timelock (задержка вступления в силу), предоставление предупреждения о рисках и плана миграции, активация экстренных привилегий только в экстренных ситуациях, причем все действия должны быть отслеживаемыми и подлежащими аудиту. Вам не обязательно связывать себя, но вы должны сделать так, чтобы обновление больше не выглядело как «темное управление», а как «окно изменений банковской системы» — предварительное уведомление, проверяемость, возможность отката или компенсации.
Третьим ключевым моментом являются многоподписи и риски для персонала. Многие думают, что многоподпись безопасна, но на самом деле многоподпись просто превращает одну точку в несколько, действительно важно, кто подписывает, достаточно ли независимо распределение, есть ли четкий процесс действий, существует ли защита от социальных атак, есть ли план на экстренный случай. Системы стабильных монет больше всего боятся «концентрации привилегий + произвольности процессов», потому что, если произойдет внутренняя ошибка или социальная атака, последствия будут сложнее исправить, чем внешняя атака. Для пользователя не важно, как вы управляете внутри, ему важно, «не произойдет ли внезапно что-то с деньгами». Поэтому структура управления должна быть спроектирована так, чтобы «даже если кто-то ошибается, система не взорвется сразу».
Четвертым ключевым моментом является то, что «риски параметров» следует рассматривать как объекты управления рисками, а не как инструменты управления. Многие инциденты не являются уязвимостями кода, а параметры настроены слишком агрессивно: для краткосрочного роста увеличивают лимиты выплат, чтобы привлечь капиталы, повышают интенсивность стимулов, чтобы увеличить доходность, и вытягивают стратегические риски на максимум. Краткосрочно данные выглядят красиво, в долгосрочной перспективе это мины. Принципы сети расчетов должны быть более консервативными: лучше расти медленно, но гарантировать, что система сможет выдержать давление, особенно необходимо гарантировать, что выкуп и доступность средств не будут жертвованы. Пользователи стабильных монет терпеливы к «медленному», но нетерпеливы к «проблемам».
Если экосистема Plasma хочет выйти на более крупный масштаб, безопасное поле боя будет постепенно переходить от «защиты от хакеров» к «управлению привилегиями». Важно, есть ли дыры в контрактах, но еще важнее, кто может нажимать на ключевые кнопки, как они действуют, есть ли задержка и границы перед действием, можно ли остановить убытки, если что-то пойдет не так. Если привилегии и управление можно сделать институционализированными, процессуальными и проверяемыми, Plasma станет настоящей сетью расчетов; в противном случае, даже если технологии будут сильными, одна внутренняя ошибка или инцидент управления могут разрушить доверие.
