Bu metin, bu yıl piyasaya sürülmeye hazırlanan (muhtemelen) dağıtılmış ağ Telegram Açık Ağının (TON) yapısını ele aldığım bir dizi makalenin devamı niteliğindedir. İÇİNDE Bunun en temel düzeyini, düğümlerin birbirleriyle etkileşim biçimini anlattım.
Her ihtimale karşı, bu ağın geliştirilmesiyle hiçbir ilgimin olmadığını ve tüm materyallerin açık (doğrulanmamış da olsa) bir kaynaktan alındığını hatırlatmama izin verin - (ayrıca ekte , ana noktaları özetleyen), geçen yılın sonunda ortaya çıkan. Bu belgedeki bilgi miktarı, bence bunun gerçekliğini gösteriyor, ancak bunun resmi bir onayı yok.
Bugün TON'un ana bileşeni olan blockchain'e bakacağız.
Temel Kavramlar
Hesap (hesap). 256 bitlik bir sayıyla tanımlanan bir veri kümesi hesap_kimliği (çoğunlukla bu, hesap sahibinin ortak anahtarıdır). Temel durumda (aşağıya bakın) sıfır iş zinciri), bu veri kullanıcının bakiyesi anlamına gelir. Belirli bir alanı "işgal et" hesap_kimliği herkes yapabilir, ancak değerini yalnızca belirli kurallara göre değiştirebilirsiniz.
Akıllı sözleşme (akıllı sözleşme). Aslında bu, akıllı sözleşme kodu ve değişkenlerinin saklandığı bir hesapla desteklenen özel bir durumdur. Bir "cüzdan" durumunda, nispeten basit ve önceden belirlenmiş kurallara göre para yatırmak ve ondan para çekmek mümkünse, o zaman akıllı bir sözleşme durumunda, bu kurallar kendi kodu biçiminde yazılır (bazı Turing'lerde). -tam programlama dili).
Blockchain Durumu (Blockchain'in durumu). Tüm hesapların / akıllı sözleşmelerin durumları kümesi (soyut anlamda, anahtarların hesap tanımlayıcıları olduğu ve değerlerin hesaplarda depolanan veriler olduğu bir karma tablosu).
mesaj (mesaj). Yukarıda “kredi ver ve parayı sil” ifadesini kullandım - bu belirli bir mesaj örneğidir (“transfer N gram hesaptan hesap_1 hesap başına hesap_2"). Açıkçası, yalnızca hesabın özel anahtarına sahip olan düğüm böyle bir mesaj gönderebilir. hesap_1 - ve bunu bir imzayla onaylayabilir. Bu tür mesajların normal bir hesaba iletilmesinin sonucu, bakiyesinde bir artış ve akıllı bir sözleşmeye göre kodunun (mesajın alındığını işleyecek) yürütülmesidir. Elbette başka mesajlar da mümkündür (akıllı sözleşmeler arasında parasal tutarların değil, keyfi verilerin aktarılması).
Işlem (işlem). Bir mesajın iletilmesine işlem denir. İşlemler blok zincirinin durumunu değiştirir. Blok zincirindeki bloklar işlemlerden (mesaj teslim kayıtları) oluşur. Bu bağlamda, blockchain'in durumunu artımlı bir veritabanı olarak düşünebilirsiniz; tüm bloklar, veritabanının mevcut durumunu elde etmek için sırayla uygulanması gereken "farklardır". Bu "farklılıkları" paketlemenin (ve bunları kullanarak tam durumu geri yüklemenin) ayrıntıları bir sonraki makalede tartışılacaktır.
TON'da Blockchain: nedir ve neden?
Önceki makalede de belirtildiği gibi, Blockchain, elemanları (bloklar) bir "zincir" halinde düzenlenmiş ve zincirin her bir sonraki bloğu bir öncekinin karmasını içeren bir veri yapısıdır.. Yorumlarda şu soru soruldu: Zaten bir DHT'miz (dağıtılmış bir karma tablosu) varken neden böyle bir veri yapısına ihtiyacımız var? Açıkçası, bazı veriler DHT'de saklanabilir, ancak bu yalnızca çok "hassas" olmayan bilgiler için uygundur. Kripto para bakiyeleri DHT'de saklanamıyor; bunun başlıca nedeni, kontrollerin bulunmaması. bütünlük. Aslında blockchain yapısının tüm karmaşıklığı, içinde saklanan verilere müdahaleyi önlemek için büyüyor.
Ancak TON'daki blockchain diğer birçok dağıtılmış sistemden çok daha karmaşık görünüyor ve bunun iki nedeni var. Birincisi, ihtiyacı en aza indirme arzusudur. çatallar. Geleneksel kripto para birimlerinde tüm parametreler başlangıç aşamasında belirlenir ve bunları değiştirmeye yönelik herhangi bir girişim aslında “alternatif bir kripto para birimi evreninin” ortaya çıkmasına yol açar. İkinci sebep ise kırma desteğidir (parçalama, parçalama) blok zinciri. Blockchain zamanla küçülemeyecek bir yapıdır; ve genellikle ağın sağlığından sorumlu olan her düğüm, onu tamamen depolamak zorunda kalır. Geleneksel (merkezi) sistemlerde bu tür sorunları çözmek için parçalama kullanılır: veritabanındaki kayıtların bir kısmı bir sunucuda, bir kısmı diğerinde vb. bulunur. Kripto para birimleri söz konusu olduğunda, bu tür işlevsellik hala oldukça nadirdir; özellikle de, başlangıçta planlanmayan bir sisteme parçalama eklemenin zor olması nedeniyle.
TON yukarıdaki sorunların her ikisini de nasıl çözmeyi planlıyor?
Blockchain içeriği. Çalışma zincirleri.
Öncelikle blockchainde nelerin saklanması planlandığından bahsedelim. Hesapların durumları (temel durumda “cüzdanlar”) ve akıllı sözleşmeler (basitlik açısından bunun hesaplarla aynı olduğunu varsayacağız) burada saklanacaktır. Aslında bu normal bir karma tablosu olacak - içindeki anahtarlar tanımlayıcılar olacak hesap_kimliğive değerler aşağıdaki gibi şeyleri içeren veri yapılarıdır:
- denge;
- akıllı sözleşme kodu (yalnızca akıllı sözleşmeler için);
- akıllı sözleşme veri depolama (yalnızca akıllı sözleşmeler için);
- İstatistik;
- (isteğe bağlı) bir hesaptan yapılan transferler için genel anahtar, varsayılan olarak account_id;
- giden mesajların sırası (alıcıya iletmek için buraya girilirler);
- Bu hesaba teslim edilen en son mesajların listesi.
Yukarıda bahsedildiği gibi, blokların kendisi işlemlerden, yani çeşitli account_id hesaplarına iletilen mesajlardan oluşur. Ancak, account_id'ye ek olarak mesajlar 32 bitlik bir alan da içerir çalışma zinciri_id - sözde tanımlayıcı. çalışma zinciri (iş zinciri, çalışan blockchain). Bu, farklı konfigürasyonlara sahip birkaç bağımsız blok zincirine sahip olmanızı sağlar. Bu durumda workchain_id = 0 özel bir durum olarak kabul edilir, sıfır iş zinciri - TON (Gram) kripto para birimine karşılık gelecek olan içindeki bakiyelerdir. Büyük olasılıkla, ilk başta başka çalışma zincirleri hiç mevcut olmayacak.
Parça zincirleri. Sonsuz Parçalama Paradigması.
Ancak blockchain sayısındaki artış bununla sınırlı değil. Parçalamayla ilgilenelim. Her hesabın (account_id) kendi blok zincirine sahip olduğunu, aldığı tüm mesajları içerdiğini ve bu tür tüm blok zincirlerinin durumlarının ayrı düğümlerde saklandığını hayal edin.
Elbette bu çok israftır: büyük ihtimalle bunların her birinde kırık zincirler (kırık zincir, parça blok zinciri) işlemler çok nadiren alınacak ve çok sayıda güçlü düğüme ihtiyaç duyulacak (ileriye baktığımda, sadece cep telefonlarındaki istemcilerden değil, ciddi sunuculardan bahsettiğimizi görüyorum).
Bu nedenle, parça zincirleri, hesapları tanımlayıcılarının ikili öneklerine göre birleştirir: Bir parça zincirinin öneki 0110 ise, bu sayılarla başlayan tüm account_id işlemleri buna dahil olacaktır. Bu Shard_prefix 0 ila 60 bit arasında bir uzunluğa sahip olabilir ve en önemlisi dinamik olarak değişebilir.
Parça zincirlerinden birine çok fazla işlem akmaya başlar başlamaz, üzerinde çalışan düğümler, önceden belirlenmiş kurallara göre onu iki alt parçaya "bölerler" - önekleri bir biraz daha uzun olacaktır (ve bunlardan biri için bu biraz daha uzun olacaktır). 0 olacak ve diğeri için - 1). Örneğin, Shard_prefix = 0110b ikiye ayrılır 01100b ve 01101b. Buna karşılık, iki "komşu" parça zinciri (bir süreliğine) yeterince rahat hissetmeye başlarsa yeniden birleşecekler.
Bu nedenle, parçalama "aşağıdan yukarıya" yapılır; her hesabın kendi parçası olduğunu varsayarız, ancak bunlar - şimdilik - öneklerle "yapıştırılmıştır". Bu ne anlama geliyor Sonsuz Parçalama Paradigması (sonsuz parçalama paradigması).
Ayrı olarak, çalışma zincirlerinin yalnızca sanal olarak var olduğunu vurgulamak isterim - aslında çalışma zinciri_id belirli bir parça zincirinin tanımlayıcısının bir parçasıdır. Resmi anlamda, her bir parça zinciri bir çift sayıyla tanımlanır (çalışma zinciri_id, Shard_prefix).
Hata düzeltme. Dikey blok zincirleri.
Geleneksel olarak blockchaindeki herhangi bir işlemin "kesin olarak belirlenmiş" olduğuna inanılır. Bununla birlikte, TON durumunda, birisinin (sözde) olması durumunda "tarihi yeniden yazmak" mümkündür. düğüm-"balıkçı") bloklardan birinin yanlış imzalandığını kanıtlayacaktır. Bu durumda, ilgili parça zincirine, düzeltilen bloğun karma değerini içeren (parça zincirindeki son bloğu değil) özel bir düzeltici blok eklenir. Shardchain'i yatay olarak dizilmiş bir blok zinciri olarak temsil ederek, düzeltici bloğun hatalı bloğa sağa değil yukarıdan bağlandığını söyleyebiliriz - bu nedenle küçük bir "dikey blok zincirinin" parçası haline geldiği kabul edilir. . Dolayısıyla, kırık zincirlerin olduğu söylenebilir. iki boyutlu blok zincirleri.
Hatalı bir bloktan sonra, sonraki bloklar onun yaptığı değişikliklere atıfta bulunuyorsa (yani, geçersiz olanlara dayanarak yeni işlemler yapıldıysa), bu bloklara "yukarıdan" düzeltici bloklar da eklenir. Bloklar "etkilenen" bilgileri etkilemediyse bu "düzeltici dalgalar" onlar için geçerli değildir. Örneğin, yukarıdaki çizimde, C hesabının bakiyesini artıran ilk bloğun işlemi hatalı olarak kabul edilmiştir; bu nedenle, bu hesabın üçüncü bloktaki bakiyesini azaltan işlemin de iptal edilmesi ve düzeltici blok bloğun kendisi üzerinde işlendi.
Düzeltici bloklar orijinal blokların “üstünde” konumlanmış olarak gösterilse de aslında bunların karşılık gelen blok zincirinin sonuna (kronolojik olarak konumlandırılmaları gereken yere) eklenecekleri unutulmamalıdır. İki boyutlu düzenleme yalnızca blok zincirinin hangi noktasına "bağlanacağını" gösterir (içlerinde bulunan orijinal bloğun hash'i aracılığıyla).
"Geçmişi değiştirme" kararının ne kadar iyi olduğu konusunda ayrı ayrı felsefe yapabilirsiniz. Öyle görünüyor ki, eğer parça zincirinde yanlış bir bloğun ortaya çıkma ihtimaline izin verirsek, o zaman hatalı bir düzeltici bloğun ortaya çıkma ihtimalini engelleyemeyiz. Burada, anladığım kadarıyla, yeni bloklar üzerinde fikir birliğine varması gereken düğüm sayısındaki fark - nispeten küçük - her bir parça zinciri üzerinde işe yarayacak "çalışma Grubu» düğümler (bileşimi oldukça sık değişiyor) ve düzeltici blokların uygulanması herkesin onayını gerektirecek doğrulayıcı düğümler. Doğrulayıcıları, çalışma gruplarını ve diğer düğüm rollerini gelecekteki bir makalede daha ayrıntılı olarak ele alacağım.
Hepsine hükmedecek tek bir blockchain
Yukarıda, kendi içinde bir yerde saklanması gereken farklı blok zincir türleri hakkında birçok bilgi listelenmektedir. Özellikle aşağıdaki bilgilerden bahsediyoruz:
- iş zincirlerinin sayısı ve konfigürasyonları hakkında;
- parça zincirlerinin sayısı ve önekleri hakkında;
- şu anda hangi düğümlerin hangi parça zincirlerinden sorumlu olduğu hakkında;
- tüm parça zincirlerine eklenen son blokların karmaları.
Tahmin edebileceğiniz gibi tüm bunlar başka bir blockchain deposuna kaydediliyor. ana zincir (ana zincir, ana blok zinciri). Bloklarındaki tüm shardchainlerin bloklarından hashlerin bulunması nedeniyle sistemi yüksek oranda bağlantılı hale getirir. Diğer şeylerin yanı sıra bu, ana zincirde yeni bir bloğun oluşturulmasının, parça zincirlerindeki blokların oluşturulmasından hemen sonra gerçekleşeceği anlamına gelir; parça zincirlerindeki blokların neredeyse aynı anda yaklaşık olarak her 5 saniyede bir ve bir sonraki bloğun da ortaya çıkması beklenir. ana zincir - bundan bir saniye sonra.
Ancak mesajların gönderilmesi, akıllı sözleşmelerin yürütülmesi, parça zincirlerinde ve ana zincirde bloklar oluşturulması ve hatta bloklarda hata olup olmadığının kontrol edilmesi gibi devasa çalışmaların uygulanmasından kim sorumlu olacak? Milyonlarca kullanıcının Telegram istemcisi yüklü telefonları gerçekten tüm bunları sinsice mi yapacak? Veya belki de Durov ekibi ademi merkeziyetçilik fikirlerinden vazgeçecek ve sunucuları bunu eski yöntemle mi yapacak?
Aslında ne biri ne de diğeri doğru. Ancak bu makalenin alanları hızla tükeniyor, bu nedenle bir sonraki bölümde düğümlerin çeşitli rollerinden (bazılarının bahsettiğini zaten fark etmiş olabilirsiniz) ve çalışma mekaniğinden bahsedeceğiz.
Kaynak: habr.com