Akıllı sözleşme hesaplaması: Hyperledger Fabric vs MultiChain vs Ethereum vs Corda

Bir blok zincirine kod koymanın birden fazla yolu vardır

Blok zincirleriyle ilgili çoğu tartışmada, "akıllı sözleşmeler" kavramının ortaya çıkması uzun sürmez. Popüler hayal gücünde, akıllı sözleşmeler, güvenilir bir aracı gerektirmeden taraflar arası etkileşimlerin yürütülmesini otomatikleştirir. Yasal ilişkileri kelimelerden ziyade kodla ifade ederek, işlemlerin kasıtlı olsun veya olmasın doğrudan ve hatasız yapılmasını sağlamayı taahhüt ederler.

Teknik bir bakış açısından, akıllı bir sözleşme daha spesifik bir şeydir: bir blok zincirinde yaşayan ve bu zincirin işlemleri için kuralları tanımlayan bilgisayar kodu. Bu açıklama kulağa yeterince basit geliyor, ancak bunun arkasında bu kuralların nasıl ifade edildiği, yürütüldüğü ve doğrulandığı konusunda büyük bir çeşitlilik yatıyor. Yeni bir uygulama için blockchain platformu seçerken “Bu platform akıllı sözleşmeleri destekliyor mu?” sorusu geliyor. sormak doğru değil. Bunun yerine şunu sormamız gerekiyor: “Bu platform ne tür akıllı sözleşmeleri destekliyor?”

Bu makalede amacım, akıllı sözleşme yaklaşımları ve temsil ettikleri ödünleşimler arasındaki bazı önemli farklılıkları incelemektir. Bunu, bir çeşit özelleştirilmiş zincir içi kodu destekleyen dört popüler kurumsal blok zinciri platformuna bakarak yapacağım. Birincisi, IBM'in Hyperledger Fabricsözleşmelerini "zincir kodu" olarak adlandırır. İkincisi, MultiChain platformumuz, akıllı filtreler 2.0 sürümünde. Üçüncü, Ethereum (ve izinli Nisap ve Yuva yan ürünler), "akıllı sözleşme" adını popüler hale getirdi. Ve sonunda, R3 Corda, işlemlerinde "sözleşmelere" atıfta bulunan. Tüm farklı terminolojiye rağmen, nihayetinde bunların tümü aynı şeyi ifade eder - bir zincirin kurallarını tanımlayan uygulamaya özel kod.

Daha ileri gitmeden önce, okuyucuyu aşağıdaki içeriğin çoğunun doğası gereği teknik olduğu ve genel programlama ve veritabanı kavramlarına aşina olduğu konusunda uyarmalıyım. İyi ya da kötü için, bu önlenemez - ayrıntılara girmeden, belirli bir proje için bir blok zinciri kullanıp kullanmayacağınıza ve (eğer öyleyse) kullanılacak doğru blok zinciri türüne dair bilinçli bir karar vermek imkansızdır.

Blockchain ile ilgili temel bilgiler

Biraz bağlamla başlayalım. Birden çok kuruluş tarafından paylaşılan ve temel alınan bir veritabanına dayalı bir uygulama hayal edin. Geleneksel bir merkezileştirilmiş mimaride, bu veri tabanı, birbirlerine güvenmeseler bile tüm katılımcıların güvendiği tek bir taraf tarafından barındırılır ve yönetilir. Veritabanını değiştiren işlemler, yalnızca bu merkezi tarafın sistemlerindeki uygulamalar tarafından, genellikle katılımcılardan alınan mesajlara yanıt olarak başlatılır. Veritabanı, yalnızca kendisine mantıklı olan işlemleri göndermek için uygulamaya dolaylı olarak güvenildiği için söyleneni yapar.

Blok zincirleri, güvenilir bir aracı olmadan paylaşılan bir veritabanını yönetmenin alternatif bir yolunu sağlar. Bir blok zincirinde, her katılımcı veritabanının bir kopyasını tutan ve onu değiştiren işlemleri bağımsız olarak işleyen bir "düğüm" çalıştırır. Katılımcılar, her biri yalnızca kimlik sahibi tarafından bilinen ilgili bir özel anahtara sahip olan genel anahtarlar veya "adresler" kullanılarak tanımlanır. İşlemler herhangi bir düğüm tarafından oluşturulabilirken, kökenlerini kanıtlamak için başlatıcının özel anahtarı tarafından "dijital olarak imzalanır".

Düğümler birbirine eşler arası bir şekilde bağlanır, işlemleri hızla yayar ve zaman damgası alınıp ağ boyunca onaylandığı "bloklar". Blok zincirinin kendisi, kelimenin tam anlamıyla, her tarihsel işlemin sıralı bir kaydını oluşturan bu blokların bir zinciridir. Merkezi kontrol gerektirmeden tüm düğümlerin blok zincirinin içeriği üzerinde anlaşmaya varmasını sağlamak için bir "fikir birliği algoritması" kullanılır. (Bu açıklamanın bir kısmının, her düğümün veritabanının yalnızca kısmi bir kopyasına sahip olduğu ve küresel bir blok zinciri bulunmadığı Corda için geçerli olmadığını unutmayın. Bunun hakkında daha sonra daha fazla konuşacağız.)

Prensip olarak, herhangi bir paylaşılan veritabanı uygulaması, çekirdeğinde bir blok zinciri kullanılarak mimariye sahip olabilir. Ancak bunu yapmak, merkezi bir senaryoda bulunmayan bir dizi teknik zorluk yaratır:

