Сегодня я дважды видел, как одну и ту же формулу проверяют, и почти пролистал мимо причины.
Читая отчет по безопасности Dusk, я наткнулся на формулу комиссии: произведение лимита газа на цену газа равно максимальной комиссии. Это правило “закрепляется” дважды: сначала при входе транзакции в mempool, затем внутри исполнения в VM.
Сначала я подумал: ну да, это просто избыточность. Ремни и подтяжки — нечего глубже копать.
Но следующий абзац не дал мне расслабиться. Ограничения только на уровне mempool недостаточно: злоумышленному proposer'у не нужно включать транзакцию исключительно в “mempool-честном” варианте полей.
Именно в этом и пролом. Значение, доказанное или подписанное в одной части транзакции, не связывает все уровни, которые потом его используют. Можно заранее зафиксировать легитимную комиссию, но подать другой вариант в исполнение — если само исполнение независимо не откажется доверять тому, что ранее уже якобы проверили.
Подпиши и докажи максимальную комиссию, пусть mempool это проверит, а proposer соберет блок без обязанности сохранять это. А VM выполнит логику возвратов против того, что фактически пришло.
Все время возвращается к одному: почти все доверие держится на том, что proposer останется честным между контрольными точками. Собственно, вторую проверку и добавляют ровно потому, что на это полагаться нельзя.
Не знаю, сколько еще полей в этой цепочке проверяются только на одном слое.
Что происходит с этой проверкой при реальной перегрузке, когда proposer’ам под давлением нужно строить блоки быстро? 👍
#dusk $DUSK @Dusk
Читая отчет по безопасности Dusk, я наткнулся на формулу комиссии: произведение лимита газа на цену газа равно максимальной комиссии. Это правило “закрепляется” дважды: сначала при входе транзакции в mempool, затем внутри исполнения в VM.
Сначала я подумал: ну да, это просто избыточность. Ремни и подтяжки — нечего глубже копать.
Но следующий абзац не дал мне расслабиться. Ограничения только на уровне mempool недостаточно: злоумышленному proposer'у не нужно включать транзакцию исключительно в “mempool-честном” варианте полей.
Именно в этом и пролом. Значение, доказанное или подписанное в одной части транзакции, не связывает все уровни, которые потом его используют. Можно заранее зафиксировать легитимную комиссию, но подать другой вариант в исполнение — если само исполнение независимо не откажется доверять тому, что ранее уже якобы проверили.
Подпиши и докажи максимальную комиссию, пусть mempool это проверит, а proposer соберет блок без обязанности сохранять это. А VM выполнит логику возвратов против того, что фактически пришло.
Все время возвращается к одному: почти все доверие держится на том, что proposer останется честным между контрольными точками. Собственно, вторую проверку и добавляют ровно потому, что на это полагаться нельзя.
Не знаю, сколько еще полей в этой цепочке проверяются только на одном слое.
Что происходит с этой проверкой при реальной перегрузке, когда proposer’ам под давлением нужно строить блоки быстро? 👍
#dusk $DUSK @Dusk