Yeni Başlayanlar İçin TON Kılavuzu: Hesaplar, Jetonlar ve Güvenlik

Arka plan

TON (The Open Network), başlangıçta Telegram ekibi tarafından tasarlanan ve geliştirilen merkezi olmayan bir blok zinciri platformudur. TON, büyük ölçekli merkezi olmayan uygulamaları (DApps) ve akıllı sözleşmeleri desteklemek için yüksek performanslı ve ölçeklenebilir bir blok zinciri platformu sağlamayı amaçlamaktadır.

TON, kullanımı kolay, Telegram ile derinlemesine entegre olması ve sıradan insanların tokenleri kolayca kullanmasına olanak sağlaması açısından benzersizdir. Aynı zamanda, diğer blok zincirlerinden farklı bir mimariyle karmaşıktır ve FunC adlı ana akım olmayan bir akıllı sözleşme dili kullanır.

Bugün, TON’un özelliklerini ve kullanıcı varlıklarının güvenliğini hesaplar, tokenler ve işlemler açısından tartışacağız.

TON’un Özellikleri

Hesap Oluşturma

TON’da bir hesap adresi oluşturma yöntemi çoğu blok zincirinden farklıdır; bu bir akıllı sözleşme adresidir. İlk olarak, her şey özel bir anahtarla başlar. TON, açık anahtar oluşturmak için öncelikle Ed25519 algoritmasını kullanır ve süreç aşağıdaki gibidir:

Açık anahtarın iki şekli vardır: Birincisi, özel anahtardan hesaplanan ham açık anahtardır ve aşağıdaki gibi görünür:

E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D

Diğeri ise bazı bilgiler ve kontrol bitleri içeren “güzelleştirilmiş” bir açık anahtardır ve şöyle görünür:

Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2

Sadece açık anahtarı almanın Ethereum’daki gibi hesap adresini elde etmenizi sağlayacağını düşünüyorsanız yanılıyorsunuz. Sadece kullanıcının açık anahtarına sahip olmak, kullanıcının hesap adresini hesaplamak için yeterli değildir.

Belirtildiği gibi, kullanıcının hesap adresi bir akıllı sözleşme adresidir, ancak bir hesabınız olmadan bir akıllı sözleşmeyi nasıl dağıtabilirsiniz?

Doğru sıra, önce adresi hesaplamak, bir miktar başlangıç jetonu almak ve ardından sözleşmeyi dağıtmaktır. Hesap adresini hesaplama süreci aşağıdaki şemada gösterilmektedir:

Bir kullanıcının adresi de birden fazla biçimde gelir. İlk olarak, aşağıdaki gibi görünen ham form vardır:

0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296

Ardından, aşağıdaki gibi görünen kullanıcı dostu bir form vardır:

Mainnet:

• Sıçrayabilir: EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
• Sıçrayamaz: UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S

Testnet:

• Sıçrayabilir: kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
• Sıçrayamaz: 0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY

Bu adresleri dikkatle incelediğinizde, sadece ilk ve son birkaç karakterde farklılık gösterdiklerini, ortadaki account_id‘in aynı olduğunu görebilirsiniz.

Ancak, açık anahtar ile hesap adresi arasındaki ilişkiyi hala göremiyoruz.

İşin sırrı, kullanıcının cüzdan sözleşmesini kontrol etmesini sağlayan, kullanıcının açık anahtarını içeren başlangıçtaki initial data‘de yatmaktadır. workchainId‘nin anlaşılması kolaydır; TON sadece tek bir zincir değil, birçok parçadan oluşur.

Her shard, tüm ağın bir parçasıdır ve belirli hesapları ve işlemleri yönetir. Akıllı sözleşmeleri bulmak ve yönetmek için hangi shard’da olduklarını belirtmek gerekir. Bounceable ve Non-bounceable arasındaki fark nedir?

Bu, akıllı sözleşmelerin çalışma şekliyle ilgilidir, ancak daha fazla bakmaya devam edelim.

Cüzdan Sözleşmesi