• İşlem kuralları. Herhangi bir katılımcı veritabanını doğrudan değiştirebiliyorsa, uygulamanın kurallarına uymasını nasıl sağlarız? Bir kullanıcının veritabanının içeriğini kendi kendine hizmet edecek şekilde bozmasını engelleyen nedir?
• Determinizm. Bu kurallar tanımlandıktan sonra, veritabanının kendi kopyaları için işlemleri işlerken birden çok düğüm tarafından birden çok kez uygulanacaktır. Her düğümün tam olarak aynı sonucu almasını nasıl sağlarız?
• Çatışmaların önlenmesi. Merkezi bir koordinasyon olmadan, her biri uygulamanın kurallarına uyan ancak yine de birbiriyle çatışan iki işlemle nasıl başa çıkacağız? Çatışmalar, kasıtlı bir sistemle oyun oynama girişiminden kaynaklanabilir veya kötü şans ve zamanlamanın masum bir sonucu olabilir.

Peki akıllı sözleşmeler, akıllı filtreler ve zincir kodu nereden geliyor? Temel amaçları, bu zorlukları çözmek için bir blok zincirinin temelini oluşturan altyapıyla çalışmaktır. Akıllı sözleşmeler, uygulama kodunun merkezi olmayan eşdeğeridir - tek bir merkezi yerde çalıştırmak yerine, blok zincirindeki birden çok düğümde çalışır, bu veritabanının içeriğini değiştiren işlemleri oluşturur veya onaylar.

Bu zorluklardan ilki olan işlem kurallarıyla başlayalım ve sırasıyla Fabric, MultiChain, Ethereum ve Corda'da nasıl ifade edildiklerini görelim.

İşlem kuralları

İşlem kuralları, blockchain destekli veritabanlarında belirli bir işlevi yerine getirir - dönüşümler bu, veritabanının durumunda gerçekleştirilebilir. Bu gereklidir, çünkü bir blok zincirinin işlemleri, katılımcılarından herhangi biri tarafından başlatılabilir ve bu katılımcılar, veritabanını istedikleri zaman değiştirmelerine izin verecek kadar birbirlerine yeterince güvenmezler.

İşlem kurallarının neden gerekli olduğuna dair iki örnek görelim. İlk olarak, katılımcıları tarafından yayınlanan PDF belgelerini toplamak ve zaman damgası vurmak için tasarlanmış bir blok zinciri hayal edin. Bu durumda, hiç kimse belgeleri kaldırma veya değiştirme hakkına sahip olmamalıdır, çünkü bunu yapmak sistemin tüm amacını - belgenin kalıcılığını - baltalayacaktır. İkinci olarak, kullanıcılarının bakiyelerini takip eden, paylaşılan bir finansal defteri temsil eden bir blok zinciri düşünün. Bir katılımcının kendi bakiyesini keyfi olarak şişirmesine veya başkalarının parasını almasına izin veremeyiz.

Girdiler ve çıktılar

Blok zinciri platformlarımız, işlem kurallarını ifade etmek için iki geniş yaklaşıma dayanır. “Girdi-çıktı modeli” dediğim ilki MultiChain ve Corda'da kullanılıyor. Burada işlemler, sırasıyla bir "girdi" ve "çıktı" kümesi oluşturarak, silip oluşturdukları veritabanı satırlarını veya "durumları" açıkça listeler. Bir satırı değiştirmek, o satırı silmek ve onun yerine yenisini oluşturmakla eşdeğer işlem olarak ifade edilir.

Veritabanı satırları yalnızca girdilerde silindiğinden ve yalnızca çıktılarda oluşturulduğundan, her girdinin bir önceki işlemin çıktısını "harcaması" gerekir. Veritabanının mevcut durumu "harcanmamış işlem çıktıları" veya "UTXO'lar", yani henüz kullanılmamış önceki işlemlerin çıktıları olarak tanımlanır. İşlemler ayrıca veritabanının bir parçası olmayan ancak anlamlarını veya amaçlarını tanımlamaya yardımcı olan "meta veriler", "komutlar" veya "ekler" olarak adlandırılan ek bilgiler içerebilir.

Bu üç girdi, çıktı ve meta veri seti göz önüne alındığında, MultiChain veya Corda'daki bir işlemin geçerliliği, bu setler üzerinde rastgele hesaplamalar yapabilen bazı kodlarla tanımlanır. Bu kod işlemi doğrulayabilir veya karşılık gelen açıklamayla bir hata döndürebilir. Girdi-çıktı modelini, işlemlerin her bir kuralı takip etmesini sağlayan bir kontrol listesi tutan otomatik bir “denetçi” olarak düşünebilirsiniz. İşlem bu kontrollerden herhangi birini geçemezse, ağdaki tüm düğümler tarafından otomatik olarak reddedilecektir.

Girdi-çıktı modelini paylaşmalarına rağmen MultiChain ve Corda'nın bunu çok farklı şekilde uyguladıkları unutulmamalıdır. MultiChain'de çıktılar, JSON, metin veya ikili formatta varlıklar ve / veya veriler içerebilir. Kurallar, tüm işlemleri veya yalnızca belirli varlıkları veya veri gruplarını içerenleri kontrol etmek için ayarlanabilen "işlem filtreleri" veya "akış filtreleri" ile tanımlanır. Buna karşılık, bir Corda çıktı "durumu", tanımlanmış veri alanları ile Java veya Kotlin programlama dilinde bir nesne tarafından temsil edilir. Corda'nın kuralları, belirli durumlara eklenen “sözleşmelerde” tanımlanır ve bir devletin sözleşmesi yalnızca bu durumu girdilerinde veya çıktılarında içeren işlemlere uygulanır. Bu, Corda'nın olağandışı görünürlük modeliişlemlerin yalnızca karşı tarafları veya sonraki işlemlerini etkiledikleri kişiler tarafından görülebildiği.

