Ana içeriğe geç

Cüzdan Sözleşmesi Türleri

TON Blockchain üzerinde farklı versiyonlarda cüzdanlar hakkında duymuş olabilirsiniz. Ancak bu versiyonlar ne anlama geliyor ve birbirlerinden nasıl farklılar?

Bu makalede, TON cüzdanlarının çeşitli versiyonlarını ve değişikliklerini keşfedeceğiz.

bilgi

Başlamadan önce, makaleyi tam olarak anlamak için aşina olmanız gereken bazı terimler ve kavramlar var:

  • Mesaj yönetimi, çünkü bu cüzdanların ana işlevselliğidir.
  • FunC dili, çünkü bu dili kullanarak yapılan implementasyonlara büyük ölçüde dayanacağız.

Ortak Kavram

Gerginliği azaltmak için, cüzdanların TON ekosisteminde belirli bir varlık olmadığını anlamalıyız. Onlar hâlâ kod ve verilerden oluşan akıllı sözleşmelerdir ve bu anlamda TON'daki diğer aktörlerle (yani, akıllı sözleşme) eşittirler.

Kendi özel akıllı sözleşmeniz veya herhangi bir başkası gibi, cüzdanlar da harici ve dahili mesajlar alabilir, dahili mesajlar ve günlükler gönderebilir ve "get" yöntemleri sağlayabilir. Dolayısıyla, soru şudur: ne tür bir işlevsellik sağlarlar ve versiyonlar arasında nasıl farklılık gösterirler?

Her cüzdan versiyonunu, standart bir harici arayüz sağlayan, cüzdanlarla etkileşime geçmek için farklı harici istemcilerin aynı şekilde etkileşimde bulunmasına olanak tanıyan bir akıllı sözleşme implementasyonu olarak düşünebilirsiniz. Bu implementasyonları ana TON monorepo'da FunC ve Fift dillerinde bulabilirsiniz:

Temel Cüzdanlar

Cüzdan V1

Bu en basit olanıdır. Sadece aynı anda dört işlem göndermenize izin verir ve imzanız ve seqno dışında hiçbir şeyi kontrol etmez.

Cüzdan kaynak kodu:

Bu versiyon, bazı ciddi sorunları olduğu için normal uygulamalarda bile kullanılmaz:

  • Sözleşmeden seqno ve halka açık anahtarı almak için kolay bir yol yoktur.
  • valid_until kontrolü yoktur, bu nedenle işlemin çok geç onaylanmayacağından emin olamazsınız.

İlk sorun V1R2 ve V1R3'te düzeltildi. R, "revizyon" anlamına gelir. Genellikle, revizyonlar yalnızca get yöntemleri ekleyen küçük güncellemelerdir; bunların hepsini new-wallet.fif'in değişiklik geçmişinde bulabilirsiniz. Buradan sonra yalnızca en son revizyonlara odaklanacağız.

Yine de, her bir sonraki versiyon öncekinin işlevselliğini devraldığı için, bunu değiştirmemek önemli olacaktır; bu, sonraki versiyonlar için bize yardımcı olacaktır.

Kalıcı Bellek Düzeni

  • seqno: 32-bit uzunlukta sıra numarası.
  • public-key: 256-bit uzunlukta halka açık anahtar.

Harici Mesaj Gövde Düzeni

  1. Veri:
    • signature: 512-bit uzunlukta ed25519 imzası.
    • msg-seqno: 32-bit uzunlukta sıra numarası.
    • (0-4)mode: her bir mesaj için gönderme modunu tanımlayan en fazla dört 8-bit uzunlukta tamsayı.
  2. Mesajları içeren hücrelere kadar 4 referans.

Gördüğünüz gibi, cüzdanın ana işlevi TON blockchain ile dış dünyadan güvenli bir şekilde iletişim sağlamaktır. seqno mekanizması yeniden oynama saldırılarına karşı koruma sağlar ve Ed25519 imzası, cüzdan işlevselliğine yetkili erişim sağlar. Bu mekanizmalardan her birinin detaylarına girmeyeceğiz, çünkü bunlar harici mesaj belgelerinde ayrıntılı olarak açıklanmıştır ve harici mesaj alan akıllı sözleşmeler arasında oldukça yaygındır. Yük veri, hücrelere kadar 4 referans ve bunlarla ilişkili mod sayısını içermektedir ve bu doğrudan send_raw_message(cell msg, int mode) yöntemine aktarılacaktır.

