Dağıtılmış Uygulamalar Mimarisi: Arka Uç, Güvenlik ve Tasarım Kalıpları

Merkezi olmayan uygulamalar veya Uygulamalar, yüksek güvenlik ve güvenilirlik elde etmek için özel bir sistem tasarımı gerektirir. Bu makalede, çoğu EOS, Tron ve diğer merkezi olmayan veri platformları için geçerli olsa da, Ethereum'u birincil bir örnek olarak alan, merkezi olmayan uygulamalar için arka uç ve akıllı sözleşmelerin nasıl düzgün bir şekilde tasarlanıp uygulanacağına dair birkaç ana prensibi ele alacağım.

Makale özeti:

  • Özel endişeler güvenlik endişesi olmadan arka uçta nasıl saklanır
  • Akıllı sözleşmeler nasıl düzgün bir şekilde tasarlanır ve neyin “merkezsizleştirileceği”
  • Merkezileşmemiş ve yarı merkezileşmiş uygulamalar mimarisi örnekleri
  • Ağ yükü ve arızaları gibi düşük seviyeli işlerle nasıl başa çıkılır?

Büyük olacak, hadi yapalım!

Merkezi Olmayan Programlar ve Blockchain

Blockchain bugün çok fazla evlat edinme ve düzenleme zorluğu ile karşı karşıya kalmasına rağmen, algoritması ne olursa olsun, blockchain, hashgraph, tempo veya diğer herhangi bir dağıtılmış muhasebe teknolojisinin gelip gelmeyeceği konusunda burada kalmak için bir tür teknolojidir.

Blockchain ve diğer benzer teknolojilerin getirdiği ana değer şu şekilde genelleştirilebilir: İnsanların yarattıktan sonra pratik olarak değiştirilemeyecek veya uygulama sırasında değiştirilemeyecek programlar yazmasına ve çalıştırmasına izin verir. Başka bir deyişle, bu programlar her zaman tasarlandığı gibi çalışır ve hiçbir taraf davranışlarını etkileyemez.

Bu tanım, bugün madeni paraların nasıl ileri geri transfer edilebileceğini tanımlayan programlar olarak kabul edersek, bugün varolan birçok şifreleme için geçerlidir. Bu aynı zamanda kripto para birimlerinin ve birçok farklı jetonun neden gerçek değere sahip olduğunu açıklar: tanımlanmış “temel programları” ile ince havadan üretilemezler.

Ethereum / EOS / Tron /… platformları, Bitcoin’in aksine daha karmaşık bir program katmanı uygular, bu da yürütme ortamını uygulayarak herkesin kendi ademi merkeziyetçi programlarını platformun üzerine yazmasına izin verir. Bu kullanıcı tanımlı programlar, istisnasız olarak her zaman tasarlandığı gibi çalışır ve güvenlikleri platform tarafından garanti edilir.

Merkezi Olmayan Uygulamalar

Merkezi olmayan bir ağda çalışan geleneksel ön ve arka uç teknolojileriyle birlikte çalışan bu güvenli ve değişmez programlar, bugün merkezi olmayan uygulamalar (ppUygulamalar) olarak adlandırdığımız şeydir. Bunlardan bazıları yarı merkezileştirilebilir, gerçekten merkezi olmayan uygulamadaki faaliyetlerin büyük bir kısmı merkezi bir tarafın kontrolünde gerçekleşmelidir.

Birisi benden DApp’ların nasıl çalıştığını çizmemi istedi, muhtemelen bunu çizerdim

Bugün ademi merkeziyetçi uygulamalar dediğimiz şeyi hayal etmek için, _YouTube_ veya _Instagram_ gibi mevcut herhangi bir merkezi web kaynağını örnek olarak alın ve parola korumalı bir merkezi hesap yerine "kripto kimliğinizin" web / mobil kaynağa bağlı olduğunuzu hayal edin.

