TON'un teknik özelliklerinin ve akıllı sözleşme geliştirme paradigmasının ayrıntılı açıklaması

Orijinal yazar: @Web3 Mario

Giriş: TON ekosistemindeki en büyük oyun olan Notcoin'in Binance'de piyasaya sürülmesi ve tamamen dolaşımda olan token ekonomik modelinin neden olduğu muazzam servet etkisiyle TON kısa sürede büyük ilgi gördü. Bir arkadaşımla sohbet ettikten sonra TON'un teknik eşiğinin nispeten yüksek olduğunu ve DApp geliştirme paradigmasının ana akım genel zincir protokolünden çok farklı olduğunu öğrendim. Bu nedenle, ilgili konuları derinlemesine incelemek için biraz zaman harcadım ve sizinle paylaşacak biraz deneyimim var. Kısacası, TON'un temel tasarım konsepti, geleneksel blok zinciri protokolünü aşağıdan yukarıya bir şekilde yeniden yapılandırmak ve birlikte çalışabilirliği terk etme pahasına yüksek eşzamanlılık ve yüksek ölçeklenebilirliğin nihai arayışını elde etmektir.

TON'un temel tasarım konsepti – yüksek eşzamanlılık ve yüksek ölçeklenebilirlik

TON'daki tüm karmaşık teknoloji seçiminin amacının yüksek eşzamanlılık ve yüksek ölçeklenebilirlik arayışından kaynaklandığı söylenebilir. Elbette, bunu doğumunun geçmişinden anlamak bizim için zor değil. TON veya Açık Ağ, bir L1 blok zinciri ve birden fazla bileşenden oluşan merkezi olmayan bir bilgi işlem ağıdır. TON başlangıçta Telegram'ın kurucusu Nikolai Durov ve ekibi tarafından geliştirildi ve şimdi dünyanın dört bir yanındaki bağımsız katkıda bulunanlardan oluşan bir topluluk tarafından destekleniyor ve sürdürülüyor. Doğumu, Telegram ekibinin kendileri için blok zinciri çözümlerini keşfetmeye başladığı 2017 yılına dayanıyor. O zamanlar Telegram'ın dokuz haneli kullanıcı tabanını destekleyebilecek mevcut bir L1 blok zinciri olmadığından, o zamanlar Telegram Açık Ağı olarak adlandırılan kendi blok zincirlerini tasarlamaya karar verdiler. Zaman 2018'e geldi. TON'u gerçekleştirmek için gereken kaynakları elde etmek amacıyla Telegram, 2018'in ilk çeyreğinde Gram token'larının (daha sonra Toncoin olarak yeniden adlandırıldı) satışını başlattı. 2020'de, düzenleyici sorunlar nedeniyle Telegram ekibi TON projesinden çekildi. Daha sonra, küçük bir açık kaynak geliştiricileri ve Telegram yarışması kazananları grubu TON kod tabanını devraldı, projeyi The Open Network olarak yeniden adlandırdı ve orijinal TON teknik incelemesinde özetlenen ilkeleri izleyerek blockchain'i bugüne kadar aktif olarak geliştirmeye devam etti.

Tasarım hedefi Telegram için merkezi olmayan bir yürütme ortamı olmak olduğundan, doğal olarak iki sorunla karşı karşıyadır: yüksek eş zamanlı istekler ve büyük miktarda veri. Bildiğimiz gibi, teknolojinin gelişmesiyle birlikte, en yüksek TPS'ye sahip olduğunu iddia eden Solana'nın ölçülen maksimum TPS'si yalnızca 65.000'dir ve bu, milyonlarca TPS gerektiren Telegram ekosistemini desteklemek için açıkça yeterli değildir. Aynı zamanda, Telegram'ın geniş ölçekli uygulamasıyla, ürettiği veri miktarı çoktan gökleri aştı ve son derece yedekli dağıtılmış bir sistem olarak blockchain, ağdaki her düğümün verilerin tam bir kopyasını kaydetmesini gerektirir ki bu da gerçekçi değildir.

Bu nedenle, yukarıdaki iki sorunu çözmek için TON, ana akım blok zinciri protokolünde iki optimizasyon yaptı:

• Sistemin tasarımında Sonsuz Parçalama Paradigması benimsenerek, veri yedekliliği sorunu çözülmüş, böylece performans darboğazları ortadan kaldırılırken büyük veri taşınabilmiştir;

• Aktör modeline dayalı tamamen paralel yürütme ortamının tanıtılmasıyla, ağ TPS'si büyük ölçüde iyileştirildi;

Bir blok zinciri zinciri olun - sınırsız parçalama yetenekleri sayesinde her hesap özel bir hesap zincirine sahip olur

Parçalamanın, performansı iyileştirmek ve maliyetleri azaltmak için çoğu blok zinciri protokolü için ana akım çözüm haline geldiğini biliyoruz ve TON bunu aşırıya götürerek sonsuz bir parçalama paradigması önerdi; bu, blok zincirinin ağ yüküne göre parça sayısını dinamik olarak artırmasına veya azaltmasına izin verildiği anlamına geliyor. Bu paradigma, TON'un yüksek performansı korurken büyük ölçekli işlemleri ve akıllı sözleşme işlemlerini yönetmesini sağlar. Teoride, TON her hesap için özel bir hesap zinciri kurabilir ve belirli kurallar aracılığıyla bu zincirler arasındaki tutarlılığı sağlayabilir.

Soyut olarak ifade etmek gerekirse, TON’da dört katmandan oluşan zincir yapısı vardır:

• Hesap Zinciri: Bu zincir katmanı, belirli bir hesapla ilgili bir işlem zincirini temsil eder. İşlemlerin bir zincir yapısı oluşturabilmesinin nedeni, bir durum makinesi için, yürütme kuralları tutarlı olduğu sürece, durum makinesinin aynı talimat sırasını aldıktan sonra aynı sonucu alacak olmasıdır. Bu nedenle, tüm blockchain dağıtılmış sistemlerinin işlemleri bir zincirde sıralaması gerekir ve TON da bir istisna değildir. Hesap zinciri, TON ağındaki en temel bileşen birimidir. Genellikle, hesap zinciri sanal bir kavramdır ve bağımsız bir hesap zincirinin gerçekten var olması olası değildir.

• Shard Zinciri: Çoğu bağlamda, shard zinciri TON'un gerçek bileşen birimidir. Sözde shard zinciri, hesap zincirlerinin bir koleksiyonudur.

• WorkChain: EVM tabanlı bir workchain oluşturup üzerinde Solidity akıllı sözleşmeleri çalıştırmak gibi özel kurallara sahip bir dizi shard zinciri olarak da adlandırılabilir. Teoride, topluluktaki herkes kendi workchain'ini oluşturabilir. Gerçekte, onu oluşturmak oldukça karmaşık bir görevdir ve ondan önce onu oluşturmak için (pahalı) ücreti ödemeniz ve workchain'inizin oluşturulmasını onaylamak için doğrulayıcıların 2/3'ünün oylarını almanız gerekir.

• MasterChain: Son olarak, TON'da tüm shard zincirlerine kesinlik getirmekten sorumlu olan master chain adı verilen özel bir zincir vardır. Bir shard zinciri bloğunun karma değeri master zinciri bloğuna birleştirildiğinde, shard zinciri bloğu ve tüm üst blokları nihai olarak kabul edilir, bu da bunların sabit ve değiştirilemez içerik olarak kabul edilebileceği ve tüm shard zincirlerinin sonraki blokları tarafından referans alınabileceği anlamına gelir.

Bu paradigmayı benimseyerek TON ağı aşağıdaki üç özelliğe sahip olur:

• Dinamik Parçalama: TON, yükteki değişikliklere uyum sağlamak için parça zincirlerini otomatik olarak bölebilir ve birleştirebilir. Bu, yeni blokların her zaman hızlı bir şekilde oluşturulduğu ve işlemlerin uzun bekleme sürelerine neden olmadığı anlamına gelir.

• Son derece ölçeklenebilir: Sonsuz parçalama paradigması sayesinde TON, teorik olarak 2 üzeri 60 çalışma zincirine kadar neredeyse sınırsız sayıda parçayı destekleyebilir.