tehlike

Cüzdanın gönderdiğiniz dahili mesajlar için herhangi bir doğrulama sağlamadığını unutmayın. Veriyi dahili mesaj düzenine göre seri hale getirmek programcının (yani, harici istemcinin) sorumluluğundadır.

Çıkış Kodları

Çıkış KoduAçıklama
0x21seqno kontrolü başarısız oldu, yanıt koruması gerçekleşti
0x22Ed25519 imzası kontrolü başarısız oldu
0x0Standart başarılı yürütme çıkış kodu.
bilgi

Not edin ki TVM standart çıkış kodlarına sahip olup (0x0 bunlardan biridir), örneğin, gas bittiğinde 0xD kodunu alabilirsiniz.

Get Yöntemleri

  1. int seqno() mevcut saklanan seqno'yu döner.
  2. int get_public_key() mevcut saklanan halka açık anahtarı döner.

Cüzdan V2

Cüzdan kaynak kodu:

Bu versiyon, işlemin çok geç onaylanmasını istemiyorsanız, bir işlem için bir zaman sınırı belirlemek için kullanılan valid_until parametresini tanıtır. Bu versiyon ayrıca, V2R2'de eklenen halka açık anahtar için bir get-yöntemi de yoktur.

Önceki versiyonla karşılaştırıldığında tüm farklılıklar, valid_until işlevselliğinin eklenmesinin bir sonucudur. valid_until kontrolünün başarısızlığını belirten yeni bir çıkış kodu eklendi: 0x23. Ayrıca, harici mesaj gövde düzenine yeni bir UNIX zaman alanı eklendi; bu, işlemin zaman sınırlamasını ayarlamaktadır. Tüm get metodları aynı kalır.

Harici Mesaj Gövde Düzeni

  1. Veri:
    • signature: 512-bit uzunlukta ed25519 imzası.
    • msg-seqno: 32-bit uzunlukta sıra numarası.
    • valid-until: 32-bit uzunlukta Unix-zaman tamsayısı.
    • (0-4)mode: her bir mesaj için gönderme modunu tanımlayan en fazla dört 8-bit uzunlukta tamsayı.
  2. Mesajları içeren hücrelere kadar 4 referans.

Cüzdan V3

Bu versiyon, aynı halka açık anahtarı kullanarak birden fazla cüzdan oluşturmanıza olanak tanıyan subwallet_id parametresini tanıtır (yani, yalnızca bir seed ifadesine sahip olabilirsiniz ve birden fazla cüzdanınız olabilir). Daha önce olduğu gibi, V3R2 sadece halka açık anahtar için bir get-yöntemi ekler.

Cüzdan kaynak kodu:

Esasen, subwallet_id sadece sözleşme dağıtıldığında sözleşme durumuna eklenen bir numaradır. TON'daki cüzdan adresi, durumunun ve kodunun bir hash'idir, dolayısıyla cüzdan adresi farklı bir subwallet_id ile değişecektir. Bu versiyon şu anda en yaygın olarak kullanılan versiyondur. Çoğu kullanım durumunu kapsar ve temiz, basit ve büyük ölçüde önceki versiyonlarla aynıdır. Tüm get yöntemleri aynı kalır.

Kalıcı Bellek Düzeni

  • seqno: 32-bit uzunlukta sıra numarası.
  • subwallet: 32-bit uzunlukta subwallet kimliği.
  • public-key: 256-bit uzunlukta halka açık anahtar.

Harici Mesaj Düzeni

  1. Veri:
    • signature: 512-bit uzunlukta ed25519 imzası.
    • subwallet-id: 32-bit uzunlukta subwallet kimliği.
    • msg-seqno: 32-bit uzunlukta sıra numarası.
    • valid-until: 32-bit UNIX zaman tamsayısı.
    • (0-4)mode: her bir mesaj için gönderme modunu tanımlayan en fazla dört 8-bit tamsayı.
  2. Mesajları içeren hücrelere kadar 4 referans.

Çıkış Kodları

Çıkış KoduAçıklama
0x23valid_until kontrolü başarısız oldu; işlem onaylama süresi çok geç
0x23Ed25519 imzası kontrolü başarısız oldu
0x21seqno kontrolü başarısız oldu; yanıt koruması etkinleştirildi
0x22subwallet-id saklananla eşleşmiyor
0x0Standart başarılı yürütme çıkış kodu.

