Hızla gelişen blockchain teknolojisi alanında, TON (The Open Network), verimli ve esnek bir blockchain platformu olarak geliştiricilerin artan ilgisini çekiyor. TON'un benzersiz mimarisi ve özellikleri, merkezi olmayan uygulamaların geliştirilmesi için güçlü araçlar ve zengin olanaklar sunmaktadır.

Ancak, işlevsellik ve karmaşıklığın artmasıyla birlikte, akıllı sözleşmelerin güvenliği daha da kritik hale gelmiştir. TON üzerindeki akıllı sözleşme programlama dili FunC, esnekliği ve verimliliği ile bilinir, ancak birçok potansiyel risk ve zorluk da sunar. Güvenli ve güvenilir akıllı sözleşmeler yazmak, geliştiricilerin FunC'ın özelliklerini ve beraberinde gelen potansiyel riskleri derinlemesine anlamalarını gerektirir.

Bu makale, TON blok zincirindeki akıllı sözleşme ile ilgili özelliklerin detaylı bir analizini sunacak, aynı zamanda genellikle göz ardı edilen TON akıllı sözleşmelerindeki zayıf noktaları ele alacak.

TON'ın Asenkron Özelliklerinin ve Hesap Mekanizmasının Analizi

Akıllı Sözleşmelerde Asenkron Çağrılar

Ağ bölümleme ve Asenkron İletişim

TON blok zinciri üç farklı zincir tipi ile tasarlanmıştır: Ana zincir, Çalışan zincirler ve Parça zincirler.

Masterchain, tüm ağın çekirdeği olup, tüm ağın meta verilerini ve uzlaşma mekanizmasını depolamaktan sorumludur. Tüm Workingchain'lerin ve Shardchain'lerin durumlarını kaydeder ve ağın tutarlılığını ve güvenliğini sağlar. Workingchain'ler bağımsız blokzincirlerdir ve maksimum 2^32 zincir bulunur, belirli türdeki işlemleri ve akıllı sözleşmeleri yönetmekten sorumludur. Her Workingchain, farklı uygulama ihtiyaçlarını karşılamak için kendi kurallarına ve özelliklerine sahip olabilir. Shardchain'ler, Workingchain'lerin alt zincirleri olup, Workingchain'lerin iş yükünü daha fazla bölmek için kullanılır ve işleme kapasitesini ve ölçeklenebilirliği artırır. Her Workingchain, maksimum 2^60 Shardchain'e bölünebilir ve Shardchain'ler, bazı işlemleri bağımsız olarak ele alarak verimli paralel işleme sağlar.

Teoride, her hesap, her biri COIN/TOKEN bakiyesini bağımsız olarak koruyan bir Shardchain'i yalnızca işgal edebilir. Hesaplar arasındaki işlemler tamamen paralelleştirilebilir. Hesaplar asenkron mesajlar aracılığıyla iletişim kurar ve Shardchain'ler arasında mesajların seyahat etmesi için yol log_16(N) - 1'dir, burada N Shardchain'in sayısıdır.

Görüntü kaynağı: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574Web3 dünyasının bir parçası olarak, Ton'da etkileşimler mesaj gönderme ve alma yoluyla gerçekleştirilir. Bu mesajlar içsel olabilir (genellikle birbirleriyle etkileşimde bulunan akıllı sözleşmeler tarafından gönderilir) veya dışsal (dış kaynaklar tarafından gönderilir). Mesaj iletim süreci, hedef sözleşmeden anlık yanıtlar gerektirmez, gönderenin kalan mantığı yürütmeye devam etmesine izin verir. Bu asenkron iletişim mekanizması, Ethereum'un senkron çağrılarına kıyasla daha fazla esneklik ve ölçeklenebilirlik sunar, yanıtların beklenmesinden kaynaklanan performans darboğazlarını azaltırken, aynı zamanda paralellik ve yarış koşullarının ele alınmasında zorluklar da ortaya çıkar.

Mesaj formatı ve yapısı

