Anubis-მა WebAssembly-ზე დაფუძნებული proof-of-work გამოუშვა

ანტიბოტური სისტემა Anubis, რომელიც ვიზიტორს გვერდზე შესვლამდე ამოცანის ამოხსნას სთხოვს, ახალი ტიპის შემოწმებაზე გადადის. პროექტის ავტორის თქმით, ამას ერთი წელი, ასობით კომიტი, ხუთი თაობის pull request-ები, ათეულობით ტესტი და Anubis-ის ნაწილის Rust-ზე გადაწერა დასჭირდა. შედეგია WebAssembly-ზე დაფუძნებული proof-of-work შემოწმება, რომლის ჩართვაც ადმინისტრატორებს საკუთარ წესებსა და ზღვრებში შეეძლებათ.

ფუნქცია პირველად Anubis v1.28.0-ში გამოჩნდება — ნაგულისხმევად გამორთული. v1.29.0-ში მისი ჩართვა ადმინისტრატორებისა და მომხმარებლების გამოხმაურებაზე იქნება დამოკიდებული.

მეხსიერებაზე მომთხოვნი ამოცანა

ახალი შემოწმება argon2id-ს იყენებს — მეხსიერებაზე დამოკიდებულ (memory-hard) ფუნქციას, ძველი, მხოლოდ პროცესორზე დამოკიდებული ჰეშირების ნაცვლად. პრაქტიკული აზრი ის არის, რომ მასობრივად ამოსახსნელად საჭიროა არა მხოლოდ გამოთვლითი სიმძლავრე, არამედ მეხსიერების გამტარობაც — ეს აძვირებს სქრეიპერების მიერ CUDA-ზე გადატანილ ამომხსნელებს. ადმინისტრატორი ახალ გამოწვევას კონკრეტულ წესზე მიაბამს, მაგალითად, „ზომიერი ეჭვის“ ზღვარზე difficulty 6-ით.

WebAssembly ასევე საშუალებას იძლევა, კლიენტმა და სერვერმა ერთი და იგივე ბინარული ფაილი გაუშვან ალგორითმის ორი დამოუკიდებელი იმპლემენტაციის ნაცვლად. აქამდე „fast“ გამოწვევა ორჯერ არსებობდა: JavaScript-ზე და Go-ზე. ავტორი შედარებას Nintendo-ს CIC ჩიპთან აკეთებს, სადაც ორივე მხარე ერთსა და იმავე ლოგიკას ასრულებს. 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-ს ესმის.

დეტერმინისტული WASM→JavaScript ხელსაწყოს აწყობისას კი LLVM-ის ბაგი გამოვლინდა: კომპილატორი გამონაკლისების ბლოკებს მანქანური მისამართის მიხედვით ამუშავებდა და ყოველი აწყობა დაახლოებით 29 ბაიტით განსხვავდებოდა. ASLR-ის გამორთვით ავტორმა დიაგნოზი დაადასტურა; ბაგი upstream-ში გამოსწორდა. ბრაუზერების შესამოწმებლად მან ააწყო „chromesweep“ — Chrome-ის მრავალი ვერსიის გამშვები, რომლის ბიბლიოთეკა TecharoHQ/gubal-ის სახელით გამოქვეყნდა.

რა დარჩა გასაკეთებელი

არსებობს escape hatch: WebAssembly ისევ JavaScript-ად კომპილირდება იმ ბრაუზერებისთვის, რომლებიც WASM-ს პოლიტიკით თიშავენ — მაგალითად, iOS-ის Lockdown რეჟიმი ან GrapheneOS-ის Vanadium. ეს გზა ნელია და პროგრესის ზოლი ჯერ არ მუშაობს. იმის გამო, რომ WASM-ის ამომხსნელი ძალიან სწრაფია, difficulty-ის ხელახლა დაყენება შეიძლება საჭირო გახდეს; იგეგმება მობილური მოწყობილობების კლასიფიკატორი IP-რეპუტაციისა და TLS fingerprint-ის გამოყენებით.