Cüzdan V4

Bu versiyon, önceki versiyonların tüm işlevselliğini korurken, ayrıca çok güçlü bir şey de getirir: eklentiler.

Cüzdan kaynak kodu:

Bu özellik, geliştiricilerin bir kullanıcının cüzdanıyla birlikte çalışan karmaşık mantıklar gerçekleştirmesine olanak tanır. Örneğin, bir DApp'in belirli özellikleri kullanmak için her gün kullanıcıdan küçük bir miktar jeton ödemesi talep edebileceği bir durum söz konusu olabilir. Bu durumda, kullanıcı işlemi imzalayarak eklentiyi cüzdanına yüklemelidir. Eklenti, talep edildiğinde her gün belirlenen adrese jeton gönderecektir.

Eklentiler

Eklentiler, geliştiricilerin dilediği gibi uygulayabileceği diğer akıllı sözleşmelerdir. Cüzdan ile ilgili olarak, bunlar, cüzdanın kalıcı belleğinde bir sözlükte depolanan akıllı sözleşme adresleridir. Bu eklentiler, fon talep etme ve cüzdanın "izinli liste" sinden kendilerini çıkarma izinlerine sahiptir.

Kalıcı Bellek Düzeni

  • seqno: 32-bit uzunlukta sıra numarası.
  • subwallet-id: 32-bit uzunlukta subwallet-id.
  • public-key: 256-bit uzunlukta halka açık anahtar.
  • plugins: eklentileri içeren sözlük (boş olabilir).

Dahili Mesajları Alma

Önceki cüzdan versiyonlarının hepsi, dahili mesajları alma konusunda basit bir implementasyona sahipti. Sadece herhangi bir gönderenin gelen fonlarını kabul ettiler ve iç mesaj gövdesini dikkate almadılar; diğer bir deyişle, boş bir recv_internal yöntemleri vardı. Ancak, daha önce belirtildiği üzere, cüzdanın dördüncü versiyonu, iki yeni mevcut işlemi tanıtmaktadır. Dahili mesaj gövde düzenine bakalım:

  • op-code?: 32-bit uzunlukta işlem kodu. Bu isteğe bağlı bir alan; mesaj gövdesinde 32 bit'ten az içeren, yanlış bir op-kodu içeren veya tanımlı bir eklenti olarak kaydedilmemiş bir gönderen adresinin bulunduğu herhangi bir mesaj, önceki cüzdan versiyonlarına benzer şekilde basit transfer olarak değerlendirilecektir.
  • query-id: 64-bit uzunlukta tamsayı. Bu alanın akıllı sözleşmenin davranışı üzerinde bir etkisi yoktur; sözleşmeler arasındaki mesaj zincirlerini takip etmek için kullanılır.
  1. op-code = 0x706c7567, fon talebi işlem kodu.
    • toncoins: VARUINT16 miktarında talep edilen toncoinler.
    • extra_currencies: Talep edilen ek para birimlerinin miktarını içeren sözlük (boş olabilir).
  2. op-code = 0x64737472, izinli listeden eklenti-gönderenin kaldırılması talebi.

Harici Mesaj Gövde Düzeni

  • signature: 512-bit uzunlukta ed25519 imzası.
  • subwallet-id: 32-bit uzunlukta subwallet kimliği.
  • valid-until: 32-bit uzunlukta Unix-zaman tamsayısı.
  • msg-seqno: 32-bit uzunlukta sıra tamsayısı.
  • op-code: 32-bit uzunlukta işlem kodu.
  1. op-code = 0x0, basit gönderim.
    • (0-4)mode: her bir mesaj için gönderim modunu tanımlayan en fazla dört 8-bit uzunlukta tamsayı.
    • (0-4)messages: Mesajları içeren hücrelere kadar dört referans.
  2. op-code = 0x1, eklenti dağıtma ve yükleme.
    • workchain: 8-bit uzunlukta tamsayı.
    • balance: VARUINT16 toncoin miktarında başlangıç bakiyesi.
    • state-init: Eklentinin başlangıç durumunu içeren hücre referansı.
    • body: İçerik olan hücre referansı.
  3. op-code = 0x2/0x3, eklenti yükleme / eklentiyi kaldırma.
    • wc_n_address: 8-bit uzunlukta workchain_id + 256-bit uzunlukta eklenti adresi.
    • balance: VARUINT16 toncoin miktarında başlangıç bakiyesi.
    • query-id: 64-bit uzunlukta tamsayı.

