Аудит безопасности Те, кто работает аудиторами безопасности, в курсе, что даже самая дотошная проверка порой не спасает от проблем. Каждый эксперт или группа экспертов по безопасности склонны пропускать неизвестные им бреши, в зависимости от уровня их знаний и опыта. Все так и в случае, когда нужно проверить код с совершенно новой перспективы (смарт-контракты), с новым языком (Solidity) и новым классом атак (таким как теоретико-игровой). Число и глубина аудитов безопасности должны напрямую быть связаны с количеством денег, которые этот аудит проверяет. Для нового массива кода, который должен обрабатывать сотни миллионов долларов, несколько проверок, сделанных разными фирмами — вполне закономерная практика. Аудит безопасности — то, что по факту было сделано основателями Эфириума, они наняли LeastAuthority, Dejavu и Coinspect для аудита платформы. Но создатели The DAO этого не сделали, хотя в числе кураторов проекта были и известные Эфириум активисты, которым следовало порекомендовать подобную проверку. Формализация Аудит безопасности не заменяет использование формальных моделей для разработки смарт-контрактов и использования статических/динамических подтверждений правильности кода. Формальные методы всегда давали лучшие гарантии, даже несмотря на то что модель может быть слишком сложной в настройке. Также, предметно-ориентированные языки (DSL’ы) могут предотвращать широкий ассортиментбагов. Проблема в том, что формализация очень дорога, так что о ней часто забывают. Это еще один урок, который стоит усвоить: безопасное программирование стоит денег. Мы ожидаем новые инструменты формализации, написанные специально для RSK и Ethereum. Так или иначе, множество инструментов уже имеются в традиционных языках программирования, таких, как Java, JML, KeY. Вот одна из причин, по которым RSK строит параллельный чейн-инструментарий (toolchain), который позволяет смарт-контрактам быть записанными в Java, и мы ожидаем, что высокорискованные контракты будут разработаны с использованием этого инструментария. Прогрессивная децентрализация В чем-то настолько сложном, как создание Децентрализованной Автономной Организации, нельзя предсказать ни правильность кода, ни динамику и возможные бреши в системе голосования. Организация голосования — это комплексный человеческий процесс, и как таковой он потребует тестирования и нахождения ошибок перед тем, как будет корректно формализован. Адекватный подход заключается в начинании с контракта, который может быть легко и быстро обновлен с помощью (n,m) мультиподписей во владении нескольких «нотариусов», где n — простое большинство, и прогрессивное увеличение n может проходить до достижения полного нотариального консенсуса. Наконец, когда контракт полностью протестирован в реальных условиях, мультиподпись автоматически убирается через заданный промежуток времени. Возможно, у The DAO было бы намного меньше поддержки в самом начале, но в долгосрочной перспективе это увеличивает шансы на успех. RSK адаптировали эти критерии для гибридной системы консенсуса: по началу она требует нотариальных заверений, но количество «нотариусов» со временем уменьшается, пока не исчезает совсем благодаря merged-майнингу. Мы назвали данный подход прогрессивной децентрализацией. Он может применяться в отношении смарт-контрактов и систем консенсуса. Игнорирование рисков Много раз в прошлом, когда мне доводилось получать отчеты с аудитов по безопасности, очень часто приходили ответы, утверждающие, что нет такой уязвимости, так как необходимые условия атаки никогда не станут реальными, или атака слишком сложна чтобы ее выполнить, или что решение проблемы может иметь высокую степень влияния на комфорт пользователя. В реальности, как показывает мой опыт, подобная аргументация слаба. Неактивные уязвимости существуют благодаря изменениям в софте, так что подозрительный кусок кода, который не активирован по началу, может стать потенциальной уязвимостью после очередного обновления. Сложность атак вычисляется некорректно: атакующий правильно подсчитывает прибыль относительно затрачиваемых усилий, намного более точно, чем это делает жертва, которая не знает о возможностях атакующего. Влияние на комфорт пользователя может быть совершенно несущественным в случае, если софт полезен на протяжении короткого периода времени, пока кто-то не совершит атаку и все не бросят его использовать. Проблема рекурсивного вызова — четкий пример случая, когда уязвимость была хорошо известна заранее и задокументирована, но лишь некоторые люди восприняли ее серьезно. Плохая документация Разработчики Эфириума отчаянно нуждаются в особом сайте для документации паттернов дизайна, общих ошибок, неправильных трактовок, и лучших практик безопасности для программирования смарт-контрактов. В RSK мы будем создавать ресурсную область полностью посвященную безопасности смарт-контрактов, и мы пригласим исследователей принять участие в создании стандартов. Наш среднесрочный план включает создание платформы для проведения соревнований по взлому смарт-контрактов и прочих хакерских мероприятий (нечто вроде CTF). Программа RSK по сертификации партнеров Мы заключили договора с компаниями по безопасности, которые предоставят базовую сертификацию смарт-контрактам. Эти договора позволят стартапам тестировать свой код против самых распространенных дыр в безопасности, так как первый уровень проверок касается полного аудита кода. Мы приглашаем все компании по компьютерной безопасности, заинтересованные в данной теме, принимать участие в инициативе. С нами можно связаться, просто написав на почту: [email protected] Заключительные ремарки Область смарт-контрактов все еще находится на стадии взросления. Совершенно ясно, что ошибок не избежать. Пока не разработано достаточное количество инструментов и не написано множество строк документации к ним, нам стоит подойти к программированию контрактов с точки зрения «эшелонированной защиты», создавая и добавляя множество уровней безопасности, уменьшая тем самым влияние уязвимостей. Человеческие ошибки спровоцированы неясной семантикой языков программирования и нехваткой документации. Люди в RSK и все сообщество учатся на примере The DAO, но в то же время, мы подтверждаем, что RSK использует такой подход к использованию зрелых языков для разработки контрактов, который направит нас на истинный путь. Мы также призываем компании и платформы, занимающиеся смарт-контрактами, проводить аудиты безопасности, а инвесторов и пользователей прикладывать максимум усилий в поиске уязвимостей и разборе фактов прежде чем принимать ответственное решение. RSK Blog
