Teknik olmayan bir kişinin herhangi bir dağıtılmış sistem hakkında en sevdiği soru şudur: "Blockchain'inizde kaç tps var?" Ancak yanıt olarak verilen sayının, soruyu soran kişinin duymak istediği sayıyla genellikle çok az ortak noktası vardır. Aslında, "Blockchain'iniz iş gereksinimlerime uyacak mı?" diye sormak istedi ve bu gereksinimler tek bir sayı değil birçok koşuldan oluşuyor; burada ağ hata toleransı, kesinlik gereksinimleri, boyutlar, işlemlerin doğası ve diğer birçok parametre yer alıyor. Dolayısıyla “kaç tps” sorusunun cevabının basit olması pek olası değildir ve neredeyse hiçbir zaman tamamlanmayacaktır. Oldukça karmaşık hesaplamalar yapan onlarca veya yüzlerce düğümden oluşan dağıtılmış bir sistem, ağın durumu, blockchain içeriği, teknik arızalar, ekonomik sorunlar, ağa yapılan saldırılar ve diğer birçok nedene bağlı olarak çok sayıda farklı durumda olabilir. . Performans sorunlarının olası olduğu aşamalar geleneksel hizmetlerden farklıdır ve bir blockchain ağ sunucusu, bir veritabanının, web sunucusunun ve torrent istemcisinin işlevselliğini birleştiren bir ağ hizmetidir, bu da onu tüm alt sistemlerdeki yük profili açısından son derece karmaşık hale getirir. : işlemci, bellek, ağ, depolama

Merkezi olmayan ağlar ve blok zincirleri, merkezi yazılım geliştiricileri için oldukça spesifik ve sıra dışı yazılımlardır. Bu nedenle, merkezi olmayan ağların performansının ve sürdürülebilirliğinin önemli yönlerini, bunları ölçme ve darboğazları bulma yaklaşımlarını vurgulamak istiyorum. Blockchain kullanıcılarına hizmet sağlama hızını sınırlayan çeşitli performans sorunlarına bakacağız ve bu tür yazılımların karakteristik özelliklerini not edeceğiz.

Bir blockchain istemcisinin hizmet talebinin aşamaları

Az ya da çok karmaşık bir hizmetin kalitesi hakkında dürüstçe konuşmak için, yalnızca ortalama değerleri değil, aynı zamanda maksimum/minimum, medyanları ve yüzdelik dilimleri de dikkate almanız gerekir. Teorik olarak bazı blockchainlerde 1000 tps'den bahsedebiliriz, ancak 900 işlem muazzam bir hızla tamamlandıysa ve 100'ü birkaç saniyeliğine "takılıp kaldıysa", o zaman tüm işlemler üzerinden toplanan ortalama süre bir müşteri için tamamen adil bir ölçüm değildir. işlemini birkaç saniye içinde tamamlayamadığım kişi. Kaçırılan fikir birliği turlarının veya ağ bölünmelerinin neden olduğu geçici "boşluklar", test tezgahlarında mükemmel performans sergileyen bir hizmeti büyük ölçüde mahvedebilir.

Bu tür darboğazları tespit etmek için gerçek bir blockchain'in kullanıcılara hizmet etmekte zorluk çekebileceği aşamaları iyi anlamak gerekir. Bir işlemin teslim edilmesi ve işlenmesi döngüsünün yanı sıra, müşterinin işleminin işlendiğini ve muhasebeleştirildiğini doğrulayabileceği yeni bir blok zinciri durumu elde etme döngüsünü açıklayalım.

işlem müşteri üzerinde oluşturulur
işlem istemcide imzalanır
müşteri düğümlerden birini seçer ve işlemini ona gönderir
istemci, işlemin sonuçlarının görünmesini bekleyerek düğümün durum veritabanındaki güncellemelere abone olur
düğüm, işlemi p2p ağı üzerinden dağıtır
birkaç veya bir BP (blok üreticisi) birikmiş işlemleri işleyerek durum veritabanını günceller
BP gerekli sayıda işlemi işledikten sonra yeni bir blok oluşturur
BP p2p ağı üzerinden yeni bir blok dağıtıyor
yeni blok istemcinin eriştiği düğüme teslim edilir
düğüm durum veritabanını günceller
düğüm müşteriye ilişkin güncellemeyi görür ve ona bir işlem bildirimi gönderir