Bu, Cüzdan Yazılımının size sağladığı şeydir. Bu kimliğin özel anahtarı (bu kimlik adına hareket edebileceğiniz bir sır) yerel cihazınızda depolanır ve asla çevrimiçi olmaz; bu kimliği sizin kontrol etmenizi mümkün kılmaz. Bu kimlikle, web sitesini kullanarak hem merkezi (merkezi bir otorite tarafından kontrol edilen web kaynağı) hem de merkezi olmayan (merkezi bir makamı ortadan kaldırmak olan geleneksel www'den farklı bir ağ olan) ağda farklı eylemler gerçekleştirebilirsiniz. bir erişim noktası ve / veya grafiksel bir kullanıcı arayüzü olarak. Bu "kripto kimliğinin" amacı, eylemlerinizin kriptografik olarak güvence altına alındığı ve hiç kimsenin imzaladığınız şeyi veya imzanızı değiştiremediğidir.

Günümüzde, Ethereum, EOS veya Tron gibi hataya dayanıklı, merkezi olmayan ağların hesaplama ve depolama yetenekleri sınırlıdır. Ölçeklenebilir olsaydı, grafiksel kullanıcı arayüzü, veri ve iş mantığı dahil tüm yerelleştirilmiş uygulamayı depolamak için merkezi olmayan ağları kullanabilirdik. Bu durumda, bu uygulamaları gerçekten merkezi olmayan / dağıtılmış olarak adlandırırız.

Ancak, bu ağlar bugün ölçeklendirilemediğinden, uygulamalarımız için maksimum yerelleşme seviyesine ulaşmak için farklı yaklaşımları birleştiriyoruz. “Geleneksel” olan arka uç, bildiğimiz gibi hiçbir yere gitmiyor. Örneğin:

  • Merkezi olmayan bir uygulama için ön ucu barındırmak için arka ucu kullanıyoruz.
  • Var olan diğer teknolojiler ve hizmetler ile entegrasyon için arka ucu kullanıyoruz. Gerçek, dünya standartlarında uygulamalar yalıtılmış bir ortamda yaşayamaz.
  • Merkezi olmayan bir ağ için (özellikle blockchain) yeterince büyük olan her şeyi depolamak ve işlemek için arka ucu kullanıyoruz. Pratik olarak, tüm uygulama ve iş mantığı, yalnızca blok zinciri kısmı hariç, dünyanın herhangi bir yerinde saklanır. IPFS ve benzeri depolama katmanları, dosyaların erişilebilirliğini garanti edemez, bu nedenle dosyaları kendimiz barındırmadan onlara güvenemeyiz. Başka bir deyişle, çalışan özel bir sunucuya her zaman ihtiyaç vardır.

Bugün itibariyle sağlam bir arka uç kullanmadan güvenli ve kısmen merkezi olmayan bir uygulama oluşturmanın yolu yoktur ve bu makalenin amacı bu hakkın nasıl yapılacağını açıklamaktır.

(De) merkezileşme ve Belirteçler

Bu yüzden, bugün hemen hemen tüm ademi merkeziyetçi uygulamaların, özel ademi merkeziyetçi bir uygulamayı yönlendiren özel yapım (ya da sadece basitçe klonlanmış) şifreler etrafında oluşturulduğu anlaşılmaktadır. Jetonlar basitçe programlanabilir bir para birimi veya varlıktır, o kadar.

Belirteç akıllı sözleşmeleri, kullanıcıların belirteçleri nasıl transfer edebileceğini belirlerken, uygulama akıllı sözleşmeleri, belirteç akıllı sözleşmelerinde eksik olan her şeyi uzatabilir. Her iki akıllı sözleşme de merkezi olmayan ağların üzerinde çalışıyor

Genellikle, bir belirteç, Ethereum gibi merkezi olmayan bir platformun üzerine yazılmış “akıllı bir sözleşmedir” (özel bir program). Bazı jetonlara sahip olarak, temel olarak bir web kaynağında veya mobil uygulamada farklı hizmetler alabilir ve bu jetonu başka bir şey için takas edebilirsiniz. Buradaki kilit nokta, jetonun kendi başına yaşadığı ve merkezi bir otorite tarafından kontrol edilmediğidir.

Belirteçler etrafında oluşturulan birçok uygulama örneği vardır: CryptoKitties (ERC721 belirteçleri) gibi çok sayıdaki tahsilli oyunlardan LOOM Network gibi hizmet odaklı uygulamalara ve hatta DreamTeam (ERC20 uyumlu belirteçler) gibi Brave ve oyun platformları gibi tarayıcılara kadar.

Geliştiriciler kendi uygulamaları üzerinde ne kadar kontrole sahip olacaklarına (veya olmayacaklarına) karar verecek ve karar vereceklerdir. Tüm uygulamanın iş mantığını akıllı sözleşmelerin üstüne kurabilirler (CryptoKitties'in yaptığı gibi) veya akıllı sözleşmelerden hiçbir şekilde faydalanamazlar, sunucularındaki her şeyi merkezileştirirler. Bununla birlikte, en iyi yaklaşım ortada bir yerdedir.

Merkezi Olmayan Ağlar İçin Arka Uç

Teknik açıdan, belirteçleri ve diğer akıllı sözleşmeleri web / mobil uygulamalarla birleştiren bir köprü bulunmalıdır.

Müşterilerin doğrudan akıllı sözleşmelerle etkileşime girdiği günümüzün tamamen merkezi olmayan uygulamalarında bu köprü, Infura gibi halka açık API'lerin veya düğüm havuzlarının JSON RPC API yeteneklerine daralmıştır; kendi bireysel ağ düğümünü çalıştırın ve destekleyin. Bununla birlikte, bu API, basit sorgulamalar yapmaya ya da verimli bir şekilde veri toplamalarına olanak tanıyan yalnızca temel ve çok dar bir işlevler kümesi sağlar. Bu nedenle, sonunda, özel arka uç devreye girerek, uygulamayı yarı merkezileştirmiştir.

Merkezi olmayan ağla olan bütün etkileşim, uygulama ihtiyaçlarına bağlı olarak yalnızca bir veya iki noktaya daraltılabilir:

  1. Ağ olaylarını dinleme (simge aktarımı gibi) / ağ durumunu okuma.
  2. Yayıncılık işlemleri (token transferi gibi durum değiştiren akıllı sözleşme işlevlerini çağırmak).

Bu noktaların her ikisini de uygulamak oldukça zor, özellikle de güvenli ve güvenilir bir arka uç çözümü oluşturmak istiyorsak. Aşağıda, yıkacağımız ana noktalar şunlardır:

  • Her şeyden önce, Ethereum'da, olayların alınması kutunun dışında üretime hazır değildir. Çok sayıda nedenden dolayı: çok sayıda olay alınırken ağ düğümleri başarısız olabilir, ağ çatalları vb. Nedeniyle olaylar kaybolabilir veya değişebilir. Olayları ağdan senkronize etmek ve güvenilir teslimatlarını garanti etmek için bir soyutlama katmanı oluşturmak zorundayız.
  • Aynı şekilde işlem yayıncılığı için, Ethereum’un sayısız sayaç ve gaz tahminleri gibi düşük seviyeli şeyleri soyutlamalıyız. Ayrıca, işlem yayıncılığı, gelişmiş arka uç güvenliği gerektiren özel anahtarların kullanılmasını gerektirir.
  • Güvenlik. Bunu ciddiye alacağız ve özel anahtarların arka uçta tehlikeye girmeyeceğini garanti etmenin imkansız olduğunu göreceğiz. Neyse ki, arka uç hesapların güvenliğinin yüksek olmasına gerek kalmadan merkezi olmayan bir uygulama tasarlama yaklaşımı var.

Bizim uygulamada, tüm bunlar Ethereum Gateway adını verdiğimiz Ethereum için sağlam bir arka uç çözümü yarattı. Ethereum’ün eğlencesinden diğer mikro servisleri de soyutlar ve çalışmak için güvenilir bir API sağlar.

Hızla büyüyen bir başlangıç ​​olarak, açık bir nedenden ötürü (henüz henüz) tam çözümü açıklayamıyoruz, ancak merkezi olmayan uygulamanızın kusursuz çalışmasını sağlamak için bilmeniz gereken her şeyi paylaşacağım. Bununla birlikte, belirli bir sorunuz veya sorunuz varsa, benimle temas kurmaktan çekinmeyin. Bu yazıya yapılan yorumlar da çok beğeniliyor!

Ethereum için Arka Uç İzleme. Monitör, temelde yinelenen faturalandırma özelliğimizle ilgili etkinlikleri gösterir (her saat başı zirveleri görebilseniz de).

Dağıtılmış Uygulamalar Mimarisi

Makalenin bu bölümü yüksek oranda belirli bir ademi merkeziyetçi uygulamanın gereksinimlerine bağlıdır, ancak bu uygulamaların üzerine kurulu bazı temel etkileşim kalıplarını çözmeye çalışacağız (latformPlatform = Ademi Merkeziyetçi Platform = Ethereum / EOS / Tron / Neyse):

Müşteri Ð latformPlatform: tamamen merkezi olmayan uygulamalar.

Müşteri (tarayıcı ya da mobil uygulama), ademi merkeziyetçi platformla doğrudan Metamask, Trust ya da Trezor ya da Ledger gibi donanım cüzdanları gibi Ethereum “cüzdan” yazılımıyla konuşuyor. Bu şekilde inşa edilen DApp örnekleri, CryptoKitties, Loom’un Temsilci Çağrısı, crypto cüzdanlarının kendilerini (Metamask, Trust, Tron Wallet, diğerleri), Etherdelta ve benzeri ademi merkeziyetçi şifreli alışverişidir.

ÐPlatform ⬌ Müşteri ⬌ Arka Uç ⬌ latformPlatform: merkezi veya yarı merkezi uygulamalar.

Merkezi olmayan platform ve sunucu ile müşteri etkileşimi çok az ortak noktaya sahiptir. Buna iyi bir örnek, BitFinex veya Poloniex gibi bugün (herhangi bir merkezi) kripto değişimidir: borsasında işlem yaptığınız para birimleri geleneksel veri tabanına kaydedilir. Varlıkları belirli bir adrese (ÐPlatform ⬌ Müşteri) göndererek veritabanı bakiyenizi "artırabilir" ve uygulamadaki bazı işlemlerden sonra (Var Son ⬌ ÐPlatform) varlıkları geri çekebilirsiniz, ancak "ÐApp" olarak yaptığınız her şeyi kendisi (Client ⬌ Back End), ÐPlatform ile doğrudan etkileşiminiz anlamına gelmez.

Başka bir örnek de, yarı-merkezileştirilmiş yaklaşımı kullanan Etherscan.io'dur: burada tüm merkezi-merkezi olmayan eylemleri yapabilirsiniz, ancak uygulamanın kendisi kapsamlı bir arka sonu olmadan mantıklı değildir (Etherscan sürekli olarak işlemleri senkronize eder, verileri ayrıştırır ve saklar, sonuçta kapsamlı bir API / UI sağlamak).

Arada bir şey: hala, merkezi veya yarı merkezi uygulamalar.

Yukarıdaki yaklaşımlar birleştirildi. Örneğin, kripto karşılığında çeşitli hizmetler sunan ve kripto kimliğinizle giriş yapıp bilgileri imzalamanıza izin veren bir uygulamaya sahip olabiliriz.

Umarım, tamamen merkezi olmayan uygulamaların etkileşim paterni (Müşteri the patternPlatform) herhangi bir soru sormaz. Infura veya Trongrid gibi inanılmaz hizmetlere güvenerek, hiç bir sunucu gerektirmeyen bir uygulama oluşturabilirsiniz. Hemen hemen tüm Ethereum için Ethers.js veya Tron için Tron-Web gibi istemci tarafı kütüphaneler bu kamu hizmetlerine bağlanabilir ve ağ ile iletişim kurabilir. Ancak, daha karmaşık sorgular ve görevler için yine de kendi sunucunuzu ayırmanız gerekebilir.

Arka ucu içeren etkileşim modellerinin geri kalanı işleri daha ilginç ve karmaşık hale getirir. Bunları bir resme koymak için, arka ucumuzun ağdaki bazı olaylara tepki verdiği bir durum düşünelim. Örneğin, kullanıcı bize tahsilat yapma izni veren bir tahsis işlemi yayınlar. Bir ödeme yapmak için, gönderilen harcırah olayına yanıt olarak ödeme işlemini yayınlamamız gerekir:

Sunucunun dağıtılmış ağdaki kullanıcının eylemine verdiği tepkiyle ilgili örnek bir akış

Arka uç bakış açısıyla, burada ne oluyor:

  1. Ağı sürekli olarak sorgulayarak belirli bir ağ olayını dinleriz.
  2. Bir etkinlik gerçekleştikten sonra, bazı iş mantıkları uygularız ve ardından yanıt olarak bir işlem yayınlamaya karar veririz.
  3. İşlemi yayınlamadan önce, büyük olasılıkla mayınlı olmasını sağlamak istiyoruz (Ethereum'da başarılı işlem gazı tahmini, mevcut ağ durumuna karşı hiçbir hata olmadığı anlamına gelir). Ancak, işlemin başarıyla mayınlanacağını garanti edemeyiz.
  4. Özel bir anahtar kullanarak işlemi imzalayıp yayınlarız. Ethereum'da ayrıca işlemin gaz fiyatını ve gaz limitini de belirlemeliyiz.
  5. İşlemi yayınladıktan sonra, durumu sürekli olarak ağı araştırıyoruz.
  6. Çok uzun sürerse ve işlemin durumunu alamıyorsak, yeniden yayınlamamız veya “başarısızlık senaryosunu” tetiklememiz gerekir. İşlemler çeşitli nedenlerle kaybedilebilir: ağ tıkanıklığı, düşme eşleri, ağ yükü artışı, vb. Ethereum'da bir işlemi farklı (gerçek) bir gaz fiyatı ile yeniden imzalamayı da düşünebilirsiniz.
  7. Nihayet işlemlerimizi tamamladıktan sonra, gerekirse daha fazla iş mantığı gerçekleştirebiliriz. Örneğin, diğer arka uç servislerini işlemin tamamlandığına dair bilgilendirebiliriz. Ayrıca, işlemle ilgili nihai kararları vermeden önce birkaç onay beklemeyi göz önünde bulundurun: ağ dağıtılır ve sonuç birkaç saniye içinde değişebilir.

Gördüğünüz gibi çok şey oluyor! Ancak, uygulamanız, neyi başarmaya çalıştığınıza bağlı olarak, bu adımlardan bazılarını gerektirmeyebilir. Ancak, sağlam ve sağlam bir arka uç oluşturmak, yukarıda belirtilen tüm sorunlara bir çözüm bulunmasını gerektirir. Bunu yıkalım.

Dağıtılmış Uygulamalar Back End

Burada, soruların çoğunda ortaya çıkan bazı noktaları vurgulamak istiyorum:

  • Ağ olaylarını dinlemek ve ağdan veri okumak
  • İşlemleri yayınlama ve güvenli bir şekilde yapma

Ağ Olaylarını Dinleme

Ethereum'da, diğer ademi merkeziyetçi ağlarda olduğu gibi, akıllı sözleşme olayları kavramı (veya olay kayıtları veya sadece kayıtlar) zincir dışı uygulamaların blok zincirinde neler olduğunun farkında olmalarını sağlar. Bu olaylar akıllı sözleşme geliştiricileri tarafından akıllı sözleşme kodunun herhangi bir noktasında oluşturulabilir.

Örneğin, iyi bilinen ERC20 belirteç standardı içerisinde her bir belirteç aktarımı, Transfer olayını kaydetmelidir, böylece zincir dışı uygulamaların bir belirteç aktarımı gerçekleştiğini bilmelerini sağlayın. Bu olayları “dinleyerek” herhangi bir (yeniden) eylem gerçekleştirebiliriz. Örneğin, bazı mobil şifreleme cüzdanları, belirteçler adresinize aktarıldığında size bir push / e-posta bildirimi gönderir.

Aslında, ağ olaylarını kutudan dinlemek için güvenilir bir çözüm yoktur. Farklı kütüphaneler olayları izlemenize / dinlemenize izin verir, ancak bir şeylerin yanlış gidebileceği, kaybedilen veya işlenmeyen olaylara neden olan birçok durum vardır. Olayları kaybetmemek için, olaylar senkronizasyon işlemini sürdürecek özel bir arka uç oluşturmak zorundayız.

Gereksinimlerinize bağlı olarak, uygulama değişebilir. Fakat sizi burada bir resme koymak, mikro hizmet mimarisi açısından güvenilir Ethereum olayları teslimatını nasıl sağlayabileceğinizin seçeneklerinden biridir:

Ethereum olaylarının tüm arka uç servislerine güvenilir bir şekilde ulaştırılması

Bu bileşenler aşağıdaki şekilde çalışır:

  1. Events senkronizasyonu arka uç servisi sürekli olarak ağı araştırır ve yeni olaylar almaya çalışır. Yeni etkinlikler mevcut olduğunda, bu olayları mesaj veriyoluna gönderir. Mesaj veriyoluna başarılı bir şekilde gönderildiğinde, blockchain için olduğu gibi, bir sonraki sefer bu bloktan yeni olaylar talep etmek için son etkinliğin bloğunu kaydedebiliriz. Aynı anda çok fazla olay almanın her zaman başarısız isteklerle sonuçlanabileceğini unutmayın; bu nedenle, ağdan talep ettiğiniz olayların / blokların sayısını sınırlamanız gerekir.
  2. Mesaj veriyolu (örneğin, Tavşan MQ) olayı, her arka uç hizmeti için ayrı ayrı ayarlanan her kuyruğa yönlendirir. Etkinlik yayınlamadan önce, etkinlik senkronizasyonu arka uç hizmeti, yönlendirme anahtarını (örneğin akıllı bir sözleşme adresi + etkinlik konusu) belirtirken, tüketiciler (diğer arka uç hizmetleri) yalnızca belirli etkinliklere abone olan sıralar oluşturur.

Sonuç olarak, her bir arka uç hizmeti yalnızca ihtiyaç duyduğu olayları alır. Dahası, mesaj veriyolu tüm olayların yayınlandıktan sonra teslim edilmesini garanti eder.

Elbette, mesaj yolu yerine başka bir şey kullanabilirsiniz: HTTP geri aramaları, soketleri, vb. Bu durumda, geri aramaları teslim etmenin nasıl garanti edileceğini çözmeniz gerekir: üstel / özel geri arama denemelerini yönetme, özel izleme ve yakında.

Yayın İşlemleri

Merkezi olmayan ağda bir işlem yayınlamak için gerçekleştirmemiz gereken birkaç adım vardır:

  1. İşlemi hazırlama İşlem verilerinin yanı sıra, bu adım, bu işlemin geçerli olup olmadığını ve mayınlı olacağını (Ethereum'da gaz tahmini) ve işlemin sıralı numarasını (Ethereum'da olmayan) bulmak için ağ durumunun talep edilmesini gerektirir. Kütüphanelerin bazıları bunu kaputun altında yapmaya çalışıyor, ancak bu adımlar önemlidir.
  2. İşlemin imzalanması. Bu adım, özel anahtarın kullanılması anlamına gelir. Büyük olasılıkla, burada özel özel anahtar montaj çözümünü (örneğin) gömmek isteyeceksiniz.
  3. İşlemin yayınlanması ve yeniden yayınlanması. Buradaki kilit noktalardan biri, yayınlanan işleminizin her zaman merkezi olmayan ağdan kaybolma ya da bırakılma şansına sahip olmasıdır. Örneğin, Ethereum'da, şebekenin gaz fiyatı aniden yükselirse yayınlanan işlem iptal edilebilir. Bu durumda, işlemi yeniden yayınlamanız gerekir. Ayrıca, işlemi en kısa zamanda mayınlı tutmak için diğer parametrelerle (en azından daha yüksek gaz fiyatı ile) yeniden yayınlamak isteyebilirsiniz. Bu nedenle, işlemin yeniden yayınlanması, değiştirme işleminin daha önce önceden imzalanmamış olması durumunda (farklı parametrelerle) yeniden imzalanması anlamına gelebilir.
Ethereum işlem yayıncılığına ilişkin yukarıdaki noktalar görselleştirildi

Yukarıdaki yaklaşımları kullanarak, aşağıdaki sıralama diyagramında gösterilene benzer bir şey inşa edebilirsiniz. Bu belirli dizi diyagramında (genel olarak!) Blok zincirinin yinelenen faturalandırmanın nasıl çalıştığını (bağlantılı bir makalede daha fazlası var) göstermektedir:

  1. Kullanıcı, sonunda sözleşmenin başarılı bir ödeme işlemi gerçekleştirmesini sağlayan akıllı sözleşmede bir işlev yürütür.
  2. Belirli bir görevden sorumlu olan bir arka uç servis, ücret ödeneği olayını dinler ve bir ücretlendirme işlemi yayınlar.
  3. Ücret işlemi kesildikten sonra, belirli bir görevden sorumlu olan bu arka uç servis Ethereum ağından bir etkinlik alır ve bir sonraki mantık tarihini ayarlamak da dahil olmak üzere bir miktar mantık gerçekleştirir.
Blok zinciri tekrarlayan faturalamanın nasıl çalıştığının genel sıra şeması, arka uç hizmetler ve Ethereum ağı arasındaki etkileşimi gösterir

Arka Uç Güvenlik ve Akıllı Sözleşmeler

İşlem yayıncılığı her zaman özel bir anahtar kullanmayı içerir. Özel anahtarları güvende tutmanın mümkün olup olmadığını merak ediyor olabilirsiniz. Evet, evet ve hayır. Özel anahtarların arka tarafta güvenli bir şekilde saklanmasını sağlayan çok sayıda karmaşık strateji ve farklı yazılım türleri vardır. Bazı özel anahtar depolama çözümleri coğrafi olarak dağıtılmış veritabanları kullanır, bazıları ise özel donanım kullanımını önerebilir. Bununla birlikte, herhangi bir durumda, yarı-merkezi bir uygulamanın en savunmasız noktası, özel anahtarın bir işlemi imzalamak için bir araya getirildiği ve kullanıldığı (veya özel donanım olması durumunda, bir işlem imzalama prosedürünü tetikleme noktası) olmasıdır. Dolayısıyla, teorik olarak, kurşun geçirmez korumanın saklanan özel anahtarlardan ödün vermemesine olanak sağlayacak% 100 güvenilir bir çözüm yoktur.

Şimdi böyle düşün. Çoğu durumda, arka taraftaki özel anahtarları o kadar sık ​​güvenceye almanıza gerek kalmaz. Bunun yerine, akıllı sözleşmeleri ve tüm uygulamayı, özel bir anahtar sızıntısının normal davranışlarını etkilemeyecek şekilde tasarlayabilirsiniz. Bu yaklaşımla, yetkili hesapların akıllı sözleşme ile nasıl etkileşime girdiği önemli değildir. Sadece normal işini yapmak için akıllı bir sözleşmeyi “tetikliyorlar” ve akıllı sözleşmenin kendisi de gerekli tüm onaylamaları gerçekleştiriyor. Ben buna “operasyonel hesap deseni” diyorum.

Arka uç hesaplarınız için askeri düzeyde güvenliğe ihtiyaç duymadığınız merkezi olmayan uygulamalar için operasyonel hesap deseni

Bu durumda, acil durumlarda:

  • Saldırganın çalabileceği tek şey işlem yayıncılığı için operasyonel hesaplara yatırılan küçük miktarda Ether (Ethereum'dan beri).
  • Saldırgan, akıllı sözleşme mantığına veya sürece dahil olan herhangi birine zarar veremez
  • Tehlikeli operasyonel hesaplar hızlı bir şekilde diğer hesaplarla hızlı bir şekilde değiştirilebilir, ancak bunun için manuel değiştirme (yeni hesaplar oluşturma ve tüm akıllı sözleşmelerdeki hesapları yeniden yetkilendirme) ya da tüm sihrleri bir süper işlemden tek bir işlemle yapacak ek bir çözüm geliştirmeyi gerektirir -secure (donanım veya çoklu imza) ana hesap.

Örneğin, Ethereum çözümü için yinelenen faturalandırmada, arka uçta ne olursa olsun, yinelenen fatura akıllı sözleşmesi, herhangi biri riske atılırsa, ödünç verilen hesapları değiştirmek için tam bir ay ayıracak şekilde tasarlanmıştır. .

Ancak, arka uç özel anahtar deponuzu olabildiğince güvenli bir şekilde almak istiyorsanız, EtherCare hesaplarını saklayan ve yöneten Ethereum için büyük bir eklentiyle Vault'u kullanmayı deneyebilirsiniz (ayrıca, açık kaynaklı modüllerimize göz atın - biz yakında benzer bir şey serbest bırakmak üzeresiniz). Bağlantılı projeleri ziyaret edip oradan kendiniz öğrenebilseniz de, burada ayrıntılara derinlemesine dalmayacağım.

Söylemem gereken tek şey bu değil. Ancak, bu makalenin beklediğimden çok daha uzun olduğu ortaya çıktı, bu yüzden durmam gerekiyor. Yazılım, kripto, seyahat önerileriyle ilgileniyorsanız veya sadece ilginç bir şeyi takip etmek istiyorsanız Orta / diğer ağlarıma abone olun. Umarım çok değerli bir bilgi vermişimdir ve faydalı bulursunuz. Bu yazıyı yorumlamaktan ve yaymaktan çekinmeyin!