Akıllı Sözleşme Adresleri
Bu bölüm, TON Blockchain üzerindeki sözleşme akıllı adreslerinin ayrıntılarını açıklayacak ve aktörlerin TON'daki akıllı sözleşmelerle eşanlamlı olduğunu açıklayacak.
Her Şey Bir Akıllı Sözleşmedir
TON'da akıllı sözleşmeler, Aktör modeli tarafından oluşturuluyor. Aslında, TON'daki aktörler teknik olarak akıllı sözleşmeler olarak temsil edilir. Bu, cüzdanınızın bile basit bir aktörü (ve akıllı sözleşme) olduğu anlamı gelir.
Tipik olarak, aktörler gelen ileti işleri, iç durum davranışlarını ve sonuç olarak çıkan mesajlar üretir. Bu nedenle, TON Blockchain'deki her aktörün (yani akıllı sözleşmenin) diğer aktörlerden mesaj alabilmesi için bir adresi olması gerekir.
Ethereum Sanal Makinesi'nde (EVM), adresler akıllı sözleşmelerden tamamen ayrıdır. Farklılıklar hakkında daha fazla bilgi edinmek için Tal Kol tarafından yazılan ["TON Blockchain'in Solidity geliştiricileri için sürpriz olacak altı benzersiz özelliği"](https://blog.ton.org/six-unique-aspects-of-ton-blockchain- that-will-surprise-solidity-geliştiricileri) makalemizi okuyoruz.
Akıllı Sözleşme Adresi
TON'da çalışan akıllı sözleşme adresleri genellikle iki ana yapısından oluşur:
(workchain_id): işlem zinciri aralığını belirtir (imzalı 32-bit tamsayı)
(account_id): kullanıcı adresini belirtir (işlem zincirine bağlı olarak 64-512 bit arasındaki değişiklikler)
Bu belgeler ham adresler bölümü, (workchain_id, account_id) çiftlerinin nasıl sunulduğunu tartışacağız.
İşlem Zinciri Kimliği ve Hesap Kimliği
İşlem Zinciri Kimliği
Daha önce gördüğümüz gibi, TON Blockchain'de 2^32ye kadar işlem zinciri oluşturmak mümkündür. Ayrıca, 32 bitlik önek akıllı adres sözleşmelerinin, TON Blockchain'deki farklı zincir işlemlerindeki akıllı sözleşme adresleriyle sahip olduğunu belirttik. Bu, akıllı sözleşmelerin TON Blockchain'deki farklı iş
Günümüzde, TON Blockchain'de yalnızca Masterchain (workchain_id=-1) ve bazen de temel workchain (workchain_id=0) çalışmaktadır.
Her ikisinin de 256-bit adresleri vardır, dolayısıyla bundan böyle workchain_id'nin 0 veya -1 olduğunu ve iş zinciri içindeki adresin tam olarak 256-bit olduğunu varsayarız.
Hesap Kimliği
TON'daki tüm hesap kimlikleri, MasterChain ve BaseChain'deki (veya temel çalışma zincirindeki) 256 bitlik adresleri kullanır.
Aslında Hesap Kimliği (account_id), akıllı sözleşme nesneleri (özellikle SHA256) için karma işlevler olarak tanımlanır. TON Blockchain üzerinde çalışan her akıllı sözleşme, iki ana bileşeni depolar. Bunlar şunları içerir:
- Derlenmiş kod. Bayt kodunda derlenen akıllı sözleşme mantığı.
- Başlangıç durumu. Sözleşmenin zincir üzerinde konuşlandırıldığı ilk andaki değerleri.
Son olarak, adres hesabını doğru bir şekilde almak için (Başlangıç kodu, Başlangıç durumu) nesne çiftine karşılık gelen hash değerini hesaplamak gerekir. Şu anda, TVM'in nasıl çalıştığına derinlemesine bakmayacağız, ancak TON'daki hesap kimliklerinin şu formül kullanılarak belirlendiğini anlamak önemlidir: : account_id = hash(başlangıç kodu, başlangıç durumu)
Zamanla, bu belgeler boyunca, TVM ve TL-B şemasının teknik özelliklerine ve genel bakışına daha derinlemesine dalacağız. Artık account_id oluşumuna ve bunların TON üzerindeki akıllı sözleşme adresleriyle etkileşimlerine aşina olduğumuza göre, Raw ve User-Friendly adresleri açıklayalım.
Ham ve Kullanıcı Dostu Adresler
TON'daki akıllı sözleşme adreslerinin iş zincirlerinden ve hesap kimliklerinden (özellikle MasterChain ve BaseChain için) nasıl yararlandığına dair kısa bir genel bakış sağladıktan sonra, bu adreslerin iki ana biçimde ifade edildiğini anlamak önemlidir:
- Ham adresler: Akıllı sözleşme adreslerinin orijinal tam gösterimi.
- Kullanıcı dostu adresler: Kullanıcı dostu adresler, daha iyi güvenlik ve kullanım kolaylığı sağlayan gelişmiş bir ham adres biçimidir.
Aşağıda, bu iki adres türü arasındaki farklar hakkında daha fazla bilgi vereceğiz ve TON'da kullanıcı dostu adreslerin neden kullanıldığını daha ayrıntılı olarak inceleyeceğiz.
Ham adres
Ham akıllı sözleşme adresleri bir iş zinciri kimliği ve hesap kimliği (workchain_id, account_id) içerir ve aşağıdaki biçimde görüntülenir:
- [decimal workchain_id]:[hexap_id ile 64 onaltılık basamak]
Aşağıda, iş zinciri kimliğini ve hesap kimliğini birlikte kullanan bir ham akıllı sözleşme adresi örneği verilmiştir (workchain_id ve account_id olarak ifade edilir):
-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260
Adres dizesinin başlangıcındaki "-1"e dikkat edin, bu, MasterChain'e ait bir workchain_id anlamına gelir.
:::Not Adres dizilerinde küçük karşılıkları yerine ('a', 'b', 'c' gibi) büyük harfler ('A', 'B', 'C', 'D' vb.) kullanılabilir. 'd' vb.). :::
Ham Adreslerle İlgili Sorunlar
Ham Adres formunu kullanmak tw sunaro ana sorunlar:
- Ham adres formatını kullanırken, bir işlemi göndermeden önce hataları ortadan kaldırmak için adresleri doğrulamak mümkün değildir. Bu, işlemi göndermeden önce yanlışlıkla adres dizisine karakter ekler veya çıkarırsanız, işleminizin yanlış hedefe gönderileceği ve para kaybına neden olacağı anlamına gelir.
- Ham adres formatını kullanırken, kullanıcı dostu adresler kullanan işlemleri gönderirken kullanılanlar gibi özel işaretler eklemek imkansızdır. Bu konsepti daha iyi anlamanıza yardımcı olmak için aşağıda hangi bayrakların kullanılabileceğini açıklayacağız.
Kullanıcı Dostu Adres
İnternette (örneğin, genel mesajlaşma platformlarında ve e-posta hizmet sağlayıcıları aracılığıyla) ve gerçek dünyada adres paylaşan TON kullanıcılarının deneyimini güvence altına almak ve basitleştirmek için kullanıcı dostu adresler geliştirildi.
Kullanıcı Dostu Adres Yapısı
Kullanıcı dostu adresler toplamda 36 bayttan oluşmakta ve sırasıyla aşağıdaki bileşenler üretilerek elde edilmektedir:
[bayraklar - 1 bayt] — Adreslere sabitlenen bayraklar, akıllı sözleşmelerin alınan mesaja tepki verme şeklini değiştirir. Kullanıcı dostu adres biçimini kullanan bayrak türleri şunları içerir:
- Zıplayabilir. Geri dönen veya geri dönen olmayan bir adres türünü belirtir. ("zıplayabilir" için 0x11, "zıplayamaz" için 0x51)
- isTestnetOnly. Yalnızca test ağı amaçları için kullanılan bir adres türünü belirtir. 0x80 ile başlayan adresler, üretim ağında çalışan yazılımlar tarafından kabul edilmemelidir.
- isUrlSafe. Bir adres için güvenli url olarak tanımlanan, kullanımdan kaldırılmış bir bayrağı belirtir. Tüm adresler daha sonra güvenli url olarak kabul edilir.
[workchain_id - 1 bayt] — Workchain kimliği (workchain_id), işaretli 8 bitlik bir tamsayı workchain_id tarafından tanımlanır. (BaseChain için 0x00, MasterChain için 0xff)
[account_id - 32 byte] — Hesap kimliği bir (big-endian'den oluşur -little-endian/)) İş zinciri içinde 256 bit adres.
[adres doğrulama - 2 bayt] — Kullanıcı dostu adreslerde, adres doğrulama önceki 34 bayttan bir CRC16-CCITT imzasından oluşur. (örneğin) Aslında, kullanıcı dostu adresler için doğrulamaya ilişkin fikir, tüm banka kartlarında kullanıcının olmayan yazmasını önlemek için kullanılan Luhn algoritmasına oldukça benzer. yanlışlıkla mevcut kart numaraları.
Bu 4 ana bileşenin eklenmesi şu anlama gelir: toplamda 1 + 1 + 32 + 2 = 36 bayt (kullanıcı dostu adres başına).
Kullanıcı dostu bir adres oluşturmak için geliştiricinin 36 baytın tamamını aşağıdakilerden birini kullanarak kodlaması gerekir:
- base64 (yani rakamlar, büyük ve küçük Latin harfleri, '/' ve '+')
- base64url ("/" ve "+" yerine "_" ve "-" ile)
Bu işlem tamamlandıktan sonra boşluksuz 48 karakter uzunluğunda kullanıcı dostu bir adresin oluşturulması tamamlanır.
TON'da bazen ham ve kullanıcı dostu adresler yerine mywallet.ton gibi DNS adresleri kullanılır. Aslında, DNS adresleri kullanıcı dostu adreslerden oluşur ve geliştiricilerin TON etki alanındaki DNS kaydındaki tüm bayraklara erişmesine izin veren gerekli tüm bayrakları içerir.
Kullanıcı Dostu Adres Kodlama Örnekleri
Örneğin, bir "test veren" akıllı sözleşmesi (istenen herkese 2 test belirteci gönderen testnet ana zincirinde bulunan özel bir akıllı sözleşme) aşağıdaki ham adresi kullanır:
-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260
Yukarıdaki "test veren" ham adresi, kullanıcı dostu adres formuna dönüştürülmelidir. Bu, base64 veya base64url formları (daha önce tanıttığımız) kullanılarak aşağıdaki gibi elde edilir:
kf/8uRo6OBbQ97jCx2EIuKm8Wmt6Vb15+KsQHFLbKSMiYIny(base64)kf_8uRo6OBbQ97jCx2EIuKm8Wmt6Vb15-KsQHFLbKSMiYIny(base64url)
:::bilgi Her iki formun da (base64 ve base64url) geçerli olduğuna ve kabul edilmesi gerektiğine dikkat edin! :::
Geri Dönebilen ve Geri Dönemeyen Adresler
Sıçrayabilen adres bayrağının arkasındaki temel fikir, gönderen güvenliğidir.
Örneğin, hedef akıllı sözleşme mevcut değilse veya işlem işlenirken geri alma sorunları ortaya çıkarsa, mesaj gönderene "geri döner" ve işlemin orijinal değerinin geri kalanını oluşturur (eksi tüm aktarım ve gaz ücretleri). Bu, gönderenin, işlemi kabul etmeyen bir adrese gönderilen fonlarını kaybetmemesini sağlar.
Özellikle geri çevrilebilir adreslerle ilgili olarak:
- bounceable=false işareti genellikle alıcının bir cüzdan olduğu anlamına gelir.
- bounceable=true bayrağı genellikle kendi uygulama mantığına (örneğin, bir DEX) sahip özel bir akıllı sözleşmeyi belirtir. Bu örnekte geri dönüşü olmayan mesajlar güvenlik nedeniyle gönderilmemelidir.
Bu konu hakkında daha fazlasını okumaktan çekinmeyin