Gördüğünüz gibi, dördüncü versiyon, önceki versiyonlara benzer şekilde 0x0 işlem kodu aracılığıyla standart işlevselliği sunmaya devam etmektedir. 0x2 ve 0x3 işlemleri eklentiler sözlüğünün manipülasyonuna olanak tanır. 0x2 durumunda, bu adresle eklentiyi kendiniz dağıtmanız gerektiğini unutmayın. Buna karşın, 0x1 işlem kodu, durum_init alanı ile dağıtım işlemini de yönetir.

ipucu

state_init adı itibarıyla pek anlamlı değilse, aşağıdaki referanslara göz atın:

  • ton-blokzincirindeki-adresler
  • dağıtım mesajı gönderme
  • dahili mesaj düzeni

Çıkış Kodları

Çıkış KoduAçıklama
0x24valid_until kontrolü başarısız oldu, işlem onaylama süresi çok geç
0x23Ed25519 imzası kontrolü başarısız oldu
0x21seqno kontrolü başarısız oldu, yanıt koruması etkinleştirildi
0x22subwallet-id saklananla eşleşmiyor
0x27Eklentiler sözlüğü manipülasyonu başarısız oldu (0x1-0x3 recv_external op-kodları)
0x50Fon talebi için yeterli bakiye yok
0x0Standart başarılı yürütme çıkış kodu.

Get Yöntemleri

  1. int seqno() mevcut saklanan seqno'yu döner.
  2. int get_public_key() mevcut saklanan halka açık anahtarı döner.
  3. int get_subwallet_id() mevcut subwallet ID'yi döner.
  4. int is_plugin_installed(int wc, int addr_hash) tanımlanan workchain ID ve adres hash'ine sahip eklentinin kurulu olup olmadığını kontrol eder.
  5. tuple get_plugin_list() eklentilerin listesini döner.

Cüzdan V5

Şu anda en modern cüzdan versiyonudur ve Tonkeeper ekibi tarafından geliştirilen, V4'ün yerini almayı ve rastgele uzantılar sağlamayı amaçlamaktadır.

V5 cüzdan standardı, kullanıcılar ve tüccarlar için deneyimi iyileştiren birçok fayda sunar. V5, gaz ücretsiz işlemleri, hesap devri ve kurtarma, tokenler ve Toncoin ile abonelik ödemelerini ve düşük maliyetli çoklu transferleri destekler. Önceki işlevselliği (V4) korumanın yanı sıra, yeni sözleşme aynı anda 255 mesaja kadar gönderim yapmanıza olanak tanır.

Cüzdan kaynak kodu:

TL-B şeması:

tehlike

Önceki cüzdan versiyonu spesifikasyonlarının aksine, TL-B şemasına dayanacağız, çünkü bu cüzdan versiyonunun arayüz implementasyonu görece karmaşıktır. Bunun için her biri için bazı açıklamalar sağlayacağız. Yine de, temel bir anlayış gereklidir; cüzdan kaynak kodu ile birlikte bu yeterli olmalıdır.

Kalıcı Bellek Düzeni

