BTC ayrıca kendi akıllı sözleşmeler fonksiyonuna sahip olacak

Son zamanlarda, Bitcoin ekosisteminde Fractal BTC adlı bir projenin bir dizi test ağı geçirdikten sonra Eylül ayında resmi ana ağa geçti. Fractal'ın en büyük özelliklerinden biri, akıllı sözleşmeler yeteneğine sahip olması ve ana ağın lansmanı ile birlikte yeni bir token protokolü CAT20'yi piyasaya sürmesidir. Peki, CAT20'nin teknik olarak ne gibi zekice yönleri var? Bu süreçten neler öğrenebiliriz?

Fraktal Bitcoin Tanıtımı

CAT20'yi anlamadan önce, Fractal Bitcoin'i kısaca anlamamız gerekiyor. İkisi arasındaki ilişki, ERC20 ile ETH arasındaki ilişkiye benzer; CAT20 protokolü, Fractal Bitcoin'in üzerine konuşlandırılmıştır.

Fractal Bitcoin, aynı zamanda fraktal Bitcoin olarak da bilinir, tamamen BTC ile uyumlu bir "ikinci katman" ağdır. BTC'ye kıyasla, blok onay süresi daha hızlıdır, sadece 1 dakikadır. Temel prensibi basitçe, BTC ağının birkaç kopyasını alarak, her bir zincirin işlem yapabilmesi ve işlem yapabilen düğümlerin sayısının artması ile hızın doğal olarak artmasıdır. Ancak, farklı zincirler arasındaki iletişim yöntemleri gibi spesifik detaylar şu anda çok net değildir ve resmi olarak referans alabileceğimiz teknik belgeler de sağlanmamıştır.

Eğer sadece bir ikinci katman zinciri daha hızlı işlem yapıyorsa, bu pek heyecan verici görünmüyor. Ancak, Fractal, güvenlik nedenleriyle uzun zaman önce BTC'den vazgeçilen OP_CAT işlem kodunu etkinleştirdi ve bu, Fractal Bitcoin'in yeteneklerini bir seviyeye yükseltti. Bazıları, OP_CAT'ın BTC'ye akıllı sözleşmeler yeteneği kazandırabileceğini düşünüyor ve bu da insanlara daha fazla hayal gücü sunuyor.

Şu anda, Fractal Bitcoin üzerinde ERC20 benzeri bir protokol gerçekleştirilmiştir.

CAT Protokolü

Alt katman OP_CAT desteği ile, kısa sürede ilgili protokol CAT Protokolü ortaya çıktı. Şu anda gerçek bir şekilde çalışan bir protokol CAT20 protokolüdür.

Olgun ERC20 protokollerine kıyasla, herkesin bir Token dağıtması artık oldukça kolaylaştı. Peki, CAT20 nasıl ERC20 benzeri bir yaşam döngüsü sağlıyor?

Yayınla

Dağıtım öncesinde, kullanıcıların kendi cüzdan adreslerini ve token'in temel bilgilerini belirtmeleri gerekmektedir, bu bilgiler ERC20 ile benzerdir. CAT20'nin bazı farklılıkları, ön madencilik ve her Mint işlemi için miktar kısıtlamalarının ayarlanabilmesiyle ilgilidir. Elbette, ERC20 de bu işlevleri sözleşme yetenekleri aracılığıyla gerçekleştirebilir.

Dağıtım aşamasında iki işlem başlatılacak ve bunlar iki aşama olarak görülebilir: "commit" ve "reveal". "commit" aşamasında, işlemin çıktı betiğinde tokenin temel bilgileri, örneğin tokenin adı, sembolü vb. yazılacaktır. "commit" aşamasında başlatılan işlemin hashId'si, bu tokenin kimliği olarak kullanılacak ve diğer tokenlerden ayırt edilmesini sağlayacaktır.

"reveal" aşamasında, işlem ilk olarak bir OP_RETURN çıktısı verecek ve burada CAT20'nin başlangıç durumunun Hash'ı saklanacaktır. Sonrasında önemli bir rol oynayan bir Minter çıktısı verilecek ve bu, sonraki Mint sürecinde Mint sürecinin durum değişikliklerini korumak için kullanılacaktır.

Tüm Deploy sürecinde, "commit" ve "reveal" blockchain üzerinde yaygın olarak kullanılan iki adım olan gönderim ve açıklama adımlarını takip etmektedir, bu da proje dağıtımında yaygın bir yöntemdir.