TON'da mesajlar genellikle gönderici, alıcı, miktar ve mesaj gövdesi gibi bilgiler içerir. Mesaj gövdesi işlev çağrıları, veri transferleri veya diğer özel içeriklerden oluşabilir. TON'un mesaj formatı esnek ve genişletilebilir olarak tasarlanmıştır, farklı sözleşmeler arasında çeşitli bilgi türlerinin etkili iletişimine izin verir.

Mesaj kuyruğu ve durum işleme

Her sözleşme, henüz işlenmemiş olan mesajları depolamak için bir mesaj kuyruğunu korur. Yürütme sırasında, sözleşme kuyruktan sırayla mesajları işler. Mesaj işleme asenkron olduğundan, sözleşmenin durumu bir mesaj alındığında hemen güncellenmeyecektir.

Asenkron mesajlaşmanın avantajları

•Verimli Parçalama Mekanizması: TON'un asenkron mekanizması, parçalama tasarımıyla son derece uyumludur. Her parça, sözleşme iletilerini ve durum değişikliklerini bağımsız olarak işleyerek parçalar arası senkronizasyonun neden olduğu gecikmeleri önler. Bu tasarım, genel ağ aktarım hızını ve ölçeklenebilirliğini artırır.

• Azaltılmış Kaynak Tüketimi: Asenkron mesajlar anında yanıt gerektirmez, bu da TON sözleşmelerinin birden fazla blokta yürütülmesine ve tek bir blok içinde aşırı kaynak tüketiminden kaçınmasına olanak tanır. Bu, TON'un daha karmaşık ve kaynak yoğun akıllı sözleşmelere destek sağlamasını sağlar.

•Arıza Toleransı ve Güvenilirlik: Asenkron mesaj iletim mekanizması, sistem arıza toleransını artırır. Örneğin, bir sözleşme kaynak kısıtlamaları veya diğer nedenlerden dolayı zamanında bir mesaja yanıt veremezse, gönderici diğer mantığı işlemeye devam edebilir ve tek bir sözleşmedeki gecikmeler nedeniyle sistemin durmasını önleyebilir.

Eşzamansız sözleşme tasarımının zorlukları

•Durum Uyumsuzluk Sorunları: Mesaj iletme işleminin asenkron yapısı nedeniyle sözleşmeler farklı zamanlarda farklı mesajlar alabilir, bu da geliştiricilerin durum uyumluluğuna özel dikkat göstermelerini gerektirir. Sözleşmeler tasarlarken, farklı mesaj sıralamalarının durum değişikliklerini nasıl etkileyebileceğini düşünmek ve sistem'in tüm koşullar altında tutarlılığını sağlamak önemlidir.

•Yarış Koşulları ve Koruma: Asenkron ileti işleme, birden çok ileti aynı anda sözleşme durumunu değiştirmeye çalışabilir ve potansiyel yarış koşulu sorunlarını ortaya çıkarabilir. Geliştiriciler, durum çatışmalarını önlemek için uygun kilit mekanizmalarını uygulamalı veya işlem bazlı operasyonları kullanmalıdır.

•Güvenlik Düşünceleri: Asenkron sözleşmeler, çapraz sözleşme iletişimi işlemlerini ele alırken ara saldırıları veya tekrar saldırılarını içeren risklere açıktır. Bu nedenle, asenkron sözleşmeler tasarlarken, zaman damgaları, rastgele sayılar veya çok imza yaklaşımları gibi önleyici önlemler almak gibi olası güvenlik risklerini ele almak önemlidir.

Defter modeli

TON (The Open Network), blockchain altyapısını tasarlarken benzersiz bir hesap soyutlama ve defter modeli kullanır. Bu modelin esnekliği, hesap durumlarını, mesaj iletimini ve sözleşme yürütmesini nasıl yönettiğinde yansır.

Hesap soyutlaması

TON'un hesap modeli, her hesabın bir sözleşme olarak görülebileceği bir sözleşme tabanlı soyutlama kullanır. Bu, Ethereum'un hesap soyutlama modeline oldukça benzer, ancak daha esnek ve geneldir. TON'da hesaplar sadece varlıklar için konteynerler değildir, aynı zamanda sözleşme kodu ve durum verilerini de içerir. Her hesap, kodu, verileri ve mesaj işleme mantığından oluşur.

