ЄС цього разу справді взявся за регулювання криптовалют. Як тільки з’явився новий регламент щодо переказу коштів (TFR), "правила подорожі" стали невід’ємною темою для кожного постачальника віртуальних активів (VASP) — інформація про транзакції має бути передана у реальному часі, а особи обох сторін повинні бути ідентифіковані без помилок. Ці вимоги безпосередньо ставлять під удар проєкти приватних валют.

Візьмемо Dusk як приклад. Його концепція дуже хитра: щоденні транзакції повністю зашифровані, приватність користувачів не порушується; але регулятор має особливий ключ, за допомогою якого за судовим наказом можна відкрити "чорний ящик" і переглянути конкретні записи транзакцій. Ця схема "можливого аудиту пізніше" у минулому здавалася цілком прийнятною для боротьби з відмиванням грошей.

Проблема у нових вимогах TFR. Вони не передбачають лише постфактум перевірки, а вимагають звітувати у реальному часі. Коли відбувається кожна транзакція, частина інформації, що стосується VASP, має негайно передаватися іншій стороні без затримки. Це ставить під питання архітектуру системи Dusk: у мережі з увімкненою приватністю та шифруванням, як автоматично та миттєво визначити, чи є контрагент регульованим сервісом? Як гарантувати точність і безпомилковість переданої інформації?

Це майже неминуче вимагає впровадження якогось виду тегової системи або надійного оракула, що позначає учасників транзакцій. Як тільки починаєш це робити, обіцянка "повної приватності" Dusk починає похитуватися. Більш реалістична проблема у тому, що це вже не просто криптографічна задача, а складна задача з дотримання нормативів.

З точки зору регуляторів, вони, ймовірно, віддають перевагу системі, яка з самого початку має автоматизований процес звітування — на відміну від системи, що вимагає їхнього активного втручання для отримання ключів, ручного розшифрування та багаторазового перегляду "чорного ящика". Перший варіант більш прозорий, ефективний і легше інтегрується у існуючу регуляторну систему.

Ось реальність, з якою стикаються приватні валюти: від технічної концепції до реального застосування потрібно переступити через цю прірву. Не можна просто казати "я можу зробити так, щоб ви могли перевірити пізніше", потрібно довести, що "я можу безшовно адаптуватися до вашого реального регулювання". Це виклик не з легких і без простих відповідей.