TON'a ilk bakış: Hesaplar, Token'lar, İşlemler ve Varlık Güvenliği

Orijinal yazar: Johan

arka plan

TON (Açık Ağ), başlangıçta Telegram ekibi tarafından tasarlanıp geliştirilen merkezi olmayan bir blok zinciri platformudur. TON'un amacı, büyük ölçekli merkezi olmayan uygulamaları (DApp'ler) ve akıllı sözleşmeleri desteklemek için yüksek performanslı ve ölçeklenebilir bir blok zinciri platformu sağlamaktır.

TON çok özeldir. Kullanımı kolaydır. Telegram ile derinlemesine entegredir ve sıradan insanların token'ları kolayca kullanmasını sağlar. Ayrıca karmaşıktır. Diğer blok zincirlerinden tamamen farklı bir mimariye sahiptir ve ana akım olmayan FunC akıllı sözleşme dilini kullanır. Bugün TON'un özelliklerini ve kullanıcı varlıklarının güvenliğini hesaplar, token'lar ve işlemler açısından ele alacağız.

TON'un Özellikleri

Hesap Oluşturma

TON hesap adresinin oluşturulma şekli çoğu blok zincirinden farklıdır. Bu bir akıllı sözleşme adresidir. İlk olarak, özel bir anahtarla başlayın. TON, genel bir anahtar oluşturmak için çoğunlukla Ed 25519 algoritmasını kullanır. Oluşturma süreci şu şekildedir:

Ortak anahtarların iki biçimi vardır. Biri, özel anahtardan hesaplanan orijinal ortak anahtardır ve şu şekilde görünür:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Diğeri ise, genel anahtarın bazı bilgilerini ve kontrol bitlerini taşıyan güzelleştirilmiş bir genel anahtardır, örneğin: Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Ethereum gibi, sadece genel anahtarı alarak hesap adresini elde edebileceğinizi düşünmek safçadır. Sadece kullanıcının genel anahtarına sahip olmak, kullanıcı hesap adresini hesaplamak için yeterli değildir. Kullanıcı hesap adresinin akıllı sözleşme adresi olduğunu söyledik, ancak bir hesabımız bile yok, akıllı sözleşmeyi nasıl dağıtabiliriz? Doğru sıra, önce adresi hesaplamak, başlangıçta küçük miktarda token almak ve ardından sözleşmeyi dağıtmaktır. Hesap adresinin hesaplama süreci aşağıdaki şekilde gösterilmiştir:

Kullanıcı adresinin de birden fazla biçimi vardır. İlki, şu şekilde görünen orijinal biçimdir:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

Ve şu gibi kullanıcı dostu formlar:

Ana ağ:

Zıplayabilir:

EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX

Geri tepmez:

UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Test ağı:

Zıplayabilir:

kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd

Geri tepmez:

0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Bu adreslerin dikkatli bir şekilde incelenmesi, yalnızca ilk ve son karakterlerde farklılık gösterdiklerini gösterir. Ortadaki `account_id` aynıdır, ancak genel anahtar ile hesap adresi arasındaki ilişkiyi hala göremiyoruz. Aslında gizem, başlangıçtaki `başlangıç verileri`nde yatmaktadır; bu, kullanıcının cüzdan sözleşmesinin sahipliğini kontrol ettiği bir kullanıcı genel anahtarını içerir. `workchainId` anlaşılması kolaydır. TON yalnızca tek bir zincir değildir. Birçok parçadan oluşur. Her parça, tüm ağın bir parçasıdır ve belirli bir hesap ve işlem kümesini işler. Akıllı sözleşmeleri bulmak ve yönetmek için, hangi parçada bulunduklarını açıkça belirtmek gerekir. `Bounceable` ile `Non-bounceable` arasındaki fark nedir? Bu, akıllı sözleşmelerin çalışma mekanizmasıyla ilgilidir. Aşağıya bakmaya devam edelim.

Cüzdan Sözleşmesi

Aşağıda bir kullanıcı cüzdanı sözleşmesinin kaynak kodu bulunmaktadır. Kullanıcı mesajını alırken 4 parametreyi (stored_seqno, stored_subwallet, public_key, plugins) okuduğu görülebilir:

cüzdan-v4-kodu.fc

