Giriş: Binance, TON ekosistemindeki en büyük oyun olan Notcoin'i piyasaya sürdükten ve tamamen dolaşımdaki token ekonomisi büyük bir servet etkisi yarattıktan sonra, TON hızla büyük ilgi gördü. Arkadaşlarımla konuşurken, TON'in yüksek bir teknik engele sahip olduğunu ve DApp geliştirme modelinin ana akım blok zinciri protokollerinden çok farklı olduğunu öğrendim. Bu yüzden, bu konuyu derinlemesine araştırmak için biraz zaman harcadım ve sizinle paylaşacak bazı görüşlerim var. short olarak, TON'in temel tasarım felsefesi, birlikte çalışabilirlikten ödün vermek anlamına gelse bile, yüksek eşzamanlılık ve ölçeklenebilirlik elde etmeye odaklanarak geleneksel blok zinciri protokollerini sıfırdan yeniden oluşturmaktır.

TON'ın Temel Tasarım İlkeleri - Yüksek Eşzamanlılık ve Ölçeklenebilirlik

TON'daki tüm karmaşık teknoloji seçimlerinin amacının yüksek eşzamanlılık ve yüksek ölçeklenebilirlik arayışından geldiği söylenebilir. Tabi bunu doğuşunun arka planından anlamak bizim için zor değil. TON veya Açık Ağ, bir L1 blok zinciri ve birden fazla bileşen içeren merkezi olmayan bir bilgi işlem ağıdır. TON ilk olarak Telegram'ın kurucusu Nikolai Durov ve ekibi tarafından geliştirildi ve şu anda bağımsız katılımcılardan oluşan küresel bir topluluk tarafından destekleniyor ve sürdürülüyor. Doğuşu, Telegram ekibinin kendileri için blok zinciri çözümlerini keşfetmeye başladığı 2017 yılına kadar uzanıyor. O sırada mevcut hiçbir L1 blok zinciri Telegram'ın dokuz haneli kullanıcı tabanına destek edemediğinden, daha sonra Telegram Open Network olarak adlandırılan kendi blok zincirlerini tasarlamaya karar verdiler. Zaman 2018'de geldi. TON uygulamak için gereken kaynakları elde etmek emir Telegram, 2018'in ilk çeyreğinde Gram tokenlerinin (daha sonra Toncoin olarak yeniden adlandırıldı) satışını başlattı. 2020'de Telegram ekibi, düzenleyici sorunlar nedeniyle TON projesinden çekildi. Daha sonra, küçük bir grup açık kaynak geliştiricisi ve Telegram yarışması kazananı TON'in kod tabanını devraldı, projeyi The Open Network olarak yeniden adlandırdı ve orijinal TON teknik incelemesinde belirtilen ilkelere bağlı kalarak blok zincirini bugüne kadar aktif olarak geliştirmeye devam etti.

TON, Telegram'ın merkezi olmayan yürütme ortamı olarak tasarlandığından, iki ana zorluğu ele alması gerekiyordu: yüksek eşzamanlı talepler ve büyük veriler. En hızlısı olduğunu iddia eden Solana test edilen en yüksek TPS (saniye başına işlem) bile yalnızca 65.000'dir ve Telegram için gereken milyon düzeyindeki TPS çok short. Ek olarak, Telegram tarafından üretilen büyük miktarda veri, her düğümün verilerin tam bir kopyasını depoladığı bir blok zinciri tarafından yönetilemez.

Bu zorlukların üstesinden gelmek için ana akım blok zinciri protokollerini iki şekilde optimize TON:

l Veri fazlalığını azaltmak için bir "Sonsuz Parçalama Paradigması" kullanır, bu da büyük miktarda veriyi işlemesini ve performans darboğazlarını hafifletmesini sağlar.

l Aktör modeline dayalı tamamen paralel bir yürütme ortamı sunarak, ağ TPS büyük ölçüde iyileştirilir;

Bir Blok Zinciri Zincir Oluşturma - Her Hesaba Sonsuz Parçalama Aracılığıyla Kendi Özel Zincirini Sağlama