Hesap Yapısı: Her TON hesabının benzersiz bir adresi vardır, bu adres hesap kodunun hash değeri, dağıtımdaki başlangıç verileri ve diğer parametrelerin bir kombinasyonundan oluşur. Bu, farklı ortamlarda (örneğin, farklı blok zincirleri veya parçacıklar) dağıtılan aynı kod ve başlangıç verilerinin farklı adresler üretebileceği anlamına gelir.

Esneklik: Her hesap kendi sözleşme kodunu yürütebildiği için, TON hesapları çok karmaşık mantığı uygulayabilir. Hesaplar sadece basit bakiye tutucuları değil, karmaşık durum geçişleri, hesaplar arası mesaj iletişimi ve hatta belirli koşullara dayalı otomasyonu yönetebilir. Bu, TON'un hesap modelinin geleneksel blockchain hesap modellerine göre daha ölçeklenebilir ve esnek olmasını sağlar.

Defter yapısı

TON'un defter yapısı, büyük ölçekli eşzamanlı işlemleri verimli bir şekilde işlemek üzere tasarlanmıştır ve asenkron mesaj geçişi ve çoklu shard işlemlerini destekler. Her hesabın durumu, etkin durum doğrulama özellikleri sağlayan bir Merkle ağacı yapısında depolanır.

Durum Depolama

Hesap durumu bilgileri kalıcı depolamada saklanır ve bütünlük ve güvenlik sağlamak için bir Merkle ağacıyla düzenlenir. Bu tasarım ayrıca özellikle çapraz shard işlemlerinde etkili sorgulama ve doğrulama sağlar.

Bir hesap veya akıllı sözleşme durumu genellikle şunları içerir:

1. 2. Diğer para birimlerinin bakiyesi 3. Akıllı sözleşme kodu (veya hash'i) 4. Akıllı sözleşmenin kalıcı verileri (veya Merkle hash'i) 5. Kalıcı depolama birimlerinin sayısına ve ham bayt kullanımına ilişkin istatistikler 6. Akıllı sözleğin kalıcı depolama için son ödeme zaman damgası (esasen ana zincir blok numarası) 7. Bu hesaptan para transferi ve mesaj göndermek için gerekli genel anahtar (isteğe bağlı; varsayılan olarak bu, account_id ile aynıdır). Bazı durumlarda, Bitcoin işlem çıkışlarına benzer şekilde daha karmaşık imza kontrol kodları burada bulunabilir; bu tür durumlarda, account_id bu kodun hash'i olacaktır.

Her hesap için tüm bilgiler gerekli değildir. Örneğin, akıllı sözleşme kodu "basit" hesaplar için değil, yalnızca akıllı sözleşmeler için geçerlidir. Ek olarak, her hesapta temel para biriminin sıfır olmayan bir bakiyesi olması gerekirken (örneğin, temel çalışma zinciri ve parça zincirleri için Gram), diğer para birimi bakiyeleri sıfır olabilir. Kullanılmayan verilerin saklanmasını önlemek için, çeşitli "yapıcı işlevlerini" ayırt etmek için farklı işaretleme baytları kullanan bir çalışma zincirinin oluşturulması sırasında bir toplam-çarpım türü tanımlanır. Sonuç olarak, hesap durumu TVM'nin kalıcı deposunda bir birim koleksiyonu olarak kaydedilir.

Mesaj Aktarımı ve İşleme

TON'un defter yapısı, asenkron mesaj iletimine yerleşik destek içerir. Her hesap, aldığı mesajları bağımsız olarak işleyebilir ve durumunu güncelleyebilir. Bu asenkron mesajlaşma mekanizması, tek bir işlemdeki gecikmeler nedeniyle diğer hesapların normal işleyişini etkilemeden hesaplar arasında karmaşık etkileşimlere olanak tanır.

Gaz modeli

