Anubis-ը մեկ տարվա աշխատանքից հետո թողարկեց WebAssembly proof-of-work

Անտիբոտային Anubis համակարգը, որը այցելուից պահանջում է լուծել փոքր խնդիր կայք մուտք գործելուց առաջ, շուտով կսկսի տալ այլ տիպի խնդիր։ Ըստ հեղինակի՝ այդ փոփոխությունը տևել է մեկ տարի՝ հարյուրավոր commit-ներ, pull request-երի հինգ սերունդ, տասնյակ թեստեր և Anubis-ի մի մասի վերաշարադրում Rust-ով։ Արդյունքը WebAssembly-ի վրա հիմնված proof-of-work ստուգումն է, որը ադմինիստրատորները կարող են միացնել իրենց կանոններում ու շեմերում։

Այն առաջին անգամ կհայտնվի 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» սխալով։ Լուծումը wasm-opt-ով ֆունկցիաների կրճատումն էր՝ MVP հիմք գումարած այն, ինչ հասկանում է Chrome 75-ը։

Դետերմինիստական WebAssembly-ից JavaScript փոխարկիչ կառուցելիս հայտնաբերվեց նաև LLVM-ի սխալ. կոմպիլյատորը բացառությունների բլոկները շրջանցում էր մեքենայական հասցեների հերթականությամբ, ուստի յուրաքանչյուր կառուցում տարբերվում էր մոտ 29 բայթով։ ASLR-ի անջատումը շեղումը դարձրեց կայուն և հաստատեց ախտորոշումը. սխալը ուղղվեց upstream-ում։ Հին բրաուզերները ստուգելու համար հեղինակը կառուցեց «chromesweep» գործիքը, որը հրապարակվեց որպես TecharoHQ/gubal գրադարան։

Ինչ դեռ ավարտված չէ

Կա փախուստի ուղի. WebAssembly-ը կրկին կոմպիլյացվում է JavaScript-ի այն բրաուզերների համար, որոնք WASM-ը անջատում են քաղաքականությամբ՝ օրինակ iOS-ի Lockdown ռեժիմը կամ GrapheneOS-ի Vanadium-ը։ Այդ ուղին դանդաղ է, և առաջընթացի գիծը դեռ միացված չէ։ Քանի որ WebAssembly լուծիչը շատ արագ է, բարդության կարգավորումները կարող են վերանայման կարիք ունենալ. ընթացքի մեջ է նաև դասակարգիչ, որն օգտագործում է IP-հեղինակությունը և TLS fingerprint-ը՝ հեռախոսներին ավելի մեծ զիջում տալու համար։