Можно ли создать инструмент, который читает смарт-контракты и проверяет их безопасность?

Мне очень нужна помощь с моим дипломным проектом. В настоящее время я нахожу пробел, о котором просит мой советник, и, похоже, мне трудно с этим справиться. Что я мог придумать, так это создать инструмент, который считывает смарт-контракты и видит недостатки и уязвимости закодированного смарт-контракта. Может ли кто-нибудь объяснить мне, возможно ли это, и есть ли какие-либо ссылки, которыми вы могли бы поделиться, или некоторые идеи для моего дипломного проекта. Кстати, сейчас изучаю информатику! Заранее спасибо!

Ребята из Truffle сделали отладчик, который вы можете проверить.
я думаю, вы спрашиваете об инструментах формальной проверки: посмотрите на ethereum.stackexchange.com/questions/11092/…
С другой стороны, я думаю, что «недостатки и уязвимости» относятся к известным эксплойтам и распространенным ошибкам в контрактах. Я не думаю, что это подходящая тема для диссертации, потому что а) это требует некоторого опыта работы со смарт-контрактами и б) появляются новые эксплойты
Кроме того, даже после формальной проверки это только доказывает, что код делает то, что указано в спецификации. Это не доказывает, что спецификация не имеет непредвиденных последствий. Вероятно, невозможно доказать, что любая программа, развернутая в реальном мире, не имеет непредвиденных последствий. Мы даже не можем правильно написать законы, а мы тысячелетиями пытались сделать это правильно. (Убийство = плохо. За исключением самообороны. За исключением самообороны с использованием чрезмерной силы. За исключением самообороны с использованием чрезмерной силы в пылу мгновения войны/стрессе. И т. д.)

Ответы (2)

В вполне общем случае это логически невозможно, так как сводится к решению «проблемы остановки». (На каком уровне образования находится эта «диссертация»? Я ожидаю, что любой исследователь информатики знаком с этим фундаментальным принципом вычислимости.)

Вы /можете/ сканировать байт-код на наличие определенного поведения, вызовов функций и т. д., но как только разрешены какие-либо косвенные действия или пользовательский ввод, эти сканы в конечном итоге становятся эвристиками, а не железными доказательствами.

Другой способ сформулировать это: вполне возможно полностью проверить программу, когда известны все входные данные, и программе не разрешено выполнять ответвление назад в потоке выполнения или использовать невстраиваемые вызовы функций (поэтому нет возможности рекурсии). , в свою очередь, смутно связано с тем, почему компиляторы FORTRAN так хороши в оптимизации. Как только вы посерьёзнеете эту тему, вы обнаружите множество интересных результатов, восходящих к заре вычислений фон Неймана!

Углубление в область «статического анализа программ», вероятно, будет плодотворным. В этой области есть много как теоретических, так и практических результатов, хотя больше из них направлено на поиск переполнения буфера в коде C, чем на попытки выяснить, является ли программа «плохой».

Другой вопрос, как вы определяете «плохую» программу — мне непонятно, можете ли вы вообще дать строгое формальное определение того, что такое «плохая» программа, которое было бы и полезным, и нетривиальным.

То, на что вы намекаете, - это статический анализ программы. В общем, невозможно создать полностью автоматизированный инструмент, который может проверять все уязвимости с идеальной памятью и точностью.

Хорошие инструменты для проверки наличия уязвимостей существуют. Например, https://contract-library.com выполняет анализ безопасности для всех смарт-контрактов в основной сети Ethereum и тестовых сетях. Вот пример уязвимого контракта: https://contract-library.com/contracts/Ethereum/0xb91824d10079a44864a9bec11b4ae022d7732e05 .

Некоторые из уязвимостей, которые он может обнаружить, связаны с газом. Вот наша статья, в которой описываются некоторые из этих анализов, если вы заинтересованы в воспроизведении/улучшении наших результатов: https://www.nevillegrech.com/assets/pdf/madmax-oopsla18.pdf