blog 1HaberlerGeliştiricilerEnterpriseBlockchain AçıklamasıEtkinlikler ve KonferanslarBasınBültenler

Haber bültenimize abone ol.

E

Senin gizliliğine saygı duyuyoruz

AnasayfaBlogKurumsal Blockchain

İşletmeler için Ölçeklendirme Konsensüsü: IBFT Algoritmasını Açıklamak

İstanbul Bizans Hata Toleransı (IBFT), özel Ethereum ağlarında kesinliği nasıl iyileştirir ve verimi artırır. Yazan: ConsenSys · Haziran 22, 2018 · Yayınlanan 22 Haziran 2018

Ethereum kahramanı ConsenSys


Konsensüs algoritmaları, blok zincirinin temel yeniliklerinden biridir ve aynı zamanda en kafa karıştırıcı olanlardan biridir. Satoshi Nakamoto, Bitcoin işlemlerini eşzamanlı olarak güvence altına almak ve doğrulamak için bir araç olarak uygulanan bir Proof of Work (PoW) sürümü yarattı. Blockchain topluluğu, Proof of Stake (PoS), Proof of Authority (PoA), PBFT (Practical Byzantine Fault Tolerant) ve hepsi dağıtılmış bir şekilde fikir birliği oluşturmak için tasarlanmış birçok başka bir alfabe çorbası oluşturmak için bu temel vizyon üzerine inşa etti. sistem, blockchain’i bu kadar değerli kılan tek doğruluk kaynağını yaratıyor.

IBFT (İstanbul Bizans Hata Toleranslı), Ethereum ağında Proof of Work’e alternatif olan bir fikir birliği mekanizmasıdır. Diğer algoritmalar gibi, IBFT de blok zincirindeki işlemler için üzerinde mutabık kalınan tek bir sipariş sağlar ve işletmeler için mutabakat kesinliği dahil olmak üzere ek faydalar sağlar. IBFT ilk olarak Geth’de Amis Technologies tarafından uygulanmıştır, ve Quorum’da uygulandıktan kısa bir süre sonra.

IBFT mutabakat mekanizmasının işleyişine geçmeden önce, IBFT’yi ne zaman ve neden kullanmak isteyeceğinizi belirtmekte fayda var. Herkese açık bir blok zincirinde, kısa cevap muhtemelen yapmayacağınızdır. Ancak konsorsiyum veya özel blok zincirleri söz konusu olduğunda, IBFT oldukça çekici görünmeye başlar.

PoW algoritması, hem donanım hem de elektrik açısından ünlüdür. Bu maliyet kasıtlı olup, herhangi birinin ağı kolayca ele geçirmesini önlemek içindir ve bu nedenle PoW, herkesin (saldırganlar dahil) katılabileceği tam ademi merkeziyetçi durumlar için çok uygundur. Bununla birlikte, kuruluşlar tarafından kullanılan konsorsiyum / özel zincirlerdeki düğümler, özünde bir kamu zincirindekilerden daha güvenilirdir. Bu nedenle, PoW fikir birliği mekanizması aşırı derecede külfetli olabilir ve diğer mekanizmalar, dağıtılmış bir sistemi çalıştırmak için “yeterli” güven sağlayabilir..

İspat Kanıtı, aynı şekilde, işletmeler için daha az alakalı olabilir, çünkü izin verilen bir ağda gaz için ödeme daha az önemlidir. Düğümlerin (zorunlu olarak) ağda para birimini korumaya ihtiyacı olmadığından, PoS gereksiz gereksinimleri ortaya çıkaracaktır..

Bu ödünleşimler göz önünde bulundurulduğunda, Yetki Kanıtı (PoA), ağdaki düğümlere bir round-robin veya başka bir rasgele sistem kullanarak zincir için yeni bloklar üretme ayrıcalığının tahsis edildiği bir sistemi kullanarak, olası en iyi çözüm olarak ortaya çıkıyor..