• Uyarlanabilirlik: Ağın bir bölümündeki yük arttığında, bu bölüm artan işlem hacmini karşılamak için daha fazla parçaya bölünebilir. Tersine, yük azaldığında, verimliliği artırmak için parçalar birleştirilebilir.

Daha sonra böyle çok zincirli bir sistem, özellikle sınırsız parçalama yeteneği nedeniyle, öncelikle zincirler arası iletişim sorunuyla yüzleşmelidir. Ağdaki parça sayısı belirli bir seviyeye ulaştığında, zincirler arasında bilgi yönlendirmesi zor bir görev haline gelecektir. Ağda 4 düğüm olduğunu ve her düğümün bağımsız bir çalışma zincirini sürdürmekten sorumlu olduğunu düşünün; burada bağlantı ilişkisi, düğümün kendi çalışma zincirindeki işlem sıralama işinden sorumlu olmasının yanı sıra, hedef zincirdeki durum değişikliklerini de izlemesi ve işlemesi gerektiği anlamına gelir. TON'da bu, çıktı kuyruğundaki mesajları izleyerek elde edilir.

İş zinciri 1'deki hesap A'nın iş zinciri 3'teki hesap C'ye bir mesaj göndermek istediğini varsayalım. O zaman mesaj yönlendirme probleminin tasarlanması gerekir. Bu örnekte, iki yönlendirme yolu vardır, iş zinciri 1 -> iş zinciri 2 -> iş zinciri 3 ve iş zinciri 1 -> iş zinciri 4 -> iş zinciri 3.

Daha karmaşık durumlarla karşı karşıya kalındığında, mesaj iletişimini hızla tamamlamak için verimli ve düşük maliyetli bir yönlendirme algoritmasına ihtiyaç duyulur. TON, zincirler arası mesaj iletişimi yönlendirme keşfini elde etmek için hiperküp yönlendirme algoritması olarak adlandırılan algoritmayı seçti. Hiperküp olarak adlandırılan yapı, özel bir ağ topolojisine atıfta bulunur. n boyutlu bir hiperküp, her biri n bitlik bir ikili sayı ile benzersiz bir şekilde tanımlanabilen 2^n köşeden oluşur. Bu yapıda, ikili gösterimde yalnızca bir bit farklılık gösteriyorlarsa herhangi iki köşe bitişiktir. Örneğin, 3 boyutlu bir hiperküpte, 000 köşesi ve 001 köşesi yalnızca son bitte farklılık gösterdikleri için bitişiktir. Yukarıdaki örnek 2 boyutlu bir hiperküptür.

Hiperküp yönlendirme protokolünde, mesajları kaynak zincirinden hedef zincirine yönlendirme süreci, kaynak ve hedef zincir adreslerinin ikili gösteriminin karşılaştırılmasıyla gerçekleştirilir. Yönlendirme algoritması, iki adres arasındaki minimum mesafeyi (yani, ikili gösterimdeki farklı bitlerin sayısını) bulur ve bilgiyi hedef zincire ulaşana kadar adım adım bitişik zincirler boyunca iletir. Bu yöntem, veri paketlerinin en kısa yol boyunca iletilmesini sağlayarak ağın iletişim verimliliğini artırır.

Elbette, bu süreci basitleştirmek için TON iyimser bir teknik çözüm de önerdi. Bir kullanıcı, genellikle bir merkle trie kökü olan bir yönlendirme yolunun geçerli kanıtını sağlayabildiğinde, düğüm kullanıcı tarafından gönderilen mesajın güvenilirliğini doğrudan doğruya kabul edebilir. Buna anında hiperküp yönlendirmesi de denir.

Bu nedenle, TON'daki adreslerin diğer blok zinciri protokollerindeki adreslerden önemli ölçüde farklı olduğunu görebiliriz. Diğer ana akım blok zinciri protokollerinin çoğu, eliptik şifreleme algoritması tarafından üretilen genel-özel anahtardaki genel anahtara karşılık gelen karmayı adres olarak kullanır, çünkü adres yalnızca benzersizlik için kullanılır ve yönlendirme adreslemesi işlevini taşıması gerekmez. TON'daki adres iki bölümden oluşur (workchain_id, account_id), burada workchain_id, burada ayrıntılı olarak açıklanmayacak olan hiperküp yönlendirme algoritması adresine göre kodlanır.