Sözleşmeler ve mesajlar

"Sözleşme-mesaj modeli" dediğim ikinci yaklaşım ise Hyperledger Fabric ve Ethereum'da kullanılıyor. Burada, blok zincir üzerinde birden fazla "akıllı sözleşme" veya "zincir kodu" oluşturulabilir ve her birinin kendi veritabanı ve ilişkili kodu vardır. Bir sözleşmenin veritabanı, doğrudan blok zinciri işlemleri yerine yalnızca koduyla değiştirilebilir. Bu tasarım modeli, nesne yönelimli programlamada kod ve verilerin "kapsüllenmesine" benzer.

Bu modelle, bir blok zinciri işlemi, bazı isteğe bağlı parametreler veya verilerle bir sözleşmeye gönderilen bir mesaj olarak başlar. Sözleşmenin kodu, mesaja ve parametrelere tepki olarak yürütülür ve bu reaksiyonun bir parçası olarak kendi veritabanını okumakta ve yazmakta serbesttir. Sözleşmeler ayrıca diğer sözleşmelere mesaj gönderebilir, ancak birbirlerinin veritabanlarına doğrudan erişemezler. İlişkisel veritabanları dilinde sözleşmeler, zorunlu Veritabanına tüm erişimin önceden tanımlanmış bir kod aracılığıyla gittiği "saklı prosedürler".

Ethereum'un bir varyasyonu olan Fabric ve Quorum, bir ağın birden fazla "kanal" veya "özel durum" tanımlamasına izin vererek bu resmi karmaşıklaştırır. Amaç, her biri yalnızca belirli bir katılımcı alt grubu tarafından görülebilen ayrı ortamlar oluşturarak blok zinciri gizliliği sorununu azaltmaktır. Bu teoride umut verici görünse de, gerçekte her kanaldaki veya özel devletteki sözleşmeler ve veriler diğerlerinden izole edilmiştir. Sonuç olarak, akıllı sözleşmeler açısından, bu ortamlar ayrı blok zincirlerine eşdeğerdir.

Örnek kurallar

Bu iki modelle tek varlıklı bir mali defter için işlem kurallarının nasıl uygulanacağını görelim. Defterimizin veritabanındaki her satırda, sahibin adresini ve sahip olunan varlığın miktarını içeren iki sütun vardır. Girdi-çıktı modelinde, işlemler iki koşulu karşılamalıdır:

1. Bir işlemin çıktılarındaki toplam varlık miktarı, girdilerindeki toplamla eşleşmelidir. Bu, kullanıcıların keyfi olarak para oluşturmasını veya silmesini engeller.
2. Her işlem, girişlerinin her birinin sahibi tarafından imzalanmalıdır. Bu, kullanıcıların birbirlerinin parasını izinsiz harcamalarını engeller.

Birlikte ele alındığında, bu iki koşul, basit ama uygulanabilir bir finansal sistem oluşturmak için gerekli olan tek şeydir.

Sözleşme mesajı modelinde, varlığın sözleşmesi, üç parametre alan bir "ödeme gönder" mesajını destekler: gönderenin adresi, alıcının adresi ve gönderilecek miktar. Buna karşılık, sözleşme aşağıdaki dört adımı gerçekleştirir:

1. İşlemin gönderen tarafından imzalandığını doğrulayın.
2. Gönderenin yeterli paraya sahip olup olmadığını kontrol edin.
3. İstenilen miktarı gönderenin satırından çıkarın.
4. Bu miktarı alıcının satırına ekleyin.

İlk iki adımdaki çeklerden herhangi biri başarısız olursa, sözleşme iptal edilecek ve herhangi bir ödeme yapılmayacaktır.

Dolayısıyla, hem girdi-çıktı hem de sözleşme mesajı modelleri, işlem kurallarını tanımlamanın ve paylaşılan bir veritabanını güvende tutmanın etkili yollarıdır. Aslında teorik düzeyde, bu modellerin her biri diğerini simüle etmek için kullanılabilir. Ancak pratikte en uygun model, inşa edilen uygulamaya bağlı olacaktır. Her işlem bir kaç veya daha fazla bilgi parçasını etkiliyor mu? İşlem bağımsızlığını garanti etmemiz gerekiyor mu? Her bir veri parçasının açık bir sahibi var mı yoksa paylaşılacak bir küresel durum var mı?

Cevapların bu iki model arasındaki bir seçimi nasıl etkilemesi gerektiğini keşfetmek burada kapsamımızın ötesindedir. Ancak genel bir kılavuz olarak, yeni bir blockchain uygulaması geliştirirken, işlem kurallarını her iki biçimde de ifade etmeye ve hangisinin daha doğal bir şekilde uyduğunu görmeye değer. Fark, (a) programlama kolaylığı, (b) depolama gereksinimleri ve verimi ve (c) çakışma algılama hızı açısından kendini ifade edecektir. Bu son sayı hakkında daha sonra daha fazla konuşacağız.

Yerleşik kurallar

İşlem kuralları söz konusu olduğunda, MultiChain'in özellikle Fabric, Ethereum ve Corda'dan farklı olduğu bir yol var. Bu diğer platformların aksine, MultiChain, blockchain tabanlı uygulamalar için bazı temel yapı taşları sağlayan birkaç yerleşik soyutlamaya sahiptir. gerektiren geliştiricilerin kendi kodlarını yazmaları. Bu soyutlamalar, yaygın olarak ihtiyaç duyulan üç alanı kapsar: (a) dinamik izinler, (b) aktarılabilir varlıklar ve (c) veri depolama.