IBFT, PoA’nın birçok çeşidinden biridir ve aşağıdaki faydaları sağlar:

  • Anında blok kesinliği. Belirli bir zincir yüksekliğinde önerilen yalnızca 1 blok vardır. Tek zincir böylelikle çatallanmayı, amca bloklarını ve bir işlemin zincirde daha sonra bir kez “geri alınma” riskini ortadan kaldırır..
  • Bloklar arasında daha az zaman. Blokları inşa etmek ve doğrulamak için gereken çaba önemli ölçüde azaltılır (özellikle PoW ile ilgili olarak), bu da zincirin verimini büyük ölçüde artırır..
  • Yüksek veri bütünlüğü ve hata toleransı. IBFT, önerilen her bloğun bütünlüğünü sağlamak için bir grup doğrulayıcı kullanır. Bu doğrulayıcıların bir süper çoğunluğunun (~% 66) bloğu zincire eklenmeden önce imzalaması gerekir, bu da blok sahteciliğini çok zorlaştırır. Grubun ‘liderliği’ de zamanla döner – hatalı bir düğümün zincir üzerinde uzun vadeli etki yaratamamasını sağlar.
  • Operasyonel olarak esnek. Doğrulayıcılar grubu, zaman içinde değiştirilebilir, bu da grubun yalnızca tam güvenilen düğümleri içermesini sağlar.

Burada, çoğunlukla teknik olmayan terimlerle IBFT’ye genel bir bakış sağladık. IBFT’nin bazı orijinal teklifleri için GitHub’da EIP’leri inceleyebilirsiniz:

Bu makalenin geri kalanında, EIP’lerde bulunan ve kendi araştırmamızla öğrendiğimiz kavramların birçoğunu tartışarak, IBFT’nin daha teknik konularını inceleyeceğiz..

Not: IBFT kodu ayrıca bir go-ethereum çekme isteğinde de bulunabilir # 16385.

Operasyon

IBFT fikir birliği mekanizması aşağıdaki bileşenlerden oluşur:

  1. Bir PBFT ilham veren grup fikir birliği modeli.
  2. Üyelerin doğrulama grubuna eklenebileceği / çıkarılabileceği bir süreç.

IBFT, yeteneğin tüm yönlerini desteklemek için Blok Başlığının (ince bir şekilde) yeniden işlenmesini gerektirir.

Grup Konsensüs Modeli

Genel Bakış

IBFT, önerilen bir bloğun zincire eklenmeye uygun olup olmadığını belirlemek için bir Ethereum ağında çalışan bir doğrulama düğümleri (Doğrulayıcılar) havuzu kullanır..

Doğrulayıcıların bir düğümü isteğe bağlı olarak Teklif Veren olarak seçilir ve blok aralığında bir blok oluşturmaktan ve söz konusu bloğu grupla paylaşmaktan sorumludur. Doğrulayıcıların büyük çoğunluğu bloğun geçerli olduğunu düşünürse blok zincirine eklenir..

Mutabakat turunun tamamlanmasının ardından, Doğrulayıcılar, bir sonraki blok aralığında aday Bloğu sağlamaktan sorumlu olacak yeni bir Teklif Sahibi seçebilir..

Konsensüs mekanizması, tüm Doğrulayıcıların aynı bloğu zincire aynı yükseklikte eklemesinden sorumlu olan senkronize bir durum makinesidir..

Bir blok eklenemezse, Teklif Veren değiştirilir ve süreç yeniden başlar.

Durum makinesine yalnızca bir bloğun eklenebilmesini sağlamak için, IBFT, doğrulayıcıların büyük çoğunluğu eklemeyi kabul ettikten sonra (ancak söz konusu işi gerçekleştirmeden) önerilen bloğun değiştirilmesini önler, bu işlem “Blok Kilitleme” olarak adlandırılır..

IBFT fikir birliği mekanizması, doğrulama düğümlerinin 1 / 3’ünden daha azının yanlış davranması koşuluyla (güvenlik ihlali nedeniyle veya hatalı kod nedeniyle) sistem kararlılığı sunar. Yani F hatalı düğümleri tolere etmek için doğrulama grubu en az 3F + 1 düğüm içermelidir (bundan fazlası sistem bütünlüğünü artırmaz).

Not: Burada F, sistem tarafından tolere edilen hatalı düğümlerin sayısını ifade eder..

