CashTokens: yerel tokenlar Bitcoin Cash'e geliyor

Giriş ve arka plan

2008'in sonlarında Bitcoin fikri “peer-to-peer bir elektronik nakit sistemi” olarak sunuldu, aslında Satoshi Nakamoto, bu protokolün temellerini attığı teknik belgeyi bu ifadeyle başlattı. Satoshi'nin kendi sözleriyle, elektronik nakit, kişilerin “finansal bir kurumdan geçmeden” doğrudan ödeme yapmalarını sağlar; bu prensip, Bitcoin-BTC'nin 2017 yılına kadar temel dayanağı oldu. 2017'de “Bitcoin'in nakit olarak” savunucuları, Bitcoin Cash (BCH) adlı ayrı bir ağa geçmek zorunda kaldılar – İngilizce'de “Bitcoin cash”. Böylece, dijital para kavramı, özellikle BCH durumunda bu niteliği tartışmasız bir şekilde savunan Bitcoin teknolojisinin başlangıç noktasıdır.

Bu nitelik, diğer kullanım durumlarının entegrasyonuyla çelişmez, yeter ki bunları entegre etmek, BCH'nin para olarak kullanılma yeteneğini veya daha fazla kişinin bunu bu şekilde benimsemesi için sistemini ölçeklendirme yeteneğini riske atmasın.