Artık parçalamanın çoğu blok zinciri protokolü için performansı artırmak ve maliyetleri azaltmak için ana çözüm haline geldiğini biliyoruz ve TON bunu aşırıya götürdü ve sonsuz parçalama paradigması olarak adlandırılan sonsuz parçalama paradigmasını önerdi. Blok zincirinin ağ yüküne bağlı olarak parça sayısını dinamik olarak artırmasına veya azaltmasına izin vermeyi ifade eder. Bu paradigma, TON yüksek performansı korurken büyük ölçekli işlemleri ve akıllı sözleşme işlemlerini gerçekleştirmesini sağlar. Teorik olarak TON, her hesap için özel bir hesap zinciri kurabilir ve bu zincirler arasında belirli kurallar aracılığıyla birlikte çalışabilirliği sağlayabilir. tutarlılık

Özünde, TON'in zincir yapısı dört katmandan oluşur

AccountChain: Bu katman, belirli bir hesap bağlı bir dizi işlemi temsil eder. İşlemler bir zincir oluşturur, çünkü bir durum makinesinde tutarlı yürütme kuralları, durum makinesinin aynı emir talimatları işlerken aynı sonuçları üretmesini sağlar. Bu nedenle, tüm blok zinciri sistemleri, işlemlerin bir zincire bağlanmasını gerektirir ve TON farklı değildir. AccountChain, TON ağındaki en temel birimdir. Tipik olarak, AccountChain sanal bir kavramdır ve bağımsız bir AccountChain'in var olması olası değildir.

ShardChain: Çoğu bağlamda, ShardChain TON içindeki gerçek birimdir. ShardChain, esasen bir AccountChain koleksiyonudur.

WorkChain: Solidity akıllı sözleşmeler'ı çalıştırmak için EVM dayalı bir WorkChain oluşturmak gibi özel kurallara sahip bir dizi parça zinciri olarak da bilinir. Teorik olarak, topluluktaki herkes kendi WorkChain'ini oluşturabilir. Bununla birlikte, bir tane inşa etmek oldukça karmaşıktır ve (yüksek) oluşturma ücretinin ödenmesini ve doğrulayıcılar 2 / 3'ünden onay alınmasını gerektirir.

MasterChain: TON'de, tüm parça zincirlerine kesinlik sağlayan MasterChain adı verilen benzersiz bir zincir vardır. Bir parça ağı bloğunun hash değeri bir MasterChain bloğuna dahil edildiğinde, bu parça ağı blok ve tüm ana blokları nihai olarak kabul edilir, yani sabit ve değişmezdirler, sonraki tüm parça ağı blokları tarafından referans alınırlar.

Bu paradigma, TON ağına üç temel özellik kazandırır:

Dinamik Parçalama: TON, değişen yüklere uyum sağlamak için parça zincirlerini otomatik olarak bölebilir ve birleştirebilir, bu da yeni blokların hızlı bir şekilde oluşturulmasını ve işlemlerin long gecikmeler yaşamamasını sağlar.

Yüksek Ölçeklenebilirlik: Sonsuz parçalama paradigması ile TON, teorik olarak 2^60 İş Zincirine kadar neredeyse sınırsız sayıda parça destek edebilir.

Uyarlanabilirlik: Ağın bir kısmı artan yük yaşadığında, daha yüksek işlem hacim işlemek için daha fazla parçaya bölünebilir. Tersine, yük azaldığında, verimliliği artırmak için parçalar birleşebilir.

Bunun gibi çok zincirli bir sistemde, birincil zorluk cross-chain iletişimdir. Sonsuz parçalama özelliği sayesinde, ağdaki parça sayısı önemli ölçüde arttığında, zincirler arasında yönlendirme bilgileri karmaşık hale gelir. Örneğin, her biri bağımsız bir WorkChain'e sahip dört düğümlü bir ağ düşünün. Her düğüm, kendi işlem sıralamasını yönetmenin yanı sıra, diğer zincirlerdeki durum değişikliklerini de izlemeli ve işlemelidir. TON'de bu, çıkış kuyruğundaki iletiler izlenerek yapılır.