Durum Makinesi

IBFT Durum Makinesi

Eyaletler
  • Teklif Bekliyor. Doğrulayıcı, mevcut teklif veren tarafından sağlanacak yeni bir bloğu bekliyor. Doğrulayıcı bu tur için teklif veren ise, önerilen bloğu hazırlar ve bir ön hazırlık mesajıyla iletirler..
  • Hazırlanıyor. (Geçerli) bir önerilen blok almış ve onaylayıcı emsalleri bilgilendirmiş; şimdi doğrulayıcı akranlarının engellemeyi kabul ettiklerini bildirmesini bekliyor.
  • hazır. Doğrulayıcı eşin blok kabulünü almış ve benzer bir konumda olmalarını bekliyor. Bu aşamada, önerilen blok “kilitlenmiştir” ve bir ekleme girişimi gerçekleştirilene kadar değiştirilemez.
  • Yuvarlak Değişim. Tur, fikir birliğine varılmadan önce zaman aşımına uğradı veya blok eklenemedi. Tüm onaylayıcıların bir sonraki tur numarası üzerinde anlaşmasını bekleyin.
Geçişler
  1. BirBekleyen Teklif → Hazırlanıyor. Teklif verenden yeni bir blok (Preprepare mesajı) alındığında (yani blok, önerilen zincir ekleme noktası gibi içeriğinde de geçerlidir).
  2. Teklif Bekleniyor → Tur Değişikliği. Alınan teklif, belirli bir kural grubuna göre geçerli bir blok değildi (ör. Geçersiz teklif veren, yanlış yuvarlak numaralandırma).
  3. Hazırlanıyor → Hazır. Doğrulayıcı eşlerden 2F + 1 bildirimlerinin alınması üzerine (mesaj hazırlayın), önerilen bloğun yerleştirme için uygun olduğunu belirtir.
  4. Hazır → Teklif Bekliyor. Doğrulayıcı eşlerden bloğu zincire eklemeye hazır olduklarını belirten 2F + 1 bildirimlerinin (Teslim mesajı) alınması üzerine. Geçişte bloğu zincire ekleme işlemi gerçekleştirilir (başarılı).
  5. Hazır → Yuvarlak Değişim. Hazır olarak->Bekleyen Teklif, ancak blok ekleme başarısız oldu.
  6. Tur Değişikliği → Teklif Bekleniyor. Doğrulayıcıların 2F + 1’i, kullanılacak bir sonraki tur numarası üzerinde anlaştı.

Not: “RoundChange” e yapılan tüm geçişler, Doğrulayıcının doğrulayıcı eşlerine bir “RoundChange” mesajı iletmesine neden olur..

Blok Kilitleme

IBFT, çatalların yaratılmayacağını zorunlu kılar. Bu amaçla, bir blok çoğunluk tarafından kabul edildiğinde (yani Hazır durumuna girişte) blok “kilitli” hale gelir.

Bu, bu bloğu zincire ekleme girişiminde bulunulana kadar başka hiçbir bloğun yerleştirilmeyeceği anlamına gelir. Böylelikle ya blok başarılı bir şekilde eklenir (bu ya da sonraki turlarda yeterli commit mesajı alındığında) ya da blok yerleştirme başarısız olursa, atılır ve mevcut zincir yüksekliğinde yeni bir blok önerilir..

Doğrulama Grubu Üyeliği

Onay grubunun üyeleri, bir oylama mekanizması aracılığıyla zaman içinde değişebilir. Üyeler, çoğunluk (Kat (N / 2) + 1) oyuyla eklenebilir veya çıkarılabilir; her oy Blok Başlığında kaydedilir.

Ağdaki her düğüm (doğrulanmayan düğümler dahil), geçerli Doğrulayıcıları belirlemek ve mayınlı bloklardaki imzaların beklenen gruba girmesini sağlamak için her doğrulayıcı için oy sayısını izlemekten sorumludur..

Her bir oy Blok Başlığında yer aldığından, yalnızca belirli bir tur için Teklif Veren oy kullanabilir. Bu nedenle, düğümler zamanında eklenecek / kaldırılacaksa, Teklif Veren rolünün düzenli olarak güncellenmesi önemlidir..

