CAT20: Fractal BTC'deki Token protokolü

Bu makale sadece teknik paylaşım amaçlıdır, herhangi bir yatırım tavsiyesi oluşturmaz.

BTC 上也要有自己的Akıllı Sözleşme了？

Son zamanlarda BTC ekosistemine, Fractal BTC, birkaç Testnet denemesinden sonra nihayet Ana Ağ'da başlatıldı. Fractal'ın büyük bir özelliği, 'Akıllı Sözleşme' yeteneğine sahip olması ve neredeyse Ana Ağ'ın başlatılmasıyla aynı zamanda yeni bir Token protokolü olan CAT 20'yi başlatmasıdır. CAT 20'de hangi teknik tasarımlar var? Biz ne öğrenebiliriz?

Fraktal Bitcoin

CAT 20 protokol, Fractal Bitcoin üzerine dağıtılan bir şekilde ERC 20 ve ETH'nin ilişkisi gibi, Fractal Bitcoin'un kısa bir tanımını yapmadan önce CAT 20'yi anlamak için gerekli.

Fraktal Bitcoin, ayrıca Fraktal BTC olarak da bilinir, tamamen BTC ile uyumlu bir 'ikinci katman' ağıdır. BTC'ye kıyasla, Blok onaylama süresi daha hızlıdır, sadece 1 dakika sürer. Temel prensibi basitçe, adından da anlaşılacağı gibi, BTC ağını birkaç kopya haline getirmektir; her zincir işlemi işleyecektir, işlemi işleyebilir Düğüm sayısı arttıkça hız da doğal olarak artar. Ancak farklı zincirler arasındaki iletişim gibi belirli detaylar şu anda pek net değil, resmi olarak başvurulabilecek bir teknik belge de mevcut değil.

Eğer sadece bir ikinci katman zinciri işlemi daha hızlıysa, pek heyecan verici bir nokta gibi görünmüyor. Ancak, Fractal'da güvenlik nedenlerinden dolayı uzun süredir kullanılmayan Operasyon Kodu OP_CAT'yi etkinleştirmek, Fractal Bitcoin'in yükseliş yeteneğini bir adım öteye taşıdı. OP_CAT'nin BTC'ye Akıllı Sözleşme yeteneği kazandırabileceği söyleniyor, bu durumda hayal edilebilecek alanlar daha da genişliyor.

Şimdi, Fractal Bitcoin üzerinde ERC 20'ye benzer bir protokol gerçekleştirildi.

OP_CAT neden kaldırıldı ve neden Fractal Bitcoin üzerinde kullanılabilir hale geldiği hakkında ve ileride daha fazla konuşabileceğimiz hakkında bilgi verelim, burada CAT 20 takip ediyoruz.

CAT Protokolü Aşağıdaki içerik White Paper'a bakılarak hazırlanmıştır: Tanıtım | CAT Protokolü ()

Ve github deposu: GitHub - CATProtocol/cat-token-box: CAT protokolünü uygulayan paketler için bir monorepo ()

Alt seviye OP_CAT desteği ile hızla bir protokol olan CAT Protocol ortaya çıktı. Şu anda çalışan bir protokol olan CAT 20 protokolü var ve Unisat'ta buna karşılık gelen bir panel de eklendi:

CAT 20 adını görünce, ERC 20'ye benzer olduğunu anlayabilirsiniz. Olgun ERC 20 protokolüne kıyasla, Token dağıtmak çok daha kolay hale geldi. CAT 20, ERC 20 benzeri bir yaşam döngüsü nasıl sağlar?

Yayınlama

Dağıtımdan önce, kullanıcıların CüzdanAdres ve Token temel bilgilerini belirlemesi gereklidir. Token temel bilgileri ERC20'ye benzer:

Bazı farklılıklar olacaktır. CAT 20, önceden kazma ve her seferinde Mint miktarı sınırlandırma özelliği ayarlayabilir. Tabii ki ERC 20, bu yetenekleri sözleşme yoluyla da gerçekleştirebilir.

部署阶段中， iki işlem başlatılır ve iki aşamaya ayrılabilir: 'commit' ve 'reveal'. Resmi web sitesinde belirtildiği gibi, dağıtım aşaması aşağıdaki gibidir:

"commit" aşamasında, işlemin çıktı betiğine Token'ın temel bilgileri yazılır, örneğin Token'ın adı, sembolü vb. "commit" aşamasında başlatılan işlemin hashId'si, bu Token'ın diğer Tokenlardan ayırt edilmesi için bir işaret olarak kullanılır.

Bu işlemde 'bc1pucq...ashx' UTXO'nun taahhüdüne karşılık geldiği görülebilir. Kalan iki işlem 'bc1pszp...rehc4' adresine yönlendirilir, birinci işlem 'açığa çıkarma' aşamasındaki gaz ücretini ödemek için kullanılır, diğeri ise para üstüdür.

Reveal aşamasında, önceki onay aşamasının ilk iki çıktısına karşılık gelen iki utxo girişi olduğu görülebilir. Bu işlemde öncelikle bir OP_RETURN çıktısı üretilecek, OP_RETURN içinde CAT 20'nin başlangıç durumunun Hash'i saklanacak. Ardından, Mint sürecinde önemli bir rol oynayacak olan bir Minter daha çıktı verecektir ve Mint sürecindeki durum değişikliklerini korumak için kullanılacaktır.

Deploy sürecinin tamamına bir göz atarsak, "commit" ve "reveal" Blok-on-chain'de yaygın olarak kullanılan bir şekilde adım adım atılmıştır, bu, projenin birçok verisinin sadece "reveal" aşamasında ortaya çıktığı daha yaygın bir şekilde projenin dağıtımıdır.

Mint

Mint Token'ı incelediğimizde, işlem şu şekildedir.

Yukarıdaki şekilde, Mint işlemi aşağıdaki özelliklere sahiptir.

• mint'in girdisi bir minter'dır, başlangıçta deploy anında oluşturulmuştur.
• Her bir mint işleminde, giriş olarak yalnızca bir minter bulunur ve çıkış olarak istenilen sayıda minter bulunur (biraz sorunlu)
• Her mint işleminde sadece bir adet token vardır (biraz sorunlu).
• Çıktı sırası önemlidir, minter kelimesinin ardından TOKEN olmalıdır

Mint sürecini anladığımızda, gerçekte bazı özel durumları fark edebiliriz, bu da tüm Mint sürecini ilginç hale getirir.

Örneğin, minter mint işleminin çıktısı olarak 1, birden fazla hatta 0 olabilir. Her seferinde Mint yapıldığında 1 olarak ayarlanırsa, ağda kullanılabilecek minter miktarı sabit kalacaktır (1), bu da Mint'in kalabalık hale gelmesine neden olacaktır, herkes bu minter'ı kapmak zorunda kalacak, bu durumu önlemek için her seferinde çıktı olarak verilen minter miktarını 1'den büyük olarak ayarlamak gereklidir, bu şekilde mint yapıldıktan sonra herkesin kullanabileceği minter sayısı giderek artacaktır.

Ancak her bir fazladan minter çıktısının anlamına gelir ki, bir utxo daha fazla ödemeniz gerekecektir. Ekonomik nedenlerden dolayı, daha fazla insan minter'ı 0 olarak ayarlamaya istekli olacaktır, bu da minter'ın kaçınılmaz bir şekilde daralmasına neden olacaktır, bu da bazı insanların fedakarlık yapmasını gerektirecektir, fazladan minter'ı isteyerek ödemek.

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

İşlemin Oluşturulması

Belki bazı arkadaşlar bir sorun fark etmiş olabilir, o da neden minter'ın utxo'sunu işlem oluşturmak için kullanabildiğimizdir? Bu sorunu anlamak için 'akıllı sözleşme' kodunu analiz etmek gereklidir.

1、açığa çıkarma utxo

Öncelikle, reveal sürecindeki işlemleri analiz ederken, önceki işlemin çıktı commitini girdi olarak kullandığını fark ettik. Neden bizim Adresimiz olmayan bir utxo ile işlem girdisi oluşturabiliyoruz?

Normal şartlarda, bir Özel Anahtar'ın karşılığı bir Açık Anahtar'dır ve Açık Anahtar bir Adres türetilir. Bir giriş utxo'nun geçerli olup olmadığını doğrularken, genellikle imza kullanarak Açık Anahtar'ı çözerek şifresini çözülen verinin orijinal işlemle eşleşip eşleşmediğini karşılaştırarak belirlenir. Bu mantık genellikle BTC komut dosyasında yazılır. Bu nedenle, komut dosyasının mantığını ustaca değiştirerek, komut dosyasında yazılan Özel Anahtar ve Açık Anahtar çiftini kendi Adres'imize ayarlayabiliriz, böylece farklı iki Adres'in utxo'sunu kontrol edebiliriz.