Şimdi bu aşamalara daha yakından bakalım ve her aşamadaki olası performans sorunlarını açıklayalım. Merkezi sistemlerden farklı olarak ağ istemcileri üzerinde kod yürütmeyi de ele alacağız. Çoğu zaman, TPS ölçülürken, işlem işlem süresi müşteriden değil düğümlerden toplanır - bu tamamen adil değildir. Müşteri, düğümün işlemini ne kadar hızlı işlediğini umursamaz; onun için en önemli şey, blok zincirinde yer alan bu işlemle ilgili güvenilir bilginin kendisine ulaştığı andır. Esasen işlem yürütme süresi olan bu ölçümdür. Bu, farklı istemcilerin, aynı işlemi gönderseler bile, kanala, düğümün yüküne ve yakınlığına vb. bağlı olarak tamamen farklı zamanlar alabileceği anlamına gelir. Bu nedenle, optimize edilmesi gereken parametre bu olduğundan, istemciler üzerinde bu süreyi ölçmek kesinlikle gereklidir.

İstemci tarafında bir işlemin hazırlanması

İlk iki noktayla başlayalım: İşlem müşteri tarafından oluşturulur ve imzalanır. Tuhaf bir şekilde, bu aynı zamanda müşterinin bakış açısından blockchain performansında bir darboğaz da olabilir. Bu, tüm hesaplamaları ve işlemleri verilerle üstlenen merkezi hizmetler için alışılmadık bir durumdur ve müşteri, büyük miktarda veri veya hesaplama isteyebilecek kısa bir istek hazırlayarak hazır bir sonuç elde eder. Blok zincirlerde müşteri kodu giderek daha güçlü hale gelir, blok zinciri çekirdeği giderek daha hafif hale gelir ve büyük bilgi işlem görevleri genellikle istemci yazılımına aktarılır. Blockchainlerde, bir işlemi oldukça uzun süre hazırlayabilen istemciler vardır (çeşitli merkle kanıtlarından, kısa ve öz kanıtlardan, eşik imzalarından ve istemci tarafındaki diğer karmaşık işlemlerden bahsediyorum). Zincir üzerinde kolay doğrulamaya ve müşteri üzerinde bir işlemin yoğun bir şekilde hazırlanmasına iyi bir örnek, burada Merkle ağacına dayalı bir listeye üyeliğin kanıtıdır. makale.

Ayrıca, müşteri kodunun yalnızca işlemleri blok zincirine göndermediğini, ilk önce blok zincirinin durumunu sorguladığını ve bu etkinliğin ağ ve blok zinciri düğümlerindeki tıkanıklığı etkileyebileceğini unutmayın. Bu nedenle, ölçüm alırken müşteri kodunun davranışını mümkün olduğunca tam olarak taklit etmek mantıklı olacaktır. Blok zincirinizde, bazı varlıkları aktarmak için en basit işleme düzenli bir dijital imza koyan sıradan hafif istemciler olsa bile, her yıl istemci üzerinde daha büyük hesaplamalar yapılıyor, kripto algoritmaları güçleniyor ve işlemin bu kısmı daha da güçleniyor. gelecekte önemli bir darboğaza dönüşecektir. Bu nedenle dikkatli olun ve 3.5 saniye süren bir işlemde, işlemi hazırlamak ve imzalamak için 2.5 saniye, ağa gönderip yanıt beklemek için 1.0 saniye harcandığı durumu kaçırmayın. Bu darboğazın risklerini değerlendirmek için yalnızca blockchain düğümlerinden değil, istemci makinelerden de ölçümler toplamanız gerekir.

Bir işlemin gönderilmesi ve durumunun izlenmesi

Bir sonraki adım, işlemi seçilen blockchain düğümüne göndermek ve işlem havuzuna kabul etme durumunu almaktır. Bu aşama, normal veri tabanı erişimine benzer; düğüm, işlemi havuza kaydetmeli ve p2p ağı aracılığıyla bu işlemle ilgili bilgileri dağıtmaya başlamalıdır. Buradaki performansı değerlendirme yaklaşımı, geleneksel Web API mikro hizmetlerinin performansını değerlendirmeye benzer ve blok zincirlerdeki işlemlerin kendisi güncellenebilir ve durumları aktif olarak değiştirilebilir. Genel olarak, bazı blok zincirlerindeki işlem bilgilerinin güncellenmesi, örneğin zincir çatalları arasında geçiş yaparken veya BP'ler bir işlemi bir bloğa dahil etme niyetini açıkladığında birden çok kez gerçekleşebilir. Bu havuzun boyutuna ve içindeki işlem sayısına ilişkin sınırlamalar, blok zincirinin performansını etkileyebilir. İşlem havuzu mümkün olan maksimum boyuta kadar doldurulursa veya RAM'e sığmazsa ağ performansı keskin bir şekilde düşebilir. Blockchain'lerin gereksiz mesaj seline karşı koruma sağlayacak merkezi bir yolu yoktur ve eğer blockchain yüksek hacimli işlemleri ve düşük ücretleri destekliyorsa, bu durum işlem havuzunun taşmasına neden olabilir; bu da başka bir potansiyel performans darboğazıdır.