Örneğin MultiChain, ağa bağlanma, işlem gönderme ve alma, varlık veya akış oluşturma veya diğer kullanıcıların izinlerini kontrol etme izinlerini yönetir. Birden fazla değiştirilebilir varlık ihraç edilebilir, devredilebilir, emekli olabilir veya güvenli ve atomik olarak değiştirilebilir. Zincir üzerindeki veya zincir dışı verileri JSON, metin veya ikili formatlarda yayınlamak, endekslemek ve almak için bir zincir üzerinde herhangi bir sayıda "akış" oluşturulabilir. Bu soyutlamalar için tüm işlem kuralları kullanıma hazırdır.

MultiChain üzerinde bir uygulama geliştirirken, bu yerleşik işlevselliği göz ardı etmek ve işlem kurallarını yalnızca akıllı filtreler kullanarak ifade etmek mümkündür. Bununla birlikte, akıllı filtreler, varsayılan davranışlarını etkinleştirerek yerleşik soyutlamalarıyla birlikte çalışmak üzere tasarlanmıştır. kısıtlı özelleştirilmiş şekillerde. Örneğin, belirli etkinlikler için izin, herhangi bir yöneticinin yapacağı varsayılan davranış yerine belirli yöneticiler tarafından kontrol ediliyor olabilir. Belirli varlıkların devri zamanla sınırlı olabilir veya belirli bir miktarın üzerinde ek onay gerektirebilir. Belirli bir akıştaki veriler, yalnızca gerekli alanlara ve değerlere sahip JSON yapılarından oluştuğundan emin olmak için doğrulanabilir.

Tüm bu durumlarda, akıllı filtreler işlemlerin doğrulanması için ek gereksinimler oluşturur, ancak Kaldır yerleşik basit kurallar. Bu, blok zinciri uygulamalarındaki temel zorluklardan birinin ele alınmasına yardımcı olabilir: bazı zincir içi kodlardaki bir hatanın feci sonuçlara yol açabileceği gerçeği. Halka açık Ethereum blok zincirinde bu sorunun sonsuz örneklerini gördük, en ünlüsü DAO'nun Ölümü ve Eşlik çoklu imzalı hatalar. Daha geniş anketler Ethereum akıllı sözleşmelerinde saldırganların diğer insanların fonlarını çalmasını veya dondurmasını sağlayan çok sayıda yaygın güvenlik açığı buldu.

Elbette MultiChain akıllı filtreler de hatalar içerebilir, ancak sonuçları kapsam açısından daha sınırlıdır. Örneğin, yerleşik varlık kuralları, bir akıllı filtrenin içerdiği diğer mantık ne olursa olsun, bir kullanıcının diğerinin parasını harcamasını veya yanlışlıkla kendi parasını yok etmesini engeller. Akıllı filtrede bir hata bulunursa, defterin temel bütünlüğü korunurken devre dışı bırakılabilir ve düzeltilmiş bir sürümle değiştirilebilir. Felsefi olarak MultiChain, veritabanı platformunun sütunlar, tablolar, dizinler ve kısıtlamalar gibi bir dizi yerleşik soyutlama sağladığı geleneksel veritabanı mimarilerine daha yakındır. Tetikleyiciler ve saklı yordamlar gibi daha güçlü özellikler, gerçekten ihtiyaç duyulan durumlarda, isteğe bağlı olarak uygulama geliştiricileri tarafından kodlanabilir.

İşlem kuralları	Kumaş	Çoklu Zincir	Ethereum	Halat
Model	Sözleşme-mesaj	Giriş çıkış	Sözleşme-mesaj	Giriş çıkış
Yerleşik	Hayır	İzinler + varlıklar + akışlar	Hayır	Hayır

Determinizm

Hesaplaşmamızın bir sonraki bölümüne geçelim. Hangi yaklaşımı seçersek seçelim, bir blockchain uygulamasının özel işlem kuralları, uygulama geliştiricileri tarafından yazılan bilgisayar kodu olarak ifade edilir. Ve merkezi uygulamalardan farklı olarak, bu kod, her işlem için birden fazla kez ve birden fazla yerde çalıştırılacaktır. Bunun nedeni, farklı katılımcılara ait birden fazla blok zinciri düğümünün her birinin bu işlemi kendileri için doğrulaması ve / veya yürütmesi gerektiğidir.

Bu tekrarlanan ve gereksiz kod yürütme, merkezi uygulamalarda nadiren bulunan yeni bir gereksinimi ortaya çıkarır: determinizm. Hesaplama bağlamında, determinizm, bir kod parçasının, nerede ve ne zaman çalıştırılırsa çalıştırılsın, aynı parametreler için her zaman aynı cevabı vereceği anlamına gelir. Bu, bir blockchain ile etkileşime giren kod için kesinlikle çok önemlidir, çünkü determinizm olmadan, o zincirdeki düğümler arasındaki fikir birliği feci bir şekilde bozulabilir.

Öncelikle girdi-çıktı modelinde bunun pratikte nasıl göründüğünü görelim. İki düğümün bir işlemin geçerli olup olmadığı konusunda farklı bir görüşü varsa, biri o işlemi içeren bir bloğu kabul edecek ve diğeri kabul etmeyecektir. Her blok açıkça bir önceki bloğa geri bağlandığından, bu, ağda kalıcı bir "çatal" oluşturacak ve bir veya daha fazla düğüm, o andan itibaren tüm blok zincirinin içeriği hakkında çoğunluk görüşünü kabul etmeyecektir. Azınlıktaki düğümler, veritabanının gelişen durumundan kesilecek ve artık uygulamayı etkili bir şekilde kullanamayacak.

