Teknik kılavuz: işlem verilerinin depolanması
Amaçları
1. Defter verilerinin yapısını anlayın
2. Bloğun yapısını ve işlem verilerini anlayın
3. Defter verilerinin depolama sürecini anlayın
Görev yerine getirme
9.1.1 Blockchain defter verileri
Defter, düzenli ve kurcalamaya dayanıklı tüm işlem değişikliklerinin kayıtlarını tutar. Her işlem zinciri kodunun, dağıtılmış defterdeki veri değişikliklerini kaydetmesi gerekir Kaydedilmesi gereken verilere, anahtar-değer çiftleri (K-V) şeklinde depolanan durum denir.Hyperledger Fabric defteri iki farklı ancak ilişkili bölümden oluşur:
- Dünya Devleti
- Blockchain
Dünya durumu: Dünya durumu, aslında durumun depolanmasını ve geri alınmasını kolaylaştırmak için bir NoSQL veritabanıdır; bir grup defter durumunun en son değeri, anahtar-değer çiftleri biçiminde saklanır. Uygulamaların, tüm işlem günlüğünü geçmeden mevcut defterin en son değerini hızlı bir şekilde elde etmesini sağlar. Değeri basit bir değer olabilir veya anahtar / değer çiftlerinden oluşan bir dizi karmaşık veriden oluşabilir. Aşağıda gösterildiği gibi:
Yukarıdaki şekilde görebileceğiniz gibi, her dünya devletinin bir sürüm numarası vardır ve başlangıç sürüm numarasının değeri 0'dır. Durum her değiştirildiğinde, durumun sürüm numarası artar. Durum güncellendiğinde, işlemin oluşturulduğu andaki sürümle eşleştiğinden emin olmak için de kontrol edilir.
Blockchain: İşlem günlüklerini kaydeden bir dosya sistemidir.Karma değerlerle birbirine bağlanmış N bloktan oluşur; her blok bir dizi çoklu sıralı işlem içerir. Blok başlığı, bu blokta kaydedilen işlemin hash değerini ve önceki blok başlığının hash değerini içerir. Bu şekilde, defterdeki tüm işlemler sıralanır ve şifrelenmiş bir biçimde birbirine bağlanır. Başka bir deyişle, dağıtılmış bir ağda, hash zincirini kırmadan defter verilerini kurcalamak imkansızdır.
Yukarıdaki şekilde, B2 bloğunun tüm işlemlerini içeren D2 blok verisine sahip olduğunu görebiliriz: T5, T6, T7. En önemlisi, B2 bloğunun blok başlığı (H2), D2'deki tüm işlemlerin şifrelenmiş karmasını ve önceki bloğun (B1) eşdeğer karmasını içerir. Bu bağlantı yoluyla bloklar birbirleriyle ayrılmaz bir şekilde bağlanır.
Aşağıda blok ve borsanın ayrıntılı yapısını ayrıntılı olarak analiz ediyoruz.
Blok: Her blok üç bölümden oluşur
Yukarıdaki şekilde gösterildiği gibi, B2 bloğunun blok başlığı (H2), blok numarası (2), mevcut blok verilerinin (D2) karması (CH2) ve önceki bloktan (blok numarası 1) gelen karma (CH2) içerir. PH1) kopyalardan oluşur.
- Blok Başlığı: Blok başlığı, blok oluşturulduğunda yazılan üç alan içerir.
Blok numarası: 0'dan başlayan bir tamsayı Blok zincirine eklenen her yeni blok için, önceki değere bağlı olarak 1 artırılacaktır.
Mevcut Blok Karma: Mevcut blokta yer alan tüm işlemlerin hash değeri.
Önceki Blok Hash: Blok zincirindeki önceki bloğun hash kopyası.
Blok oluşturulduğunda yazılır ve sırayla bir dizi işlem içerir.
Bu bölüm, bloğun yazılma zamanının yanı sıra ilgili sertifika, genel anahtar ve imzayı içerir. Daha sonra, Block Committer her işlem için geçerli / geçersiz bir gösterge (bit maskesi olarak da adlandırılır) ekledi.
Artık bloğun yapısını anladığımıza göre, blok verilerindeki işlem yapısı nedir, işlemin / işlemin ayrıntılı yapısını daha iyi anlayalım.
İşlem: Bloktaki Blok Veriler, dünyanın durumundaki değişiklikleri kaydeden bir dizi işlemin ayrıntılı yapısını içerir.
Yukarıdaki şekilde gösterildiği gibi: B1 bloğunun blok verilerindeki (D1) işlem (T4), işlem başlığını (H4), işlem imzasını (S4), işlem teklifini (P4), işlem yanıtını (R4) ve onay listesini (E4) içerir. ).
Üstbilgi
Zincir kodunun adı ve sürümü gibi işlemle ilgili bazı temel meta verileri alın.
İşlem imzası (İmza)
Bu bölüm, istemci uygulamasının özel anahtarı kullanılarak oluşturulan kriptografik imzayı içerir. İşlem içeriğine müdahale edilip edilmediğini kontrol etmek için kullanılır.
Teklif
Çağrılacak zincir kodunun işlev adını, işlevi çağırmak için gerekli girdi parametrelerini ve zincir kodu, gönderilen işlem teklifine göre defteri günceller.
İşlem yanıtı (Yanıt)
Zincir kodu simülasyon çalıştırma çağrıldıktan sonra, dünya durumundan önceki ve sonraki değerler elde edilir ve bir okuma-yazma seti (RW-seti) olarak istemciye döndürülür.
Onay listesi (Onaylar)
İşlem yalnızca bir işlem yanıtı içerir, ancak gerekli onay stratejisini karşılamak için gerekli kuruluştan birden fazla onay imzası vardır.
9.1.2 Veri depolama
Blok zinciri dosyalar biçiminde saklanır. Varsayılan olarak, her blok dosyasının önüne blockfile_ eklenir ve bunu altı basamaklı bir ad izler ve başlangıç numarası varsayılan olarak 000000'dir.Yeni bir dosya varsa, her seferinde 1 artırılacaktır. Blok zinciri dosyalarının varsayılan depolama dizini şöyledir: / var / hyperledger / production / ledgersData / chains.Bu dizin iki alt dizin içerir: Blok zinciri dosyalarının depolandığı zincirler dizini (kanal dosyası dizini her bir Ledger'ı ayırt etmek için kullanılır ve her Peer düğümü onu ele alır. Ait olduğu her kanal, kanalın defterinin bir kopyasını kaydedecek ve index bilgilerini kaydeden bir dizin dizini uygulamak için levelDB'yi kullanacaktır. Dizin yapısı aşağıdaki gibidir:
Orderer düğümünün kendisi bir defter kaydeder, ancak Eş düğüm tarafından tutulan durum veritabanını ve geçmiş dizin verilerini içermez:
- Durum Veritabanı: İşlem günlüğündeki (Dünya Durumu) tüm anahtarların en son değerini depolar ve varsayılan veritabanı LevelDB kullanır. Zincir kodu çağrıları, işlemleri mevcut durum verilerine göre yürütür.
- Geçmiş Veritabanı: LevelDB veritabanı, bloktaki geçerli işlemlerle ilgili anahtarları depolamak için veri depolama taşıyıcısı olarak kullanılır, ancak değeri değil (veritabanı değerin boş olmasına izin vermez, bu nedenle aslında değer bayt {} 'dır).
dStore: Peer tarafından eklenen tüm ledgerIds (veya chainid / channelId) depolayın. Ve tüm dünyadaki defter numarasının benzersizliğini garanti edin. Varsayılan depolama dizini şudur: / var / hyperledger / production / ledgersData / ledgerProvider
Okuma-yazma seti
Simüle edilmiş işlem ve okuma-yazma seti
Simüle edilen işlem gerçekleştirildikten sonra, onaylayan düğüm (Endorser) bir okuma-yazma seti (Okuma-Yazma Seti) oluşturacaktır, okuma seti (Okuma Seti), işlemin simülasyon uygulaması sırasında okunan benzersiz anahtarı ve karşılık gelen gönderilen değeri ve bunun Sürümlerin bir listesini gönderin Yazma Seti, işlem tarafından yazılan benzersiz anahtarların ve yeni değerlerin bir listesini içerir. İşlem bir silme işlemi gerçekleştirirse, Yazma Setindeki anahtar için bir silme bayrağı ayarlayın. Bir işlemde aynı anahtar birden çok kez değiştirilirse, yalnızca son değiştirilen değer (yani en son değer) korunacaktır. Ek olarak, işlem belirtilen anahtarın değerini okursa, yalnızca gönderilen durum değeri döndürülür ve aynı işlemdeki değiştirilmiş ancak taahhüt edilmemiş değer okunamaz.
Yukarıda bahsedildiği gibi, anahtarın sürümü yalnızca Okuma Setine dahildir; Yazma Seti yalnızca anahtar listesini ve en son değerini içerir.
version, belirtilen anahtar için, onu temsil etmek için monoton olarak artan bir sayının kullanılması gibi çeşitli yollarla uygulanabilen benzersiz bir tanımlayıcı üretir. Mevcut uygulamada, blok zincirinin yüksekliğine göre ifade edilir, yani işlemin yüksekliği, değişim tarafından değiştirilen anahtarın versiyonu olarak kullanılır ve işlemin yüksekliği bir Sürüm yapısı ile temsil edilir (aşağıdaki Sürüm yapısına bakın), burada TxNum, bloktaki bu tx'in sayısını temsil eder. Bu çözümün artımlı seri numaralarına göre birçok avantajı vardır, çünkü bu çözüm, belirtilenb, simüle edilmiş işlemler ve işlem doğrulaması gibi modüllerde iyi bir şekilde kullanılabilir.
Ek olarak, işlem simülasyon sırasında bir aralık sorgusu yürütürse, aralık sorgusu ve sonucu, sorgu bilgisi ile temsil edilen okuma-yazma kümesine eklenecektir.
İşlem doğrulama ve dünya durumu güncellemesi
Commiter düğümü, işlemin geçerliliğini kontrol etmek için okuma-yazma setinin okuma seti kısmını kullanır ve yazma seti kısmı, etkilenen anahtarın versiyon numarasını ve değerini günceller.
Doğrulama aşamasında, okuma setindeki her bir anahtarın sürüm numarası, durum veri tabanındaki dünya durumu ile karşılaştırılır, eşleşirse işlem geçerli kabul edilir. Okuma-yazma seti ayrıca bir veya daha fazla sorgu bilgisi (sorgu bilgisi) içeriyorsa, ek doğrulama gerçekleştirilir. Bu doğrulama, bu toplu sorgunun sonuç aralığında hiçbir anahtarın eklenmemesini, silinmemesini veya değiştirilmemesini sağlar. Başka bir deyişle, doğrulama sırasında herhangi bir aralık sorgusunu (işlem simülasyon sırasında yürütülür) yeniden yürütürseniz, simülasyon yürütme sırasında elde edilen işlemle aynı sonucu vermelidir. Bu doğrulama, gönderildiğinde bir hayalet okuma varsa, işlemin geçersiz olarak kabul edilmesini sağlar. Fantom okuma korumasının yalnızca Chaincode tarafından çağrılan GetStateByRange yöntemini uyguladığını unutmayın.Diğer toplu sorgu yöntemleri (GetQueryResult gibi), hayali okuma riskine sahip olacaktır. Simülasyon aşaması ve doğrulama aşaması sırasında sonuç setinin istikrarını sağlayın.
İşlem, geçerlilik kontrolünü geçerse, commiter düğümü dünya durumunu güncellemek için yazma setini kullanır. Güncelleme aşamasında, yazma setindeki her anahtar için, karşılık gelen değer ve dünya durumundaki sürüm numarası güncellenecektir.
Simülasyon ve doğrulama örneği
Okuma-yazma kümesini anlamaya yardımcı olmak için bir simülasyon örneğine bakalım. WorldState'in bir demet (k, ver, val) ile temsil edildiğini varsayalım, burada anahtar k, var, k'nin en yeni sürümü ve val, k'nin değeridir.
T1, T2, T3, T4 ve T5 olmak üzere beş işlem vardır. Bu beş işlemin simülasyon süreci aynı worldSate anlık görüntüsüne dayanmaktadır. Aşağıdaki kod parçacığı, her bir işlemin okuma ve yazma gerçekleştirme sırasını göstermektedir.
Şimdi işlem sırasının T1 ~ T5 olduğunu varsayalım:
T1 doğrulaması, okuma işlemi olmadığı için başarılı oldu. Daha sonra worldState'deki k1 ve k2 (k1,2, v1 '), (k2,2, v2') olarak güncellenecektir.
T2 doğrulaması başarısız oldu çünkü okuduğu k1 önceki T1 işleminde değiştirildi
Okuma işlemi olmadığı için T3 doğrulaması başarılı oldu. Daha sonra worldState'deki k2 (k2,3, v2 '') olarak güncellenecek
T4 doğrulaması başarısız oldu çünkü okuduğu k2 önceki T1 işleminde değiştirildi
T5 doğrulaması başarılıdır çünkü okuduğu k5 önceki işlemlerde değiştirilmemiştir.