Şüphe edilmesi kolay bir nokta daha var. Ana zincirin ve her bir çalışma zincirinin birbirine bağlı olduğunu fark etmiş olabilirsiniz. O zaman tüm çapraz zincir bilgileri, tıpkı Cosmos gibi ana zincir üzerinden iletilebilir. TON'un tasarım konseptinde, ana zincir yalnızca en kritik görevleri, yani birçok çalışma zincirinin kesinliğini korumak için kullanılır. Mesajları ana zincir üzerinden yönlendirmek imkansız değildir, ancak ortaya çıkan işlem ücretleri çok pahalı olacaktır.

Son olarak, fikir birliği algoritmasından kısaca bahsedeyim. TON, BFT+PoS yöntemini kullanır, yani herhangi bir staker blok paketlemeye katılma fırsatına sahiptir. TON'un seçim yönetimi sözleşmesi, düzenli aralıklarla tüm Staker'lardan rastgele bir paketleme doğrulayıcı kümesi seçecektir. Doğrulayıcılar olarak adlandırılan seçilen düğümler, BFT algoritması aracılığıyla blokları paketleyecektir. Yanlış bilgi paketlerlerse veya kötü davranırlarsa, stake ettikleri token'lara el konulacaktır, aksi takdirde blok ödülleri alacaklardır. Bu temelde yaygın bir seçimdir, bu yüzden burada tanıtmayacağım.

Aktör tabanlı akıllı sözleşmeler ve tamamen paralel yürütme ortamı

TON ile ana akım blok zinciri protokolleri arasındaki bir diğer fark ise akıllı sözleşme yürütme ortamıdır. Ana akım blok zinciri protokollerinin TPS sınırlamalarını aşmak için TON, aşağıdan yukarıya bir tasarım yaklaşımı benimsedi ve akıllı sözleşmeleri ve yürütme yöntemlerini Aktör modelini kullanarak yeniden yapılandırdı ve bunların tam paralel yürütme yeteneklerine sahip olmasını sağladı.

Çoğu ana akım blok zinciri protokolünün tek iş parçacıklı seri yürütme ortamı kullandığını biliyoruz. Ethereum'u örnek olarak ele alırsak, yürütme ortamı EVM, girdi olarak işlemleri alan bir durum makinesidir. Blok üreten düğüm, blokları paketleyerek işlemlerin sıralamasını tamamladığında, bu sırayla EVM aracılığıyla işlemleri yürütecektir. Tüm süreç tamamen seri ve tek iş parçacıklıdır, yani bir seferde yalnızca bir işlem yürütülebilir. Bunun avantajı, işlem sırası onaylandığı sürece yürütme sonucunun geniş dağıtılmış bir kümede tutarlı olmasıdır. Aynı zamanda, aynı anda yalnızca bir işlem seri olarak yürütüldüğünden, yürütme süreci sırasında diğer işlemlerin erişilecek bir durum verisini değiştirmesinin imkansız olduğu anlamına gelir, böylece akıllı sözleşmeler arasında birlikte çalışabilirlik elde edilir. Örneğin, Uniswap aracılığıyla ETH satın almak için USDT kullanırız. İşlem yürütüldüğünde, işlem çiftindeki LP'lerin dağılımı belirli bir değerdir, bu nedenle karşılık gelen sonuçlar belirli matematiksel modeller aracılığıyla elde edilebilir. Ancak durum böyle değilse, tahvil eğrisi hesaplaması yapılırken diğer LP’ler yeni likidite ekliyorsa, hesaplama sonucu güncelliğini yitirmiş bir sonuç olacak ve bu da kabul edilemez bir durumdur.

Ancak bu mimarinin de belirgin sınırlamaları var, yani TPS darboğazı ve bu darboğaz, mevcut çok çekirdekli işlemciler altında çok eski görünüyor. Bu, Red Alert gibi bazı eski bilgisayar oyunlarını oynamak için en son PC'yi kullanmaya benziyor. Muharebe birimlerinin sayısı belirli bir seviyeye ulaştığında, hala takılıp kaldığını göreceksiniz. Bu, yazılım mimarisiyle ilgili bir sorundur.

