Anubis випустив proof-of-work на WebAssembly після року роботи

Антиботовий сервіс Anubis, який змушує відвідувачів розв'язувати невелику задачу перед доступом до сайту, незабаром видаватиме завдання іншого типу. За словами автора проєкту, на це пішов рік: сотні коммітів, п'ять поколінь pull request'ів, десятки тестів і переписування частини Anubis на Rust. Результат — перевірка proof-of-work на базі WebAssembly, яку адміністратори можуть вмикати у власних правилах і порогах.

Уперше вона з'явиться вимкненою за замовчуванням у версії Anubis v1.28.0. Вмикання за замовчуванням заплановане на v1.29.0 і залежатиме від відгуків тих, хто її використовує.

Задача, що вимагає пам'яті, а не лише процесора

Нова перевірка використовує argon2id — функцію, що потребує пам'яті (memory-hard), замість старого хешування, обмеженого процесором. Практичний сенс у вартості: масове розв'язування таких задач потребує не лише обчислень, а й пропускної здатності пам'яті, що здорожує підхід «перенести розв'язувач на CUDA», який пробують скрейпери. Адміністратор прив'язує задачу до конкретного правила, наприклад до порога «помірна підозра» зі складністю 6.

WebAssembly також дозволяє клієнту й серверу запускати один і той самий бінарний файл замість двох окремих реалізацій алгоритму: досі задача «fast» існувала двічі — на JavaScript і на Go. Автор порівнює це з чіпом блокування в Nintendo Entertainment System, де обидві сторони виконують ідентичну логіку. Код WebAssembly написано на Rust (no-std, wasm32-unknown-unknown), бо він дає малі та швидкі бінарники.

Деталі, що з'їли рік: баг LLVM і Chrome 75

Більшість затримки створили деталі. Anubis досі підтримує Chrome 75, адже багато смарттелевізорів і дешевих Android-телефонів не мають шляху оновлення. Передкомпільована стандартна бібліотека Rust використовує reference types, які старі збірки Chrome відкидають із помилкою «expected table index 0, found 128». Рішенням стало вирізання функцій WebAssembly через wasm-opt: база MVP плюс лише те, що розуміє Chrome 75.

Під час збирання детермінованого інструмента WebAssembly-до-JavaScript виявився й баг LLVM: компілятор обходив блоки обробки винятків у порядку машинних вказівників, тому кожна збірка відрізнялася приблизно на 29 байтів. Вимкнення рандомізації адресного простору зробило відхилення стабільним і підтвердило діагноз; баг виправили в upstream. Для тестування старих браузерів автор створив «chromesweep» — запускач багатьох версій Chrome, опублікований як бібліотека TecharoHQ/gubal.

Що ще не завершено

Існує запасний шлях: WebAssembly компілюється назад у JavaScript для браузерів, які вимикають WASM політикою, наприклад режиму Lockdown в iOS або Vanadium у GrapheneOS. Цей шлях повільний, і смуга прогресу для нього ще не працює. Оскільки розв'язувач на WebAssembly дуже швидкий, налаштування складності, ймовірно, доведеться переглянути; також у роботі класифікатор, що використовує репутацію IP і TLS-відпечаток, щоб давати телефонам більше поблажливості.