Şimdi sözleşme-mesaj modelinde fikir birliği bozulursa ne olacağını görelim. İki düğümün bir sözleşmenin belirli bir mesaja nasıl yanıt vermesi gerektiği konusunda farklı bir görüşü varsa, bu, veritabanlarının içeriklerinde bir farklılığa yol açabilir. Bu da, sözleşmenin diğer sözleşmelere gönderdiği mesajlar da dahil olmak üzere gelecekteki mesajlara yanıtını etkileyebilir. Nihai sonuç, farklı düğümlerin veritabanının durumuna bakış açısı arasında giderek artan bir farklılaşmadır. (Ethereum bloklarındaki "durum kökü" alanı, sözleşmelerin yanıtlarındaki herhangi bir farkın, bir süre gizli kalma riskinden ziyade, derhal tamamen felaket bir blok zincir çatallamasına yol açmasını sağlar.)

Belirsizliğin kaynakları

Dolayısıyla, blockchain kodundaki non-determinizm açıkça bir problemdir. Fakat eğer hesaplamanın aritmetik gibi temel yapı taşları deterministik ise, neyi düşünmemiz gerekir? Görünüşe göre birkaç şey var:

• En açık olanı, rastgele sayı üreteçleri, çünkü tanım gereği bunlar her seferinde farklı bir sonuç üretmek üzere tasarlanmıştır.
• Geçerli saati kontrol etme, çünkü düğümler işlemleri tam olarak aynı anda işlemez ve her durumda saatleri senkronize olmayabilir. (Blok zinciri içindeki zaman damgalarına referans vererek zamana bağlı kuralları uygulamak hala mümkündür.)
• İnternet, disk dosyaları veya bilgisayarda çalışan diğer programlar gibi harici kaynakları sorgulama. Bu kaynakların her zaman aynı yanıtı vereceği garanti edilemez ve kullanılamaz hale gelebilir.
• Birden çok kod parçasını paralel "iş parçacıkları" içinde çalıştırmak, çünkü bu işlemlerin biteceği sıranın tahmin edilemediği bir "yarış durumuna" yol açar.
• Farklı bilgisayar işlemci mimarilerinde çok az farklı yanıtlar verebilen herhangi bir kayan nokta hesaplamasının yapılması.

Dört blok zinciri platformumuz, bu tuzaklardan kaçınmak için birkaç farklı yaklaşım kullanır.

Deterministik yürütme

Yaklaşımı en "saf" olduğu için Ethereum ile başlayalım. Ethereum sözleşmeleri, Ethereum Sanal Makinesi ("EVM") tarafından yürütülen "Ethereum bayt kodu" adı verilen özel amaçlı bir formatta ifade edilir. Programcılar bayt kodunu doğrudan yazmazlar, bunun yerine Solidity adı verilen JavaScript benzeri bir programlama dilinden onu oluşturur veya "derler". (Diğer diller önceden mevcuttu, ancak o zamandan beri kullanımdan kaldırıldı.) Determinizm, Solidity ve Ethereum bayt kodunun deterministik olmayan işlemleri kodlayamamasıyla garanti edilir - bu kadar basit.

MultiChain filtreleri ve Corda sözleşmeleri, mevcut programlama dillerini ve çalışma zamanı ortamlarını uyarlayarak farklı bir yaklaşım seçer. MultiChain, Google'ın V8 Ayrıca, Chrome tarayıcısının ve Node.js platformunun çekirdeğini oluşturan, ancak determinizm dışı kaynakların devre dışı bırakıldığı motor. Benzer şekilde Corda, Java veya Kotlinher ikisi de bir Java Sanal Makinesi ("JVM") içinde çalışan "Java bayt kodu" olarak derlenir. Corda şimdilik Oracle'ın standart deterministik olmayan JVM'sini kullanıyor, ancak aşağıdakileri entegre etmek için çalışmalar sürüyor: deterministik versiyon. Bu arada, Corda sözleşme geliştiricileri kodlarında determinizm olmamasına dikkat etmelidir.

Ethereum'un saflığı, MultiChain ve Corda tarafından benimsenen evrimsel yaklaşımla nasıl karşılaştırılır? Ethereum'un ana avantajı risk minimizasyonudur - amaca yönelik oluşturulmuş bir sanal makinenin kasıtsız bir determinizm kaynağı içermesi daha az olasıdır. Böyle bir gözetim, bir yazılım güncellemesiyle giderilebilirken, onunla karşılaşacak kadar şanssız olan herhangi bir zincir için yıkıcı olacaktır. Bununla birlikte Ethereum'un sorunu, Solidity ve EVM'nin daha geniş programlama dilleri ve çalışma zamanı ortamları bağlamında küçük ve gelişmekte olan bir ekosistem oluşturmasıdır. Karşılaştırıldığında, JavaScript ve Java, Github'da en iyi iki dil, milyarlarca dijital cihazda çalıştırın ve onlarca yıldır optimize edilmiş çalışma zamanlarına sahip olun. Muhtemelen bu, halka açık Ethereum blok zincirinin eWASM, ortaya çıkan WebAssembly standardının belirleyici bir çatalı.

Onay yoluyla determinizm

Belirleyicilik söz konusu olduğunda, Hyperledger Fabric tamamen farklı bir yaklaşım benimser. Fabric'te, bir "istemci" düğümü bir zincir koduna bir mesaj göndermek istediğinde, önce bu mesajı bazı "onaylayan" düğümlere gönderir. Bu düğümlerin her biri zincir kodunu bağımsız olarak yürütür ve mesajın Efekt bu zincir kodunun veritabanında. Bu görüşler müşteriye resmi bir “onay” oluşturan dijital bir imza ile birlikte geri gönderilir. Müşteri, amaçlanan sonuç için yeterli onay alırsa, bu onayları içeren bir işlem oluşturur ve bunu zincire dahil edilmek üzere yayınlar.