Bazı protokollerin bu konuya dikkat çektiğini ve kendi paralel çözümlerini önerdiğini duyabilirsiniz. Örneğin, şu anda en yüksek TPS'ye sahip olduğu bilinen Solana, paralel olarak yürütme yeteneğine de sahiptir. Ancak, tasarım konsepti TON'dan farklıdır. Solana'da, temel fikir tüm işlemleri yürütme bağımlılıklarına göre birkaç gruba ayırmaktır ve farklı gruplar arasında hiçbir durum verisi paylaşılmaz. Yani, özdeş bir bağımlılık yoktur, bu nedenle farklı gruplardaki işlemler çakışma endişesi olmadan paralel olarak yürütülebilir. Aynı gruptaki işlemler için, yürütme için hala geleneksel seri yöntemi kullanılır.

Ancak TON'da seri yürütme mimarisi tamamen terk edilir ve yürütme ortamını yeniden oluşturmak için paralellik için tasarlanmış bir geliştirme paradigması olan Aktör modeli benimsenir. Sözde Aktör modeli ilk olarak 1973'te Carl Hewitt tarafından, geleneksel eşzamanlı programlarda paylaşılan durumun karmaşıklığını mesaj geçirme yoluyla çözme amacıyla önerildi. Her Aktör'ün kendi özel durumu ve davranışı vardır ve diğer Aktörlerle hiçbir durum bilgisini paylaşmaz. Aktör modeli, mesaj geçirme yoluyla paralel hesaplamayı uygulayan eşzamanlı hesaplama için bir hesaplama modelidir. Bu modelde Aktör, alınan mesajları işleyebilen, yeni Aktörler oluşturabilen, daha fazla mesaj gönderebilen ve bir sonraki mesaja nasıl yanıt verileceğine karar verebilen temel iş birimidir. Aktör modelinin aşağıdaki özelliklere sahip olması gerekir:

• Kapsülleme ve Bağımsızlık: Her Aktör mesajların işlenmesinde tamamen bağımsızdır ve birbirlerine müdahale etmeden mesajları paralel olarak işleyebilir.

• Mesaj iletimi: Aktörler yalnızca mesaj gönderip alarak etkileşim kurarlar ve mesaj iletimi eşzamansızdır.

• Dinamik yapı: Aktörler çalışma zamanında daha fazla Aktör yaratabilir. Bu dinamizm, Aktör modelinin ihtiyaç duyulduğunda sistemi genişletmesini sağlar.

TON, akıllı sözleşme modelini tasarlamak için bu mimariyi kullanır, bu da TON'da her akıllı sözleşmenin tamamen bağımsız depolama alanına sahip bir Aktör modeli olduğu anlamına gelir. Çünkü herhangi bir harici veriye dayanmaz. Ayrıca, aynı akıllı sözleşmeye yapılan çağrılar hala alıcı kuyruğundaki mesajların sırasına göre yürütülür, böylece TON'daki işlemler çakışmalar konusunda endişelenmeden paralel olarak verimli bir şekilde yürütülebilir.

Ancak bu tasarım bazı yeni etkiler de getiriyor. DApp geliştiricileri için alışılmış geliştirme paradigmaları aşağıdaki gibi bozulacak:

1. Akıllı sözleşmeler arası asenkron çağrılar: TON'un akıllı sözleşmeleri içinde harici sözleşmeleri çağırmak veya harici sözleşme verilerine atomik olarak erişmek imkansızdır. Solidity'de, sözleşme A'nın 1. fonksiyonundan sözleşme B'nin 2. fonksiyonunu çağırmak veya sözleşme C'nin salt okunur 3. fonksiyonu aracılığıyla belirli durum verilerine erişmek, tüm sürecin atomik olduğunu ve tek bir işlemde yürütüldüğünü biliyoruz ki bu çok kolay bir şeydir. Ancak TON'da bu mümkün olmayacaktır. Harici akıllı sözleşmelerle herhangi bir etkileşim, yeni işlemleri paketleyerek asenkron olarak yürütülecektir. Akıllı sözleşmeler tarafından başlatılan bu tür işlemlere dahili mesajlar da denir. Ve yürütme işlemi, yürütme sonucunu elde etmek için engellenemez.