contract_state$_ 
is_signature_allowed:(## 1)
seqno:#
wallet_id:(## 32)
public_key:(## 256)
extensions_dict:(HashmapE 256 int1) = ContractState;

Gördüğünüz gibi, ContractState, önceki versiyonlarla karşılaştırıldığında büyük değişiklikler geçirmemiştir. Ana fark, imzayı ve saklanan halka açık anahtarı sınırlayan veya izin veren yeni is_signature_allowed 1-bit bayraktır. Bu değişikliğin önemini daha sonraki konularda açıklayacağız.

Kimlik Doğrulama Süreci

signed_request$_             // 32 (opcode from outer)
wallet_id: # // 32
valid_until: # // 32
msg_seqno: # // 32
inner: InnerRequest //
signature: bits512 // 512
= SignedRequest; // Toplam: 688 .. 976 + ^Cell

internal_signed#73696e74 signed:SignedRequest = InternalMsgBody;

internal_extension#6578746e
query_id:(## 64)
inner:InnerRequest = InternalMsgBody;

external_signed#7369676e signed:SignedRequest = ExternalMsgBody;

Mesajlarımızın gerçek yükü olan InnerRequest'e geçmeden önce, versiyon 5'in kimlik doğrulama sürecindeki önceki versiyonlardan nasıl farklı olduğuna bakalım. InternalMsgBody kombinatori, dahili mesajlar aracılığıyla cüzdan işlemlerine erişimin iki yolunu tanımlar. İlk yöntem, daha önceki sürümden zaten aşina olduğumuz yöntemdir: extensions_dict içinde saklanan, daha önce kaydedilmiş bir eklenti olarak kimlik doğrulama. İkinci yöntem ise, harici isteklerle benzer şekilde, saklanan halka açık anahtar ve imza aracılığıyla kimlik doğrulamasıdır.

İlk bakışta, bu gereksiz bir özellik gibi görünebilir, ancak aslında bu, cüzdanınızın eklenti altyapısının bir parçası olmayan harici hizmetler (akıllı sözleşmeler) aracılığıyla taleplerin işlenmesini sağlamaktadır; bu, V5'in ana özelliklerinden biridir. Gaz ücretsiz işlemler, bu işlevselliğe dayanmaktadır.

Not edin ki, fon kabul etmek hâlâ bir seçenektir. Pratikte, kimlik doğrulama sürecini geçemeyen herhangi bir alınan dahili mesaj, transfer olarak kabul edilecektir.

İşlemler

Öncelikle, kimlik doğrulama sürecinde daha önce gördüğümüz InnerRequest'i belirtmeliyiz. Önceki versiyonun aksine, hem harici hem de dahili mesajlar aynı işlevselliğe erişebilir, yalnızca imza modunu değiştirme (yani, is_signature_allowed bayrağı) dışındadır.

out_list_empty$_ = OutList 0;
out_list$_ {n:#}
prev:^(OutList n)
action:OutAction = OutList (n + 1);

action_send_msg#0ec3c86d mode:(## 8) out_msg:^(MessageRelaxed Any) = OutAction;

// V5'teki genişletilmiş işlemler:
action_list_basic$_ {n:#} actions:^(OutList n) = ActionList n 0;
action_list_extended$_ {m:#} {n:#} action:ExtendedAction prev:^(ActionList n m) = ActionList n (m+1);

action_add_ext#02 addr:MsgAddressInt = ExtendedAction;
action_delete_ext#03 addr:MsgAddressInt = ExtendedAction;
action_set_signature_auth_allowed#04 allowed:(## 1) = ExtendedAction;

actions$_ out_actions:(Maybe OutList) has_other_actions:(## 1) {m:#} {n:#} other_actions:(ActionList n m) = InnerRequest;

InnerRequest'i iki işlem listesi olarak düşünebiliriz: ilki, OutList, bir mesaj gönderim talebi içeren hücre referanslarının isteğe bağlı bir zinciridir, her biri mesaj moduna göre yönlendirilmiştir. İkincisi, bir-bit bayrağı has_other_actions ile yönetilen ActionList zinciridir; bu, eklentili işlemler varlığını işaret eder. İlk iki eklenti eylemi, action_add_ext ve action_delete_ext, ekleme veya silme istediğimiz dahili adresle birlikte takip edilir. Üçüncüsü, action_set_signature_auth_allowed, halka açık anahtar aracılığıyla kimlik doğrulamasını kısıtlar veya izin verir ve cüzdanla etkileşimde bulunmanın tek yolunu eklentiler aracılığıyla bırakır. Bu işlevsellik, kaybolan veya tehlikedeki özel anahtar durumunda son derece önemli olabilir.

bilgi

Maksimum işlem sayısının 255 olduğunu not edin; bu, c5 TVM kaydedicisinde gerçekleştirilmesinin sonucudur. Teknik olarak, boş OutAction ve ExtendedAction ile bir talep gönderebilirsiniz, ancak bu durumda, sadece fon kabul etmekle benzer bir durum olacaktır.

Çıkış Kodları

Çıkış KoduAçıklama
0x84İmza kullanarak kimlik doğrulama denemesi, bu devre dışı bırakıldığında
0x85seqno kontrolü başarısız, yanıt koruması gerçekleşti
0x86wallet-id saklanan ile eşleşmiyor

| 0x87 | Ed25519 imza kontrolü başarısız || 0x88 | valid-until kontrolü başarısız | | 0x89 | Dış mesaj için send_mode +2 bit (hataları göz ardı et) ayarını zorunlu kılın. | | 0x8A | external-signed ön eki alınan ile eşleşmiyor | | 0x8B | Uzantı ekleme işlemi başarısız oldu | | 0x8C | Uzantı kaldırma işlemi başarısız oldu | | 0x8D | Desteklenmeyen genişletilmiş mesaj ön eki | | 0x8E | Uzantı sözlüğü boşken imza ile kimlik doğrulamayı devre dışı bırakmaya çalıştı | | 0x8F | Önceden ayarlanmış bir duruma imza ayarlama denemesi | | 0x90 | İmza devre dışı bırakıldığında son uzantıyı kaldırma denemesi | | 0x91 | Uzantının yanlış çalışma zinciri var | | 0x92 | Dış mesaj aracılığıyla imza modunu değiştirmeye çalıştı | | 0x93 | Geçersiz c5, action_send_msg doğrulaması başarısız oldu | | 0x0 | Standart başarılı yürütme çıkış kodu. |

tehlike

0x8E, 0x90 ve 0x92 cüzdan çıkış kodlarının amacı, cüzdan işlevine erişiminizi kaybetmenizi engellemektir. Bununla birlikte, cüzdanın saklanan uzantı adreslerinin gerçekten TON'da mevcut olup olmadığını kontrol etmediğini unutmamalısınız. Ayrıca, başlangıç verileri olarak boş bir uzantılar sözlüğü ve kısıtlı imza modu ile bir cüzdan dağıtabilirsiniz. Bu durumda, ilk uzantınızı ekleyene kadar cüzdana açık anahtar aracılığıyla erişmeye devam edebileceksiniz. Bu nedenle, bu senaryolar konusunda dikkatli olun.

Get yöntemleri

  1. int is_signature_allowed(): saklanan is_signature_allowed bayrağını döndürür.
  2. int seqno(): mevcut saklanan seqno'yu döndürür.
  3. int get_subwallet_id(): mevcut alt cüzdan kimliğini döndürür.
  4. int get_public_key(): mevcut saklanan açık anahtarı döndürür.
  5. cell get_extensions(): uzantılar sözlüğünü döndürür.

Gazsız İşlemler İçin Hazırlık

v5 cüzdan akıllı sözleşmesinin, sahibi tarafından imzalanmış içsel mesajların işlenmesine izin verdiği daha önce söylenmiştir. Bu, örneğin, USDt'yi kendisinde transfer ederken ağ ücretlerinin ödenmesi gibi gazsız işlemler yapmanıza da olanak tanır. Genel şema şöyle görünmektedir:

image

ipucu

Sonuç olarak, Tonkeeper'ın Battery gibi bu işlevselliği sağlayan hizmetler olacaktır: kullanıcı adına TON'lar cinsinden işlem ücretlerini ödeyecek, ancak token cinsinden bir ücret talep edeceklerdir.

Akış

  1. Kullanıcı USDt gönderirken, iki dış USDt transferi içeren bir mesajı imzalar:
    1. Alıcının adresine USDt transferi.
    2. Hizmet lehine küçük bir USDt miktarının transferi.
  2. Bu imzalı mesaj, HTTPS aracılığıyla Hizmet arka ucu tarafından zincir dışı gönderilir. Hizmet arka ucu, bunu TON blockchain'ine gönderir ve ağ ücretleri için Toncoin öder.

Gazsız arka uç API'nin beta sürümü tonapi.io/api-v2 adresinde mevcuttur. Herhangi bir cüzdan uygulaması geliştiriyorsanız ve bu yöntemlerle ilgili geribildiriminiz varsa lütfen @tonapitech sohbetinde paylaşın.

Cüzdan kaynak kodu:

Özel cüzdanlar

Bazen temel cüzdanların işlevselliği yeterli olmaz. Bu nedenle, yüksek yük, kilitli ve kısıtlı olmak üzere birkaç özel cüzdan türü vardır.

Bunlara bir bakış atalım.

Yüksek Yük Cüzdanları

Kısa bir süre içinde birçok mesajla çalışırken, Yüksek Yük Cüzdanı adı verilen özel bir cüzdan ihtiyacı vardır. Daha fazla bilgi için makaleyi okuyun.

Kilitli cüzdan

Herhangi bir nedenle, belirli bir süre para çekme imkanı olmadan bir cüzdanda paraları kilitlemeniz gerekiyorsa, kilitli cüzdanına bir göz atın.

Bu, cüzdandan herhangi bir şey çekemeyeceğiniz zamanı ayarlamanıza olanak tanır. Ayrıca, bu ayarlara göre belirli dönemlerde bazı paraları harcayabilmenizi sağlayacak şekilde kilidi açma sürelerini de özelleştirebilirsiniz.

Örnek: 10 yıl toplam vesting süresi ile 1 milyon parayı tutacak bir cüzdan oluşturabilirsiniz. İlk yıl boyunca fonlar kilitlenmesi için vade süresini bir yıl olarak ayarlayın. Ardından, 1'000'000 TON / 120 ay = ~8333 TON her ay kilidi açılacak şekilde açma süresini bir ay olarak ayarlayabilirsiniz.

Cüzdan kaynak kodu:

Kısıtlı cüzdan

Bu cüzdanın işlevi, normal bir cüzdan gibi hareket etmek, ancak transferleri yalnızca bir önceden belirlenmiş varış adresine sınırlandırmaktır. Bu cüzdanı oluşturduğunuzda varış adresini ayarlayabilir ve ardından yalnızca bu adrese fon transferi yapabilirsiniz. Ancak, bu cüzdanla bir doğrulayıcı çalıştırmak için hâlâ doğrulama sözleşmelerine fon transferi yapabileceğinizi unutmayın.

Cüzdan kaynak kodu:

Bilinen op kodları

bilgi

Ayrıca op-kodu, op::kod ve işletim kodu olarak bilinir.

Sözleşme türüHex kodOP::Kod
Küresel0x00000000Metin Yorum
Küresel0xffffffffAtlama
Küresel0x2167da4bŞifreli Yorum
Küresel0xd53276dbAşırılıklar
Elektrik0x4e73744bYeni Hisse
Elektrik0xf374484cYeni Hisse Onayı
Elektrik0x47657424Hisse Kurtarma Talebi
Elektrik0x47657424Hisse Kurtarma Yanıtı
Cüzdan0x0f8a7ea5Jetton Transfer
Cüzdan0x235caf52Jetton Çağrı
Jetton0x178d4519Jetton İç Transfer
Jetton0x7362d09cJetton Bildir
Jetton0x595f07bcJetton Yak
Jetton0x7bdd97deJetton Yakma Bildirimi
Jetton0xeed236d3Jetton Durumunu Ayarla
Jetton-Minter0x642b7d07Jetton Mint
Jetton-Minter0x6501f354Jetton Yönetici Değiştir
Jetton-Minter0xfb88e119Jetton Yönetici Talep
Jetton-Minter0x7431f221Jetton Yönetici Bırak
Jetton-Minter0xcb862902Jetton Meta Verisini Değiştir
Jetton-Minter0x2508d66aJetton Güncelle
Vade0xd372158cYükleme
Vade0x7258a69bBeyaz Liste Ekle
Vade0xf258a69bBeyaz Liste Ekle Yanıtı
Vade0xa7733acdGönder
Vade0xf7733acdGönder Yanıtı
Dedust0x9c610de3Dedust Swap ExtOut
Dedust0xe3a0d482Dedust Swap Jetton
Dedust0xea06185dDedust Swap İçsel
Dedust0x61ee542dDışarı Takas
Dedust0x72aca8aaEş Takas
Dedust0xd55e4686Likidite Deposu İçsel
Dedust0x40e108d6Likidite Deposu Jetton
Dedust0xb56b9598Likidite Deposu tüm
Dedust0xad4eb6f5Havuzdan Ödeme
Dedust0x474а86саÖdeme
Dedust0xb544f4a4Depo
Dedust0x3aa870a6Para Çekme
Dedust0x21cfe02bHazine Oluşturun
Dedust0x97d51f2fVolatil Havuz Oluştur
Dedust0x166cedeeDepoyu İptal Et
StonFi0x25938561İç Takas
StonFi0xf93bb43fÖdeme Talebi
StonFi0xfcf9e58fLikidite Sağla
StonFi0xc64370e5Takas Başarılı
StonFi0x45078540Takas Başarılı referansı

Sonuç

Gördüğünüz gibi, TON'da birçok farklı cüzdan versiyonu vardır. Ancak çoğu durumda, sadece V3R2 veya V4R2'ye ihtiyacınız vardır. Periyodik olarak fonların kilidini açma gibi ek işlevselliğe sahip olmak istiyorsanız, özel cüzdanlardan birini de kullanabilirsiniz.

Ayrıca Bakın