Я нашёл наиболее показательный баг AEGIS за пределами самого доказательства с нулевым разглашением. Значение рядом с ним было контролируемо не полностью.
В процессе транзакции Phoenix в Dusk Network пользователь мог зафиксировать корректный max_fee, однако при выполнении всё ещё использовались поля комиссии, которые не были связаны в ту же общую модель безопасности. Враждебные параметры газа могли привести к раздуванию суммы возврата или к переполнению. Изменяемый адрес возврата мог перенаправить средства.
Доказательство было верным. Семантика транзакции была связана с ним не полностью.
Комиссия — не безобидные метаданные, если путь возврата может создать или перенаправить ценность.
Это полезное предупреждение для любого протокола приватности. Доказательство одного утверждения идеально не защищает соседние поля, которым затем доверяет выполнение. Система должна связать доказательство, подпись, расчёт комиссии, назначение и путь возврата в один инвариант.
AEGIS добавил проверенное умножение gas_limit на gas_price и потребовал, чтобы результат равнялся доказанному max_fee. Dusk применил эту проверку дважды: при поступлении в mempool и снова внутри выполнения в виртуальной машине. Также он связал адрес stealth для возврата так, чтобы подмена сделала транзакцию недействительной.
Вторая проверка — это та деталь, о которой я больше всего забочусь. Злоумышленный предложивший блок не обязан соблюдать предположения честного mempool. Если инвариант существует только на сетевом краю, консенсус всё равно может выполнить транзакцию, которая обошла этот край.
Теперь я бы наблюдал за тем же защитным паттерном в Dusk: дешёвое отклонение до поступления, авторитетная валидация при выполнении и регрессионные тесты, которые мутируют каждое поле вокруг доказательства.
AEGIS закрыл известные критические пути. Больший вопрос в том, содержат ли другие контракты Dusk значения, которые "проверяются" на одном уровне и лишь доверяются на следующем.
Криптография может доказать ровно то, что от неё требуют доказать. Безопасность зависит от того, что Dusk запрашивает полное утверждение.
#dusk $DUSK @Dusk
В процессе транзакции Phoenix в Dusk Network пользователь мог зафиксировать корректный max_fee, однако при выполнении всё ещё использовались поля комиссии, которые не были связаны в ту же общую модель безопасности. Враждебные параметры газа могли привести к раздуванию суммы возврата или к переполнению. Изменяемый адрес возврата мог перенаправить средства.
Доказательство было верным. Семантика транзакции была связана с ним не полностью.
Комиссия — не безобидные метаданные, если путь возврата может создать или перенаправить ценность.
Это полезное предупреждение для любого протокола приватности. Доказательство одного утверждения идеально не защищает соседние поля, которым затем доверяет выполнение. Система должна связать доказательство, подпись, расчёт комиссии, назначение и путь возврата в один инвариант.
AEGIS добавил проверенное умножение gas_limit на gas_price и потребовал, чтобы результат равнялся доказанному max_fee. Dusk применил эту проверку дважды: при поступлении в mempool и снова внутри выполнения в виртуальной машине. Также он связал адрес stealth для возврата так, чтобы подмена сделала транзакцию недействительной.
Вторая проверка — это та деталь, о которой я больше всего забочусь. Злоумышленный предложивший блок не обязан соблюдать предположения честного mempool. Если инвариант существует только на сетевом краю, консенсус всё равно может выполнить транзакцию, которая обошла этот край.
Теперь я бы наблюдал за тем же защитным паттерном в Dusk: дешёвое отклонение до поступления, авторитетная валидация при выполнении и регрессионные тесты, которые мутируют каждое поле вокруг доказательства.
AEGIS закрыл известные критические пути. Больший вопрос в том, содержат ли другие контракты Dusk значения, которые "проверяются" на одном уровне и лишь доверяются на следующем.
Криптография может доказать ровно то, что от неё требуют доказать. Безопасность зависит от того, что Dusk запрашивает полное утверждение.
#dusk $DUSK @Dusk