Bu anlamda, Bitcoin Cash (BCH), “CHIP” adı verilen bir fikir sunma, tartışma ve standartlaştırma sürecine sahiptir; bu da nakit iyileştirme önerilerinin kısaltmasıdır (. Bitcoin-BTC'nin “BIP” veya “Bitcoin iyileştirme önerileri” gibi, topluluğun yeni işlevler eklemek için geliştirilecek fikirlerin uygunluğunu tartışmasına ve değerlendirmesine olanak tanır.

Yıllardır peşinden koşulan işlevlerden biri, Bitcoin Cash blockchain'i üzerinden diğer varlıkların transfer edilme olasılığıdır. Kripto para dünyasında genellikle “token” veya “jeton” olarak adlandırılan, birçok kripto ekosisteminde oldukça popüler olan varlıklar, bulundukları ağlara ek ekonomik faaliyet sunar ve akıllı sözleşmelerin uygulanabilmesi gibi işlevlerle birlikte, merkeziyetsiz borsalarda takas edilebilir veya DeFi platformlarında kullanılabilir.

BCH'nin BTC'den bağımsız hale geldiği zaman, “renkli paralar” kavramına dayanan token'ların dahil edilmesi için birkaç öneri vardı; bu kavram, ) Bitcoin Cash'in çok küçük bir miktarının gönderilmesine, örneğin (, token transfer etmek için meta veriler içeren işlemlerle referans eder. Başka bir deyişle, BCH işlemlerini diğer varlıklar için bir araç olarak kullanmak, bu ekli meta verileri bir token, transfer edilen miktar vb. olarak yorumlayabilen bir protokol gerektirir.

Bu fikir, Bitcoin Cash )BCH( ağı üzerinde çeşitli protokoller aracılığıyla uygulanmaya başladı ve en bilinen ve uzun ömürlü olanı “Simple Ledger Protocol” veya "SLP tokenleri"dir.

Ancak, “renkli paralar” modelinin belirli sınırlamaları vardır; içerdiği bilgileri doğrulamak için ek yazılım çalıştırma gerekliliği ve bu işlemleri geçerli sayabilmek için en az 1 onay bekleme zorunluluğu gibi. Bu zayıflıklardan dolayı, “renkli paralar” token gönderip almak için geçerli bir alternatif sunar, ancak ana para ile yapılan ödemelerin niteliklerini eşitler.

Yeni standart: daha iyi bir model

15 Mayıs 2023'te Bitcoin Cash )BCH(, diğer yeni işlevlerin yanı sıra, “renkli paralar” protokollerinin getirdiği kısıtlamalar olmaksızın token transferi yapabilme yeteneğini içeren bir güncelleme ile entegre edilecektir. Bu yeni işlevin teknik spesifikasyonuna “CHIP-2022-02” tanımlayıcısı atanmıştır ve adı "CashTokens: Bitcoin Cash için token primitifleri"dir. Basit terimlerle, CashTokens, SLP tokenlerinin “Basit Defter Protokolü” ile karşılaştırıldığında üst düzey bir çözümü temsil etmekte olup, diğer şeylerin yanı sıra aşağıdaki özelliklerle farklılık göstermektedir:

• “SLP token” destekli altyapının, bu tür işlemleri doğrulamak için ek yazılım olan “SLP düğümleri” çalıştırması gerekiyordu; yani, işlemlerdeki metadata'dan yola çıkarak doğrulama yapması gerekiyordu. CashTokens durumunda, desteği sadece bir Bitcoin Cash düğümü gerektirir, bu nedenle madenciler ve tam düğüm operatörleri onun geçerliliğini tasdik edebilir.
• SLP token işlemleri 0-conf ile uyumlu değildir, bu nedenle ilk onayı beklemeden işlemleri kabul etmek riskli olabilir. CashTokens ile yapılan işlemler 0-conf ile uyumludur, bu nedenle 200$'dan daha düşük onayı olmayan işlemleri güvenilir kabul etmek mantıklıdır.
• Bitcoin Cash ağı “UTXO” modeline dayansa da, SLP tokenlerinin işlemleri “DAG” modeli ile doğrulanır. CashTokens işlemleri ise UTXO modeline dayanır, bu da bu standardın işlemlerini doğrularken daha yüksek bir verimlilik sağlar.

Bu avantajlar, birçok diğerinin yanı sıra, CashToken'ların daha iyi bir kullanıcı deneyimi sunmasını sağlar ve kendi kendine saklanan cüzdanlar ile ticaret platformlarının token gönderimi ve depolanmasıyla uyumluluğunu genişletme konusunda yaşanan sürtüşmeyi azaltır. Öte yandan, CashToken'larla yapılan işlemler, Bitcoin Cash cinsinden madencilere ücret öder, bu nedenle nihai olarak popülaritesi sistemin sürdürülebilirliğine katkıda bulunacaktır.

CashTokens: tokenlerin ilkel biçimleri

CashTokens'un teknik spesifikasyonunda “Token Primitives for Bitcoin Cash” ifadesi resmi isim olarak geçmektedir. Bu ifade, İspanyolca konuşan bir kitle için biraz kafa karıştırıcı olabilir, çünkü )yanlış( bir şekilde “primitif”, az sofistike veya DeFi ile sınırlı bir şey ifade ettiği düşünülebilir.

Ancak, CashTokens yalnızca Bitcoin Cash'in script dilinde yazılmış akıllı sözleşmelerle uyumlu değildir, aynı zamanda terim basitlik çağrıştırmayı amaçlamamaktadır. Bu bağlamda “primitifler” ifadesi, bir protokolün temel bir işlevine atıfta bulunmaktadır; protokolün yerel bir işlevi olduğundan, kavramın çok daha net bir çevirisi “Bitcoin Cash için yerel Token'lar” olabilir.

Güncelleme: Öncelikle makale, CashToken'ların ), SLP( token'larından farklı olarak iki adres formatının kullanımını gerektirmediğini belirtiyordu. Bitcoin Cash )BCH( yerel token'ları, hem BCH hem de CashToken'ları alabilen token bilinci olan adreslerin kullanımına izin verdiğinden, bir düzeltme yapılmıştır. Normal formatta yalnızca BCH alan adresler de bulunmaktadır. İki formatın kullanımı, kullanıcıların bu tür varlıkları yansıtmayan cüzdanlara token göndermemesi içindir. Öte yandan, <<token primitives=“”>> teriminin çevirisi <<tokens primitivos=“”>> olarak düzeltilmiştir. Doğru çeviri <<primitivas de=“” token=“”>> veya aynı fikri iletmek için alternatif olarak <<tokens nativos=“”>> olmalıdır.</tokens></primitivas></tokens></token></token>