Blok zincirlerde, müşteri istediği herhangi bir blok zinciri düğümüne bir işlem gönderir, işlemin karması genellikle müşteri tarafından göndermeden önce bilinir, dolayısıyla tek yapması gereken bağlantıyı sağlamak ve iletimden sonra blok zincirinin değişmesini beklemektir. durumu, işlemine olanak sağlıyor. "TPS"yi ölçerek, bir blockchain düğümüne bağlanmanın farklı yöntemleri için tamamen farklı sonuçlar alabileceğinizi unutmayın. Bu, normal bir HTTP RPC veya "abone olma" modelini uygulamanıza olanak tanıyan bir WebSocket olabilir. İkinci durumda, istemci daha erken bir bildirim alacaktır ve düğüm, işlem durumuyla ilgili yanıtlara daha az kaynak (çoğunlukla bellek ve trafik) harcayacaktır. Dolayısıyla "tps"yi ölçerken istemcilerin düğümlere bağlanma biçimini hesaba katmak gerekir. Bu nedenle, bu darboğazın risklerini değerlendirmek için, kıyaslama blok zincirinin, gerçek ağlara karşılık gelen oranlarda hem WebSocket hem de HTTP RPC istekleri olan istemcileri taklit edebilmesi ve işlemlerin doğasını ve boyutlarını değiştirebilmesi gerekir.

Bu darboğazın risklerini değerlendirmek için yalnızca blockchain düğümlerinden değil, istemci makinelerden de ölçümler toplamanız gerekir.

İşlemlerin ve blokların p2p ağı üzerinden iletilmesi

Blok zincirlerinde, katılımcılar arasında işlemleri ve blokları aktarmak için eşler arası (p2p) ağ kullanılır. İşlemler, düğümlerden birinden başlayarak, işlemleri bloklar halinde paketleyen ve aynı p2p'yi kullanarak yeni blokları tüm ağ düğümlerine dağıtan eş blok üreticilerine ulaşana kadar ağ boyunca yayılır. Çoğu modern p2p ağının temeli, Kademlia protokolünün çeşitli modifikasyonlarıdır. Burada Bu protokolün iyi bir özeti ve burada - BitTorrent ağında çeşitli ölçümler içeren bir makale; bu tür bir ağın, merkezi bir hizmetin katı bir şekilde yapılandırılmış ağından daha karmaşık ve daha az tahmin edilebilir olduğu anlaşılabilir. Ayrıca, burada Ethereum düğümleri için çeşitli ilginç ölçümlerin ölçülmesiyle ilgili makale.

Kısacası, bu tür ağlardaki her eş, diğer eşlerden oluşan kendi dinamik listesini tutar ve içerik tarafından adreslenen bilgi bloklarını talep eder. Bir eş bir istek aldığında ya gerekli bilgiyi verir ya da isteği listeden bir sonraki sözde rastgele eşe iletir ve bir yanıt aldıktan sonra bunu istek sahibine iletir ve bir süre önbelleğe alarak bu bilgiyi verir. bir dahaki sefere daha erken bilgi bloğu. Böylece, popüler bilgiler çok sayıda eşin çok sayıda önbelleğinde kalır ve popüler olmayan bilgiler yavaş yavaş değiştirilir. Akranlar, kimin kime ne kadar bilgi aktardığının kaydını tutar ve ağ, aktif dağıtıcıları, derecelendirmelerini artırarak ve onlara daha yüksek düzeyde hizmet sağlayarak teşvik etmeye çalışır ve aktif olmayan katılımcıları otomatik olarak benzer listelerden çıkarır.