WorkChain 1'deki A Hesabının, WorkChain 3'teki C Hesabına bir mesaj göndermek istediğini varsayalım. Bu, bir ileti yönlendirme çözümü tasarlamayı gerektirir. Bu örnekte iki yönlendirme yolu vardır: WorkChain 1 -> WorkChain 2 -> WorkChain 3 ve WorkChain 1 -> WorkChain 4 -> WorkChain 3.

Daha karmaşık senaryolarda, hızlı mesaj iletişimi için verimli ve düşük maliyetli bir yönlendirme algoritması gereklidir. TON, cross-chain ileti yönlendirme keşfi için "hiper küp yönlendirme algoritmasını" kullanır. Bir hiperküp yapısı, n boyutlu bir hiperküpün, her biri benzersiz bir şekilde n-bitlik bir ikili sayı ile tanımlanan 2^n köşeye sahip olduğu özel bir ağ topolojisidir. Bu yapıda, ikili temsilleri yalnızca bir bit farklıysa, herhangi iki köşe bitişiktir. Örneğin, 3 boyutlu bir hiperküpte, 000 köşesi ve 001 köşesi bitişiktir çünkü yalnızca son bitte farklılık gösterirler. Yukarıdaki örnek 2 boyutlu bir hiperküptür.

Hiper küp yönlendirme protokol, kaynak WorkChain'den hedef WorkChain'e bir iletinin yönlendirilmesi, ikili adresleri karşılaştırılarak yapılır. Algoritma, bu adresler arasındaki minimum mesafeyi (yani farklı bitlerin sayısını) bulur ve mesajı, hedefine ulaşana kadar bitişik WorkChains üzerinden iletir. Bu, veri paketinin en kısa yolu izlemesini sağlayarak ağ iletişim verimliliğini artırır. Bu süreci basitleştirmek için TON iyimser bir çözüm de sunuyor. Bir kullanıcı, tipik olarak bir Merkle deneme kökü olan bir yönlendirme yolunun geçerli kanıtını sağlayabilirse, düğüm mesajın gerçekliğini hemen doğrulayabilir. Bu, anında hiperküp yönlendirme olarak bilinir. Sonuç olarak, TON adresleri diğer blok zinciri protokollerindekilerden önemli ölçüde farklıdır. Çoğu blok zinciri protokolü, eliptik şifreleme algoritmaları tarafından oluşturulan bir açık anahtarın hash adres olarak kullanır ve yönlendirme işlevlerine ihtiyaç duymadan benzersizliğe odaklanır. TON'de adresler iki bölümden oluşur: (workchain_id, hesap_id), workchain_id hiperküp yönlendirme algoritmasına göre kodlanmıştır. Neden tüm cross-chain bilgileri Cosmos'a benzer şekilde MasterChain aracılığıyla aktarmıyorsunuz diye merak edebilirsiniz. TON'in tasarımında MasterChain, WorkChains'in kesinliğini korumak gibi yalnızca en kritik görevi yerine getirir. Mesajları MasterChain üzerinden yönlendirmek mümkün olsa da, ilgili ücretler aşırı derecede yüksek olacaktır.

Son olarak, konsensüs algoritmasını kısaca tartışalım. TON, BFT (Bizans Hatası Toleransı) ve PoS (Proof of Stake) kombinasyonunu kullanır. Bu, herhangi bir staker'ın blok oluşturmaya katılabileceği anlamına gelir. TON seçim yönetişim sözleşmesi, tüm stake edenler arasından rastgele bir doğrulayıcılar grubunu periyodik olarak seçer. Bu seçilen doğrulayıcılar daha sonra bloklar oluşturmak için BFT algoritmasını kullanır. Bir doğrulayıcı geçersiz bloklar oluşturursa veya kötü niyetli davranırsa, stake edilen tokenlerine el konulur. Tersine, başarılı bir şekilde geçerli bloklar oluşturdukları için ödüller alırlar. Bu yöntem oldukça yaygındır, bu yüzden burada daha fazla ayrıntıya girmeyeceğiz.

Tamamen paralel bir yürütme ortamında Actor modelini kullanan akıllı sözleşmeler