Belirleyiciliği garanti etmek için, her zincir kod parçasının, işlemlerini geçerli kılmak için tam olarak hangi düzeyde onay gerektiğini tanımlayan bir "onay politikası" vardır. Örneğin, bir zincir kodunun politikası, blok zinciri düğümlerinin en az yarısından onayların gerekli olduğunu belirtebilir. Bir diğeri, üç güvenilir tarafın herhangi birinin onayını gerektirebilir. Her iki durumda da, her düğüm gerekli onayların alınıp alınmadığını bağımsız olarak kontrol edebilir.

Farkı açıklığa kavuşturmak için, çoğu blockchain platformundaki determinizm şu soruyu temel alır: "Bu kodu bu veriler üzerinde çalıştırmanın sonucu nedir?" - ve her düğümün bu soruyu aynı şekilde yanıtlayacağından kesinlikle emin olmalıyız. Buna karşılık, Fabric'teki determinizm farklı bir soruya dayanır: "Yeterli sayıda destekçi bu kodu bu veriler üzerinde çalıştırmanın sonucu üzerinde hemfikir mi?" Buna cevap vermek oldukça basit bir sayma meselesidir ve non-determinizmin içeriye girmesi için yer yoktur.

Fabric'in belirleyiciliğinin onaylanmasının bir dizi ilginç sonucu vardır. İlk olarak, zincir kod birçok farklı programlama dilinde yazılabilir, çünkü bunların determinizm için uyarlanması gerekmez (Go, Java ve JavaScript şu anda desteklenmektedir). İkincisi, zincir kodu bir blok zincirinin bazı katılımcılarından gizlenebilir, çünkü yalnızca müşteriler ve destekçiler tarafından yürütülmesi gerekir (veritabanının kendisi küresel olarak görünür). Son olarak ve en önemlisi, Fabric chaincode, çevrimiçi bir web API kullanarak hava durumunu kontrol etmek gibi diğer blockchain ortamlarında yasak olan şeyleri yapabilir. En kötü durumda, her destekleyicinin bu API'den farklı bir yanıt aldığı durumlarda, müşteri belirli bir sonuç için yeterli onay alamaz ve hiçbir işlem gerçekleşmez. (Kumaş ekip üyelerinin hala tavsiye etmek sürprizlerden kaçınmak için chaincode içinde deterministik mantığı kullanmak.)

Fabric bu esneklik için hangi bedeli öder? Bir blok zincirinin amacı, aracıları paylaşılan bir veritabanı odaklı uygulamadan kaldırmaksa, Fabric'in destekleyicilere olan güveni bu hedeften büyük bir adım uzaklaşır. Zincirdeki katılımcılar için, zincir kodunun kurallarını takip etmek artık yeterli değildir - aynı zamanda bunu yaptıklarını kabul etmek için bazı diğer düğümlere de ihtiyaçları vardır. Daha da kötüsü, kötü niyetli bir destekleyici alt kümesi, zincir kodunu hiç takip etmeyen veritabanı değişikliklerini onaylayabilir. Bu, destekleyicilere, işlemleri sansürleyebilen ancak blok zinciri kurallarını ihlal edemeyen normal blok zincirlerindeki doğrulayıcılardan çok daha fazla güç sağlar. Blockchain uygulama geliştiricileri, bu değiş tokuşun kendi özel durumlarında mantıklı olup olmadığına karar vermelidir.

Determinizm	Kumaş	Çoklu Zincir	Ethereum	Halat
Model	Cirolar	Uyarlanmış çalışma zamanı	Amaca yönelik oluşturulmuş sanal makine	Uyarlanmış çalışma zamanı
Diller	Git + Java + JavaScript	JavaScript	katılık	Java + Kotlin
Kod görünürlüğü	Karşı taraflar + cirolar	Blockchain	Blockchain	Karşı taraflar + bakmakla yükümlü
zorunlu	Yok hayır	Evet	Evet	Şimdilik hayır)

Çatışmaların önlenmesi

Şimdiye kadar, farklı blok zinciri platformlarının işlem kurallarını kodda nasıl ifade ettiklerini ve her düğümün bu kuralları aynı şekilde uyguladıklarını belirleyici olarak nasıl sağladıklarını tartıştık. Şimdi, hesaplaşmamızın üçüncü bir yönünden bahsetme zamanı: Her platform, kendi içinde geçerli olan iki işlemin birbiriyle çatışması olasılığını nasıl ele alıyor? En basit örnekte, Alice'in bir mali defterde 10 $ 'ı olduğunu ve biri Bob'a 8 $, diğeri Charlie'ye 7 $ göndermek olmak üzere iki işlem yayınladığını hayal edin. Açıkça, bu işlemlerden yalnızca birinin başarılı olmasına izin verilebilir.

İki model

MultiChain'in ve Corda'nın bu soruna yaklaşımını birlikte gruplayarak başlayabiliriz. Daha önce açıklandığı gibi, bunların her ikisi de işlemleri ve bunların kurallarını temsil etmek için bir girdi-çıktı modeli kullanır; burada her işlem girdisi bir önceki işlem çıktısını harcar. Bu, çatışmaları önlemek için basit bir ilkeye götürür: Her çıktı yalnızca bir kez harcanabilir. MultiChain filtreleri ve Corda sözleşmeleri, bu kısıtlamayı kesinlikle uygulamak için kendi platformlarına güvenebilir. Alice'in 10 doları önceki bir işlem çıktısı ile temsil edildiğinden, bu tek harcama kuralı onu hem Bob'a hem de Charlie'ye göndermesini otomatik olarak durdurur.