TON (The Open Network), benzersiz gaz ücreti modeli aracılığıyla akıllı sözleşmelerin yürütme verimliliğini önemli ölçüde optimize eder. Bu gaz ücreti modeli, akıllı sözleşmenin yürütülmesi sırasında tüketilen kaynakları ölçmek ve sınırlamak için kullanılır. Ethereum gibi geleneksel blok zincirleriyle karşılaştırıldığında, TON'un modeli daha karmaşık ve verimlidir ve sözleşmenin yürütülmesi sırasında kaynak tüketiminin daha hassas bir şekilde yönetilmesine olanak tanır.

TON'un gaz modeli, akıllı sözleşmenin yürütülmesi sırasında tüketilen hesaplama kaynaklarını, depolama işlemlerini ve mesaj iletme maliyetlerini doğru bir şekilde ölçebilir. TON'un gaz modeli, hesaplama, depolama ve mesajlaşma gibi kaynaklar için ayrıntılı ölçümler sağlayarak, aşırı karmaşıklığa sahip operasyonların çok fazla kaynak tüketmesini önler. TON, gaz tüketimini sınırlayarak, her bir ağ düğümünün hesaplama kaynaklarını adil bir şekilde tahsis edebilmesini sağlar ve ağ kaynaklarının tek bir sözleşme veya işlemle aşırı kullanılmasını önler.

TON, akıllı sözleşmelerin paralel işlenmesini destekler, böylece farklı shardlarda birden çok sözleşmenin birbirini bloke etmeden eşzamanlı olarak çalışmasına olanak sağlar. Bu tasarımda, gaz modeli paralel yürütme ve shard mekanizmalarıyla yakından entegredir. Birden çok shard üzerinde paralel olarak sözleşmeleri işleyerek, TON gaz hesaplama ve ödeme işlemini farklı düğüm ve zincirler arasında dağıtabilir, ağ sıkışıklığını önlerken kaynak kullanımını maksimize edebilir.

TON'un gaz modeli, ağın gerçek zamanlı yüküne bağlı olarak gaz ücretlerinin ayarlanmasına izin veren dinamik bir ayarlama mekanizması içerir. Bu, daha düşük ağ yükü dönemlerinde kullanıcıların daha düşük gaz ücretleriyle sözleşmeleri yürütebileceği anlamına gelir, bu da kullanıcıları düşük talep saatlerinde işlem yapmaya teşvik eder ve ağ kaynak kullanımını dengeleyerek zirve kaynak kullanımını kontrol eder. Bu mekanizma, kullanıcı deneyimini geliştirmenin yanı sıra piyasa odaklı bir yaklaşım ile zirve kaynak kullanımını kontrol eder.

TON akıllı sözleşmeleri, hataları göz ardı etmek için kolaydır

İçindeönceki güvenlik analizi makalemizTON üzerinde, TON ekosistemi içindeki yaygın güvenlik açıklarını detaylı bir şekilde açıkladık. Daha fazla referans için lütfen aşağıdaki tabloya bakın:

Bu makale, ekibimiz tarafından özetlendiği üzere, TON sözleşmelerindeki genellikle gözden kaçan güvenlik açıklarına odaklanacaktır:

(1) Kod Okunabilirliği Optimizasyonu

TON akıllı sözleşmelerinde, genellikle mesaj gönderme ile ilgili verileri depolamak için sayılar kullanılır. Örneğin, aşağıdaki kodda, karşılık gelen tanımlayıcıları ve veri depolama uzunluklarını temsil etmek için birden çok sayı örneği kullanılır, bu da kodun okunabilirliğini ve bakımını önemli ölçüde azaltır. Diğer geliştiriciler, kodu okurken bu sayıların anlamını ve amacını anlamakta zorlanabilirler. Okunabilirliği ve bakımı artırmak için, anahtar sayısal değerleri adlandırılmış sabitler olarak tanımlamanız önerilir. Örneğin, tanımlayıcılar tanımlayın0x18asNON_BOUNCEABLE.

1. check_std_addr(adres);msg = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(adres) store_coins(miktar) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);

Ek olarak, sözleşme yargılama koşullarındaki hata mesajı için, hata kodlarını değiştirmek için ilgili değişkenlerin tanımlanması da önerilir.

