Blockchain Performansını Ölçmek Neden Zor?

Performans ve ölçeklenebilirlik, hem Katman 1 projeleri (bağımsız blok zincirleri) hem de Katman 2 çözümleri (toplamalar ve zincir dışı kanallar gibi) ile ilgili olarak kripto alanında çok tartışılan zorluklardır. Ancak standartlaştırılmış ölçümlerimiz veya kıyaslamalarımız yok. Rakamlar çoğu zaman tutarsız ve eksik şekillerde raporlanıyor, bu da projelerin doğru şekilde karşılaştırılmasını zorlaştırıyor ve çoğu zaman uygulamada en önemli hususların anlaşılmasını zorlaştırıyor. 

Performansı ölçmek ve karşılaştırmak için daha incelikli ve kapsamlı bir yaklaşıma ihtiyacımız var; performansı birden çok bileşene ayıran ve farklı eksenlerdeki ödünleşimleri karşılaştıran bir yaklaşım. Bu yazıda temel terminolojiyi tanımlayacağım, zorlukları özetleyeceğim ve blockchain performansını değerlendirirken akılda tutulması gereken yönergeleri ve temel ilkeleri sunacağım. 

Ölçeklenebilirlik ve performans

Öncelikle, blockchain bağlamlarında sıklıkla yanlış kullanılan, standart bilgisayar bilimi anlamlarına sahip olan ölçeklenebilirlik ve performans olmak üzere iki terimi tanımlayalım. Performans bir sistemin ne olduğunu ölçer şu anda bunu başarabilecek kapasitede. Aşağıda tartışacağımız gibi, performans ölçümleri saniye başına işlemleri veya ortalama işlem onay süresini içerebilir. ölçeklenebilirlikdiğer taraftan ölçüm Bir sistemin kaynak ekleyerek performansı artırma yeteneği.

Bu ayrım önemlidir: Performansı artırmaya yönelik birçok yaklaşım, doğru şekilde tanımlandığında ölçeklenebilirliği hiçbir şekilde iyileştirmez. Basit bir örnek, Schnorr veya ECDSA imzalarının kabaca yarısı kadar olan BLS imzaları gibi daha verimli bir dijital imza şemasının kullanılmasıdır. Bitcoin ECDSA'dan BLS'ye geçerse blok başına işlem sayısı %20-30 artabilir ve bu da bir gecede performansı artırabilir. Ancak bunu yalnızca bir kez yapabiliriz; geçiş yapacak daha fazla alan tasarrufu sağlayan bir imza şeması yoktur (BLS imzaları daha fazla alan kazanmak için de toplanabilir, ancak bu başka bir defaya mahsus bir numaradır).

Blok zincirlerinde bir dizi başka tek seferlik hileler (SegWit gibi) mümkündür, ancak daha fazla kaynak eklemenin zaman içinde performansı artırdığı sürekli performans iyileştirmesi elde etmek için ölçeklenebilir bir mimariye ihtiyacınız vardır. Bu, bir web sunucusu oluşturmak gibi diğer birçok bilgisayar sisteminde de geleneksel düşüncedir. Birkaç genel püf noktasıyla çok hızlı bir sunucu oluşturabilirsiniz; ancak sonuçta, sürekli olarak ekstra sunucular ekleyerek sürekli artan talebi karşılayabilecek çok sunuculu bir mimariye ihtiyacınız var.

Bu ayrımı anlamak aynı zamanda "Blockchain X oldukça ölçeklenebilir, saniyede Y işlemi gerçekleştirebilir!" gibi ifadelerde bulunan yaygın kategori hatasını önlemeye de yardımcı olur. İkinci iddia etkileyici olabilir, ancak bu bir performans bir ölçeklenebilirlik metriği değil, metriktir. Kaynak ekleyerek performansı artırma yeteneğinden söz etmiyor.

Ölçeklenebilirlik doğası gereği paralellikten yararlanmayı gerektirir. Blockchain alanında, Katman 1 ölçeklendirmenin parçalamayı veya parçalamaya benzeyen bir şeyi gerektirdiği görülüyor. Parçalamanın temel kavramı (farklı doğrulayıcıların bağımsız olarak işleyebilmesi için durumu parçalara bölmek) ölçeklenebilirlik tanımıyla yakından eşleşir. Katman 2'de zincir dışı kanallar, toplama sunucuları ve yan zincirler dahil olmak üzere paralel işleme eklenmesine olanak tanıyan daha da fazla seçenek vardır.

Gecikme ve aktarım hızı karşılaştırması

