У цьому ексклюзивному інтерв’ю, взятому під час конференції Hack Seasons, Альп Басса, науковий співробітник Veridise, ділиться думкою про інноваційні інструменти Veridise, тонкощі перевірки з нульовими знаннями та майбутнє безпеки блокчейну. Під час обговорення ми досліджуватимемо перетин математики, криптографії та технології блокчейн очима одного з провідних експертів галузі.
Багатьох підприємців приваблює у свою сферу певний момент чи подія. Яким був ваш шлях до Web3?
Я походжу з академічного середовища. Я математик, який досліджував теорію чисел, зосереджуючись на кривих над кінцевими полями, еліптичних кривих і їх застосуванні в теорії кодування та криптографії. Ці інструменти активно використовуються, особливо зараз, коли криптографія з нульовим знанням має більший вплив у просторі Web3.
Я бачив, що там відбувається багато цікавого. Потім я почав працювати у Veridise, де вони проводять аудит безпеки та спеціалізуються на домені ZK, де мій досвід дуже добре вписується.
Навіщо нам взагалі потрібні аудити безпеки? Чи можуть розробники працювати без них, чи вони обов'язкові?
Безпека систем вимагає іншого мислення, яке ви повинні прийняти вже на етапі розробки. Не всі розробники можуть зосередитися на всіх аспектах процесу розробки одночасно – забезпеченні правильних специфікацій, поведінки, ефективності, інтеграції в більшу систему та безпеки. У більшості випадків безпека — це аспект, який недостатньо висвітлюється протягом усього процесу розробки.
Для розробника стало майже неможливо бути достатньо впевненим у роботі з різними складними інструментами, щоб гарантувати, що вони використовуються правильно та не мають вразливостей. Це просто інше мислення, яке потрібно застосувати. Ось чому аудити корисні.
Чи можете ви детальніше розповісти про внутрішні інструменти, розроблені Veridise, і про те, як вони покращують якість аудиту?
Існує широкий спектр інструментів, які можна використовувати. Деякі з них більш примітивні, але не вимагають надто багато фону та легкодоступні, як-от фазери. Деякі знаходяться посередині, як інструменти статичного аналізу. Вони досить швидкі, але не надто точні – можуть давати помилкові спрацьовування.
Крім того, є інструменти, які значною мірою підкріплені математикою, засновані на розв’язувачах SMT та інших математичних знаннях. Вони дуже точні, але важкі для обчислень. Ми використовуємо комбінацію всіх цих інструментів, кожен зі своїми плюсами та мінусами, щоб виявити помилки та вразливості.
На які унікальні міркування безпеки Veridise звертає увагу для протоколів DeFi?
Для протоколів DeFi у нас є інструмент статичного аналізу, за допомогою якого ви заздалегідь повідомляєте системі, які типи вразливостей шукати або до яких структур прагнути. Їх багато. Наприклад, атаки повторного входу були відповідальними за злом DAO у 2016 році. Атаки флеш-позики були використані в атаці на Cream Finance, що призвело до викрадення близько 130 мільйонів доларів.
Завдяки багаторічному досвіду аудиту ми маємо гарне уявлення про вразливості, і наші інструменти створені для перевірки всього цього. Під час наших перевірок ми детально розглядаємо їх один за одним, щоб побачити, чи з’являються такі ризики.
Розкажіть, будь ласка, докладніше про те, як ви використовуєте технологію ZK і чому аудит ZK є вашим головним пріоритетом?
ZK особливо цікавий з точки зору формальної перевірки, оскільки він дуже добре перекладається на використання інструментів. У нас є інструменти, які спрямовані саме на перевірку додатків ZK. Оскільки це дуже підходить для наших методів, це та сфера, на якій ми багато зосередили.
Ми виявили критичні вразливості в бібліотеках основних схем. Наша команда дуже сильна в цій галузі, тому ми вирішили бути дуже присутніми та бути на передовій аудиту ZK. Більшість наших досліджень також мотивовані потребами та вимогами з точки зору аудитора щодо домену ZK.
Чим ваш досвід роботи зі схемами ZK відрізняється від інших компаній?
Я б сказав, що наші інструменти – це те, що сильно відрізняє нас, оскільки ми маємо досвід офіційної перевірки. У нас є дуже потужні інструменти, і на сьогоднішній день обсяг проектів став настільки великим, що одних тільки людських зусиль недостатньо для гарного покриття кодової бази. Це необхідно, але самого по собі цього недостатньо.
Як Veridise балансує перевірку коду вручну з автоматизованим інструментальним аналізом у своєму процесі аудиту?
Є потреба в обох. Ми помічаємо це і в аудитах. У більшості випадків, коли ми проводимо дуже ретельний людський аудит, а потім запускаємо інструменти на кодовій базі, ми знаходимо деякі вразливості, які вислизнули від нашої уваги. Іноді ми спочатку запускаємо інструменти, але вони можуть виявляти лише певні види структур.
Оскільки в цих системах так багато рівнів ускладнень і абстракцій, просто покладатися на інструменти також недостатньо. Я відчуваю, що ви не можете обійтися без жодного з них, і я не думаю, що це зміниться в майбутньому.
Які ключові особливості інструменту Veridise Vanguard і як він покращує безпеку смарт-контрактів?
Авангард – один із наших головних інструментів. Використовується для статичного аналізу. У статичному аналізі ви надаєте певну специфікацію запланованої поведінки, а потім перевіряєте, чи вона виконується – чи зберігаються певні властивості без запуску коду. Це не динамічно; ви не виконуєте код, але статично намагаєтеся оцінити, чи існують певні шаблони, які можуть спричинити вразливості.
Vanguard має багато смаків. У нас є його частини, які досить гарні для покращеної безпеки смарт-контрактів, і частини, зосереджені на програмах zk.
Чи можете ви детальніше розповісти про вразливості, з якими ви стикалися в смарт-контрактах і схемах ZK?
У схемах ZK, над якими я більше працюю, однією з найбільш часто зустрічаються вразливостей є схеми з недостатніми обмеженнями. У додатку ZK ваша кодова база складається з двох частин: самої програми (звичайне виконання) та обмежень. Ви вимагаєте, щоб обмеження відображали поведінку виконання програми один до одного.
Відповідно до нещодавньої статті, близько 95% усіх уразливостей у схемах ZK спричинені недостатньо обмеженими схемами. У нас є такі інструменти, як PICUS, які особливо спрямовані на виявлення цих недостатньо обмежених схем.
Як Veridise підходить до процесу розкриття вразливостей, виявлених під час перевірок?
Звичайно, ми ні в якому разі не оприлюднюємо вразливості, тому що хтось інший може використати помилку до її усунення, особливо якщо кодова база вже використовується. Наприкінці процесу аудиту ми надаємо аудиторський звіт, у якому надаємо клієнту список усіх виявлених помилок і вразливостей.
Ми даємо клієнту деякий час, щоб виправити їх, а потім вони надсилають нам свої виправлення, які ми переглядаємо, щоб перевірити, чи справді вони вирішують усі порушені нами проблеми. Ми зібрали все це в остаточному звіті. Звіт є власністю замовника. Ми не оприлюднюємо це, якщо клієнт не погодиться.
Якщо ви перейдете на веб-сторінку Veridise, ви побачите список усіх аудиторських звітів, які клієнти погодилися оприлюднити. У більшості випадків вони погоджуються, щоб ми оприлюднили це. Фактично, вони хочуть це як сертифікат того, що код перевірено та максимально вільний від помилок після аудиту.
Як Veridise адаптує свої процеси аудиту для різних блокчейн-платформ і мов?
Як ви знаєте, сфера дуже активна, і щодня з’являються нові ланцюги, нові мови та нові способи вираження схем ZK. Ми бачимо це також у вхідних проектах і запитах на аудит, які базуються на різних середовищах або мовах. Ми пливемо за течією, бачимо, звідки надходять запити, і маємо відчуття, у якому напрямку буде розвиватися сфера в найближчому майбутньому.
Ми намагаємося адаптувати наші інструменти до потреб спільноти. Це триватиме й у майбутньому, коли ми будемо динамічно змінювати речі відповідно до розвитку галузі.
Чи можете ви детальніше розповісти про інструменти, які ви плануєте запровадити в майбутньому?
Одним із напрямків, у якому інструменти зміняться найближчим часом, є те, що ми пропонуватимемо безпеку як послугу. Це називається нашою платформою SaaS, на якій ми зробимо інструменти доступними для людей у процесі розробки.
Замість того, щоб спочатку завершувати весь проект, а потім проводити аудит, ми зробимо наші інструменти корисними в налаштуваннях, де розробники зможуть використовувати їх під час розробки, щоб переконатися, що код, який вони розробляють, безпечний і не містить уразливостей. SaaS має бути доступним найближчим часом.
Публікація Злом коду вразливостей DeFi: глибоке занурення Альпа Басса в безпеку смарт-контрактів вперше з’явилася на Metaverse Post.