Aşağıda bir kullanıcı cüzdan sözleşmesinin kaynak kodundan bir parça yer almaktadır. Kullanıcıdan bir mesaj alırken dört parametre okuduğunu göstermektedir: stored_seqno, stored_subwallet, public_key ve plugins:

wallet-v4-code.fc



() recv_external(slice in_msg) impure {

var signature = in_msg~load_bits(512);

var cs = in_msg;

var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));

throw_if(36, valid_until <= now());

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()); ;;##The Initial Data

ds.end_parse();

throw_unless(33, msg_seqno == stored_seqno);

throw_unless(34, subwallet_id == stored_subwallet);

throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));

//...

}

Aslında, bu kullanıcı cüzdan sözleşmesi dağıtıldığında, 256 bit public_key dahil olmak üzere bazı başlangıç parametreleri gerektirir. Bu, aynı sözleşme kodunu kullanırken bile her kullanıcının benzersiz bir sözleşme adresine sahip olmasını sağlar.

Kullanıcı tarafından başlatılan her işlem in_msg ile imzalanmalı, ardından cüzdan sözleşmesi (check_signature) tarafından doğrulanmalı ve ardından sözleşme blok zincirinde işlemler gerçekleştirmelidir. Buradan, bir kullanıcının açık anahtarının çok sayıda cüzdan adresine karşılık gelebileceği sonucunu çıkarabiliriz.

Farklı cüzdan sözleşmelerinin dağıtılması veya farklı başlatma verilerinin kullanılması tamamen farklı sözleşme adresleriyle sonuçlanacaktır.

Jetton Token

Bir token, blok zincirindeki bir varlığı temsil eder ve bu da onu anlamamız gereken temel bir unsur haline getirir. Jetton, TON tokenlerinin standart formudur ve iki sözleşmeden oluşur: Jetton-minter ve Jetton-wallet.

Bir token çıkarıldığında, bir Jetton-minter sözleşmesi oluşturulur. Bu sözleşme başlatma işlemi, toplam token arzı, yönetici, cüzdan kodu ve diğer ayrıntılar gibi bilgileri kaydeder.

Tokenlar kullanıcılara dağıtıldığında, Minter sözleşmesi her kullanıcı için bir cüzdan sözleşmesi dağıtır. Sözleşme başlatma sırasında, kullanıcının bakiyesini, sahipliğini, token Minter sözleşme adresini, kullanıcı cüzdan kodunu ve diğer ilgili bilgileri kaydeder. Her kullanıcının ayrı ayrı konuşlandırılmış bir sözleşmesi vardır.

Burada oluşturulan sözleşmenin, kullanıcının hesap cüzdanı sözleşmesinden farklı olan belirli Jetton tokenlerini yönetmek için bir cüzdan sözleşmesi olduğuna dikkat etmek önemlidir. Burada kaydedilen owner_address, kullanıcının hesap cüzdanının adresidir.

Alice Kullanıcısı belirteçleri Bob Kullanıcısına aktardığında, çağırma ilişkisi aşağıdaki gibidir:

Alice işlemi zincir dışı bir uygulama aracılığıyla imzalar ve cüzdan sözleşmesi aracılığıyla operasyonel bir komut gönderir. Bu komutlar, transferi gerçekleştirmek için token cüzdanını da çağıracaktır. Bob’un token cüzdanı tokenları aldığında, Bob’un cüzdan sözleşmesini (Bob’un Jetton cüzdanının sahip adresi) bilgilendirir.

İşlem sırasında kalan gaz varsa, genellikle Alice’in hesap sözleşmesi olmak üzere uygun adrese iade edilir.

Aşağıda Tonviewer tarayıcısı tarafından ayrıştırılan bir Jetton token aktarımı örneği yer almaktadır:

Bir ERC20 transferi yalnızca tek bir sözleşme çağrısı gerektirirken, bir Jetton token transferi en az dört sözleşme çağrısı gerektirir. Bu yöntem, zincir içi eşzamanlılığı mümkün kılarak işlem verimliliğini artırmak üzere tasarlanmıştır.