Klasik olarak blockchain sistemi performansı, gecikme ve verim olmak üzere iki boyutta değerlendirilir: Gecikme, bireysel bir işlemin ne kadar hızlı onaylanabileceğini ölçerken verim, zaman içindeki toplam işlem oranını ölçer. Bu eksenler hem Katman 1 hem de Katman 2 sistemlerine ve ayrıca diğer birçok bilgisayar sistemine (veritabanı sorgu motorları ve web sunucuları gibi) uygulanır.

Ne yazık ki hem gecikmenin hem de verimin ölçülmesi ve karşılaştırılması karmaşıktır. Ayrıca, bireysel kullanıcılar aslında verimi (sistem çapında bir ölçü olan) umursamazlar. Gerçekten umursadıkları şey, gecikme ve işlem ücretleri; daha spesifik olarak, işlemlerinin mümkün olduğunca hızlı ve ucuz bir şekilde onaylanmasıdır. Diğer birçok bilgisayar sistemi de maliyet/performans esasına göre değerlendirilse de, işlem ücretleri, geleneksel bilgisayar sistemlerinde gerçekte mevcut olmayan, blockchain sistemleri için biraz yeni bir performans eksenidir.

Gecikmeyi ölçmedeki zorluklar

Gecikme ilk başta basit görünüyor: Bir işlemin onaylanması ne kadar sürer? Ancak bu soruyu cevaplamanın her zaman birkaç farklı yolu vardır.

İlk olarak, farklı zaman noktaları arasındaki gecikmeyi ölçebilir ve farklı sonuçlar elde edebiliriz. Örneğin, kullanıcı yerel olarak "gönder" düğmesine bastığında mı yoksa işlem bellek havuzuna ulaştığında mı gecikmeyi ölçmeye başlıyoruz? Ve işlem önerilen bir blokta olduğunda veya bir blok bir veya altı takip bloğuyla onaylandığında saati durduruyor muyuz?

En yaygın yaklaşım, bir müşterinin bir işlemi ilk yayınladığı andan itibaren bir işlemin makul bir şekilde "onaylandığı" zamana kadar (gerçek dünyadaki tüccarların bir ödemenin alındığını dikkate alması ve ürünü serbest bırakması anlamında) doğrulayıcıların bakış açısını alır. . Elbette farklı üye işyerleri farklı kabul kriterleri uygulayabilir, hatta tek bir üye iş yeri bile işlem tutarına bağlı olarak farklı standartlar kullanabilir.

Doğrulayıcı merkezli yaklaşım pratikte önemli olan birçok şeyi gözden kaçırıyor. Birincisi, eşler arası ağdaki gecikmeyi (istemcinin bir işlemi yayınlamasından çoğu düğümün bunu duymasına kadar geçen süre ne kadar sürer?) ve istemci tarafındaki gecikmeyi (bir işlemin hazırlanması ne kadar sürer) göz ardı eder. müşterinin yerel makinesinde mi?). İstemci tarafındaki gecikme, Ethereum ödemesini imzalamak gibi basit işlemler için çok küçük ve öngörülebilir olabilir, ancak korumalı bir Zcash işleminin doğru olduğunu kanıtlamak gibi daha karmaşık durumlar için önemli olabilir.

Ölçmeye çalıştığımız zaman penceresini gecikmeyle standartlaştırsak bile cevap neredeyse her zaman değişir. Şimdiye kadar oluşturulmuş hiçbir kripto para sistemi sabit işlem gecikmesi sunmadı. Hatırlanması gereken temel bir kural şudur:

Gecikme, tek bir sayı değil, bir dağılımdır.

Ağ oluşturma araştırma topluluğu bunu uzun zamandır anlamıştır (örneğin bkz. Gil Tene'den mükemmel konuşma). İşlemlerin %0.1'inde (veya web sunucusu sorgularında) bile oldukça yüksek bir gecikme süresi ciddi şekilde etkileneceğinden, dağıtımın "uzun kuyruğuna" özel bir önem verilmektedir. darbe son kullanıcılar.

Blockchain'lerde onay gecikmesi çeşitli nedenlerden dolayı değişiklik gösterebilir:

Gruplama: çoğu sistem işlemlerini bir şekilde toplu olarak gerçekleştirir; örneğin çoğu Katman 1 sistemindeki bloklar halinde. Bu, değişken gecikmelere yol açar çünkü bazı işlemlerin toplu dolana kadar beklemesi gerekecektir. Diğerleri şanslı olabilir ve gruba en son katılabilir. Bu işlemler hemen onaylanır ve herhangi bir ek gecikme yaşanmaz.

Değişken tıkanıklık: çoğu sistem tıkanıklıktan muzdariptir, bu da sistemin hemen idare edebileceğinden daha fazla işlemin (en azından bazı zamanlarda) kaydedildiği anlamına gelir. İşlemler öngörülemeyen zamanlarda yayınlandığında (genellikle bir özet olarak soyutlanır) yoğunluk ne kadar değişebilir? Poisson süreci) veya yeni işlemlerin oranı gün veya hafta boyunca değiştiğinde veya popüler bir NFT lansmanı gibi harici olaylara yanıt olarak.