Bu benzerliğe rağmen, MultiChain ve Corda'nın çatışmaları nasıl önlediğine dair önemli bir farka işaret etmek önemlidir. MultiChain'de her düğüm her işlemi görür ve böylece her çıktının yalnızca bir kez harcandığını bağımsız olarak doğrulayabilir. Önceden onaylanmış bir işleme karşı çift harcama yapan herhangi bir işlem anında ve otomatik olarak reddedilecektir. Bunun aksine, Corda'da küresel bir blockchain yoktur, bu nedenle bu çifte harcamaları önlemek için "noterler" gereklidir. Her Corda çıktı durumu, daha önce harcanmadığını onaylayarak, bu çıktıyla ilgili herhangi bir işlem harcaması imzalaması gereken bir notere atanır. Bir blok zincirinin katılımcıları, bu kuralı dürüstçe takip edecekleri için noterlere güvenmelidir ve kötü niyetli noterler, istediği zaman hasara neden olabilir. Fabric'teki onaylarda olduğu gibi bu "hizmet olarak tek harcama"Tasarımın gizlilik açısından avantajları vardır, ancak blok zincirine aykırı hareket ederek aracıları yeniden devreye sokar. (Corda noterlerinin bir fikir birliği algoritması kullanan katılımcı grupları tarafından çalıştırılabileceğini açıklığa kavuşturmak önemlidir, böylece defterin bütünlüğü bireysel kötü aktörlere karşı korunabilir).

Ethereum'a geçelim. Hatırlamak gerekirse, Ethereum girdiler ve çıktılar yerine sözleşmeler ve mesajlar kullanır. Sonuç olarak, Alice'in iki ödemesi gibi işlem çatışmaları blok zinciri motoru tarafından hemen görülemez. Bunun yerine, tarafından algılanır ve engellenirler sözleşme siparişleri zincirde onaylandıktan sonra işlemleri işleyen. Alice'in her bir ödemesini işlerken, sözleşme bakiyesinin yeterli olup olmadığını doğrular. Bob'a 8 dolar ödeyen işlem önce gelirse, her zamanki gibi işlenecek ve Alice'in hesabında 2 dolar kalacaktır. Sonuç olarak, sözleşme Charlie'ye 7 dolar ödeyen ikinci işlemi gerçekleştirdiğinde, Alice'in gerekli fonlardan yoksun olduğunu görür ve işlem iptal edilir.

Çıktılar ve sözleşmeler

Şimdiye kadar, çelişen işlemleri önlemek için iki farklı teknik gördük - MultiChain ve Corda'da tek harcama çıktıları ve Ethereum'da sözleşmeye dayalı doğrulama. Peki hangisi daha iyi?

Bu soruyu yanıtlamaya yardımcı olması için, Gavin ve Helen adına 1 ABD doları tutan ve ikisinin de bu parayı bağımsız olarak harcamasına izin veren bir "2'e 100 çoklu imzalı" hesabı ele alalım. Gavin, başvurusuna Donna'ya 80 dolar ödemesini söyler ve birkaç saniye sonra Helen, Edward'a 40 dolar göndermek ister. Her iki ödeme için de yeterli para olmadığından, bu işlemler kaçınılmaz olarak çatışacaktır. Her iki işlemin de yayınlanması durumunda, sonuç zincire ilk giren kişi tarafından belirlenir. Alice'in örneğinden farklı olarak, bu çatışmanın kazara, hiç kimse uygulamanın kurallarını çiğnemeye çalışmadığı için - sadece şanssız bir zamanlamaları vardı.

Bu çatışmanın gerçekleşme olasılığını göz önüne alırken, anahtar soru şudur: Gavin işlemini gönderdikten sonra, Helen'in düğümünün ödemesinin başarısız olabileceğini bilmesi ne kadar sürer? Bu süre ne kadar kısaysa, Helen'in bu ödemeye teşebbüs etmesini durdurma olasılığı o kadar artar ve kendisini ve başvurusunu müteakip bir sürprizden kurtarır.

Girdi-çıktı modeliyle, iki işlem açıkça aynı önceki çıktıyı harcamaya çalışacağından, işlemler arasındaki herhangi bir çelişki doğrudan blok zinciri platformu tarafından görülebilir. MultiChain'de bu, Gavin'in işlemi Helen'in düğümüne yayılır yayılmaz, genellikle bir saniye veya daha kısa sürede gerçekleşir. Corda'da, çıktının noteri, Helen'in işleminin imzalanması talebini reddedecektir, çünkü zaten Gavin'in imzasını atmıştır, böylece Helen, ödemesinin başarısız olacağını anında bilecektir. (Corda noterinin kendisi dağıtılmışsa da, cevap için birkaç saniye beklemesi gerekebilir.) Her iki durumda da, blok zincirinde bir işlemin onaylanmasını ve sipariş edilmesini beklemeye gerek yoktur.

Ethereum'un modeli ne olacak? Bu durumda, blockchain platformunun bir çatışmanın olacağını bilmesinin acil bir yolu yoktur. Helen'in düğümü, Gavin'in ağ üzerindeki işlemini görebilir, ancak bunun Helen'in kendi işlemini nasıl etkileyeceğini bilemez, çünkü bakış açısından bunlar aynı sözleşmeye gönderilen iki mesajdır. Muhtemelen on saniye sonra, blok zincirinde çakışan işlemlerin son sıralaması onaylandıktan sonra, Helen'in düğümü beklenen sonuç yerine gerçek olanı yeniden hesaplayacak ve uygulaması ekranını buna göre güncelleyecektir. Bu arada hem Gavin hem de Helen karanlıkta kalacak.

