Павел Анохин: «В блокчейне одной ошибки достаточно, чтобы потерять все активы пользователей»

Павел Анохин: Конечно. У меня на тот момент уже были награды в соревнованиях аудиторов code4rena, найденные критические ошибки в топовых проектах. Одна из руководителей TeaHouse Finance вместе со мной активно участвовала в помощи сообществу Perpetual Protocol, и таким образом узнала о моих способностях. В том числе она знала о помощи в поиске и исправлении серьезной ошибки, предотвратившей потенциальные потери больше чем в десять миллионов долларов. TeaHouse Finance в тот момент выпустили свой проект в закрытое бета-тестирование и искали для него аудиторов.

Павел Анохин: TeaHouse Finance — это компания, которая занимается разработкой различных децентрализованных приложений. Их основной продукт — это Teahouse Vaults — инфраструктура для автоматизированного управления крупным капиталом на блокчейне. Благодаря их продукту менеджеры, которые управляют капиталом на блокчейне, могут открывать набор средств под управление, а инвесторы могут выбирать между разными менеджерами, вкладывая средства под их управление. Менеджерами могут быть как люди, так и программы.

TeaHouse Finance обратились ко мне с необходимостью провести аудит безопасности этой инфраструктуры на предмет возможных уязвимостей и злоупотреблений как со стороны менеджеров, так и со стороны клиентов.

Павел Анохин: Было найдено несколько небольших ошибок, которые не приводили к критическим результатам, однако потенциально могли привести к серьезным проблемам при будущих обновлениях инфраструктуры. Команда оперативно устранила эти недочеты. Также я предоставил свои соображения по возможному улучшению проекта. Команда была благодарна за подробный отчет и за мои усилия по улучшению их продукта.

Павел Анохин: Цель премии — популяризовать малый, средний и крупный бизнес, а также укрепить сотрудничество между предпринимателями и бизнес-специалистами из разных стран.

В мою задачу, как члена жюри, входила оценка эссе участников об их достижениях и проверка фактов, указанных в эссе. Было очень интересно погрузиться в бизнес-деятельность, узнать тонкости совершенно разных бизнесов. Меня всегда вдохновляли истории успешных бизнесов, а истории более чем сотни участников, которые я прочитал, все как на подбор — истории успеха. Было довольно сложно выбрать лучших из них. Достойных было много, но тем по итогам моей работы определились два победителя: Денис Кутергин как «Создатель лучшего ИТ-сервиса» и Максим Михеенко как «Лучший предприниматель в сфере компьютерной графики».

Павел Анохин: Вообще она появилась как мой личный эксперимент, разминка. Когда я занимался другой игрой в этом же жанре, уже запустив закрытое бета-тестирование перед выпуском, я просто для интереса решил написать простенькую idle-игру: Idle Bouncer. В этой игре я попробовал применить инновационные механики: более сложный и интересный процесс развития по сравнению со всеми существующими играми в жанре idle, ну и необычную визуальную составляющую — прыгающие мячики. Игра была написана буквально за два дня и тут же выпущена, без особых ожиданий результатов.

Хотелось посмотреть на комментарии от игроков idle-игр, чтобы учесть их и может быть что-то поменять в другом проекте. Игра была выпущена вечером, а на утро следующего дня меня ожидали уже сотни восторженных комментариев, высокие рейтинги, тысячи активных игроков.

Павел Анохин: Да. Пришлось срочно поставить на паузу предыдущий проект и заняться Idle Bouncer: прочитать все комментарии игроков, предложения по развитию игры, найденные ошибки. Игрокам очень понравилось, что игра меняется и развивается в соответствии с их пожеланиями — это привлекло еще больше игроков. Благодаря этой популярности проект как раз и заметили профильные медиа и журналисты.

Павел Анохин: Да, постепенно начали появляться клоны — уже когда игра существенно усложнилась, добавилось больше стратегии, что позволило увеличить удержание игроков: они стали чаще возвращаться в игру и тратить на неё больше времени и денег. А позже механики из Idle Bouncer стали внедрять новые проекты, что повышало удержание игроков для всего жанра. Совершенно неожиданно для меня моя игра действительно повлияла на весь жанр Idle, задав тренд на усложнение.

Павел Анохин: Платформа Kongregate была одним из топовых сайтов по количеству онлайн-игроков, во многом благодаря открытой политике по отношению к разработчикам и регулярным конкурсам на лучшую игру. Победители определялись по наивысшей средней оценке, а оценивали игры сами игроки. В день на Kongregate выпускалось по 100 и больше игр, поэтому конкуренция действительно была очень сильная. Надо добавить, что множество других веб-сайтов с онлайн-играми часто размещают у себя всех победителей конкурсов на лучшую игру с сайта Kongregate, поэтому благодаря победе в этих конкурсах Idle Bouncer получил еще больший приток игроков и разошелся по всему интернету.

Павел Анохин: Общий опыт программирования точно помогает с поиском уязвимостей, а разработка игр в этом смысле — это углубление опыта программирования и в том числе поиска ошибок.

Павел Анохин: Я регулярно изучаю разные крипто-проекты и проверяю код понравившихся проектов на безопасность. Frax Finance привлек своей интересной реализацией привязки к доллару.

В одном из модулей Frax Finance — Frax Swap, децентрализованный обмен криптовалют, я нашёл критическую ошибку, из-за которой больше двух с половиной миллионов долларов могли заблокироваться в платформе без возможности их вернуть, то есть потеряны навсегда. Эту ошибку я нашел несмотря на то, что модули Frax Finance прошли аудит у пяти различных очень известных и уважаемых аудиторов.

Я связался с командой разработчиков Frax Finance, переслал им отчет о найденной уязвимости, который они быстро подтвердили, тут же остановили этот модуль, чтобы избежать потерь активов. Исправление затянулось на несколько недель, в течение которых я активно взаимодействовал с командой, давал советы по исправлению.

Павел Анохин: В блокчейне безопасность критически важна: одной ошибки достаточно, чтобы потерять все активы пользователей. Поэтому мер по безопасности в блокчейне мало не бывает. Для этого они должны предприниматься на многих этапах разработки.

Еще до начала разработки обязательно нужно удостовериться в отсутствии экономических уязвимостей. Во время разработки нужно придерживаться стандартов безопасного программирования. После завершения разработки — обязательно прохождение аудита независимым аудитором, в идеале — нескольких аудиторов. Хорошо для этого подходит проведение соревнования среди аудиторов, что дает возможность мозгового штурма сотен лучших аудиторов, позволяя найти огромное количество потенциальных проблем.

Любое обновление приложения должно проходить аудит безопасности до его выпуска. Известен не один случай, когда в приложение, которое уже прошло аудит безопасности, добавлялась всего одна строчка кода, и приложение выпускалось без аудита, но именно эта одна строчка создавала уязвимость и приводила к катастрофическим потерям.

После выпуска приложения обязательно нужно иметь программу выплаты за найденные ошибки в уже работающем приложении, чтобы стимулировать специалистов по безопасности искать ошибки, а хакерам давать стимул получить честную награду, а не использовать ошибки для обогащения нечестным методом.