() recv_external(mesajdaki_dilim) saf olmayan {

var imza = in_msg~load_bits(512);

var cs = in_msg;

var (alt_cüzdan_kimliği, geçerli_tarih, mesaj_seqno) = (cs~load_uint( 32), cs~load_uint( 32), cs~load_uint( 32));

eğer_at( 36, geçerli_kadar

var ds = get_data().begin_parse();

var (stored_seqno, stored_subwallet, public_key, plugins) = (ds~load_uint( 32), ds~load_uint( 32), ds~load_uint( 256), ds~load_dict()); ;;## Başlangıç Verileri

ds.son_ayrıştırma();

throw_unless( 33, msg_seqno == saklı_seqno);

throw_unless( 34, alt cüzdan_kimliği == depolanan_alt_cüzdan);

throw_unless( 35, check_signature(dilim_karması(in_msg), imza, genel_anahtar));

//…

}

Doğru. Bu kullanıcı cüzdan sözleşmesini dağıtırken, her kullanıcının aynı sözleşme kodunu kullanırken bağımsız bir sözleşme adresine sahip olmasını sağlayan 256 bitlik bir public_key bilgisi de dahil olmak üzere bazı başlangıç parametrelerinin iletilmesi gerekir. Kullanıcı tarafından başlatılan tüm işlemlerin `in_msg` imzalaması ve ardından imzayı (check_signature) kendi cüzdan sözleşmeleri aracılığıyla doğrulaması gerekir ve ardından sözleşme zincirdeki tüm işlemleri çağırır. Bundan, bir kullanıcının genel anahtarının aslında sayısız cüzdan adresine karşılık gelebileceği sonucunu da çıkarabiliriz. Tamamen farklı sözleşme adresleri elde etmek için yalnızca farklı kaynak kodlarına veya farklı başlatma verilerine sahip cüzdanlar dağıtmanız gerekir.

Jetton jetonu

Token, varlıkların zincir üzerindeki temsilidir, bu nedenle anlamamız gereken temel bir unsurdur. Jetton, TON token'ının standart biçimidir. Jetton, Jetton-minter ve Jetton-wallet olmak üzere iki sözleşmeden oluşur:

Bir token verildiğinde, bir Jetton-minter sözleşmesi oluşturulur. Sözleşme başlatma, toplam token miktarını, yöneticileri, cüzdan kodlarını ve diğer bilgileri kaydeder.

Token'lar kullanıcılara dağıtıldığında, Minter sözleşmesi kullanıcı için bir cüzdan sözleşmesi dağıtacak ve sözleşme başlatıldığında kullanıcının bakiyesini, mülkiyetini, token Minter sözleşmesi adresini, kullanıcı cüzdan kodunu ve diğer bilgileri kaydedecektir. Her kullanıcı bağımsız olarak bir sözleşme dağıtacaktır. Burada oluşturulan sözleşmenin, kullanıcı hesabı cüzdan sözleşmesinden farklı olan belirli Jetton token'larını yönetmek için bir cüzdan sözleşmesi olduğunu unutmayın. Buradaki owner_address, kullanıcı hesabı cüzdan adresini kaydeder.

Alice kullanıcısı Bob kullanıcısına para transferi yaptığında çağrı ilişkisi şu şekilde olur:

Alice, zincir dışı APP'yi imzalar ve cüzdan sözleşmesini çağırarak işlem talimatları verir. Bu talimatlar, token'ı transfer etmek için token cüzdanını daha fazla çağırır. Bob'un token cüzdanı token'ı aldığında, Bob'un cüzdan sözleşmesini (yani, Bob Jetton-cüzdanının Sahip adresini) bilgilendirir. İşlem sırasında kalan herhangi bir Gaz varsa, bu da genellikle Alice'in hesap sözleşmesi olan yanıt adresine geri gönderilir.

Bu, Tonviewer tarayıcısı tarafından ayrıştırılan bir Jetton token transferidir:

Bir ERC 20 transferi en az bir sözleşme çağrısı gerektirirken, bir Jetton token transferi en az dört sözleşme gerektirir. Bu, transferlerin zincirde eş zamanlı olarak gerçekleştirilmesine izin vermek ve işlem verimliliğini artırmak için yapılır.

ticaret

TON'daki bir hesaba belirli olaylar gerçekleştiğinde, bir işlem tetiklenir. En yaygın olay bir mesaj almaktır. İşlem şunları içerir:

• Sözleşmeyi ilk tetikleyen gelen mesaj (özel tetikleme yöntemleri vardır)

• Gelen mesajların neden olduğu sözleşme eylemleri, örneğin sözleşme depolama alanının güncellenmesi (isteğe bağlı)

• Diğer katılımcılara giden mesajlar (isteğe bağlı)

İşlem yaparken dikkat edilmesi gereken birkaç özellik vardır:

1. Eşzamansız: TON işlemleri tek bir çağrıda tamamlanmaz. Bir dizi çağrıyı yürütmek için birden fazla farklı akıllı sözleşmeye mesaj iletmesi gerekebilir. Parça zincirindeki farklı yönlendirmeler nedeniyle TON, birden fazla akıllı sözleşme arasında mesaj geçişinin sırasını garanti edemez.

2. İşleme Ücretleri: Eşzamansız yapı da bir soruna yol açar, yani tüketilen işleme ücretlerinin tahmin edilmesi zordur. Bu nedenle, bir işlem başlatıldığında, cüzdan genellikle işleme ücreti olarak daha fazla token gönderir. Çağrılan sözleşmenin iyi bir işleme ücreti işleme mekanizması varsa, kalan işleme ücretleri sonunda kullanıcıların cüzdanına iade edilir. Kullanıcılar cüzdan tokenlarının aniden azaldığını ve birkaç dakika sonra tekrar arttığını gözlemleyebilir. Bunun nedeni budur.

3. Bounce: Bounce, sözleşmenin bir hata işleme mekanizmasıdır. Çağrılan sözleşme mevcut olmadığında veya bir hata verdiğinde, işlem bounceable olarak ayarlanmışsa, bounce mesajı çağıran sözleşmeye geri gönderilir. Örneğin: bir kullanıcı bir transfer başlatırsa ve çağrı süreci yanlış giderse, kullanıcının cüzdan sözleşmesinin bakiyesini geri yükleyebilmesi için bir bounce mesajına ihtiyaç vardır. Akıllı sözleşmeler arasında gönderilen hemen hemen tüm dahili mesajlar bounceable olmalıdır, yani bounce bitleri ayarlanmalıdır.

Varlık Güvenliği

TON'un güvenlik sorunlarına yol açabilecek pek çok özelliği bulunuyor, dolayısıyla kullanıcıların bazı yaygın tuzaklara karşı da dikkatli olması gerekiyor.

Ücret Tutma Saldırısı

Yukarıda belirtildiği gibi, cüzdanlar genellikle işlem yürütme hatalarını önlemek için daha fazla ücret göndermek zorundadır, bu da saldırganlara kötülük yapma fırsatı verir. Bir TON cüzdan kullanıcısıysanız, böyle bir durumla karşılaşmış olabilirsiniz. Cüzdanınıza her zaman çeşitli NFT'ler veya token'lar gelir. Bunların sadece önemsiz token airdrop'ları olduğunu düşündünüz, ancak işlem bilgilerini kontrol ettiğinizde bunların çok paraya satılabileceğini mi gördünüz? Ancak, bir işlem başlattığınızda, gerekli ücretin son derece yüksek olduğunu (1 TON) görürsünüz. Bu sırada, bunun bir ücret dolandırıcılığı olabileceği için dikkatli olmanız gerekir.

Saldırgan, cüzdanların tahmini transfer ücretini aşırı yüksek hale getirmek için dikkatlice oluşturulmuş bir token sözleşmesi kullandı, ancak gerçek uygulamada yalnızca ücret ele geçirildi ve herhangi bir transfer mesajı gönderilmedi.

İlk ve son sayı balıkçılığı

İlk ve son basamaklarla kimlik avı TON'a özgü değildir, ancak tüm büyük genel zincirlerde mevcuttur. Saldırgan, tüm ağdaki her kullanıcı adresi için aynı ilk ve son basamaklara sahip yüksek taklitli bir hesap oluşturacaktır. Kullanıcı bir transfer gönderdiğinde, saldırgan ayrıca yüksek taklitli hesapla küçük bir transfer gönderir ve amacı kullanıcının ödeme kaydında bir kayıt bırakmaktır. Alıcı bir token'ı geri transfer etmek istediğinde, adresi geçmiş kayıttan kopyalayabilir ve saldırganın adresine kopyalanması muhtemeldir, bu da transferin yanlış adrese yapılmasıyla sonuçlanır. Saldırgan, kullanıcının davranışını doğru bir şekilde kavrayabilir.

yorum balıkçılık

TON, para transfer ederken işlem bilgilerini not etmek için bir yorum ekleyebilir. Bu işlev, borsalarda yeniden yükleme yaparken sıklıkla kullanılır. Borsalar genellikle kullanıcıların yeniden yükleme yaparken kullanıcı kimliklerini not etmelerini gerektirir. Ancak, bu işlev genellikle kötü amaçlı kullanılır. Saldırganlar, kullanıcıların varlıklarını dolandırmak için yorumlara sahte bilgiler yazar. Şekilde gösterildiği gibi:

Kullanıcıların Anonim Telegram Numarası NFT'sine özellikle dikkat etmeleri gerekir. Bir kullanıcı Anonim Telegram Numarası ile bir TG numarası açarsa ancak İki Adımlı Doğrulamayı etkinleştirmezse, NFT dolandırıcılık yoluyla çalındığında, bilgisayar korsanları doğrudan hedef TG numarasına giriş yapabilir ve ardından varlık hırsızlığı ve dolandırıcılık gerçekleştirebilir.

Akıllı Sözleşme Güvenlik Açıkları

Akıllı sözleşmelerdeki güvenlik açıkları kullanıcıların akıllı sözleşmelere yatırılan fonları kaybetmelerine neden olabilir. Kullanıcıların iyi denetlenmiş projeleri seçmeleri gerekir. TON'un akıllı sözleşmeleri çoğunlukla FunC dilinde programlanır ve bazıları daha gelişmiş Tact veya daha düşük seviyeli Fift kullanır, bunlar oldukça özgün dillerdir. Yeni programlama dilleri, özellikle geliştiriciler için yeni güvenlik riskleri getirecektir. Güvenli programlama konusunda iyi alışkanlıklara sahip olmaları, en iyi güvenlik uygulamalarında ustalaşmaları ve üretim ortamlarına dağıtmadan önce sıkı güvenlik denetimlerinden geçmeleri gerekir. Yer kısıtlamaları nedeniyle, bu makale sözleşme güvenliğini ele almamaktadır.

Sahte şarj saldırısı

Cüzdan veya borsa kullanıcılarının sahte para yatırma saldırılarına karşı dikkatli olması gerekir. Bu saldırılar genellikle iki kategoriye ayrılır:

• Sahte para birimi, saldırgan hedef token ile aynı meta veriye sahip bir token yayınlar. Otomatik hesap girişi programı bunun doğru minter sözleşmesi olup olmadığını kontrol etmezse, yanlış hesap girişine yol açacaktır.

• Bounce, TON transfer süreci iki kullanıcının cüzdan sözleşmeleri arasında bir çağrı ilişkisi gerektirir. Alıcının cüzdan sözleşmesi yoksa ve işlem Bounceable olarak ayarlanmışsa, mesaj geri gönderilir ve orijinal fonlar işlem ücreti düşüldükten sonra göndericiye iade edilir. Ayrıntılarla ilgilenen arkadaşlar daha önce ifşa ettiğimiz sahte şarj makalemize göz atabilirler.

Özetle

Bu makale, TON'un genel ve özel anahtar oluşturma, cüzdan sözleşmeleri, token formları, işlem özellikleri vb. perspektiflerinden TON'un bazı temel teknik prensiplerini tanıtmaktadır. Ayrıca, TON kullanım sürecinde ortaya çıkabilecek olası güvenlik sorunlarını da ele alarak herkesin öğrenimine ilham vermeyi ummaktadır.

Referans Bağlantıları:

https://docs.ton.org/

https://github.com/ton-blockchain/wallet-contract

Bu makale internetten alınmıştır: TON'a ilk bakış: Hesaplar, Token'lar, İşlemler ve Varlık Güvenliği

İlgili: Forbes: 2024'ün ilk yarısında $1 milyarın üzerinde piyasa değerine sahip ilk 10 para birimi

Orijinal yazar: 1912212.eth, Forest News Bitcoin spot ETF'si bu yılın başında resmen işlem için onaylandıktan sonra, kripto para piyasası önemli bir yükseliş gördü. Bitcoin'e ek olarak, bazı MEME coin'leri de çok iyi performans gösterdi. Piyasa bu yılın nisan ayından beri düşüş eğiliminde olsa da, bazı token'lar genel olarak hala iyi bir piyasa performansına sahip. Forbes yakın zamanda, 2024'ün ilk yarısında $1 milyardan fazla piyasa değerine sahip en iyi performans gösteren ilk on kripto para birimini açıkladı. Bunlar arasında WIF, PEPE, ASI, FLOKI, JASMY, AR, CORE, TON, BGB ve BONK yer alıyor. MEME'nin 4 listede yer aldığını ve bunlardan 3'ünün Solana ekosistemine ait olduğunu belirtmekte fayda var. WIF Solana Ekosistemi MEME coin, yaklaşık 998 milyonluk toplam arzı ile…