Ancak buradan, girdi-çıktı modelinin her zaman en iyi şekilde çalıştığı sonucuna varmamalıyız. Örnek senaryomuzdaki bir varyasyonu düşünün; burada hem Gavin hem de Helen'in 40 dolarlık orijinal bakiyeden tam olarak aynı anda daha küçük 100 dolarlık ödeme talep ettikleri. Girdi-çıktı modelinde bu işlemler, her ikisi de aynı veritabanı satırını 100 $ 'ı içeren harcadıklarından ve ödemelerden yalnızca biri başarılı olacağından, çakışabilirdi. Ancak Ethereum'da, hesap her ikisi için de yeterli fon içerdiğinden, son siparişlerine bakılmaksızın her iki işlem de başarıyla işlenir. Bu durumda Ethereum, Gavin'in ve Helen'in niyetlerini daha sadık bir şekilde yerine getiriyor.

Okuma-yazma setleri

Son olarak, onay temelli yaklaşımı bu iki tekniğin bir karışımı olan Fabric'ten bahsedelim. Daha önce açıklandığı gibi, bir Fabric "istemci" düğümü bir sözleşmeye bir mesaj göndermek istediğinde, önce bazı onaylayıcı düğümlerden bu mesajı kendi adına yürütmelerini ister. Onay veren düğümler bunu Ethereum'a benzer şekilde yapar - sözleşmeyi kendi yerel veritabanlarına karşı yürütür - ancak bu işlem hemen uygulanmak yerine gözlemlenir. Her bir onaylayıcı, okunacak ve yazılacak satır kümesini kaydeder, ayrıca bu satırların o andaki tam versiyonunu da not eder. Sürümlendirilmiş satırların bu "okuma-yazma kümesi", onayda açıkça belirtilir ve müşterinin yayınladığı işleme dahil edilir.

Fabric işlemleri arasındaki çatışmalar, zincirdeki siparişleri tamamlandıktan sonra çözülür. Her düğüm, her işlemi bağımsız olarak işler, onay politikalarını kontrol eder ve belirtilen veritabanı değişikliklerini uygular. Bununla birlikte, bir işlem, önceki bir işlemle zaten değiştirilmiş bir veritabanı satırı sürümünü okur veya yazarsa, bu ikinci işlem göz ardı edilir. Alice'in Bob ve Charlie'ye yaptığı çelişkili ödemelere geri dönmek için, bu işlemlerin her ikisi de Alice'in başladığı 10 $ 'ı içeren aynı satır versiyonunu okuyacak ve değiştirecektir. Böylece ikinci işlem güvenli ve otomatik olarak iptal edilecektir.

Fabric'in çatışma çözme yaklaşımı gayet iyi çalışıyor, ancak performans ve esneklik açısından önceki iki modelin en kötüsünü birleştiriyor. Onaylar işlemleri belirli okuma-yazma setlerine dönüştürdüğünden, Gavin ve Helen'in eşzamanlı ancak uyumlu 40 $ ödemeleri, Ethereum'un kaçındığı bir çatışmaya yol açacaktır. Ancak, ciro verenler, onaylanmamış işlemleri görmezden gelerek, blok zinciri tarafından onaylanan veritabanının en son sürümüne karşı sözleşmeler yürüttüğü için Fabric, girdi-çıktı modelinin hız avantajını elde etmez. Öyleyse, Helen ödemesini Gavin'den birkaç saniye sonra başlatırsa, ancak Gavin'in blok zincirinde onaylanmasından önce, Fabric saf bir girdi-çıktı modelinin kaçındığı çelişkili işlemler yaratacaktır.

Çatışmaların önlenmesi	Kumaş	Çoklu Zincir	Ethereum	Halat
Model	Okuma-yazma setleri	Tek harcama	Sözleşme kontrolleri	Tek harcama
Doğrulama	Bağımsız	Bağımsız	Bağımsız	Güvenilir noterler
hız	~ 10s (onay)	~ 1s (yayılma)	~ 10s (onay)	0 ~ 5s (noter)

Karmaşık bir seçim

Bu bölümde, Corda, Ethereum, Fabric ve MultiChain'in "akıllı sözleşmelerin" temel zorluklarını veya bir blok zincirine gömülü uygulama kodunu ele aldığı birçok farklı yolu gözden geçirdik. Ve her platformun üç temel sorumuza farklı cevapları vardır: İşlem kuralları nasıl temsil edilir? Kod belirleyici olarak nasıl yürütülür? Ve çatışmaları nasıl önleyeceğiz?

Peki akıllı sözleşme hesaplaşmamızın galibi kim? Basit bir cevabın olmadığı şimdiye kadar aşikar olmalı. Her platform, esneklik, basitlik, performans, aracılıktan çıkarma, güvenlik ve gizlilik arasında karmaşık çok yönlü bir değiş tokuşu temsil eder. Bu nedenle, belirli bir uygulama için platform seçimi, o uygulamanın güven modelinin, içerdiği işlem türlerinin ve olası çatışma modellerinin ayrıntılı bir şekilde anlaşılmasıyla başlamalıdır. Bu soruların yanıtlarını bilmeden önce belirli bir akıllı sözleşme çözümünü zorlayan birini bulursanız, kibarca ama kesin bir şekilde "daha akıllı" bir yaklaşım benimsemeleri konusunda ısrar etmenizi öneririm.

Lütfen herhangi bir yorum gönderin LinkedIn'de.