Örneğin, bir DEX geliştirir ve EVM'deki ortak paradigmayı benimsersek, genellikle işlem yönlendirmesini yönetmek için birleşik bir yönlendirici sözleşmesi olacak ve her Havuz belirli bir işlem çiftiyle ilgili LP verilerini ayrı ayrı yönetecektir. Şu anda USDT-DAI ve DAI-ETH olmak üzere iki havuz olduğunu varsayalım. Bir kullanıcı doğrudan USDT aracılığıyla ETH satın almak istediğinde, atomik işlemi tamamlamak için yönlendirici sözleşmesi aracılığıyla bu iki havuzu tek bir işlemde sırayla talep edebilir. Ancak, TON'da bunu başarmak o kadar kolay değildir ve yeni bir geliştirme paradigması düşünmemiz gerekir. Bu paradigmayı yine de yeniden kullanırsak, bilgi akışı şu şekilde olabilir: bu talebe kullanıcı tarafından başlatılan harici bir mesaj ve üç dahili mesaj eşlik edecektir (bunun farkı göstermek için kullanıldığını unutmayın. Gerçek geliştirmede, ERC 20 paradigmasının bile yeniden tasarlanması gerekir).

2. Sözleşmeler arası çağrılarda yürütme hatalarının işlenme akışının dikkatlice değerlendirilmesi ve her sözleşmeler arası çağrı için karşılık gelen geri dönüş fonksiyonlarının tasarlanması gerekir. Ana akım EVM'de, bir işlemin yürütülmesi sırasında bir sorun oluştuğunda, tüm işlemin geri alınacağını, yani yürütmenin başlangıcındaki duruma sıfırlanacağını biliyoruz. Bu, seri tek iş parçacıklı modelde anlaşılması kolaydır. Ancak TON'da, sözleşmeler arası çağrılar eşzamansız olarak yürütüldüğünden, daha sonraki bir bağlantıda bir hata oluşsa bile, daha önce başarıyla yürütülen işlemler yürütülmüş ve onaylanmış olduğundan, bu sorunlara neden olabilir. Bu nedenle, TON'da geri tepme mesajı adı verilen özel bir mesaj türü ayarlanır, yani dahili bir mesaj tarafından tetiklenen sonraki yürütme sürecinde bir hata oluştuğunda, tetiklenen sözleşme, sözleşme tarafından ayrılmış geri tepme işlevini tetikleyerek sözleşmedeki belirli durumların sıfırlanmasını tetikleyebilir.

3. Bazı karmaşık durumlarda, ilk alınan işlem ilk olarak yürütülmeyebilir, dolayısıyla bu zamanlama ilişkisi önceden ayarlanamaz. Bu tür asenkron ve paralel akıllı sözleşme çağrıları sisteminde, işleme işlemlerinin sırasını tanımlamak zor olabilir. Bu nedenle TON'daki her mesajın mantıksal zamanı Lamport zamanı (bundan sonra lt olarak anılacaktır) vardır. Hangi olayın diğerini tetiklediğini ve doğrulayıcının önce neyi işlemesi gerektiğini anlamak için kullanılır. Basit bir model için, önce alınan işlem önce yürütülmelidir.

Bu modelde, A ve B sırasıyla iki akıllı sözleşmeyi temsil eder ve eğer msg 1 _lt ise bir zamanlama ilişkisi vardır.

Ancak daha karmaşık durumlarda bu kural bozulacaktır. Resmi belgede böyle bir örnek var. Diyelim ki A, B ve C adında üç sözleşmemiz var. Bir işlemde A, iki dahili mesaj msg 1 ve msg 2 gönderir: biri B'ye diğeri C'ye. Tam olarak aynı sırayla oluşturulmuş olsalar da (önce msg 1, sonra msg 2), msg 1'in msg 2'den önce işleneceğinden emin olamayız. Bunun nedeni, A'dan B'ye ve A'dan C'ye giden rotaların uzunluk ve doğrulayıcı kümesi açısından farklı olabilmesidir. Bu sözleşmeler farklı shard zincirlerindeyse, mesajlardan birinin hedef sözleşmeye ulaşması birkaç blok sürebilir. Yani, şekilde gösterildiği gibi iki olası işlem yolumuz var.