(2) Kullanarakend_parse()Veri Bütünlüğünü Sağlamak İçin

TON sözleşmelerinde, veri ayrıştırma işlemi, ham veriden adım adım belirtilen veri türlerini yükleyerek sabit bir sırayı takip eder. Bu ayrıştırma yöntemi, aşağıda gösterildiği gibi veri tutarlılığını ve doğruluğunu sağlar:

Dikkat etend_parse()boş bir veri dilimi olup olmadığını kontrol etmek için kullanılır. Dilim boş değilse, işlev bir istisna fırlatacaktır. Bu, verinin formatının ve içeriğinin beklenildiği gibi olduğundan emin olur. Eğerend_parse()fonksiyon dilimin içinde kalan verileri algılarsa, veri ayrıştırmanın amaçlanan şekilde devam etmediğini veya veri formatında bir sorun olduğunu gösterebilir. Bu nedenle, şu şekilde çağrı yaparakend_parse(), ayrıştırma süreci sırasında herhangi bir eksiklik veya anormallik olup olmadığını doğrulayabilirsiniz.

(3) Eşleşmeyen Veri Depolama ve Türlerden Kaynaklanan İstisnalar

Bu, çoğunlukla eşleştirme ile ilgilidir.Intveuintdepolama tipleri. Örneğin, aşağıdaki kodda,store_int()fonksiyon, bir değeri depolamak için kullanılırentdeğer-42, ama load_uint()bu değeri yüklemek için kullanılır, bu da bir istisnaya neden olabilir.

(4) Doğru Kullanımıinline_refvesatır içiDeğiştiriciler

İlk olarak, arasındaki farkı belirlemek önemlidir diziliveinline_refdeğiştiriciler:

satır içi: Fonksiyonlar ile satır içiDeğiştiriciler, her çağrıldıklarında kodlarının doğrudan çağrı noktasına yerleştirilir. Bu, işlevin gerçek kodunun işlev sıçraması aracılığıyla yürütülmesi yerine çağrı konumuna kopyalandığı anlamına gelir, bu da işlev çağrısı üzerindeki maliyeti azaltır ancak kod çoğaltmasına neden olabilir.

inline_ref: ile çalışır inline_ref değiştirici kodlarını ayrı bir hücrede saklar. İşlev her çağrıldığında, TVM, hücrede depolanan kodu CALLREF komutu, kod tekrarını önler ve daha karmaşık işlevler veya birden çok kez çağrılanlar için verimliliği artırır.

Özetle, kullanın satır içi Çağrı yükünü azaltmak için basit işlevler için, ancak olası kod yinelemesine dikkat edin. Kullanmak inline_ref verimliliği artırmak ve kod tekrarını önlemek için daha büyük veya sık çağrılan işlevler için.

(5) Doğru Çalışma Zincirini Belirleme

TON, her biri 2^32 çalışma zinciri oluşturmaya izin verir ve her biri 2^60 parçaya kadar daha da bölünebilir. Başlangıçta, iki çalışma zinciri bulunur: ana zincir (-1) ve temel zincir (0). Sözleşmelerde hedef adresleri hesaplarken, oluşturulan cüzdan adresinin doğru çalışma zinciri kimliğini belirtmek önemlidir. Yanlış adresler oluşturmayı önlemek için doğru çalışma zinciri kullanılması önerilir.force_chain()zincir kimliğini açıkça belirtmek.

(6) Hata Kodu Çakışmalarını Önleme

Sözleşme tasarımında hata kodlarının etkili yönetimi, tutarlılığı sağlamak ve karışıklığı önlemek için önemlidir. TON akıllı sözleşmeler için, her hata kodunun çatışmaları önlemek ve belirsiz hata mesajlarını önlemek için sözleşme içinde benzersiz olmasını sağlayın. Ek olarak, TON platformu veya alt sistem tarafından tanımlanan standart hata kodlarıyla çakışmalardan kaçının. Örneğin, 333 hata kodu zincir kimliği uyumsuzluğunu gösterir. Bu tür çakışmaları önlemek için 400 ile 1000 arasında hata kodları kullanmanız önerilir.

