JPM Coin Trilogy (Orta) -JPMorgan Chase neden Quorum blockchain'i tercih ediyor?
Bu makale üçlemenin ikinci bölümüdür. JPM coin-Quorum'un arkasındaki blockchain ağından bahsedelim ve özelliklerini, fikir birliği mekanizmasını ve geleneksel bankacılığın ticari ihtiyaçlarını nasıl karşılayacağınızı açıklayalım.
Quorum, JPMorgan Chase Bank tarafından 2016 yılında başlatılan açık kaynaklı bir proje olan "kurumsal düzeyde Ethereum" olarak kabul edilir.
(https://github.com/jpmorganchase/quorum)
Genel blok zinciri ile karşılaştırıldığında, Quorum aşağıdaki özelliklere sahiptir:
- Ethereum sözleşmeleriyle uyumlu
- Erişim sistemi, bilinen düğümler
- Zincir dışı + zincir üstü gizlilik koruması
- Birden çok fikir birliği mekanizması için esnek destek
- Yüksek performans, hızlı hız, çatlama önleyici
Ethereum klonu
Quorum, Ethereum istemcisinin Go dili sürümünün (go-ethereum) bir "klonu" olduğu ve go-ethereum sürümüne göre güncellendiği için Ethereum sözleşmeleriyle uyumludur. Bu, Truffle gibi geliştirme çerçeveleri de dahil olmak üzere Ethereum üzerinde çalışan tüm sözleşmelerin doğrudan Quorum'da dağıtılabileceği anlamına gelir.
Ancak bu, Quorum ve Ethereum ağının şu anda birbirleriyle iletişim kurabileceği anlamına gelmez (Birlikte Çalışabilirlik). Yetersayı daha çok bir konsorsiyum zinciridir, herkes istediği zaman ağa katılamaz. Düğümlerin eklenmesi ve kaldırılması yetki gerektirir ve bilinen kimliklerdir. Bu ağda madencilik mekanizması ve yerel token yok. Gazın kendisi alıkonulsa da Ethereum'daki Gazın fiyatı silinir, yani gasPrice = 0 ve para aktarırken madenci ücreti yoktur.
Gizlilik ve yasal düzenlemelere uygunluğa odaklanın
Ethereum'un özelliği, defterin açık ve şeffaf olmasıdır.Sıradan insanlar bir Ethereum tarayıcısı açarak her işlemin tüm bilgilerini kontrol edebilir. Şeffaflık, halka açık zincirler için bir avantajdır, ancak geleneksel endüstrilerde eşleştirilemeyen bir acı noktası haline gelmiştir. . Finans sektörü için verilerin gizliliği çok önemlidir Bankalar varlık durumlarını ve işlem kayıtlarını kamuya açıklamak istemezler ve hatta bu verilerin rakipler tarafından elde edilmesini istemezler.
Gizlilik koruması, Quorum'un temel işlevlerinden biridir. Quorum, işlemleri genel işlemler ve özel işlemler olarak böler.
Genel işlemler, temelde Ethereum ile aynı olan ana zincir düğümleri arasında doğrudan tamamlanır.
Özel işlemler, zincir dışındaki bağımsız bir sunucuda şifrelenecektir. Quorum ana zincirinde yalnızca şifrelenmiş verilerin hash değeri depolanır ve özel işlemlerin verileri zincir dışı depolanır ve yönetim motoru (Tessera ve Constellation) aracılığıyla düğümler arasında paylaşılır. Yalnızca işleme dahil olan taraflar (ve düzenleyici makamlar) işlemin ayrıntılarını görebilir ve ilişkili olmayan taraflar işlemin ayrıntılarını alamaz.
Ana zincirdeki tüm düğümlerin durumu geneldir ve mutlak bir durum mutabakatına varılırken, özel bir veri tabanının durumu farklıdır ve küresel durum depolanmaz. Özel bir işlem yapmak istiyorsanız, işlemi başlatırken yalnızca bir privateFor etiketi eklemeniz ve düğüm nesnesini eklemeniz gerekir ve işlem, özel durum veritabanında noktadan noktaya gerçekleştirilebilir.
Ama bu aynı zamanda bazı sorunları da beraberinde getiriyor.
1. privateFor node listesinin gönderilmesi onaylandıktan sonra, listeye yeni düğüm eklenemez. Diğer bir deyişle, karşı taraf önceden işlem zincirinin bir bağlantısında değilse, daha önce gerçekleşen işlemin detaylarını elde edemeyecektir. Belirli işlemler için merkez bankası veya düzenleyici ilk başta ağda değilse, ancak daha sonra katılmaya karar verirse, önceki işlem bilgilerini doğrudan alamayacağını hayal edin.
2. Özel durum veritabanı eşler arası olduğundan, küresel durum senkronize edilmez ve bu da çifte harcama riskini beraberinde getirir.
Ek olarak, verilerin zincir dışı sunuculara yerleştirilmesi, kaçınılmaz olarak merkezileşme riskleri ve tek hata noktaları getirir.
Zincir dışı gizlilik planının eksikliklerini çözmek için Quorum, özel sözleşmelerle ana zinciri birbirine bağlayan bir zincir içi gizlilik planı sağlamak için 2017 yılında Zcash ekibiyle birlikte çalıştı. Sözleşmenin iş mantığı, özel sözleşmede kararlaştırılır ve ardından ana zincirde tasfiye edilir ve sıfır bilgi kanıtlama yönteminde gizliliği korumak için bir köprü olarak z-belirteci kullanılır. .
Gizlilik köprüsü nasıl kurulur? Z sözleşmesi, ana zincir varlığıyla 1: 1 jetonlu varlık z-belirteçleri oluşturacaktır. Z-sözleşmesinin ana zincirde de çalıştığı, ancak varlıklarının, işlem bilgilerini (gönderen, alıcı, varlık sayısı vb.) Gizleyebilen Korumalı Varlıklar olduğu unutulmamalıdır.
Özel bir işlem için aşağıdaki adımları izleyin:
- Satıcı, özel bir sözleşme oluşturur ve sözleşmenin ayrıntılarını belirler: varlıkların tutarı, alıcılar ve satıcılar vb. Dahil.
- Alıcı sözleşmeyi kabul eder ve her iki taraf da özel sözleşme düzeyinde bir anlaşmaya varır.
- Özel sözleşme alıcıyı ödeme konusunda bilgilendirir.
- Alıcı, bazı varlıkları genel ana zincirden z-sözleşmesi katmanına aktarır ve gizli ödemeyi z-belirteçleri aracılığıyla tamamlar.
- Alıcı, özel sözleşme ödemesinin tamamlandığını bildirir.
- Özel sözleşme, ödemenin tamamlandığını doğrular ve satıcıyı varlıkları devretmesi için bilgilendirir.
- Satıcı ayrıca gizli aktarımı z-sözleşmesi katmanının z-belirteçleri aracılığıyla tamamlar.
- Satıcı, özel sözleşmenin devrinin tamamlandığını bildirir.
- Özel sözleşme doğrulama transferi tamamlandı ve işlem nihayet şu anda kapatıldı.
- Diğer düğümler yalnızca halka açık defterdeki bakiyeyi görebilir ve süpervizör z-sözleşmesi katmanının z-token transferini kontrol edebilir.
Bir paralel ödeme ağı katmanı ekleyerek, işlem sürecinde tüm bilgilerin açığa çıkarılmasına gerek kalmaz ve çift harcama ve merkezileştirme risklerinden kaçınmak için varlıklar zincirde tasfiye edilir. Aynı zamanda düzenleyicilere de kolaylık sağlar.
Esnek fikir birliği mekanizması - kesinlik arayışı (Kesinlik)
Yetersayı PoA, RAFT ve IBFT dahil olmak üzere üç fikir birliği mekanizmasını destekleyebilir.Bu fikir birliği mekanizmalarını tanıtmadan önce, Quorum'un en yaygın PoW (Proof of Work) veya PoS'yi (Proof of Stake) desteklemediğini gördük. Neden?
Hem PoW hem de PoS, Nakamoto Konsensüsüne aittir. Herkes herhangi bir zamanda düğüme katılabilir ve çıkabilir. Bu fikir birliği mekanizması, muhasebeciyi, düğümler arasında bir tür adil "oylama" yoluyla seçer. Düğümlerin kimliği olmadığından, karşılıklı değil serbestçe oluşturabilirler. Güven, bu nedenle oylama kaynakları kıt olmalıdır. PoW mekanizması altında, kıt kaynaklar fiziksel bilgi işlem gücü iken, PoS altında bu tür kaynaklar ekonomik haklardır. Erişime gerek olmaması, merkezi olmayan kontroller ve dengeler getirir, ancak defter tutmada düğümler arasındaki "rekabet" kaçınılmaz olarak hız ve verimliliği feda eder.
Özel zincirler ve konsorsiyum zincirleri için Nakamoto Consensus uygun değildir. Güvenlik ve gizlilik hususları için, özel zincir ve konsorsiyum zincirinin düğümlerinin ağa katılabilmeleri için karşılıklı izin almaları gerekir. Karşılıklı iznin temeli, her düğümün sabit bir kimliğe sahip olmasıdır, bu da düğümleri güvenilir veya kısmen güvenilen düğümler haline getirir. Kısmi veya tam güven düğümlerine dayalı olarak, PoA ve IBFT gibi Bizans Hata Toleranslı (BFT) yüksek performanslı hata toleranslı dağıtılmış sistemler veya RAFT gibi hataya dayanıklı dağıtılmış sistemler, Crash Fault Tolerant (CFT) kullanılabilir.
PoA
PoA'nın tam adı, Proof of Authority'dir (Proof of Authority). PoA, kimlikleri olan bir grup düğüme dayanır ve hesapları tutmak için sırayla yapılır. Başka bir deyişle, her düğüm kendi kimliğini ve yetkisini bir garanti olarak kullanıyor. Her blok için yalnızca bir imza onayı gerekir, bu da blok oluşturma hızını ve saniye başına işlem hacmini büyük ölçüde artırır.
PoA tasarımında tek bir düğümün gücünü sınırlamak için merkezileşme riski olsa da, her düğümün imza aralığının N (toplam düğüm sayısı) / 2'den büyük olması gerekir.
Quorum, erken geliştirme aşamasında PoA konsensüsünü kullandı, ancak resmi olarak üretim aşamasına girdiğinde PoA'yı ortadan kaldırdı. Bunun nedeni nedir?
Bu, finansal yerleşim ağının kesinliği tarafından en çok değer verilen veya çatallanamayan başka bir özelliği içerir.
JPM madeni para, PoW, PoS ve PoA dahil kullanım olasılığını dışlayan çatallanma önleme öncülünü gerektirir. Çünkü bu birkaç fikir birliği mekanizmaları altında, blok zinciri tutarlı kurallara göre blokları kontrol edip içermesine rağmen, aynı anda aynı yükseklikte birden fazla doğru blok olacaktır. Genel olarak konuşursak, tüm ağ hızlı bir şekilde en uzun zincirde toplanacaktır. Ancak, kural değişiklikleri söz konusu olduğunda, yani, ağda farklı kurallara uyan düğümler olduğunda, blok zincirinin çatallanma ve aynı zincire hızlı bir şekilde geri dönmeme olasılığı olacaktır, buna genellikle "çatal" diyoruz.
Bitcoin Cash'in Bitcoin'in forkuna ve kendi forkuna olan etkisine değinecek olursak, günde 6 trilyon dolar işleyen JPMorgan Chase Bank'ın fork nedeniyle bu işlemlerin kesinlikle geçersiz kılınmasını istemediğini anlayabilirsiniz.
Nispeten konuşursak, Quorum tarafından desteklenen diğer iki fikir birliği mekanizması: RAFT ve IBFT çatallanmayı önlüyor.
SAL
RAFT aslında Kubernetes ve Docker Swarm gibi konteyner küme yönetim sistemlerinde kullanılan ve yaygın olarak kullanılan geleneksel bir dağıtılmış konsensüs protokolüdür. RAFT, hataya dayanıklı, güvenilir düğümler olan ve daha hızlı blok oluşturma süresi ve kesinliği gerektiren kapalı ittifaklar için çok etkilidir.
Ethereum ile karşılaştırıldığında, RAFT'ın kendi düğümleri de vardır. Ethereum ile karşılaştırıldığında, herhangi bir düğüm blok oluşturabilir, RAFT düğümleri Lider, Takipçi ve geçici Aday olarak ayrılır.
Lider, blokların üretilmesinden sorumlu tek düğümdür. Follower, Liderin "kalp atışını" izler ve Lider tarafından geçen blokları toplar.
Takipçi, döngüsü içinde Lider'den bir kalp atışı almazsa, Lider'in öldüğünü düşünecektir. Bu sırada Lider'in kalp atışını almayan Takipçi seçimi yeniden başlatır ve kimliği Takipçiden Aday'a değiştirilir. Kendisine oy verecek ve ardından diğer İzleyicilere bir oylama başvurusu gönderecek ve Lider olacaktır.
Kalp atışını kabul etmenin amacı sistem arızalarına direnmektir ve yeni düğüm lider olarak bloklar üretmeye devam eder.
Yeni bir işlem oluşturulduğunda Liderin bunu hemen zincire kaydetmeyeceğini, bunun yerine tüm takipçilerden ve ardından yürütme mesajını alan tüm takipçilerden onay makbuzlarını aldıktan sonra bir yürütme mesajı kaydedip yayınlayacağını belirtmek gerekir. Ancak o zaman blok yerel zincire kaydedilecektir. Bu şekilde çatalları önleyebilir ve kesinliği sağlayabilirsiniz.
RAFT mekanizması altındaki varsayılan blok oluşturma aralığı 50 ms'dir ve bloklar yalnızca bir işlem gerçekleştiğinde oluşturulur, bu da depolama alanından büyük ölçüde tasarruf sağlar.
Bununla birlikte, RAFT mekanizmasının da eksiklikleri vardır.İşleminin ön koşulu, tüm düğümlerin dürüst olmasıdır.RAFT, tek bir hata noktasını tolere edebilmesine rağmen, hata toleransına sahip değildir ve düğümlerin kötülük yapmasını ve geçmiş verilerle oynamasını engelleyemez.
IBFT
Tam adı İstanbul Bizans Hata Toleransı (İstanbul Bizans Hata Toleransı) olan IBFT, çatallanmayı önleme temelinde bazı düğümlerin kötülük yapmasını engelleyebilir.
Bizans Generalleri sorunu, hata toleransı konusunda eski bir mutabakat anlaşmasıdır. Bizans ordusunun bir düşman şehri çevrelediğini, Bizans kuvvetlerinin şehrin dışında ayrı ayrı konuşlandıklarını ve her bölümün sadece kendi generali tarafından komuta edildiğini hayal edin. Generaller diğer generallerle ancak haberciler aracılığıyla iletişim kurabilirler. Düşmanı gözlemledikten sonra, uyumlu bir eylem planı geliştirmeleri gerekir. Sonuç, generallerin 2 / 3'ünden fazlası sadık olduğu sürece fikir birliğine varılabileceğini gösterdi.
IBFT, pratik bir Bizans hata toleranslı algoritmasıdır.Tamamen Lidere inanan RAFT'nin aksine, IBFT'nin öncülü dürüst olmayan düğümlerin 1 / 3'ünü tolere etmektir ve doğrulayıcılar tarafından çoklu oylama turları yoluyla bloklar fikir birliğine varıldıktan sonra oluşturulacaktır.
Blok üretimi temel olarak üç aşama gerektirir: ön hazırlık, hazırlık ve taahhüt
İlk olarak, tüm ağın düğümlerinden bir lider, sırayla blokları oluşturmaktan sorumlu olacak şekilde seçilir ve lider, bir işlem talebini aldıktan sonra yeni bir blok oluşturur.
Ön hazırlık : Ana düğüm, tüm yedekleme düğümlerine bir ön hazırlık mesajı gönderir ve önerilen düğüm, ağdan yeni bloğa yerleştirilmesi gereken birden çok işlemi toplayacak ve bunları listede sıralayacaktır.
Hazırla (Hazırla) : Tüm yedekleme düğümleri işlem listesini aldıktan sonra bu işlemleri sıralama simülasyonuna göre yürütürler. Tüm işlemler gerçekleştirildikten sonra yayın, işlem sonucuna göre yeni bloğun karma özetini hesaplar.
Onayla (Kaydet) : Bir düğüm diğer düğümlerin 2 / 3'ünden aynı özeti alırsa, tüm ağa bir commit mesajı yayınlar.
Düğüm 2/3 commit mesajı alırsa, yeni bloğu ve işlemlerini yerel blok zincirine ve durum veritabanına gönderebilir ve rastgele bir sonraki blok yüksekliği turuna girebilir.
Her bloğun üç aşamada doğrulandığı görülebilir, düğümlerin 1 / 3'ü başarısız olsa veya kötü işlese bile normal şekilde eklenebilirler. Birincil düğüm kötü amaçlıysa, yedek düğümler birbirlerini kontrol edebilir, bir çakışma durumunda bir Yuvarlak Değişiklik gönderebilir ve yeni bir birincil düğüm seçebilir.
Her blok yüksekliğinde blokların üretilmesinden yalnızca bir düğüm sorumlu olduğundan, çatallanma riski olmayacaktır. Ayrıca, defterde değişiklik yapılamaz .. Geçmiş kaydı değiştirmeye çalışmak, tüm yedekleme düğümlerinin ve ana düğümün özel anahtarlarını almayı gerektirir. PoW ile karşılaştırıldığında, IBFT'nin bir rekabet mekanizması yoktur ve blok oluşturma hızı daha hızlıdır.
Bununla birlikte, IBFT'nin dezavantajları da açıktır.Çoklu doğrulama aşamalarının yapısı altında mesaj sayısı ve düğüm sayısı katlanarak artar.Bu nedenle, IBFT'deki düğüm sayısı çok fazla olamaz ve genellikle işletme düzeyinde ve devlet ağı olarak kullanılır.
Genel olarak, düğüm erişimi, gizliliğe odaklanma, işlemlerin kesinliği ve esnek fikir birliği mekanizmaları için destek, farklı iş senaryolarının ihtiyaçlarını karşılar ve düzenleyici kolaylık, geleneksel finans devlerinin şifreli para birimlerini verirken değer verdiği özellikler ve koşullardır.
JP Morgan Chase, Quorum blok zincirinin inşasına ve bilgisine çok açık olmasına rağmen, ne yazık ki yetkili, JPM coin tarafından kullanılan fikir birliği mekanizması hakkındaki bilgileri açıklamadı. JPM coin, farklı uygulama senaryolarına göre RAFT ve IBFT arasında seçim yapacaktır. Tüm düğümler JPMorgan Bank'ın güvenilir ortaklarıysa, o zaman RAFT en iyi seçimdir; üye bankalara sadece kısmen güveniyorsanız, IBFT en uygun çözüm olacaktır.
Bu aynı zamanda, en azından erken aşamalarda, JPM madeni parasının nispeten kapalı bir ittifak hedeflediği anlamına gelir. Bununla birlikte, JPMorgan madeni paralarının genel kullanıcılar ile ilgisi yoktur JPMorgan Chasein takas ağı, bankalar arasındaki ağ etkisini büyük ölçüde artırabilir ve sınır ötesi ödemeler için daha güvenli bir uyumluluk bilgisi değişim protokolü sağlayabilir. Banka verimliliğinin iyileştirilmesi ve maliyetlerin azaltılması, şüphesiz son kullanıcılar için iyi bir şeydir. Daha da önemlisi, JPMorgan coin'in piyasaya sürülmesi, blockchain uygulaması da dahil olmak üzere Ethereum'a büyük bir destek sağlıyor. Teknik açıdan bakıldığında, Ethereum sözleşmeleriyle uyumlu Quorum ağının gelecekte mevcut halka açık blok zincirleriyle birlikte çalışarak merkezi ve eşler arası para birimi sistemleri arasında bir köprü kurması tamamen mümkündür.
Üçüncü bölümde, çeşitli ülkelerde büyük bankalar ve merkez bankaları tarafından ihraç edilen ve test edilen kripto para birimleri ve dijital para birimlerinin yanı sıra yerel ekonomiyi ve hatta küresel para piyasasını yeniden şekillendirmenin önemini yatay olarak karşılaştıracağım.
Eser sahibi: Pan Chao