Kod tabanını inceleyerek ne olduğunu anlayabiliriz：

Burada başka bir sorun olacak, bir Özel Anahtar'ın bir Açık Anahtar'a karşılık geldiği, o zaman neden oluşturulan commit Adres'in bizim Adres'imizden farklı olduğunu görebiliriz.

Yani, Özel Anahtarımız bir ISSUE_PUBKEY'ye göre Ayarlanır, bu da P2TR Adresinin bir özelliğidir.

2、minter utxo

reveal sürecinde farklı utxo'ları giriş olarak kullanırız, ancak aslında şifrelemenin Gizli Anahtarı aynıdır, yani dağıtıcının Özel Anahtarıdır. Ancak minter aşamasında, herkes bu utxo'ları nasıl giriş olarak kullanabiliyor?

Bu bölümde, tahmin ettiğim şey, daha önce bahsettiğim OP_CAT yeteneği, yani akıllı sözleşme yeteneği, her bir minter bir akıllı sözleşme. Ancak şu anda bu bölümün kaynak kodu açık değil, dolayısıyla uygulamanın ayrıntıları hakkında tam olarak bilgi sahibi değilim.

Durumun İşlemi (V2)

Minter'de devlet de korunur. Bu durum iki yerde mevcuttur: biri işlem çıktısının OP_RETURN'sinde, diğeri ise yukarıda bahsedilen Minter ve Token olan Akıllı Sözleşme'de saklanır.

OP_RETURN'de saklanan, mevcut işlem çıkış durumunun Hash'ıdır. Sözleşmede Token'in kalan Mint sayısı saklanır. Her Mint'ten sonra, yeni oluşturulan Minter'ın mint miktarı, mint yapabileceği miktarın yarısıdır. Şekilde gösterildiği gibi:

Sonunda tamamlandığında, Tüm Minter'ın kalan miktarı 0 oldu.

Başlangıçtaki grafikte, Minter'in bir akıllı sözleşme olduğu ve oluşturulan Token'ın da bir akıllı sözleşme olduğu, yani CAT 20 olduğu görülebilir. CAT 20'nin iki temel durumu vardır: miktar ve Token'ın sahibi olan Adres. Önceki BRC 20 veya yazıt gibi, CAT 20'niz Adres'inizdeki UTXO değildir.

Transfer

Transfer işlemi yapılırken, işlemin giriş ve çıkış tokenlarının miktarının tutarlı olması gerekmektedir. Tabii ki aynı işlemde farklı tokenlar olabilir, ancak farklı tokenların giriş ve çıkış miktarlarının tutarlı olması yeterlidir.

Yak

TOKEN'ı yakmak isterseniz, TOKEN'ı bir normal Adres'e transfer etmeniz yeterlidir.

Özet

Görülebileceği gibi, tüm işlemler kullanıcı tarafından oluşturulur ve son derece esnektir, bu yüzden akıllı sözleşme kısmında birçok doğrulama mantığı yapılması gereklidir. Şu anda ortaya çıkan bazı açıklar da doğrulama mantığı ihmal edildiği için ortaya çıkmıştır.

Bu tasarımın bazı faydaları olabilir:

• Tüm Token'ların sahiplik durumunu bulmak istiyorsanız, sadece token'ın utxo'sunu kontrol etmeniz yeterlidir, yukarı doğru devam etmeniz gerekmez.
• Mint durumunu görmek istiyorsanız, OP_RETURN verilerinde kedi olan işlemleri arayabilirsiniz.

ZAN kapısız su alma geldi!

İpucu: Her 24 saatte bir kez 0.01 ETH ücretsiz testnet jetonunu talep edebilirsiniz, bu, ETH ekosisteminde Web3 projelerini denemeniz ve test etmeniz için size destek olacaktır, hemen talep etmek için tıklayın:

Daha fazla blok zinciri yakında desteklenecek~

Bu makale ZAN Team'den (X hesabı @zan_team) Yeezo (X hesabı @GaoYeezo 75065) tarafından yazılmıştır.