Ми вже давно цікавимося темою анонімності у криптовалютах та намагаємося стежити за розвитком технологій у цій галузі. У своїх статтях ми вже детально розбирали принципи роботи у Monero, а також проводили технологій, що існують на цьому полі. Однак всі анонімні криптовалюти на сьогоднішній день побудовані на моделі даних, запропонованої Bitcoin - Unspent Transaction Output (далі UTXO). Для account-based блокчейнов як Ethereum існуючі рішення щодо реалізації анонімності та конфіденційності (наприклад, або ) намагалися повторити модель UTXO у смарт-контрактах.
У лютому 2019 року група дослідників зі Стенфордського університету та Visa Research випустили "Zether: Назустріч приватності у світі смарт-контрактів". Автори вперше запропонували підхід до забезпечення анонімності в account-based блокчейнах та представили два варіанти смарт-контракту: для конфіденційних (приховування балансів та сум переказів) та анонімних (приховування одержувача та відправника) транзакцій. Ми знаходимо запропоновану технологію цікавою і хотіли б поділитися її пристроєм, а також поговорити про те, чому проблема анонімності в account-based блокчейнах вважається дуже складною і чи вдалося авторам її вирішити повною мірою.
Про влаштування цих моделей даних
У UTXO-моделі транзакція складається з «входів» та «виходів». Прямий аналог "виходам" - купюри у вашому гаманці: кожен "вихід" має якийсь номінал. Коли ви розплачуєтеся з кимось (формуєте транзакцію) ви витрачаєте один або кілька «виходів», при цьому вони стають «входами» транзакції, і блокчейн позначає їх як витрачені. При цьому одержувач вашого платежу (або ви самі, якщо вам потрібна здача) отримує новостворені «виходи». Схематично це можна зобразити так:
Account-based блокчейни влаштовані приблизно як ваш банківський рахунок. Вони оперують лише сумою на вашому рахунку та сумою переказу. Коли ви переводите якусь суму зі свого рахунку, то не спалюєте жодних «виходів», мережі не потрібно запам'ятовувати, які монети витрачені, а які ні. У найпростішому випадку перевірка транзакції зводиться до перевірки підпису відправника та суми на його балансі:
Розбір технології
Далі ми поговоримо про те, як Zether приховує суму транзакцій, одержувача та відправника. Під час опису принципів його роботи ми відзначатимемо відмінності в конфіденційному та анонімному варіанті. Так як забезпечити конфіденційність в account-based блокчейнах набагато простіше, деякі з обмежень, що накладаються анонімізацією, будуть неактуальні для конфіденційної версії технології.
Приховування балансів та сум переказів
Для шифрування балансів та сум переказів у Zether використовується схема шифрування . Працює вона в такий спосіб. Коли Аліса хоче надіслати Бобу b монет за адресою (його публічним ключем) Y, вона вибирає випадкове число r і шифрує суму:
де C - Зашифрована сума, D - Допоміжне значення, необхідне для розшифрування цієї суми, G - Фіксована точка на еліптичній кривій, при множенні секретного ключа на яку виходить публічний ключ.
Коли Боб отримує ці значення, він просто додає їх до свого зашифрованого таким же способом балансу, як і зручна ця схема.
Аналогічним чином Аліса віднімає зі свого балансу такі ж значення, тільки як Y використовує свій публічний ключ.
Приховування адресата та відправника
Замішування «виходів» в UTXO з'явилося ще на зорі криптовалют і допомагає приховати відправника. Для цього сам відправник при здійсненні перекладу набирає випадкових «виходів» у блокчейні та замішує їх зі своїми. Далі підписує «виходи» кільцевим підписом — криптографічним механізмом, що дозволяє переконати того, що перевіряє, що серед замішаних «виходів» присутні монети відправника. Самі замішані монети, зрозуміло, не витрачаються.
Однак для приховування одержувача нам не вдасться генерувати фальшиві виходи. Тому в UTXO у кожного «виходу» своя унікальна адреса, і вона криптографічно пов'язана з адресою одержувача цих монет. На даний момент немає способу виявити зв'язок між унікальною адресою «виходу» та адресою одержувача, не знаючи його секретних ключів.
У account-based моделі ми не можемо використовувати одноразові адреси (інакше це буде модель «виходів»). Тому одержувача та відправника доводиться замішувати серед інших акаунтів у блокчейні. При цьому з акаунтів, що замішуються, списується зашифрований 0 монет (або додається 0 — у разі замішування одержувача), фактично не змінюючи їх реальний баланс.
Так як і відправник, і одержувач завжди мають постійну адресу, тут виникає необхідність при перекладах на ті самі адреси використовувати для замішування ті самі групи. Простіше розглянути це на прикладі.
Припустимо, Аліса вирішила зробити внесок у благодійний фонд Боба, але вважає за краще, щоб цей переклад залишався анонімним для стороннього спостерігача. Тоді, щоб замаскувати себе у полі відправника, вона вписує ще акаунти Адама та Адель. А щоб приховати Боба — у полі отримувача додатково акаунти Бена та Білла. Роблячи наступний внесок, Аліса вирішила поряд із собою вписати Алекса та Аманду, а поряд із Бобом – Брюса та Бенджена. У цьому випадку при аналізі блокчейну в цих двох транзакціях знайдеться лише одна пара учасників, що перетинається, — Аліса і Боб, що деанонімізує ці транзакції.
Гонки транзакцій
Як ми вже згадували, для приховування свого балансу в account-based системах користувач шифрує свій баланс та суму переказу. При цьому він повинен довести, що залишок на його рахунку залишається невід'ємним. Проблема полягає в тому, що, формуючи транзакцію, користувач будує доказ щодо свого поточного стану рахунку. А що буде, якщо Боб відправить Алісі транзакцію, і її буде прийнято раніше, ніж відправлена Алісою? Тоді транзакція Аліси вважатиметься невалідною, оскільки доказ балансу було побудовано до прийняття транзакції Боба.
Перше рішення, яке приходить у такій ситуації, — заморожувати аккаунт до проведення транзакції. Але цей підхід не годиться, тому що, крім складності вирішення такого завдання в розподіленій системі, в анонімній схемі буде незрозуміло, чий обліковий запис блокувати.
Для вирішення цієї проблеми технологія поділяє вхідні та вихідні транзакції: витрачання коштів має негайний вплив на стан балансу, а надходження відкладений. І тому вводиться поняття «епохи» — групи блоків фіксованого розміру. Поточна «епоха» визначається розподілом висоти блоку розмір групи. Обробляючи транзакцію, мережа оновлює баланс відправника відразу, а кошти одержувача складає накопичувач. Накопичені кошти надходять у розпорядження одержувача платежу лише за настання нової «епохи».
В результаті користувач може надсилати транзакції незалежно від того, як часто йому надходять кошти (наскільки дозволяє його баланс, зрозуміло). Розмір епохи визначають виходячи з того, наскільки швидко поширюються блоки по мережі та як швидко транзакція потрапляє в блок.
Це рішення добре працює у разі конфіденційних перекладів, проте з анонімними транзакціями, як ми побачимо далі, воно створює серйозні проблеми.
Захист від replay-атак
У account-based блокчейнах кожна транзакція підписується приватним ключем відправника, що переконує перевіряючого, що транзакція була змінена і її створив власник цього ключа. Але що якщо зловмисник, який прослуховував канал передачі, перехопить це повідомлення і відправить таке саме друге? Перевіряючи звірить підпис транзакції і буде переконаний у її авторстві, і мережа спише таку суму з балансу відправника повторно.
Цю атаку називають replay-атакою. У UTXO-моделі такі атаки не актуальні, тому що зловмисник намагатиметься використати витрачені виходи, що саме по собі не є валідним і відкидається мережею.
Щоб подібного не сталося, в транзакцію вбудовують поле зі випадковими даними, яке називають nonce або просто сіль. При повторному відправленні транзакції з «сіллю» перевіряючий дивиться, чи цей nonce використовувався раніше і, якщо ні, вважає цю транзакцію валідною. Щоб не зберігати в блокчейні всю історію nonce-ів користувачів, зазвичай у першій транзакції його приймають рівним нулю, а далі збільшують на одиницю. Мережі залишається лише перевірити, що nonce нової транзакції відрізняється від минулої на одиницю.
В анонімній схемі перекладів постає проблема валідації nonce-ів транзакцій. Ми не можемо прив'язувати nonce явним способом до адреси відправника, тому що, очевидно, це деанонімізує переклад. Ми також не можемо додавати одиницю до nonce-ам всіх аккаунтів, що беруть участь, тому що це може конфліктувати з іншими перекладами, що знаходяться в обробці.
Автори Zether пропонують генерувати nonce криптографічно – залежно від «епохи». Наприклад:
Тут x - Секретний ключ відправника, а Gepoch - Додатковий генератор для епохи, що отримується хешуванням рядка виду 'Zether +'. Тепер проблема, здавалося б, вирішується — ми не розкриваємо nonce відправника і не втручаємося в nonce непричетних учасників. Але такий підхід накладає серйозне обмеження: один обліковий запис може відправити не більше однієї транзакції в «епоху». Ця проблема, на жаль, залишається невирішеною, і зараз робить анонімну версію Zether, на наш погляд, навряд чи придатною для використання.
Складність доказів із нульовим розголошенням
В UTXO відправник повинен довести мережі, що не витрачає негативну суму, інакше стає можливою генерація нових монет з повітря (чому це можливо, ми писали в одній із попередніх ). А також підписати «входи» кільцевим підписом, щоб довести, що серед монет, що замішуються, є кошти, що належать йому.
В анонімній версії account-based блокчейна вирази для доказу виходять набагато складнішими. Відправник доводить, що:
- Сума, що відправляється, позитивна;
- Баланс залишається невід'ємним;
- Відправник правильно зашифрував суми переказів (зокрема нульові);
- Залишок на балансі змінюється лише у відправника та одержувача;
- Відправник володіє секретним ключем від свого облікового запису і він дійсно присутній у списку відправників (серед замішаних);
- Nonce, що використовується у транзакції, складено правильно.
Для такого складного доказу автори використовують суміш. (один із авторів, до речі, брав участь у її створенні) та , яку називають Sigma-bullets. Формальний доказ такого твердження — досить складне завдання, і воно обмежує кількість охочих зайнятися реалізацією технології.
Що в підсумку?
На наш погляд, частина Zether, яка приносить конфіденційність в account-based блокчейни, цілком може використовуватися вже зараз. Але зараз анонімна версія технології накладає серйозні обмеження на її використання, а її складність — на реалізацію. Однак не варто скидати з рахунків, що автори випустили її лише кілька місяців тому, і, можливо, хтось інший знайде рішення для проблем, які є сьогодні. Адже саме так діється наука.
Джерело: habr.com