İşlemler

Bir TON hesabında belirli bir olay meydana geldiğinde, bu bir işlemi tetikler. En yaygın olay “bir mesaj almaktır”. Bir işlem aşağıdaki unsurları içerir:

• Sözleşmeyi başlangıçta tetikleyen gelen mesaj (özel tetikleme yöntemleri mevcuttur).
• Sözleşmenin deposunun güncellenmesi gibi gelen mesajdan kaynaklanan sözleşme eylemleri (isteğe bağlı).
• Diğer katılımcılara gönderilen giden mesajlar (isteğe bağlı).

İşlemlerle ilgili olarak bilinmesi gereken birkaç temel özellik vardır:

1. Asenkron: TON işlemleri tek bir çağrıda tamamlanmaz; bir dizi çağrının yürütülmesi için birden fazla farklı akıllı sözleşmeye mesaj iletilmesi gerekebilir. Parçalanmış zincirlerdeki farklı yönlendirmeler nedeniyle TON, birden fazla akıllı sözleşme arasında mesaj iletim sırasını garanti edemez.
2. Ücretler: İşlemlerin eşzamanlı olmayan doğası, tüketilen ücretlerin tahmin edilmesinde bir zorluk yaratmaktadır. Bu nedenle, cüzdanlar genellikle bir işlem başlatırken ücret olarak biraz daha fazla token gönderir. Eğer çağrılan sözleşme iyi bir ücret işleme mekanizmasına sahipse, kalan ücretler kullanıcının cüzdanına iade edilir. Kullanıcılar, bu mekanizma nedeniyle cüzdan tokenlerinin aniden azaldığını ve birkaç dakika sonra tekrar arttığını fark edebilir.
3. Zıpla: Bounce, sözleşmelerde bir hata işleme mekanizmasıdır. Çağrılan sözleşme mevcut değilse veya bir hata verirse ve işlem sıçrayabilir olarak ayarlanmışsa, çağıran sözleşmeye sıçrayan bir mesaj döndürülür. Örneğin, bir kullanıcı bir transfer başlatırsa ve işlem sırasında bir hata oluşursa, kullanıcının cüzdan sözleşmesinin bakiyesini geri yükleyebilmesi için bir geri dönme mesajı gereklidir. Akıllı kontratlar arasında gönderilen neredeyse tüm dahili mesajlar bounceable olmalıdır, yani “bounce” biti ayarlanmış olmalıdır.

Varlık Güvenliği

TON, güvenlik sorunlarına yol açabilecek birçok özelliğe sahiptir, bu nedenle kullanıcıların bazı yaygın tuzakların farkında olması gerekir.

Ücret Stopajı Saldırısı

Belirtildiği gibi, cüzdanların işlem başarısızlığını önlemek için genellikle biraz ekstra ücret göndermesi gerekir, bu da saldırganlar için bir fırsat sağlar. Eğer bir TON cüzdan kullanıcısıysanız, cüzdanınızın sık sık çeşitli NFT’ler ya da tokenlar aldığı bir durumla karşılaşmış olabilirsiniz.

Başlangıçta bunlar çöp tokenlar gibi görünebilir, ancak işlem ayrıntılarını kontrol ettikten sonra, önemli miktarda para karşılığında satılabileceklerini görüyorsunuz. Ancak, bir işlem başlatmaya çalıştığınızda, gerekli ücretin son derece yüksek (1 TON) olduğunu fark ediyorsunuz. Bu noktada dikkatli olmalısınız çünkü bu bir ücret dolandırıcılığı olabilir.

Saldırganlar, cüzdanın aşırı yüksek bir transfer ücreti tahmin etmesine neden olan dikkatlice hazırlanmış bir token sözleşmesi oluşturur, ancak gerçekte yalnızca ücret alıkonulur ve hiçbir transfer mesajı gönderilmez.

İlk ve Son Rakamla Kimlik Avı