(7) Verilerin Saklanması ve Aranması dönüş() Operasyon Tamamlandıktan Sonra

TON akıllı sözleşmelerinde, mesaj işleme işlemi op-koduna göre farklı mantık seçimini içerir. Karşılık gelen mantık tamamlandıktan sonra, iki ek adım gereklidir: İlk olarak, veri değiştirildiyse, çağrı yapılır,save_data()değişikliklerin saklandığından emin olun; aksi takdirde, değişiklikler etkisiz olacaktır. İkinci olarak, çağrı yapın return()işlemin tamamlandığını belirtmek için; aksi takdirde, biratma(0xffff)istisna tetiklenecektir.

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {

int flags = cs~load_uint(4);

if (bayraklar & 1) {

;; tüm geri dönen mesajları yoksay

return ();

}

slice sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

if ((op == op::op_1())) {

handle_op1();

save_data();

return ();

}

if ((op == op::op_2())) {

handle_op2();

save_data();

return ();

}

if ((op == op::op_3())) {

handle_op3();

save_data();

return ();

Invalid input

at(0xffff);

}

Özetle, yenilikçi mimarisi ve esnek geliştirme ortamı ile TON blok zinciri, merkezi olmayan uygulama geliştiricileri için ideal bir platform haline geliyor. Bununla birlikte, akıllı sözleşmeler TON ekosisteminde giderek daha önemli bir rol oynadığından, güvenlik sorunları göz ardı edilemez. Geliştiriciler, sözleşmelerin sağlamlığını ve güvenliğini sağlamak için TON ekosisteminin özelliklerini derinlemesine anlamalı, en iyi uygulamalara sıkı sıkıya bağlı kalmalı ve güvenlik denetim süreçlerini geliştirmelidir. Ancak bu şekilde TON platformunun avantajları tam olarak gerçekleştirilebilir, daha güvenli ve daha güvenilir merkezi olmayan uygulamalar oluşturulabilir ve tüm ekosistemin sağlıklı gelişimi güvence altına alınabilir.

TON ekosistemi şu anda hızlı bir büyüme yaşıyor ve önemli miktarda fon ve aktif kullanıcı çekiyor. Ancak, eşlik eden güvenlik sorunları göz ardı edilemez. TON ekosisteminin güvenliğini ve güvenilirliğini sağlamak için Beosin, TON akıllı sözleşme çağrılarının ve operasyonlarının özelliklerine göre uyarlanmış kapsamlı ve profesyonel güvenlik denetimleri sağlayarak ekosistemin gelişimini destekler.

Beosin, TON ekosistemi içinde birçok başarılı vaka gerçekleştirmiştir. Daha önce Beosin, önde gelen merkezi olmayan stabilcoin projesi Aqua Protocol ve DeFi altyapısı ONTON Finance için kapsamlı güvenlik denetimleri gerçekleştirdi. Denetim, akıllı sözleşme kodunun güvenliği, iş mantığı uygulamasının doğruluğu, sözleşme kodunun gaz optimizasyonu ve potansiyel zayıflıkların tespiti ve giderilmesi gibi çoklu yönleri kapsadı.

Açıklama:

1. Bu makale [kaynak] adresinden yeniden üretilmiştir.Beosin], orijinal başlık 'Beosin Hard Core Araştırma | Riskten Korunmaya: TON Akıllı Sözleşmelerinin Güvenlik Riskleri ve Optimizasyon Önerileri', telif hakkı orijinal yazarına aittir [.Beosin], yeniden basım konusunda herhangi bir itirazınız varsa, lütfen iletişime geçin.Gate Learn Ekibi, ekip ilgili prosedürlere göre mümkün olan en kısa sürede halledecektir.

2. Açıklama: Bu makalede yer alan görüşler yalnızca yazarın kişisel görüşlerini temsil etmekte olup herhangi bir yatırım tavsiyesi teşkil etmemektedir.

3. Diğer dil sürümleri, Gate Learn ekibi tarafından çevrildi ve bahsedilmedi.Gate.io, çevrilen makale çoğaltılamaz, dağıtılamaz veya kopyalanamaz.