Voyager tek düğüm testinde ortalama 21,2 milyon TPS kaydetti; imza doğrulaması hariç tutuldu

Voyager, tek düğümde yapılan rastgele transfer testinde 5 saat boyunca ortalama 21,2 milyon TPS, en yüksek 21,6 milyon TPS kaydetti. İşlem imzası doğrulaması ölçüme dahil edilmedi.

Celestia Labs, 12'sinde yayımladığı teknik açıklamada test tasarımını ve işlem hacmi ölçüm koşullarını paylaştı. Şirket, Voyager'ı 29 Ekim'de AI ajanlarının ticareti için bir ödeme mimarisi olarak tanıttıktan sonra bu açıklamada uygulamanın durumunu ve performans ölçümünün kapsamını ayrıntılandırdı.

TokenPost'un Voyager'ın ortalama ve en yüksek işlem hacmi ile 5 saatlik test sonuçlarını aktardığı önceki haberin ardından gelen bu açıklama, ölçüm sürecine dahil edilen işleri ve kapsam dışında bırakılan özellikleri ele aldı. Test, yaklaşık 100 milyon hesap arasındaki rastgele transferleri kapsadı. Şirketin açıklamasına göre toplam işlem sayısı yaklaşık 400 milyardı.

Yük oluşturucu, işlemleri imzaları kontrol eden giriş katmanından geçirmeden doğrudan Voyager düğümüne gönderdi. İşlem verilerinde imzalar bulunuyordu ancak imzaları doğrulamak için geçen süre TPS ölçümüne dahil edilmedi.

Bu nedenle 21,2 milyon TPS, imza doğrulamasından ödemenin tamamlanmasına kadar tüm süreci ölçen bir değer değil. Bağımsız olarak tekrarlanan test sonuçları ve açık ağdaki gerçek kullanım işlem hacmi de doğrulanmadı.

Voyager, AI ajanlarının içerik, veri ve hizmetleri tek tek satın almasına yönelik ödemeleri hedefliyor. Ödeme kurallarını genel amaçlı bir sanal makinede çalıştırmak yerine sisteme yerleştiriyor; bakiye durumunu ise Merkle ağacı yerine düz bir tabloda saklayacak şekilde tasarlandı.

Benchmark, rastgele akıllı sözleşmelerin çalıştırılma performansını ölçmedi. Durum kökü de hesaplanmadı. Bu yüzden test sonuçları genel akıllı sözleşme kapasitesi veya açık ağ performansı olarak yorumlanamaz.

Voyager düğümündeki bakiyeleri güncelleyen durum geçiş fonksiyonu (STF) tek iş parçacığında çalışıyor. İşlem kayıtları, veritabanına yazma ve Celestia Fibre üzerinden veri yayımlama ise işlem hattının farklı aşamalarında ayrı işlem gruplarını işliyor.

İş sırası, LMAX Disruptor tabanlı döngüsel bir kuyrukla düzenleniyor. Kuyruk varsayılan olarak 4096 yuvadan oluşuyor. Her tüketici, işi dışarı aktarmadan önce en fazla 128 yuvayı gruplandırabiliyor.

Depolama aşamasının işlem hızı yürütme aşamasının gerisinde kalırsa kuyrukta biriken iş sayısı artıyor. Boş yuva kalmadığında önceki aşamalar yeni işlemleri daha yavaş işliyor. Şirket, test boyunca bellek kullanımının yaklaşık 48 GiB düzeyinde kaldığını bildirdi.

İşlem kayıt düzeneği ile Fibre veri yayımlama düzeneğinin her biri saniyede yaklaşık 4,8 GB işledi. Bu değer, imzaları içeren işlem verisinin kaydedilip yayımlanma hızını gösteriyor; imza doğrulama hızını değil.

Test, aynı işlem hacminde işlem durumunu gerçek zamanlı sorgulama özelliğini de kapsamadı. Durum kökü hesaplama ve sorgulamayı içeren ödeme akışının tamamındaki performans bu ölçümle belirlenmedi.

Şirket, hata kurtarma ve çoğaltma için gereken verileri sakladığını ancak yeniden başlatmanın ardından durumu geri yükleme ve durumu diğer düğümlere çoğaltma mantığının henüz uygulanmadığını açıkladı. Verileri saklamak ile yeniden başlatma sonrası kurtarma özelliğini uygulamak ayrı konular.

Testte kullanılan hesap durumu, tek bir cihazın belleğine sığabilecek ölçekteydi. Daha büyük durumları işleme mantığı tasarlanmış olsa da uygulaması tamamlanmadı.

Celestia Labs, temmuz ayında yayımladığı yazıda kısa süreli işlem hacmi testlerinin gerçek işletim kapasitesini değerlendirmek için yeterli olmadığını ve haftalar süren yük testlerine ihtiyaç duyulduğunu belirtmişti. Voyager benchmark'ı 5 saat sürdü.

Şirket, durum kökünü her blokta hesaplamak yerine daha seyrek hesaplamayı planladığını açıkladı. Yeniden başlatma sonrası kurtarma ve düğümler arası çoğaltma yollarını geliştirmek ve test etmek öncelikli işler arasında yer alıyor.