akım blok zinciri protokollerine kıyasla TON'deki bir diğer önemli fark, akıllı sözleşme yürütme ortamıdır. Ana akım blok zinciri protokollerinin karşılaştığı TPS sınırlamaların üstesinden gelmek için TON, aşağıdan yukarıya bir tasarım yaklaşımı kullanır ve akıllı sözleşmeler ve bunların yürütülmesini yeniden yapılandırmak için Aktör modelini kullanır ve tamamen paralel yürütme yetenekleri sağlar.

Çoğu ana akım blok zinciri protokolü, tek iş parçacıklı, seri yürütme ortamı kullanır. Örneğin, Ethereum'ın yürütme ortamı olan EVM, işlemleri sırayla işleyen bir durum makinesi olarak çalışır. Bir blok oluşturulduktan ve işlemler sıralandıktan sonra, EVM üzerinden tek tek yürütülür. Bu tamamen seri, tek iş parçacıklı işlem, herhangi bir zamanda yalnızca bir işlemin işlendiği anlamına gelir. Bunun avantajı, işlem emir oluşturulduktan sonra, yürütme sonuçlarının dağıtılmış bir ağda tutarlı kalmasıdır. Ayrıca, aynı anda yalnızca bir işlem yürütüldüğünden, başka hiçbir işlem erişilen durum verilerini değiştiremez ve akıllı sözleşmeler arasında birlikte çalışabilirliği sağlar. Örneğin, USDT ile ETH satın almak için Uniswap kullanırken, likidite havuzu dağılımı yürütme sırasında sabit bir değerdir. Bu, matematiksel modellerin kesin sonucu belirlemesine izin verir. Tersine, diğer likidite sağlayıcıları bağlanma eğrisi hesaplaması sırasında likidite eklerse, sonuçlar güncelliğini yitirir ve bu açıkça kabul edilemez.

Bununla birlikte, bu mimarinin, özellikle modern çok çekirdekli işlemcilerle modası geçmiş hissettiren TPS darboğazı gibi açık sınırlamaları da vardır. Yepyeni bir bilgisayarda Red Alert gibi eski bilgisayar oyunlarını oynamaya benzer; Savaş birimlerinin sayısı belirli bir seviyeye ulaştığında, yine de önemli bir gecikmeyle karşılaşırsınız. Bu, yazılım mimarisi sorunlarından kaynaklanmaktadır.

Bazı protokoller bu sorunu ele alıyor ve kendi paralel çözümlerini önerdiler. Örneğin, en yüksek TPS sahip olduğunu iddia eden Solana, paralel yürütmeyi de destekler. Ancak Solana'ın tasarımı TON'ninkinden farklıdır. Solana'in temel fikri, tüm işlemleri yürütme bağımlılıklarına göre gruplandırmak ve farklı grupların herhangi bir durum verisini paylaşmamasını sağlamaktır. Bu, farklı gruplardaki işlemlerin çakışma olmadan paralel olarak yürütülmesine izin veren paylaşılan bağımlılıklar olmadığı anlamına gelir. Aynı grup içindeki işlemler seri olarak yürütülmeye devam eder.

Buna karşılık, TON seri yürütme mimarisini tamamen terk eder ve yürütme ortamını yeniden yapılandırmak için Aktör modelini kullanarak paralellik için özel olarak tasarlanmış bir geliştirme paradigmasını benimser. İlk olarak 1973 yılında Carl Hewitt tarafından önerilen Aktör modeli, geleneksel eşzamanlı programlardaki paylaşılan durumların karmaşıklığını mesaj iletimi yoluyla çözmeyi amaçlamaktadır. Her Aktörün kendi özel durumu ve davranışı vardır ve durum bilgilerini diğer Aktörlerle paylaşmaz. Aktör modeli, ileti geçirme yoluyla paralel işleme sağlayan bir eşzamanlılık hesaplama modelidir. Bu modelde "Aktör", alınan mesajları işleyebilen, yeni Aktörler oluşturabilen, ek mesajlar gönderebilen ve sonraki mesajlara nasıl yanıt verileceğine karar verebilen temel bir birimdir. Aktör modeli aşağıdaki özelliklere sahip olmalıdır:

Kapsülleme ve Bağımsızlık: Her Aktör, mesajları işlerken tamamen bağımsız olarak çalışır ve müdahale olmadan paralel mesaj işlemeye izin verir.

Mesaj Geçişi: Aktörler yalnızca mesaj gönderip alarak etkileşime girer ve mesaj geçişi eşzamansızdır.

Dinamik Yapı: Aktörler çalışma zamanında ek Aktörler oluşturarak Aktör modelinin sistemi gerektiği gibi dinamik olarak genişletmesine olanak tanır.

TON, akıllı sözleşme modeli için bu mimariyi benimser, yani TON'deki her akıllı sözleşme Aktör modeline dayanır ve herhangi bir harici veriye bağlı olmadığı için tamamen bağımsız bir depolamaya sahiptir. Ayrıca, aynı akıllı sözleşmeye yapılan çağrılar, alma kuyruğundaki mesajların emir yürütülür. Bu, TON'daki işlemlerin çakışma endişesi olmadan paralel olarak verimli bir şekilde yürütülmesini sağlar. Bununla birlikte, bu tasarım aynı zamanda bazı yeni zorluklar da getiriyor. DApp geliştiriciler için, tanıdık geliştirme paradigmaları aşağıdaki şekillerde bozulacaktır:

1. Asenkron Akıllı Sözleşme Çağrıları: TON'de, harici sözleşmeleri atomik olarak çağırmak veya akıllı sözleşmeler içinde harici sözleşme verilerine erişmek mümkün değildir. Örneğin Solidity'de, Sözleşme A'nın işlevinin1 Sözleşme B'nin işlevini2 çağırması veya Sözleşme C'nin salt okunur işlevi3 aracılığıyla belirli durum verilerine erişmesi kolaydır, hepsi tek bir işlemde. Ancak TON bu başarılamaz. Harici akıllı sözleşmeler ile herhangi bir etkileşim, akıllı sözleşmeler tarafından başlatılan dahili mesajlar olarak adlandırılan yeni işlemler oluşturularak eşzamansız olarak yürütülecektir. Sonucu beklemek için yürütme işlemi engellenemez.

Örneğin, bir DEX geliştiriyorsak ve ortak EVM paradigmasını takip ediyorsak, her havuz belirli işlem çiftleri için LP verilerini bağımsız olarak yönetirken, işlem yönlendirmesini yönetmek için genellikle birleşik bir yönlendirici sözleşmemiz olur. Diyelim ki iki havuzumuz var: USDT-DAI ve DAI-ETH. Bir kullanıcı doğrudan USDT ile ETH satın almak istediğinde, tek bir atomik işlemde bu iki havuzla sırayla etkileşim kurmak için yönlendirici sözleşmesini kullanabilir. Ancak TON bu süreç o kadar basit değildir ve farklı bir geliştirme yaklaşımı gerektirir. Bu EVM paradigmasını yeniden kullanmaya çalışırsak, bilgi akışı, kullanıcı tarafından başlatılan harici bir mesaj ve işlemi tamamlamak için üç dahili mesaj içerecektir (bu örneğin farklılıkları vurgulamak için olduğunu unutmayın; gerçek geliştirmede, ERC20 paradigmasının bile yeniden tasarlanması gerekecektir).

1. Sözleşmeler arası çağrılarda hataların ele alınması ve her sözleşmeler arası etkileşim için uygun geri dönüş işlevlerinin tasarlanması için dikkatli bir değerlendirme yapılması gerekir. Ana akım EVM sistemlerinde, işlemin yürütülmesi sırasında bir hata oluşursa, tüm işlem başlangıç durumuna geri alınır. Bu, seri tek iş parçacıklı bir modelde basittir. Bununla birlikte, TON'de, sözleşmeler arası çağrılar eşzamansız olarak yürütüldüğünden, daha sonraki bir aşamada bir hata oluşursa, daha önce başarıyla yürütülen işlemler zaten onaylanmıştır ve bu da potansiyel olarak sorunlara neden olur. Bu nedenle, TON geri dönen ileti adı verilen özel bir ileti türünü kullanıma sunmuştur. Dahili bir mesajın sonraki yürütülmesinde bir hata meydana gelirse, tetiklenen sözleşme, tetikleyici sözleşmedeki belirli durumları sıfırlamak için tetikleyici sözleşmede ayrılan geri dönme işlevini kullanabilir.