Bir düğüm çoğunluk oyuna ulaştığında, onaylayıcı grubuna hemen katılır / ayrılır.

IBFT, henüz çoğunluğa ulaşmamış tüm oyların kaldırıldığı ve oylama çetelesini yeniden başlatmaya zorlayan bir noktayı tanımlayan bir Oylama Dönemini tanır. Bu, oyları hesaplarken, Doğrulayıcıların yalnızca en son dönemde başlaması gerektiği anlamına gelir. Varsayılan olarak Oylama Dönemi her 30.000 blokta bir gerçekleşir.

Oylar bir durum değişikliğini tanımlar (yani adaylar oylanır, doğrulayıcılar oylanır), belirli bir düğüm için oylama, Doğrulayıcının düğümün durumunu değiştirmesini istemediği anlamına gelir (statükoyu korumak için açık bir oylama gerekli değildir).

Blok Üstbilgi Yeniden Düzenleyicisi

Ethereum’da IBFT’yi desteklemek için blok başlıklarında bir dizi değişiklik yapılmalıdır. Bu değişiklikler şunları içerir:

  • lehtar: oylama yapılan düğümü tanımlar.
  • nonce: oy “yönünü” belirtir – AUTH veya DROP.
  • mixHash: sabitlenmiş sihirli sayı, bu bloğun IBFT onaylı olduğunu belirtir.
  • ommersHash: IBFT altında çalışırken ommer blokları olmadığından boş bir kümenin hash değeri olmalıdır.
  • zaman damgası: en azından ana bloğun zaman damgası + blok aralığı olmalıdır.
  • zorluk: 0x0000000000000001 ile doldurulmalıdır.
  • extraData: Doğrulayıcı Adresleri Listesi, ProposerSeal (teklif vereni tanımlar), CommittingSeal (bu blokta ‘commit’ bildiren doğrulayıcıların listesi) dahil olmak üzere IBFT’ye özgü verileri içerir.

Her doğrulayıcı için CommittingSeals listesi (potansiyel olarak) farklı olduğundan, blok karmasının bu bilgileri içermemesi önemlidir – yani, iki blok farklı CommittingSeals alanlarına sahip olsa bile, bunlar aynı bilgileri temsil ederler (yani işlemler vb. Aynıdır).

Sonuç

Kapanışta IBFT, PoW’nin talep ettiği gerekli altyapıyı azaltan, anında işlem kesinliği sunan bir Bizans hataya dayanıklı çözümüdür.

Ethereum ana ağında kullanılması pek olası olmasa da (çok daha geniş, bilinmeyen katılımcı aktörlerle), doğrulayıcı havuzunun güvenilir olduğu ve sorumlu tutulduğu özel bir zincirde kullanıldığında önemli fayda sağlar; Sabit bir tempo ve öngörülebilir bir işlem işleme oranına sahip bir zincir için ideal bir çözüm sunar.

Bu makalede incelenen süreçler, IBFT kullanan bir ağın Bizans düğümlerine toleranslı olacağına ve bu düğümlerin ağ üzerinde kontrol uyguladığı görüldüğünde kurtarılabileceğine güven vermektedir..

En son Ethereum haberleri, kurumsal çözümler, geliştirici kaynakları ve daha fazlası için haber bültenimize abone olun.Blockchain İş Ağları İçin Eksiksiz KılavuzKılavuz

Blockchain İş Ağları İçin Eksiksiz Kılavuz

Tokenizasyona GirişWeb semineri

Tokenizasyona Giriş

Finansın Geleceği Dijital Varlıklar ve DeFiWeb semineri

Finansın Geleceği: Dijital Varlıklar ve DeFi

Kurumsal Ethereum NedirWeb semineri

Kurumsal Ethereum Nedir?

Merkez Bankaları ve Paranın GeleceğiBeyaz kağıt

Merkez Bankaları ve Paranın Geleceği

Emtia Ticareti Finansmanı için Komgo BlockchainKasa Çivisi

Komgo: Emtia Ticareti Finansmanı için Blockchain

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me