Инженерные компромиссы неизменяемых AMM-пулов
Неизменяемость — это компромисс: неизменяемый AMM-пул убирает возможность заменить развернутый код, но также убирает возможность исправить баг внутри этого пула. STONfi использует это разделение: контракты пулов неизменяемы, а отдельный Router (маршрутизатор) остается обновляемым.
🔒 ЧТО УНИЧТОЖАЕТ НЕИЗМЕНЯЕМОСТЬ
Обновляемый контракт может перенаправлять выполнение на новый код реализации. Эта гибкость помогает командам исправлять ошибки, но создает риск злоупотребления властью при обновлениях.
В неизменяемом пуле развернутый байткод остается фиксированным. Нет указателя на реализацию, который можно заменить, и нет администратора, который может переписать ключевую логику пула.
Плюс — фиксированная поверхность атаки:
- Логику AMM можно аудитировать по одному постоянному артефакту.
- Будущая реализация не сможет незаметно заменить этот код.
⚠ СТОИМОСТЬ НЕ ИСЧЕЗАЕТ
Если в неизменяемом коде есть баг, команда не сможет исправить именно этот пул. Нужно развернуть новый пул, а старый останется в блокчейне. Тогда ликвидность и торговая активность должны добровольно мигрировать.
Неизменяемость снижает риск будущих обновлений, но делает обнаруженные баги сложнее для исправления.
STONfi разделяет ответственность: пул хранит AMM-логику и резервы в фиксированном коде, а Router координирует операции и может развиваться.
⏱ ГИБКОСТЬ В РАМКАХ
Некоторые параметры могут оставаться настраиваемыми, не делая весь контракт обновляемым. В статье в качестве примера используются комиссии: исходный код пула может допускать ограниченное изменение комиссии без изменения логики.
Обновления Router откладываются на семь дней. Это не делает невозможным злонамеренное обновление; это дает время среагировать.
Ключевой вопрос не «неизменяемый или обновляемый?». Вопрос в том, у какого компонента наибольший радиус поражения, что именно нужно менять и какие защиты окружают это изменение.
Это не инвестиционный совет — проведите собственное исследование! 🚀
$GRAM
Неизменяемость — это компромисс: неизменяемый AMM-пул убирает возможность заменить развернутый код, но также убирает возможность исправить баг внутри этого пула. STONfi использует это разделение: контракты пулов неизменяемы, а отдельный Router (маршрутизатор) остается обновляемым.
🔒 ЧТО УНИЧТОЖАЕТ НЕИЗМЕНЯЕМОСТЬ
Обновляемый контракт может перенаправлять выполнение на новый код реализации. Эта гибкость помогает командам исправлять ошибки, но создает риск злоупотребления властью при обновлениях.
В неизменяемом пуле развернутый байткод остается фиксированным. Нет указателя на реализацию, который можно заменить, и нет администратора, который может переписать ключевую логику пула.
Плюс — фиксированная поверхность атаки:
- Логику AMM можно аудитировать по одному постоянному артефакту.
- Будущая реализация не сможет незаметно заменить этот код.
⚠ СТОИМОСТЬ НЕ ИСЧЕЗАЕТ
Если в неизменяемом коде есть баг, команда не сможет исправить именно этот пул. Нужно развернуть новый пул, а старый останется в блокчейне. Тогда ликвидность и торговая активность должны добровольно мигрировать.
Неизменяемость снижает риск будущих обновлений, но делает обнаруженные баги сложнее для исправления.
STONfi разделяет ответственность: пул хранит AMM-логику и резервы в фиксированном коде, а Router координирует операции и может развиваться.
⏱ ГИБКОСТЬ В РАМКАХ
Некоторые параметры могут оставаться настраиваемыми, не делая весь контракт обновляемым. В статье в качестве примера используются комиссии: исходный код пула может допускать ограниченное изменение комиссии без изменения логики.
Обновления Router откладываются на семь дней. Это не делает невозможным злонамеренное обновление; это дает время среагировать.
Ключевой вопрос не «неизменяемый или обновляемый?». Вопрос в том, у какого компонента наибольший радиус поражения, что именно нужно менять и какие защиты окружают это изменение.
Это не инвестиционный совет — проведите собственное исследование! 🚀
$GRAM