Bu nedenle, blok üreticilerinin görebilmesi ve bloğa dahil edebilmesi için işlemin artık ağ geneline dağıtılması gerekiyor. Düğüm aktif olarak yeni bir işlemi herkese "dağıtır" ve ağı dinler, bekleyen istemciyi bilgilendirmek için gerekli işlemin indekste görüneceği bir bloğu bekler. P2p ağlarında ağın yeni işlemler ve bloklar hakkındaki bilgileri birbirine aktarması için geçen süre çok sayıda faktöre bağlıdır: yakınlarda çalışan dürüst düğümlerin sayısı (ağ açısından), "sıcaklık". Bu düğümlerin önbellekleri, blokların boyutu, işlemler, değişikliklerin niteliği, ağ coğrafyası, düğüm sayısı ve diğer birçok faktör. Bu tür ağlarda performans metriklerinin karmaşık ölçümleri karmaşık bir konudur; hem istemcilerde hem de eşlerde (blockchain düğümleri) istek işleme süresini aynı anda değerlendirmek gerekir. P2p mekanizmalarının herhangi birindeki sorunlar, yanlış veri çıkarma ve önbelleğe alma, aktif eşler listesinin etkisiz yönetimi ve diğer birçok faktör, bir bütün olarak ağın verimliliğini etkileyen gecikmelere neden olabilir ve bu darboğaz, analiz edilmesi en zor olanıdır. sonuçların test edilmesi ve yorumlanması.

Blockchain işleme ve durum veritabanı güncellemesi

Blockchain'in en önemli kısmı konsensüs algoritması, ağdan alınan yeni bloklara uygulanması ve sonuçların durum veritabanına kaydedilmesiyle işlemlerin işlenmesidir. Zincire yeni bir blok eklemek ve ardından ana zinciri seçmek mümkün olduğu kadar hızlı çalışmalıdır. Ancak gerçek hayatta "olmalı", "çalışır" anlamına gelmez ve örneğin, iki uzun rakip zincirin sürekli olarak kendi aralarında geçiş yaptığı ve her geçişte havuzdaki binlerce işlemin meta verilerini değiştirdiği bir durum hayal edilebilir. ve durum veritabanını sürekli olarak geri alma. Bu aşama, darboğazın tanımlanması açısından p2p ağ katmanından daha basittir çünkü işlem yürütme ve fikir birliği algoritması kesinlikle belirleyicidir ve burada herhangi bir şeyi ölçmek daha kolaydır.
Önemli olan, bu aşamanın performansındaki rastgele bozulmayı ağ sorunlarıyla karıştırmamaktır - düğümler ana zincir hakkında bloklar ve bilgi sağlamada daha yavaştır ve harici bir müşteri için bu yavaş bir ağ gibi görünebilir, ancak sorun tamamen farklı bir yer.

Bu aşamada performansı optimize etmek için, düğümlerin kendilerinden metrikler toplamak ve izlemek ve bunlara durum veritabanının güncellenmesiyle ilgili olanları dahil etmek faydalıdır: düğümde işlenen blokların sayısı, boyutları, işlem sayısı, zincir çatalları arasındaki geçişlerin sayısı, geçersiz blokların sayısı, sanal makinenin çalışma süresi, veri işleme süresi vb. Bu, ağ sorunlarının zincir işleme algoritmalarındaki hatalarla karıştırılmasını önleyecektir.

İşlemleri işleyen bir sanal makine, blok zincirinin çalışmasını optimize edebilecek yararlı bir bilgi kaynağı olabilir. Bellek tahsislerinin sayısı, okuma/yazma talimatlarının sayısı ve sözleşme kodunun yürütülmesinin verimliliğiyle ilgili diğer ölçümler, geliştiricilere birçok yararlı bilgi sağlayabilir. Akıllı sözleşmeler aynı zamanda programlardır; yani teoride herhangi bir kaynağı tüketebilirler: işlemci/bellek/ağ/depolama, dolayısıyla işlem işleme oldukça belirsiz bir aşamadır ve ayrıca sürümler arasında geçiş yaparken büyük ölçüde değişir. ve sözleşme kodlarını değiştirirken. Bu nedenle, blockchain performansını etkili bir şekilde optimize etmek için işlem işlemeyle ilgili ölçümlere de ihtiyaç vardır.

Müşteri tarafından bir işlemin blok zincirine dahil edilmesine ilişkin bir bildirimin alınması

