zk-SNARKs(ZKP) як система доказів, її суть полягає в тому, що доказник і перевіряючий на основі низки логічних схем розкривають і перевіряють проблему. Оскільки все більше протоколів Layer 2 та спеціальних публічних блокчейнів впроваджують технології ZKP, а також раніше існуючі проекти анонімних монет на основі ZKP, поєднання Блокчейн та ZKP стало джерелом нових загроз безпеці через складність системи. У цій статті з точки зору безпеки буде підсумовано можливі вразливості, що виникають у процесі інтеграції ZKP та Блокчейн, щоб надати посилання для безпеки відповідних проектів.
Основні характеристики zk-SNARKs
Перед аналізом безпеки системи ZKP нам спочатку потрібно зрозуміти три її основні характеристики:
Завершеність: для істинних тверджень, доводчик завжди може успішно довести їх правильність перевіряючому.
Надійність: щодо помилкових тверджень, зловмисний доказувач не може обманути перевіряючого.
Нульова знання: під час процесу перевірки перевіряючий не отримає жодної інформації від доказувача про самі дані.
Ці три характеристики є ключовими для безпеки та ефективності системи ZKP, на які потрібно особливо звернути увагу в безпекових послугах. Якщо не буде забезпечено повноту, система може не змогти надати правильні докази в екстремальних умовах, що призведе до відмови в обслуговуванні. Якщо не буде забезпечено надійність, зловмисник може підробити докази, обманюючи валідаторів, що призведе до обходу прав. Якщо не буде забезпечено нульову знаність, під час взаємодії можуть бути розкриті початкові параметри, що дозволить зловмиснику створити докази атаки або зловмиснику зловживати.
Безпекові питання проектів zk-SNARKs
Для проектів на базі ZKP у Блокчейн потрібно звернути увагу на такі аспекти безпеки:
1. zk-SNARKs електрична схема
Необхідно забезпечити безпеку, ефективність і масштабованість ZKP-циркулів, головним чином включаючи:
Помилка в проектуванні схеми: може призвести до того, що процес доказу не відповідатиме таким безпековим властивостям, як нульове знання, повнота або надійність.
Помилка реалізації криптографічного примітиву: якщо реалізація хеш-функцій, алгоритмів шифрування тощо має проблеми, це може загрожувати безпеці всієї системи доказів.
Відсутність випадковості: якщо процес генерації випадкових чисел має проблеми, це може призвести до зниження безпеки доказу.
2. Безпека контракту
Для проектів конфіденційних монет на Layer 2 або реалізованих через смарт-контракти, окрім поширених вразливостей, таких як повторний вхід та ін'єкції, слід особливо звернути увагу на безпеку перевірки міжланцюгових повідомлень та перевірки proof, оскільки це безпосередньо пов'язано з надійністю системи.
3. Доступність даних
Необхідно звернути увагу на те, як проект вирішує проблему доступності даних, забезпечуючи безпечний та ефективний доступ до даних поза ланцюгом та їх перевірку. Можна почати з аспектів зберігання даних, механізмів перевірки, процесу передачі тощо.
4. Економічні стимули
Оцінка того, чи є механізм стимулювання проекту розумним, чи може він ефективно спонукати всі сторони до участі та підтримки безпеки і стабільності системи. Включає в себе проектування моделі стимулювання, розподіл винагород, механізм покарань тощо.
5. Захист конфіденційності
Для проектів, що стосуються захисту конфіденційності, необхідно провести аудит їхніх рішень щодо конфіденційності, щоб забезпечити належний захист даних користувачів під час передачі, зберігання та перевірки, водночас підтримуючи доступність і надійність системи.
6. Оптимізація продуктивності
Оцінка стратегій оптимізації продуктивності проєкту, таких як швидкість обробки транзакцій, ефективність процесу верифікації тощо, аудит заходів оптимізації в реалізації коду.
7. Механізми відмовостійкості та відновлення
Аудит проектів, що стикаються з непередбаченими ситуаціями (, такими як збої в мережі, зловмисні атаки тощо ), стратегії відмовостійкості та відновлення, що забезпечують автоматичне відновлення системи за можливості та підтримання нормальної роботи.
8. Якість коду
Загальна якість коду аудиту проекту, увага на читабельність, підтримуваність і надійність, оцінка наявності ненормативних практик програмування, надмірного коду, потенційних помилок та інших проблем.
Важливість безпекових послуг
Щодо проектів ZKP, професійні послуги безпеки можуть забезпечити всебічний захист. Окрім звичайного аудиту коду смарт-контрактів, також потрібно мати можливість аудиту логіки кодування електричних схем, здатної одночасно використовувати ручний та автоматизований способи для аудиту умов обмеження та правильності генерації свідчень. Для важливої логіки можна за допомогою ручної збірки кастомних логічних свідчень моделювати різні види атак для тестування.
Крім того, для коду Sequencer/Prover та контракту перевірки необхідно мати можливості Fuzz та безпекового тестування, а також забезпечити захист для вузлів та даних вузлів. Після запуску проекту важливо також мати систему моніторингу та захисту в реальному часі, яка може забезпечити можливості для спостереження за станом безпеки в Блокчейн, сигналізації про ризики, відслідковування в Блокчейн тощо.
Підсумок
Обговорюючи безпеку проектів ZKP, перш за все, треба чітко визначити, для чого проект використовує ZKP, адже акценти безпеки різних типів проектів (, таких як Layer 2, конфіденційні монети, публічні блокчейни ), можуть суттєво різнитися. Але в будь-якому випадку, потрібно забезпечити ефективний захист трьох основних характеристик ZKP: повноти, надійності та нульових знань. Лише всебічно врахувавши всі аспекти безпеки, можна побудувати надійний захист для проектів ZKP.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
18 лайків
Нагородити
18
8
Репост
Поділіться
Прокоментувати
0/400
PumpDetector
· 08-03 00:42
спостерігав за zk-доказами з часів Silk Road... все ще не можу довіряти їм, чесно кажучи
Вісім основних безпекових аспектів поєднання zk-SNARKs та Блокчейн
zk-SNARKs в Блокчейн: обговорення безпеки
zk-SNARKs(ZKP) як система доказів, її суть полягає в тому, що доказник і перевіряючий на основі низки логічних схем розкривають і перевіряють проблему. Оскільки все більше протоколів Layer 2 та спеціальних публічних блокчейнів впроваджують технології ZKP, а також раніше існуючі проекти анонімних монет на основі ZKP, поєднання Блокчейн та ZKP стало джерелом нових загроз безпеці через складність системи. У цій статті з точки зору безпеки буде підсумовано можливі вразливості, що виникають у процесі інтеграції ZKP та Блокчейн, щоб надати посилання для безпеки відповідних проектів.
Основні характеристики zk-SNARKs
Перед аналізом безпеки системи ZKP нам спочатку потрібно зрозуміти три її основні характеристики:
Завершеність: для істинних тверджень, доводчик завжди може успішно довести їх правильність перевіряючому.
Надійність: щодо помилкових тверджень, зловмисний доказувач не може обманути перевіряючого.
Нульова знання: під час процесу перевірки перевіряючий не отримає жодної інформації від доказувача про самі дані.
Ці три характеристики є ключовими для безпеки та ефективності системи ZKP, на які потрібно особливо звернути увагу в безпекових послугах. Якщо не буде забезпечено повноту, система може не змогти надати правильні докази в екстремальних умовах, що призведе до відмови в обслуговуванні. Якщо не буде забезпечено надійність, зловмисник може підробити докази, обманюючи валідаторів, що призведе до обходу прав. Якщо не буде забезпечено нульову знаність, під час взаємодії можуть бути розкриті початкові параметри, що дозволить зловмиснику створити докази атаки або зловмиснику зловживати.
Безпекові питання проектів zk-SNARKs
Для проектів на базі ZKP у Блокчейн потрібно звернути увагу на такі аспекти безпеки:
1. zk-SNARKs електрична схема
Необхідно забезпечити безпеку, ефективність і масштабованість ZKP-циркулів, головним чином включаючи:
Помилка в проектуванні схеми: може призвести до того, що процес доказу не відповідатиме таким безпековим властивостям, як нульове знання, повнота або надійність.
Помилка реалізації криптографічного примітиву: якщо реалізація хеш-функцій, алгоритмів шифрування тощо має проблеми, це може загрожувати безпеці всієї системи доказів.
Відсутність випадковості: якщо процес генерації випадкових чисел має проблеми, це може призвести до зниження безпеки доказу.
2. Безпека контракту
Для проектів конфіденційних монет на Layer 2 або реалізованих через смарт-контракти, окрім поширених вразливостей, таких як повторний вхід та ін'єкції, слід особливо звернути увагу на безпеку перевірки міжланцюгових повідомлень та перевірки proof, оскільки це безпосередньо пов'язано з надійністю системи.
3. Доступність даних
Необхідно звернути увагу на те, як проект вирішує проблему доступності даних, забезпечуючи безпечний та ефективний доступ до даних поза ланцюгом та їх перевірку. Можна почати з аспектів зберігання даних, механізмів перевірки, процесу передачі тощо.
4. Економічні стимули
Оцінка того, чи є механізм стимулювання проекту розумним, чи може він ефективно спонукати всі сторони до участі та підтримки безпеки і стабільності системи. Включає в себе проектування моделі стимулювання, розподіл винагород, механізм покарань тощо.
5. Захист конфіденційності
Для проектів, що стосуються захисту конфіденційності, необхідно провести аудит їхніх рішень щодо конфіденційності, щоб забезпечити належний захист даних користувачів під час передачі, зберігання та перевірки, водночас підтримуючи доступність і надійність системи.
6. Оптимізація продуктивності
Оцінка стратегій оптимізації продуктивності проєкту, таких як швидкість обробки транзакцій, ефективність процесу верифікації тощо, аудит заходів оптимізації в реалізації коду.
7. Механізми відмовостійкості та відновлення
Аудит проектів, що стикаються з непередбаченими ситуаціями (, такими як збої в мережі, зловмисні атаки тощо ), стратегії відмовостійкості та відновлення, що забезпечують автоматичне відновлення системи за можливості та підтримання нормальної роботи.
8. Якість коду
Загальна якість коду аудиту проекту, увага на читабельність, підтримуваність і надійність, оцінка наявності ненормативних практик програмування, надмірного коду, потенційних помилок та інших проблем.
Важливість безпекових послуг
Щодо проектів ZKP, професійні послуги безпеки можуть забезпечити всебічний захист. Окрім звичайного аудиту коду смарт-контрактів, також потрібно мати можливість аудиту логіки кодування електричних схем, здатної одночасно використовувати ручний та автоматизований способи для аудиту умов обмеження та правильності генерації свідчень. Для важливої логіки можна за допомогою ручної збірки кастомних логічних свідчень моделювати різні види атак для тестування.
Крім того, для коду Sequencer/Prover та контракту перевірки необхідно мати можливості Fuzz та безпекового тестування, а також забезпечити захист для вузлів та даних вузлів. Після запуску проекту важливо також мати систему моніторингу та захисту в реальному часі, яка може забезпечити можливості для спостереження за станом безпеки в Блокчейн, сигналізації про ризики, відслідковування в Блокчейн тощо.
Підсумок
Обговорюючи безпеку проектів ZKP, перш за все, треба чітко визначити, для чого проект використовує ZKP, адже акценти безпеки різних типів проектів (, таких як Layer 2, конфіденційні монети, публічні блокчейни ), можуть суттєво різнитися. Але в будь-якому випадку, потрібно забезпечити ефективний захист трьох основних характеристик ZKP: повноти, надійності та нульових знань. Лише всебічно врахувавши всі аспекти безпеки, можна побудувати надійний захист для проектів ZKP.