4. TON'da akıllı sözleşmelerinin kalıcı depolanması, veri yapısı olarak birim olarak Hücre'yi kullanan yönlendirilmiş bir döngüsüz grafik kullanır . Veriler kodlama kurallarına göre bir Hücreye sıkıştırılacak ve yönlendirilmiş döngüsüz bir grafik biçiminde aşağıya doğru uzatılacaktır. Bu, EVM'deki karma haritaya dayalı durum verilerinin yapısal organizasyonundan farklıdır. Farklı veri isteği algoritmaları nedeniyle, TON farklı derinliklerde veri işleme için farklı Gaz fiyatları belirler. Hücre veri işleme ne kadar derin olursa, gereken Gaz da o kadar yüksek olur. Bu nedenle, TON'da bir DOS saldırısı paradigması vardır, yani bazı kötü niyetli kullanıcılar çok sayıda spam mesajı göndererek akıllı sözleşmedeki tüm sığ Hücreleri işgal eder, bu da dürüst kullanıcıların depolama maliyetinin giderek daha da yükseleceği anlamına gelir. EVM'de, karma haritanın sorgu karmaşıklığı o(1) olduğundan, aynı Gaz vardır ve benzer bir sorun olmayacaktır. Bu nedenle, TON Dapp geliştiricileri akıllı sözleşmelerde sınırsız veri türlerinden kaçınmaya çalışmalıdır. Sınırsız veri türleri ortaya çıktığında, bunlar parçalanarak parçalanmalıdır.

5. Bazı özellikler o kadar da özel değil, örneğin depolama için kira ödemek için akıllı sözleşmelere ihtiyaç duyulması, akıllı sözleşmelerin TON'da doğal olarak yükseltilebilir olması ve yerel soyut hesap işlevi, yani TON'daki tüm cüzdan adreslerinin akıllı sözleşmeler olması, ancak başlatılmamış olması, vb. geliştiricilerin dikkatli olmasını gerektiriyor.

Yukarıdakiler bu dönemde TON ile ilgili teknolojileri öğrenme deneyimlerimden bazılarıdır. Bunları sizinle paylaşmak istiyorum. Herhangi bir hata varsa, beni düzeltebileceğinizi umuyorum. Aynı zamanda, Telegram'ın muazzam trafik kaynaklarıyla, TON ekosisteminin kesinlikle Web3'e bazı yeni uygulamalar getireceğine inanıyorum. TON DApp geliştirmeyle ilgilenen arkadaşlar da benimle iletişime geçip bizimle görüşebilirler.

X Bağlantıları: https://x.com/web3_mario

Telegram Kullanıcı Adı: @MarioChin Web3

Bu makale internetten alınmıştır: TON'un teknik özelliklerinin ve akıllı sözleşme geliştirme paradigmasının ayrıntılı açıklaması

İlgili: Based Memleri Yorumlama ve Based Institute: Base ekosisteminin geleceği nerede?

Orijinal kaynak: Jesse Pollak Derleyen: Odaily Planet Daily Wenser Editör Notu: 2024'ün en popüler L2 ekosistemlerinden biri olan Base'in yükselişinin doğru zaman, doğru yer ve doğru insanların sonucu olduğu söylenebilir - sadece Memecoin çılgınlığının getirdiği bulunmaz bir fırsata sahip olmakla kalmıyor, aynı zamanda OP ekosistemine dayanan ve Coinbase tarafından desteklenen L2 düşük gazlı ağa ve protokol lideri Jesse Pollak'ın ve bir grup ekosistem kurucusunun sıkı çalışmasına da sahip. TVL'si 5,5 milyar ABD dolarına ulaşan Base ekosistemine gelince, Jesse yakın zamanda New York Meme Hackathon'da kısa bir inceleme ve özet yaptı ve yakın zamanda içeriği NFT biçiminde Zora'ya koydu ve 4.000'den fazla bastı…