İlk ve son rakam kimlik avı TON’a özgü değildir; bu kimlik avı saldırısı birçok büyük blok zincirinde mevcuttur. Saldırganlar, ağdaki her kullanıcı adresi için aynı ilk ve son rakamlara sahip sahte bir hesap oluşturur.

Bir kullanıcı bir transfer başlattığında, saldırgan da kullanıcının işlem geçmişinde bir kayıt bırakmak için kullanıcının işlemini takiben küçük bir transfer gönderir. Alıcı kullanıcı jetonları geri göndermek istediğinde, işlem geçmişindeki adresi kopyalayabilir, bu adres saldırganın adresi olabilir ve yanlış adrese transfer yapılmasına neden olabilir. Saldırgan, kullanıcının davranışını doğru bir şekilde istismar etmiştir.

Yorum Oltalama

TON üzerinde token transferi yaparken, kullanıcılar işleme açıklama eklemek için bir yorum ekleyebilir. Bu özellik genellikle borsalarda para yatırırken kullanılır; borsalar genellikle kullanıcıların kullanıcı kimliklerini para yatırma yorumuna dahil etmelerini gerektirir. Ancak bu özellik, kullanıcıların varlıklarını çalmak için yorumlara hileli bilgiler yazan kötü niyetli kişiler tarafından sıklıkla istismar edilmektedir. Örneğin:

Kullanıcılar özellikle “Anonim Telegram Numarası” NFT’si konusunda dikkatli olmalıdır. Bir kullanıcı Telegram hesabını Anonim Telegram Numarası ile etkinleştirir ancak İki Adımlı Doğrulamayı etkinleştirmezse ve bu NFT sahte ise, bilgisayar korsanı doğrudan hedef Telegram hesabına giriş yapabilir ve sonraki varlık hırsızlığı ve dolandırıcılık faaliyetlerine devam edebilir.

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

Akıllı sözleşmelerdeki güvenlik açıkları, sözleşmede depolanan fonların kaybedilmesine yol açabilir. Kullanıcılar kapsamlı bir denetimden geçmiş projeleri seçmelidir. TON’un akıllı sözleşmeleri öncelikle FunC dili kullanılarak programlanır, ancak bazıları daha gelişmiş Tact veya daha düşük seviyeli Fift kullanır.

Tüm bu diller son derece özgündür. Yeni programlama dilleri, özellikle güvenli kodlama alışkanlıkları edinmesi, en iyi güvenlik uygulamalarında uzmanlaşması ve üretim ortamına dağıtılmadan önce sıkı güvenlik denetimlerinden geçmesi gereken geliştiriciler için yeni güvenlik risklerini de beraberinde getirmektedir. Yer kısıtlamaları nedeniyle bu makalede sözleşme güvenliği ayrıntılı olarak ele alınmayacaktır.

Sahte Para Yatırma Saldırısı

Cüzdan veya borsa kullanıcıları, genellikle iki şekilde ortaya çıkan sahte para yatırma saldırılarına karşı dikkatli olmalıdır:

1. Sahte Jetonlar: Bir saldırgan, hedef token ile aynı meta verilere sahip bir token yayınlar. Otomatik para yatırma programı tokenin doğru madenci sözleşmesinden olup olmadığını kontrol etmezse, yanlış para yatırma işlemlerine yol açabilir.
2. Zıpla: TON’un transfer işlemi, iki kullanıcının cüzdan sözleşmeleri arasında bir çağırma ilişkisi gerektirir. Alıcının cüzdan sözleşmesi mevcut değilse ve işlem geri dönebilir olarak ayarlanmışsa, mesaj geri dönecek ve orijinal fonlar, ücret hariç, gönderene iade edilecektir. Ayrıntılarla ilgilenenler, sahte para yatırma işlemleriyle ilgili önceki makalemize başvurabilir.

Sonuç

Bu makale, anahtar ve cüzdan oluşturma, token formları ve işlem özellikleri perspektiflerinden TON’un bazı temel teknik ilkelerini tanıttı. Ayrıca, öğrenme yolculuğunuza ilham vermesi umuduyla TON kullanırken olası güvenlik sorunlarını da araştırdı.