Однією з головних цілей проектів, заснованих на блокчейні, є перевірка даних. Для живих прикладів ви можете переглянути цифрову ідентифікацію та онлайн-зберігання та перевірку документів. Справді, у будь-якому з цих випадків потрібна перевірка ініціатора дії/транзакції для підтвердження фізичної чи юридичної особи. Наприклад, якщо особа має цифрову форму ідентифікаційного документа, важливо забезпечити право власності. Таким чином, це чудовий приклад проблеми верифікованості даних. Розглянемо найпростіший варіант рішення — цифровий підпис, тестування якого є одним із ключових моментів при розробці смарт-контракту.
Підхід простий:
1) система формує повідомлення за відомими всім правилами
2) підписувач отримує повідомлення та додає певний набір символів — цифровий підпис, код, створений із повідомлення за допомогою закритого ключа
3) створений підпис тепер надсилається до контракту, де він розкладається для отримання адреси підписувача.
Solidity пропонує вам алгоритм ECDSA для створення підпису та подальшої декомпозиції. Нам не потрібно глибоко занурюватися в сам алгоритм (потрібну інформацію ви можете знайти у відповідних джерелах). Все, що нам потрібно знати, це те, що ECDSA є прикладом асиметричної криптографії, де перший користувач створює підпис за допомогою свого закритого ключа, а другий користувач застосовує стандартний алгоритм для отримання відкритого ключа підписувача. Таким чином, він може перевірити джерело підпису. Замість цього зосередимося на практичній частині — використанні підпису та тестуванні.
Перш за все, ми повинні розпізнати проблему. Наприклад, контракт повинен виконати якусь дію, скажімо, зберегти адресу абонента. Хоча договір повинен виконувати зберігання лише за умови перевірки абонента, ми повинні бути впевнені, що ніхто не може використовувати його адресу без дозволу. Щоб отримати автентичного абонента, нам потрібно створити якесь повідомлення, підписати його та розкласти в рамках контракту.
Ви можете знайти стандартне рішення в документації Solidity (наприклад, в 0.8.4 — остання стабільна версія на момент написання статті). Документи пропонують нам контракт, для якого були потрібні наступні вбудовані функції: генерація повідомлень, розділення підпису та код складання для отримання підписувача. Приклад показує всі необхідні методи та є досить простим, хоча він має два недоліки: йому бракує універсальності та немає хорошого прикладу тестування рішення. Тому я надаю свою версію коду та (справжню мету) — стратегію тестування контракту.
Звичайно, можна використовувати стандартна бібліотека OpenZeppelin для операцій ECDSA, але ви знову зіткнетеся з тими ж проблемами — брак гнучкості та підходів до тестування. Отже, давайте зануримося в мій приклад логіки на основі підпису. Ви можете знайти повну робочий приклад у моєму GitHub, але є кілька місць, які я хочу показати повністю.
Перш за все, ми підготуємо повідомлення. Як бачите, він формується з двох упакованих і хешованих адрес гаманців:
Друга важлива частина коду хешує повідомлення разом зі стандартним повідомленням Ethereum:
Він показує, що повідомлення було надіслано в мережі Ethereum і має довжину 32 байти, що не є випадковим числом. Після попередніх операцій ми маємо хеш, який має довжину 32 байти. Важливо мати додаткову функцію хешування в такій формі, і ми обговоримо міркування трохи пізніше.
Інші частини коду досить стандартні. Функція розділення підпису така:
і ось функція для отримання підписувача:
Для зовнішнього інтерфейсу ми будемо використовувати спеціальну функцію, яка отримує підпис і необхідні аргументи, перевіряє, чи зареєстрований користувач, формує повідомлення і перевіряє підпис:
Спочатку ми імітуємо повідомлення, яке потрібно підписати. Будемо використовувати ethers.js бібліотека, яка є (разом з web3) найбільш використовувана і зручна бібліотека. Оскільки це бібліотека з відкритим кодом, ви можете вільно досліджувати його код і документи. Крім того, ця бібліотека дає нам ідеальний інтерфейс для створення такого повідомлення:
Один із мінусів обох web3 та прості ефіри бібліотек полягає в тому, що вони не мають усіх функцій для локального середовища Ganache, оскільки обидві бібліотеки націлені на роботу з повними вузлами Ethererum. Тим не менш, існує підхід для використання локального тестування функціонал web3-облікового запису. Але потрібно створити додатковий обліковий запис, який реалізує функціонал співака та забезпечить підключення до поточного провайдера web3:
Отже, тепер ми маємо згенероване та підписане повідомлення. Але це ще не все; залишилося поговорити про кілька речей. Обидві бібліотеки (web3 і ethers) під капотом забезпечують додаткове хешування повідомлення перед створенням підпису. Крім того, повідомлення не просто хешується, а поєднується зі стандартним повідомленням Ethereum, яке ми бачили раніше:
І тому ми додали до договору додатковий спосіб. Отже, якщо ви хочете використовувати спеціальні повідомлення, пропустити додаткове хешування тощо, вам потрібно створити спеціальну версію функції підпису. Причину ми обговорювали вище — обидві стандартні бібліотеки реалізують типовий підхід до підпису повідомлення, який можна змінити, лише змінивши функціональність.
Як останній крок, давайте запустимо тест і перевіримо, чи він працює правильно:
Ми протестували створення підпису, згенероване повідомлення, схвалення та відхилення підпису. Отже, це досить повний набір тестів для перевірки функціональності.
- рахунки
- дію
- Додатковий
- алгоритм
- ВСІ
- аргументація
- стаття
- Authentic
- Біт
- випадків
- Перевірки
- код
- контракт
- криптографія
- Поточний
- дані
- розробка
- цифровий
- цифрова ідентифікація
- документація
- Навколишнє середовище
- Ефіріума
- мережа ethereum
- Face
- Перший
- Гнучкість
- Сфокусувати
- форма
- Безкоштовна
- Повний
- функція
- добре
- мішанина
- хешування
- HTTPS
- ia
- Особистість
- інформація
- IP
- IT
- ключ
- останній
- бібліотека
- місцевий
- середа
- мережу
- вузли
- пропонувати
- Пропозиції
- онлайн
- відкрити
- з відкритим вихідним кодом
- операції
- приватний
- Private Key
- проектів
- громадськість
- публічний ключ
- огляд
- прогін
- комплект
- простий
- So
- солідність
- розкол
- зберігання
- зберігати
- Стратегія
- система
- тест
- Тестування
- Тести
- Джерело
- us
- перевірка
- Wallet
- Вікіпедія
- в
- Work
- працює