Anubis, bir yıllık çalışmanın ardından WebAssembly proof-of-work'ü yayınladı

Ziyaretçileri siteye ulaşmadan önce küçük bir bulmacayı çözmeye zorlayan anti-bot kapısı Anubis, artık farklı bir bulmaca türü dağıtmaya hazırlanıyor. Yazarının anlattığına göre bu değişiklik bir yıl sürdü: yüzlerce commit, beş nesil pull request, düzinelerce test ve Anubis'in bir bölümünün Rust ile yeniden yazılması. Sonuç, yöneticilerin kendi eşik ve bot kurallarında açabileceği WebAssembly tabanlı bir proof-of-work denetimi.

İlk kez Anubis v1.28.0 sürümünde, varsayılan olarak kapalı halde görünecek. Varsayılan olarak açılması v1.29.0 için planlandı ve sistemi çalıştıranların geri bildirimlerine bağlı olacak.

İşlemciyi değil belleği zorlayan bulmaca

Yeni denetim, eski CPU'ya bağlı hashleme yerine bellek odaklı (memory-hard) bir işlev olan argon2id kullanıyor. Pratik amaç maliyet: bu bulmacaları ölçekli biçimde çözmek, işlem gücünün yanında bellek bant genişliği de gerektirdiğinden, kazıyıcıların denediği "çözücüyü CUDA'ya taşıma" yolunu pahalılaştırıyor. Yönetici bulmacayı belirli bir kurala bağlıyor; örneğin 6 zorluk derecesiyle "orta şüphe" eşiğine.

WebAssembly ayrıca tek bir algoritmanın iki ayrı uygulaması yerine istemci ve sunucunun aynı ikili dosyayı çalıştırmasını sağlıyor; bugüne kadar "fast" bulmacası biri JavaScript, diğeri Go olmak üzere iki kez mevcuttu. Yazar bunu, iki tarafın da aynı mantığı yürüttüğü Nintendo Entertainment System'in kilit çipine benzetiyor. WebAssembly kodu Rust ile yazıldı (no-std, wasm32-unknown-unknown), çünkü küçük ve hızlı ikili dosyalar üretiyor.

Bir yılı yiyen ayrıntılar: LLVM hatası ve Chrome 75

Gecikmenin çoğu ayrıntılardan kaynaklandı. Anubis hâlâ Chrome 75'i destekliyor, çünkü pek çok akıllı televizyonun ve ucuz Android telefonun yükseltme yolu yok. Rust'ın önceden derlenmiş standart kütüphanesi reference types kullanıyor; eski Chrome sürümleri bunu "expected table index 0, found 128" hatasıyla reddediyor. Çözüm, wasm-opt ile özellikleri kırpmak oldu: MVP temeli artı Chrome 75'in anladığı kadarı.

Deterministik bir WebAssembly'den JavaScript'e aracı derlerken bir LLVM hatası da ortaya çıktı: derleyici istisna işleme bloklarını makine işaretçisi sırasına göre geziyordu, bu yüzden her derleme yaklaşık 29 bayt kayıyordu. Adres uzayı rastgeleleştirmesini kapatmak sapmayı tutarlı hale getirdi ve tanıyı doğruladı; hata üst kaynakta düzeltildi. Eski tarayıcıları test etmek için yazar, birçok Chrome sürümünü başlatan "chromesweep" aracını geliştirdi ve bunu TecharoHQ/gubal kütüphanesi olarak yayımladı.

Hâlâ tamamlanmayanlar

WebAssembly'i politika gereği kapatan tarayıcılar için bir kaçış yolu var: kod yeniden JavaScript'e derleniyor. iOS Lockdown modu ve GrapheneOS'un Vanadium'u bu gruba giriyor. Bu yol yavaş ve ilerleme çubuğu henüz bağlanmadı. WebAssembly çözücüsü çok hızlı olduğundan zorluk ayarlarının yeniden düzenlenmesi gerekebilir; telefonlara daha fazla tolerans tanımak için IP itibarı ve TLS parmak izi kullanan bir sınıflandırıcı üzerinde çalışılıyor.