Mint

Mint Token sırasında, işlemlerin aşağıdaki birkaç özelliği vardır:

• mint'in girişi bir minter'dır, başlangıçta deploy sırasında oluşturulur.
• Her mint işleminde yalnızca bir minter girişi vardır ve herhangi sayıda minter çıkışı olabilir.
• Her mintleme işleminde yalnızca bir token bulunur.
• Çıktı sırasının bir gerekliliği vardır, minter'dan sonra token gelmelidir.

Minter, mint işlemine çıkan birim olarak, 1, birden fazla veya hatta 0 olabilir. Eğer her seferinde Mint için 1 olarak ayarlanırsa, o zaman tüm ağda kullanılabilir minter sayısı değişmeden kalacaktır (1 adet ), bu da Mint'in kalabalıklaşmasına neden olacaktır. Bu durumu önlemek için, her seferinde çıkan minter sayısını 1'den büyük olarak ayarlamak gerekmektedir; böylece mint işleminden sonra herkesin kullanabileceği minter sayısı giderek artacaktır.

Ancak, her eklenen bir minter, bir utxo için daha fazla ödeme yapılması gerektiği anlamına gelir. Ekonomik sebeplerden dolayı, daha fazla insan minteri 0 olarak ayarlamayı tercih edecektir, bu kaçınılmaz olarak minteri deflasyona uğratır ve bazı kişilerin fedakarlık yapmasını, fazladan minter için gönüllü olarak ödeme yapmasını gerektirir.

V2 sürümünde, varsayılan olarak iki Minter oluşturulur ve iki Minter'ın durumu mümkün olduğunca yakın olacaktır.

işlem inşası

Neden minter'ın utxo'sunu işlem yapımında kullanabiliyoruz? Bu, "akıllı sözleşmeler"in kaynak kodunun analizini gerektirir.

reveal sürecinde, işlem bir önceki işlemin çıktı commit'ini girdi olarak kullanmıştır. Bu, script mantığını ustaca yeniden yazarak gerçekleştirilmiştir; scriptte yazılı olan kamu ve özel anahtar çiftleri kendi adreslerimizindir, böylece iki farklı adresin utxo'sunu kontrol edebiliriz.

Minter utxo için, herkes bu utxo'ları giriş olarak kullanabilir, bu muhtemelen OP_CAT'ın sağladığı akıllı sözleşmeler yeteneğidir, her bir minter bir akıllı sözleşmedir.

işlem durumu (V2)

minter, durumu iki yerde saklar: biri işlem çıktısının OP_RETURN'ında, diğeri ise akıllı sözleşmelerde.

OP_RETURN'da mevcut işlem çıkış durumunun Hash'ini depolar, akılda Token'ın kalan Mint sayısını saklar. Her Mint işleminden sonra, yeni oluşturulan Minter'ın mint sayısı kalan mint sayısının ikiye bölünmesi ile eşit olacaktır.

Minter dışında üretilen Token da akıllı sözleşmeler olup, yani CAT20'dir. CAT20'nin iki temel durumu vardır: miktar ve Token'ın ait olduğu adres. Dikkat edilmesi gereken bir nokta, BRC20 veya yazıtlardan farklı olarak, CAT20'nin adresinizin UTXO'sunda yer almamasıdır.

Transfer

Transfer sırasında, işlem için oluşturulan giriş ve çıkış token sayısının tutarlı olması gerekir. Aynı işlemde birden fazla farklı token olabilir, sadece farklı tokenlerin giriş ve çıkış sayısının tutarlı olması yeterlidir.

Yak

Token'i yakmak için, sadece Token'i normal bir adrese göndermeniz yeterlidir.

Özet

Tüm işlemler kullanıcı tarafından inşa edilir, bu nedenle esneklik oldukça fazladır, bu nedenle sözleşme kısmında birçok doğrulama mantığı yapılması gerekmektedir. Şu anda ortaya çıkan bazı açıklar, doğrulama mantığında dikkatsizlik nedeniyle de olmuştur.

Bu tasarımın bazı avantajları var:

1. Tüm Token'ların sahiplik durumunu bulmak için yalnızca token'ın utxo'suna bakmak yeterlidir, yukarıya devam etmeye gerek yoktur.
2. Mint'in mevcut durumunu görmek için OP_RETURN içinde cat içeren verilerle yapılan işlemleri arayabilirsiniz.