2. Karmaşık senaryolarda, önce alınan işlemler önce tamamlanmayabilir, bu nedenle belirli bir yürütme emir varsayamazsınız. Asenkron ve paralel bir akıllı sözleşme sisteminde, işlem emir tanımlamak zor olabilir. Bu nedenle TON'daki her mesajın Lamport zamanı (lt) olarak bilinen mantıksal zamanı vardır. Hangi olayın diğerini tetiklediğini ve önce hangi doğrulayıcılar işlemesi gerektiğini belirlemeye yardımcı olur. Basit bir modelde, önce alınan işlemler önce yürütülür.

Bu modelde, A ve B iki akıllı sözleşmeler temsil eder. msg1_lt < msg2_lt ise, sıra açısından tx1_lt < tx2_lt.

Ancak, daha karmaşık durumlarda, bu kural çiğnenebilir. Resmi belgeler bir örnek veriyor: A, B ve C olmak üzere üç sözleşmemiz olduğunu varsayalım. Bir işlemde A, biri B'ye diğeri C'ye olmak üzere msg1 ve msg2 olmak üzere iki dahili mesaj gönderir. Belirli bir emir oluşturulmalarına rağmen (önce msg1, sonra msg2), msg1'in msg2'den önce işleneceğinden emin olamayız. Bu belirsizlik, A'dan B'ye ve A'dan C'ye giden yolların uzunluk ve doğrulayıcı setleri bakımından farklılık gösterebilmesinden kaynaklanmaktadır. Bu sözleşmeler farklı parça zincirlerinde yer alıyorsa, bir mesajın hedef sözleşmeye ulaşması birkaç blok sürebilir. Bu nedenle, gösterildiği gibi iki olası işlem yolu vardır.

1. TON'de, akıllı sözleşmeler için kalıcı depolama, birimler olarak hücrelerle yönlendirilmiş asiklik grafik (DAG) bir yapı kullanır. Veriler, belirli kodlama kurallarına göre bir hücreye kompakt bir şekilde sıkıştırılır ve DAG bir şekilde aşağı doğru uzanır. Bu, durum verileri için EVM kullanılan hashmap tabanlı yapıyla çelişir. Farklı veri erişim algoritmaları nedeniyle, TON verileri farklı derinliklerde işlemek için değişen gas fiyatlar atar; Daha derin hücre verilerinin işlenmesi daha fazla gas gerektirir. Sonuç olarak, TON, kötü niyetli kullanıcıların akıllı bir sözleşmeyi çok sayıda gereksiz mesajla doldurduğu ve tüm sığ hücreleri doldurduğu bir tür DOS saldırısıyla karşı karşıyadır. Bu, dürüst kullanıcılar için depolama maliyetlerini artırır. Buna karşılık, EVM'ın hashmap'i O(1) sorgu karmaşıklığına sahiptir, bu da tutarlı gas maliyetleri sağlar ve benzer sorunlardan kaçınır. Bu nedenle, TON Dapp geliştiricileri, akıllı sözleşmeler sınırsız veri türlerini kullanmaktan kaçınmalıdır. Sınırsız veri türleri gerektiğinde, bunlar parçalama kullanılarak bölümlenmelidir.

1. akıllı sözleşmeler depolama için kira ödeme zorunluluğu gibi bazı özellikler daha az benzersizdir. TON'de, akıllı sözleşmeler doğası gereği yükseltilebilir ve yerel soyut hesap işlevleriyle birlikte gelir, yani TON'deki tüm cüzdan adresleri akıllı sözleşmeler, sadece başlatılmamıştır. Geliştiricilerin bu yönlere çok dikkat etmesi gerekir.

Yasal Uyarı:

1. Bu makale [Theblockbeats] adresinden yeniden basılmıştır. Tüm telif hakları orijinal yazara [Web3Mario] aittir. Bu yeniden baskıya itirazlar varsa, lütfen Gate Learn ekibiyle iletişime geçin, derhal ilgileneceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Bahsedilmediği sürece, tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.