Bu, blockchain istemcisinin hizmeti aldığı son aşamadır; diğer aşamalarla karşılaştırıldığında büyük bir genel gider maliyeti yoktur, ancak yine de müşterinin düğümden büyük bir yanıt alma olasılığını (örneğin akıllı sözleşme) dikkate almaya değer. bir dizi veri döndürmek). Zaten “blockchaininizde kaç tps var?” sorusunu soran kişi için en önemli nokta bu nokta çünkü. Bu anda hizmetin alındığı saat kaydedilir.

Burada her zaman müşterinin blok zincirinden bir yanıt beklemek için harcadığı tüm zamanın bir gönderimi vardır; bu sefer kullanıcı başvurusunda onay bekleyecektir ve asıl önemli olan onun optimizasyonudur. geliştiricilerin ana görevi.

Sonuç

Sonuç olarak blockchain üzerinde gerçekleştirilen işlem türlerini tanımlayabilir ve bunları birkaç kategoriye ayırabiliriz:

kriptografik dönüşümler, kanıt oluşturma
eşler arası ağ iletişimi, işlem ve blok çoğaltma
işlem işleme, akıllı sözleşmelerin yürütülmesi
Blok zincirindeki değişikliklerin durum veritabanına uygulanması, işlemlere ve bloklara ilişkin verilerin güncellenmesi
durum veritabanına, blockchain düğüm API'sine, abonelik hizmetlerine yönelik salt okunur istekler

Genel olarak, modern blockchain düğümlerinin teknik gereksinimleri son derece ciddidir: kriptografi için hızlı CPU'lar, durum veritabanına depolanacak ve hızlı bir şekilde erişilecek büyük miktarda RAM, çok sayıda eşzamanlı açık bağlantı kullanan ağ etkileşimi ve büyük depolama. Bu kadar yüksek gereksinimler ve farklı türdeki operasyonların çokluğu kaçınılmaz olarak düğümlerin yeterli kaynağa sahip olmayabileceği ve daha sonra yukarıda tartışılan aşamalardan herhangi birinin genel ağ performansı için başka bir darboğaz haline gelebileceği gerçeğine yol açmaktadır.

Blockchainlerin performansını tasarlarken ve değerlendirirken tüm bu noktaları dikkate almanız gerekecektir. Bunu yapmak için, istemcilerden ve ağ düğümlerinden eşzamanlı olarak ölçümler toplamanız ve analiz etmeniz, aralarındaki korelasyonları aramanız, müşterilere hizmet sunma süresini tahmin etmeniz, tüm ana kaynakları hesaba katmanız gerekir: işlemci/bellek/ağ/depolama , bunların nasıl kullanıldığını anlayın ve birbirlerini etkileyin. Tüm bunlar, çok sayıda farklı konfigürasyon ve durum olduğundan, farklı blok zincirlerinin hızlarını "kaç TPS" şeklinde karşılaştırmayı son derece nankör bir görev haline getiriyor. Büyük merkezi sistemlerde, yüzlerce sunucudan oluşan kümelerde bu sorunlar da karmaşıktır ve aynı zamanda çok sayıda farklı metriğin toplanmasını gerektirir, ancak blockchainlerde p2p ağları, sanal makine işleme sözleşmeleri, iç ekonomiler, derece sayısı nedeniyle özgürlük çok daha fazladır, bu da testi birkaç sunucuda bile yapar, gösterge niteliğinde değildir ve yalnızca gerçeklikle neredeyse hiçbir bağlantısı olmayan son derece yaklaşık değerleri gösterir.

Bu nedenle, blockchain çekirdeğinde geliştirme yaparken, performansı değerlendirmek ve "geçen zamana kıyasla gelişti mi?" sorusunu yanıtlamak için düzinelerce düğümle bir blockchain'in başlatılmasını düzenleyen ve otomatik olarak bir kıyaslama başlatıp ölçümleri toplayan oldukça karmaşık bir yazılım kullanıyoruz. Bu bilgi olmadan birden fazla katılımcıyla çalışan protokollerde hata ayıklamak son derece zordur.

Dolayısıyla, "Blockchain'inizde kaç TPS var?" sorusunu aldığınızda, muhatabınıza biraz çay ikram edin ve bir düzine grafiğe bakmaya hazır olup olmadığını sorun ve ayrıca blockchain performans sorunlarının üç kutusunun tamamını ve çözüm önerilerinizi dinleyin. bunları çözüyoruz...

Kaynak: habr.com

Blockchaininizde kaç TPS var?