Konsensüs katmanı varyansı: Katman 1'de bir işlemin onaylanması genellikle bir blok üzerinde fikir birliğine varmak için dağıtılmış bir düğüm kümesi gerektirir; bu da tıkanıklıktan bağımsız olarak değişken gecikmeler ekleyebilir. İş kanıtı sistemleri, blokları öngörülemeyen zamanlarda bulur (aynı zamanda soyut olarak bir Poisson süreci). Hisse kanıtı sistemleri aynı zamanda çeşitli gecikmeler de ekleyebilir (örneğin, bir turda bir komite oluşturmak için yeterli sayıda düğüm çevrimiçi değilse veya bir liderin çökmesine yanıt olarak görüş değişikliği gerekiyorsa).

Bu nedenlerden dolayı iyi bir kılavuz:

Gecikmeyle ilgili iddialar, ortalama veya medyan gibi tek bir sayı yerine, onay sürelerinin bir dağılımını (veya histogramını) sunmalıdır.

Ortalama, medyan veya yüzdelikler gibi özet istatistikler kısmi bir tablo sunarken, bir sistemi doğru bir şekilde değerlendirmek, dağılımın tamamının dikkate alınmasını gerektirir. Bazı uygulamalarda, ortalama gecikme, gecikme dağılımının nispeten basit olması durumunda (örneğin, Gaussian) iyi bir fikir sağlayabilir. Ancak kripto para biriminde durum neredeyse hiçbir zaman bu şekilde olmaz: Tipik olarak yavaş onay sürelerinden oluşan uzun bir kuyruk vardır.

Ödeme kanalı ağları (örn. Lightning Network) buna iyi bir örnektir. Klasik bir L2 ölçeklendirme çözümü olan bu ağlar çoğu zaman çok hızlı ödeme onayları sunar, ancak bazen gecikmeyi büyük ölçüde artırabilecek bir kanal sıfırlaması gerektirirler.

Kesin gecikme dağılımına ilişkin iyi istatistiklere sahip olsak bile, sistem ve sistemden talep değiştikçe bu istatistikler de zaman içinde muhtemelen değişecektir. Ayrıca rakip sistemler arasındaki gecikme dağılımlarının nasıl karşılaştırılacağı da her zaman açık değildir. Örneğin, işlemleri 1 ila 2 dakika arasında eşit olarak dağıtılmış gecikmeyle (ortalama ve medyan 90 saniye) onaylayan bir sistemi düşünün. Rakip bir sistem işlemlerin %95'ini tam olarak 1 dakikada, geri kalan %5'ini ise 11 dakikada (ortalama 90 saniye ve ortanca 60 saniye) onaylıyorsa hangi sistem daha iyidir? Cevap muhtemelen bazı uygulamaların ilkini, bazılarının da ikincisini tercih edeceğidir.

Son olarak, çoğu sistemde tüm işlemlere eşit öncelik verilmediğini unutmamak önemlidir. Kullanıcılar daha yüksek bir katılım önceliği elde etmek için daha fazla ödeme yapabilir; bu nedenle, yukarıdakilerin tümüne ek olarak gecikme, ödenen işlem ücretlerinin bir fonksiyonu olarak değişir. Özetle:

Gecikme karmaşıktır. Ne kadar çok veri rapor edilirse o kadar iyidir. İdeal olarak, tam gecikme dağılımları değişen tıkanıklık koşulları altında ölçülmelidir. Gecikmenin farklı bileşenlere (yerel, ağ, toplu işlem, fikir birliği gecikmesi) göre dağılımı da faydalıdır.

Verimin ölçülmesindeki zorluklar

Verim de ilk bakışta basit görünüyor: Bir sistem saniyede kaç işlemi işleyebilir? İki temel zorluk ortaya çıkıyor: "İşlem" tam olarak nedir ve bir sistemin bugün ne yaptığını veya neler yapabileceğini mi ölçüyoruz?

"Saniye başına işlem sayısı" (veya tps), blockchain performansını ölçmek için fiili bir standart olsa da, işlemler bir ölçüm birimi olarak sorunludur. Genel amaçlı programlanabilirlik (“akıllı sözleşmeler”) ve hatta Bitcoin'in çoklu işlemleri veya çoklu imza doğrulama seçenekleri gibi sınırlı özellikler sunan sistemler için temel sorun şudur:

Tüm işlemler eşit değildir.

Bu, işlemlerin keyfi kod içerebildiği ve durumu keyfi olarak değiştirebildiği Ethereum için açıkça doğrudur. Ethereum'daki gaz kavramı, bir işlemin yaptığı genel iş miktarını ölçmek (ve ücretlendirmek) için kullanılır, ancak bu, EVM yürütme ortamına oldukça özeldir. Bir dizi EVM işlemi tarafından yapılan toplam iş miktarını, örneğin BPF ortamını kullanan bir dizi Solana işlemiyle karşılaştırmanın basit bir yolu yoktur. Her ikisini de bir dizi Bitcoin işlemiyle karşılaştırmak da benzer şekilde endişe vericidir.

İşlem katmanını konsensüs katmanına ve yürütme katmanına ayıran blok zincirleri bunu daha net hale getirebilir. (Saf) fikir birliği katmanında verim, birim zaman başına zincire eklenen bayt cinsinden ölçülebilir. Yürütme katmanı her zaman daha karmaşık olacaktır.

Yalnızca ödeme işlemlerini destekleyen toplama sunucuları gibi daha basit yürütme katmanları, hesaplamanın ölçülmesindeki zorluğu ortadan kaldırır. Ancak bu durumda bile ödemeler girdi ve çıktı sayısına göre değişiklik gösterebilir. Ödeme kanalı işlemler, verimi etkileyen gerekli "atlama" sayısına göre değişebilir. Ve toplama sunucusu verimi, bir grup işlemin daha küçük bir özet değişiklik kümesine ne kadar "netleştirilebileceğine" bağlı olabilir.

Verimle ilgili bir diğer zorluk ise teorik kapasiteyi değerlendirmek için günümüz performansını ampirik olarak ölçmenin ötesine geçmektir. Bu, potansiyel kapasiteyi değerlendirmek için her türlü modelleme sorusunu ortaya çıkarır. Öncelikle yürütme katmanı için gerçekçi bir işlem iş yüküne karar vermeliyiz. İkincisi, gerçek sistemler, özellikle de blockchain sistemleri neredeyse hiçbir zaman teorik kapasiteye ulaşamaz. Sağlamlık nedenleriyle, düğüm uygulamalarının uygulamada heterojen ve çeşitli olmasını umuyoruz (tüm istemcilerin tek bir yazılım uygulamasını çalıştırması yerine). Bu, blockchain çıktısının doğru simülasyonlarının yürütülmesini daha da zorlaştırıyor. 

Genel:

Verim talepleri, işlem iş yükünün ve doğrulayıcı popülasyonunun (miktarları, uygulamaları ve ağ bağlantıları) dikkatli bir şekilde açıklanmasını gerektirir. Açık bir standardın yokluğunda, Ethereum gibi popüler bir ağın geçmiş iş yükleri yeterli olacaktır.

Gecikme-iş hacmi değişimleri

Gecikme ve aktarım hızı genellikle bir dengedir. Gibi Lefteris Kokoris-Kogias'ın ana hatları, sistem yükü maksimum aktarım hızına yaklaştıkça gecikmenin keskin bir şekilde arttığı bir dönüm noktası nedeniyle bu değiş tokuş genellikle düzgün değildir.

Sıfır bilgi toplama sistemleri, verim/gecikme değişiminin doğal bir örneğini sunar. Büyük işlem grupları, kanıtlama süresini artırarak gecikmeyi artırır. Ancak hem kanıt boyutu hem de doğrulama maliyeti açısından zincir üzerindeki ayak izi, daha büyük parti boyutlarına sahip daha fazla işlem üzerinden amortismana tabi tutulacak ve bu da verimi artıracaktır.

İşlem ücretlerimiz

Anlaşılır bir şekilde, son kullanıcılar gecikme ve gecikme arasındaki dengeyi daha fazla önemsiyor. harçgecikme ve aktarım hızı değil. Kullanıcıların işlem hacmini önemsemek için doğrudan bir nedenleri yoktur; yalnızca mümkün olan en düşük ücretler karşılığında işlemleri hızlı bir şekilde onaylayabilmeleri gerekir (bazı kullanıcılar ücretlere daha fazla önem verirken diğerleri gecikmeye daha fazla önem verir). Yüksek düzeyde ücretler birden fazla faktörden etkilenir:

1. İşlem yapmak için ne kadar pazar talebi var?
2. Sistem tarafından ne kadar genel verim elde ediliyor?
3. Sistem doğrulayıcılara veya madencilere genel olarak ne kadar gelir sağlıyor?
4. Bu gelirin ne kadarı işlem ücretlerinden ve enflasyon ödüllerinden oluşuyor?

İlk iki faktör kabaca piyasayı temizleyen bir fiyata yol açan arz/talep eğrileridir (her ne kadar iddia edilmiş olsa da). madenciler ücretleri bu noktanın üzerine çıkarmak için kartel görevi görüyor). Diğer her şey eşit olduğunda, daha fazla verim daha düşük ücretlere yol açacaktır, ancak çok daha fazlası oluyor.

Özellikle yukarıdaki 3. ve 4. maddeler blockchain sistem tasarımının temel sorularıdır, ancak her ikisi için de iyi ilkelere sahip değiliz. Madencilere enflasyon ödüllerinden ve işlem ücretlerinden elde edilen geliri vermenin avantaj ve dezavantajları konusunda bazı anlayışlara sahibiz. Bununla birlikte, blockchain konsensüs protokollerinin birçok ekonomik analizine rağmen, doğrulayıcılara ne kadar gelir gitmesi gerektiğine dair hala geniş çapta kabul görmüş bir modelimiz yok. Bugün çoğu sistem, doğrulayıcıların sistemin pratik kullanımını engellemeden dürüst davranmasını sağlamak için ne kadar gelirin yeterli olduğuna dair bilinçli bir tahmin üzerine kuruludur. Basitleştirilmiş modellerde, %51'lik bir saldırı kurmanın maliyetinin doğrulayıcılara verilecek ödüllerle birlikte arttığı gösterilebilir.

Saldırıların maliyetini artırmak iyi bir şey ancak güvenliğin ne kadar "yeterli" olduğunu da bilmiyoruz. İki eğlence parkına gitmeyi düşündüğünüzü hayal edin. Bunlardan biri sürüş bakımına diğerine göre %50 daha az harcadığını iddia ediyor. Bu parka gitmek iyi bir fikir mi? Daha verimli olmaları ve daha az parayla eşdeğer güvenlik elde etmeleri olabilir. Belki de diğeri, sürüşleri hiçbir fayda sağlamadan güvende tutmak için gerekenden fazlasını harcıyordur. Ancak ilk parkın tehlikeli olması da söz konusu olabilir. Blockchain sistemleri benzerdir. Verimi hesaba kattığınızda, daha düşük ücretli blockchainlerin ücretleri daha düşük oluyor çünkü doğrulayıcılarını daha az ödüllendiriyorlar (ve dolayısıyla teşvik ediyorlar). Bugün bunun uygun olup olmadığını veya sistemi saldırılara karşı savunmasız bırakıp bırakmadığını değerlendirecek iyi araçlarımız yok. Etraflı:

Sistemler arasında ücretleri karşılaştırmak yanıltıcı olabilir. İşlem ücretleri kullanıcılar için önemli olsa da sistem tasarımının yanı sıra birçok faktörden de etkilenmektedir. Verim, bir sistemi bir bütün olarak analiz etmek için daha iyi bir ölçümdür.

Sonuç

Performansı adil ve doğru bir şekilde değerlendirmek zordur. Bu, bir arabanın performansını ölçmek için de aynı derecede geçerlidir. Tıpkı blockchainlerde olduğu gibi, farklı insanlar farklı şeyleri önemseyecektir. Arabalarda, bazı kullanıcılar en yüksek hıza veya hızlanmaya, bazıları yakıt tüketimine ve bazıları da çekme kapasitesine önem verecektir. Bunların hepsinin değerlendirilmesi önemsiz değildir. Örneğin ABD'de Çevre Koruma Ajansı, gaz tüketiminin nasıl değerlendirildiği ve bunun bir bayide kullanıcılara nasıl sunulması gerektiği konusunda ayrıntılı yönergeler bulundurmaktadır.

Blockchain alanı bu standardizasyon seviyesinden çok uzakta. Belirli alanlarda, gelecekte bir sistemin verimini değerlendirmek için standartlaştırılmış iş yükleriyle veya gecikme dağılımlarını sunmak için standartlaştırılmış grafiklerle bu hedefe ulaşabiliriz. Şimdilik, değerlendiriciler ve geliştiriciler için en iyi yaklaşım, değerlendirme metodolojisinin ayrıntılı bir açıklamasıyla birlikte mümkün olduğunca fazla veri toplamak ve yayınlamaktır, böylece yeniden üretilebilir ve diğer sistemlerle karşılaştırılabilir.