Від ідеї до реалізації: модифікуємо існуючу схему цифрового підпису на еліптичній кривій, щоб вона була детермінованою, і надаємо на її основі функції отримання псевдовипадкових чисел, що перевіряються в рамках блокчейна.
Ідея
Восени 2018 у блокчейні Waves були , негайно постало питання про можливість отримання , Яким можна довіряти.
Ламаючи голову над цим питанням, остаточно дійшов висновку: будь-який блокчейн — це клітина, отримати довірене джерело ентропії у замкнутій системі неможливо.
Але одна ідея мені все ж таки сподобалася: якщо буде робити підпис даних користувача детермінованим алгоритмом, то користувач завжди зможе і перевірити такий підпис по відкритому ключу, і буде впевнений, що отримане значення унікальне. Оракул при всьому бажанні не може нічого змінити, алгоритм видає однозначний результат. По суті користувач фіксує результат, але не знає його доти, поки оракул його не опублікує. Виходить, що взагалі можна не довіряти оракулу, але перевіряти результат його роботи. Тоді, у разі успішної перевірки такий підпис можна вважати джерелом ентропії для псевдовипадкового числа.
У блокчейн-платформі Waves використовується схема підпису варіант . У цій схемі підпис складається зі значень R і S, де R залежить від випадкового значення, а S обчислюється на основі повідомлення, що підписується, закритого ключа і того ж випадкового числа, що і R. Виходить, що однозначної залежності немає, для одного і того ж користувача повідомлення існує безліч валідних підписів.
Очевидно, що в чистому вигляді такий підпис неможливо використовувати як джерело псевдовипадкових чисел, оскільки він є недетермінованим і, отже, може бути легко схильний до маніпуляцій з боку оракула.
Але, як з'ясувалося, зробити її детермінованою насправді можна.
Великі надії у мене були на , Але вивчивши матч, від цього варіант довелося відмовитися. Хоча VRF і пропонує детермінований варіант підпису та його докази, в алгоритмі є дивне місце, яке відкриває чорну дірку для маніпуляцій оракулом. Зокрема, при розрахунку значення k () використовується закритий ключ, який залишається невідомим користувачеві, значить користувач не може перевірити коректність обчислення k, значить оракул може використовувати будь-яке потрібне йому значення k і одночасно вести базу даних відповідностей k і даних, що підписуються, щоб завжди вміти повторно обчислити коректний з точки зору VRF результат . Побачте розіграш на основі VRF без розкриття закритого ключа, можете порозумнішати: вказати на необхідність або розкрити ключ, або виключити його з розрахунку k, тоді закритий ключ автоматично сам розкриється при появі першого ж підпису. Загалом, як було зазначено, дивна схема для випадкового оракула.
Трохи подумавши та заручившись підтримкою місцевих аналітиків, народилася схема роботи VECRO.
VECRO - абревіатура від Verifiable Elliptic Curve Random Oracle, що по-російськи означає випадковий оракул, що перевіряється на еліптичних кривих.
Все виявилося досить просто, для досягнення детермінованості потрібно зафіксувати значення R до появи повідомлення, що підписується. Якщо R зафіксовано і є частиною повідомлення, що підписується, що додатково гарантує фіксацію R в самому підписуваному повідомленні, значення S однозначно детермінується користувальницьким повідомленням і, отже, може бути використане як джерело для псевдовипадкових чисел.
У такій схемі будь-яким чином фіксується R, це залишається в зоні відповідальності оракула. Важливо, що S однозначно визначається користувачем, але його значення невідомо, поки оракул його не опублікує. Як ми хотіли!
Говорячи про фіксований R, зверніть увагу, що під час підпису різних повідомлень однозначно розкриває закритий ключ у схемі EdDSA. Для власника оракула стає дуже важливим виключити можливість повторного використання R для підпису різних повідомлень користувача. Тобто, при будь-яких маніпуляціях чи змові оракул завжди ризикуватиме втратою свого закритого ключа.
Отже, оракул повинен надавати користувачам дві функції: ініціалізацію, яка фіксує значення R, і підпис, який повертає значення S. При цьому пара R, S є звичайним підписом користувача користувача, що містить фіксоване значення R і довільні дані користувача.
Можна заперечити, що дана схема для блокчейна ніщо інше як звичайна . Власне, так, це вона. Але є кілька нюансів. По-перше, оракул завжди працює з одним і тим же ключем у всіх операціях, наприклад, це зручно використовувати у контрактах. По-друге, існує ризик втрати закритого ключа оракулом при некоректній поведінці, наприклад, оракул дозволяє робити проби результату, тоді достатньо зробити лише дві проби, щоб дізнатися закритий ключ і отримати повний доступ до гаманця. По-третє, підпис, що нативно перевіряється в блокчейні, який є джерелом випадковості — це красиво.
Півроку ідея реалізації спалахувала, поки нарешті не з'явилася мотивація у вигляді . З великим грантом приходить велика відповідальність, тож проекту бути!
Реалізація
Отже, у цьому проекті на блокчейні Waves у режимі запит-відповідь за допомогою транзакцій трансферу між користувачем та оракулом. При цьому на обліковому записі оракула встановлений скрипт, який контролює роботу строго у відповідність до описаної вище логіки. Транзакції оракула проходять перевірку з відновленням всього ланцюжка взаємодії з користувачем. У перевірці фінального значення беруть участь усі чотири транзакції, смарт-контракт нанизує їх на сувору нитку перевірки, крок за кроком перевіряючи всі значення і не залишаючи місця для будь-яких маніпуляцій.
Ще раз, щоб відклалося та було зрозуміліше. Оракул не просто працює за запропонованою схемою. Його робота повністю контролюється на рівні блокчейна встановленим . Крок ліворуч і транзакція просто не пройде. Отже, якщо транзакція потрапила до блокчейну, користувачеві навіть перевіряти нічого не треба, за нього все вже перевірили сотні вузлів мережі.
На даний момент в основній мережі Waves запущено один VECRO (ви можете запустити свій, це не складно, просто ). Поточний код працює на PHP (на , про який ).
Для того, щоб скористатися сервісом оракула необхідно:
- Зафіксувати R;
- Надіслати мінімум 0.005 Waves на аліас оракула init@vecr;
- Отримати R-code в полі attachment в трансфері 1 R-vecr токена від оракула користувачу;
- Отримати підпис;
- Надіслати мінімум 0.005 Waves на аліас оракула random@vecr, а також ОБОВ'ЯЗКОВО вказати в полі attachment отриманий раніше R-code та додаткові дані користувача;
- Отримати S-code в полі attachment в трансфері 1 S-vecr токена від оракула користувачу;
- Використовувати S-code як джерело псевдовипадкового числа.
Нюанси поточної реалізації:
- Надіслані оракулу Waves використовуються як комісія для зворотної транзакції користувачеві, аж до максимальних 1 Waves;
- R-code - це конкатенація байта символу 'R' і 32-байт значення R кодування base58;
- R-code в attachment повинен бути першим, дані користувача йдуть після R-code;
- S-code - це конкатенація байта символу 'S' та 32-байт значення S у кодуванні base58;
- S є результатом поділу по модулю, тому не можна використовувати S як повноцінне 256-бітове псевдовипадкове число (дане число може вважатися максимум 252-бітовим псевдовипадковим числом);
- Найбільш простий варіант - використовувати як псевдовипадкове число хеш від S-code.
Приклад отримання S-code:
- Ініціалізація:
- Отримання R-code:
- Запит результату підпису R-code та даних користувача “ random”:
- Отримання S-code:
З технічної точки зору оракул повністю готовий до роботи, можете сміливо ним користуватися. З погляду використання рядовим користувачем, не вистачає зручного графічного інтерфейсу, цього доведеться зачекати.
Радий відповісти на запитання і прийняти зауваження, спасибі.
Джерело: habr.com