Kaynak: Byte CKB

Ben biliyorum, bu konuşmaya geldiğinde, Bitcoin safiyetçileri muhtemelen düşüneceklerdir: Bitcoin sadece sessizce dijital altın olmaz mı? Neden mutlaka bir Token olmalı? Neden USDT olmalı? Ama eğer varlık güvenliğine özellikle önem veriyorsanız, o zaman düşünmek zorundasınız, Ethereum bir gün çökerse? DeFi kim yakalayabilir? Ayrıca, Token çözümü BTC protokolüyle uyumludur ve orijinal işlevi bozmaz, beğenmezseniz Token istemciyi indirmezsiniz ve çok etkilenmezsiniz.

BTC'de Token üretimi: Neden mümkün değil?

BTC üzerinde Token üretimi yaparak, gerçek dünya varlıklarının ticaretini on-chain'e taşımak için bu fikir 2010 civarında BTC topluluğunda ortaya çıktı. Topluluğun ilk tartışması, gerçek dünya varlıklarını - örneğin mülk, hisse senedi, Fiat Para Birimi vb. - Merkeziyetsizlikle BTC'ye taşımak olarak hayal edildi. Ancak yasal faktörler nedeniyle, mülk ve hisse senedi gibi varlıkların taşınması bu kadar kolay olmadı. Kendi evinizin dijital varlık Token'ını başka birine ödeme yaparsanız, hükümet bunu tanımayabilir veya otomatik olarak gerçek dünya mülkiyet belgesini değiştirmek ve çeşitli vergiler ödemek gerekebilir. Ayrıca, düzenlemeler altında on-chain ticaret yapmak serbest değildir.

Bu nedenle, Fiat Para Birimi ile ilişkili coin olan Token üretimi daha çekici bir yöntemdir, yani Stablecoin. Stablecoin, Değiştirilemez Token'dan farklıdır, hala homojen Token'lerdir, ancak orijinal BTC'den ayırt edilirler. Bir Token olarak ortaya çıktıklarında, değerleri temsil ettikleri gerçek dünya varlıklarının fiyatına bağlıdır ve artık orijinal Dijital Para fiyatına sahip değillerdir (Dijital Para fiyatı varlık fiyatından çok daha yüksekse, varlığı terk etmek de mümkündür). Bu nedenle genellikle BTC üzerindeki Token'lar Satoshi birimi olarak adlandırılır.

Dijital Para olarak bir varlık olarak Token kullanmanın iki temel sorunu çözülmesi gerekmektedir:

1. Nasıl BTC ile gerçek dünyadaki varlıkları temsil edebilirim;
2. BTC'nin oldukça sınırlı betik dilinde nasıl karmaşık işlem kuralları ve sözleşmeler ayarlanır.

Aşağıdaki içerik, yukarıdaki iki noktaya odaklanarak, mevcut birkaç büyük BTC varlık üretim planını özetledi ve veri kullanılabilirliği, varlık taşıyıcısı, performans, genişletilebilirlik vb. açılardan karşılaştırdı.

BTC'deki İlk Token: Renklendirme Token

Tokenprotokol'ü BTC'de ilk kimin tasarladığını bilmek artık mümkün değil ve fikir BTC forumundaki veya topluluktaki tartışmalarda doğmuş olabilir. Renkli Para projesi, Yoni Assia tarafından 2012 yılında Vitalik Buterin, Lior Hakim, Meni Rosenfeld ve Rotem Lev ile birlikte Renkli Paralar teknik incelemesini yazdığında başlatıldı[1], Proje 2013 yılında başladı.

Dyeing coinun çalışma prensibi, bir Satoshi'yi özel bir paraya işaretlemek ve varlığın ilgili bilgilerini bu Satoshi'ye yazmak - bu süreç boyama olarak adlandırılır. Bir Satoshi'yi farklı renklere boyayabilir ve farklı etiketler ekleyebilirsiniz, ancak aynı renkteki paralar hala ayırt edilemez, örneğin dolar olarak boyanmış bir Satoshi yığını, hala homojendir. Erken dönem protokolü nSequence alanını kullandı, işlemin ilk giriş UTXO'suna bir etiket ekledi. Ancak nSequence depolama sınırı sadece 4 bayttır, bu nedenle sonraki Token tasarımlarının çoğu OP_RETURN alanına değiştirilmiştir, daha fazla meta veri depolayabilir.

Renkli para şu anda genellikle BTC üzerindeki ilk Token projesi olduğu için tartışılıyor. Projenin gelişimi aslında çok ideal değil ve geniş çapta kullanılmıyor, proje kendisi yavaş yavaş unutulmaya başlandı. Renkli paraların o zaman karşılaştığı sorun, BTC'nin bu ileri düşünceyi destekleyememesiydi, bu düşüncenin hayata geçirilmesi, verimli ve istikrarlı bir şekilde çalıştırılması çok zordu. Bu muhtemelen Vitalik'in renkli para projesinden sonra BTC'nin karşısına geçerek Akıllı Sözleşmeler konusunda neden bu kadar kararlı olduğunun nedeni de olabilir.

Boyama jetonu, utxo'nun geçerliliğini doğrulamak gibi, bir taraftan tüm zinciri indirmeyi gerektirir. Bu sorun, ileride istemci tarafı doğrulama yöntemiyle çözülecektir.

OP_RETURN kullanarak token gönderme: Counterparty & Omni Layer

Renk parasından farklı olarak, Counterparty[2][3] ve Omni Layer(USDT'nin arkasındaki protokol), utxo'ya doğrudan renk vermez, ancak bir işlemde değeri 0 olan bir UTXO ayarlar ve bu UTXO'nun OP_RETURN'ünde meta verileri depolar. OP_RETURN, 80 bayta kadar depolayabilir ve OP_RETURN'ün belirttiği utxo harcanamaz, gerçek jeton OP_RETURN'de kayıtlı olan i-th output'tur. Bu çıktının değeri genellikle 0.00000546 BTC'dir - gönderilebilen en düşük değeri sistem tanımlar, ve jetonun değeri BTC'ye bağlı olmadığı için 0.00000546 BTC'den daha fazla bir değer göndermek gerekli değildir.

Bu projelerin doğrulaması, on-chain üzerinde gerçekleştirilir ve meta veriler on-chain'de saklanır.

Omni Layer uzun bir süre ETH ağındaki bir oyuncuydu, ancak yakın zamanda BTC ekosistine geri döndü ve BTC-USDT üretimine hazırlanıyor. Counterparty bir miktar BTC Stake etti ve kendi Token'i XCP'ye sahip. Twitter'dan[4]Son zamanlarda NFT yapmaya çalışıyor gibi görünüyor.

OP_RETURN hakkında daha fazla bilgi için şuna bakabilirsiniz:

1. Bitcoin OP RETURN metadata analizi[5]
2. OP_RETURN ile USDT gönderme işlemi manuel olarak oluşturun[6]

BTC'nin Yan Zincirlerle Bağlanması: Rootstock & Liquid Network

Rootstock[7][8]Ve Liquid Ağı[9]Bu iki proje yaklaşık olarak 2017 civarında ortaya çıktı ve ikisi de yan zincir çözümleri - Bitcoin'i çift yönlü ankraj (Two-way peg) yöntemiyle yan zincire takas etmek ve EVM uyumlu yan zincirde çeşitli DeFi ve dApps kullanmak için. Benzerlikleri WBTC'ye benziyorlar.RSK'nin RBTC'si var, Liquid'in L-BTC'si var), ana hedefi Ethereum ekosistemine BTC kullanmak isteyen kişilere yöneliktir.

RBTC ile üretim yaparak Rootstock üzerinde Token üretmek, ETH zincirinde üretim yapmakla aynıdır, veya Rootstock bu yan zincir, madencilik dışında, diğer işlevleri ETH ekosistemine uyum sağlamak için yapılmıştır, örneğin Akıllı Sözleşme kodları da Solidity ile yazılmıştır. Bu nedenle buradaki Tokenlar doğrudan BTC ile ilişkili değildir, RBTC temelinde üretilir.

Bu makalede Liquid Network bir konsorsiyum blok zinciri olduğu için üzerinde derinlemesine tartışılmayacaktır.

RSK'yi daha fazla anlamak için, bkz:

• RSK: Bir durumlu akıllı sözleşmelerle Bitcoin yan zinciri (RSK makalesi)[10]
• RSK para[11]
• SSS[12]

Bahsedilen bu projelerden bazıları kayboldu (örneğin renkli para), bazıları ise BTC'nin kılığına girmiş ve aslında Ethereum ekosisteminden satılıyordu. Bu durumun temel nedeni, Ethereum'un sermayeyi benimsemesinin ardından, Merkezi Olmayan Finans ve dApps'ın mutlak piyasa üstünlüğünü elde etmesidir, bu yüzden Ethereum'un oynamadığı Merkezi Olmayan Finans projelerinin avantaj elde etmesi daha zordur. Ethereum üzerindeki token'lar, ERC-20 gibi standartlara uygun olarak üretilir ve işlem görür. Son iki yılda BTC ekosistemi de BitVM gibi kontrat işlevlerini serbest bırakmaya başladı ve BRC-20 gibi token standartları ortaya çıktı.

Akıllı Sözleşmeleri BTC üzerinde Gerçekleştirme: RGB

RGB (Bitcoin için Gerçekten İyi) 2016 yılında doğdu[13]İlk başta boya parasının rakibi olarak tasarlandı. Ancak benzer zorluklarla karşılaştığında, akıllı sözleşmeleri Bitcoin üzerinde etkinleştirmeye yönelik bir dönüş yaptı. Akıllı sözleşmelerin çalıştırılmasına odaklanmasına rağmen, token çıkarma yerine, sanal makine AluVM'nin kısıtlamaları nedeniyle 2024'e kadar tam sözleşme işlevselliği hala sınırlıdır.

RGB'nin yaklaşımı, off-chain verileri ve akıllı sözleşme kodlarını BTC dışında bir yerde toplayarak, işlem doğrulaması ve token üretimi için Merkle root kullanarak taahhüt sağlamaktır. BTC zinciri sadece işlem taahhüdünün doğrulanması ve sonlandırılması işlemini yapar, çift harcama olmadığını kanıtlar.

RGB'nin dikkate değer bir özelliği, istemci doğrulaması ve tek kullanımlık mühür bandı teknolojisinin aynı anda kullanılmasıdır, bu sayede Token'ı temsil etmek için UTXO üzerinde işaretlemeye gerek kalmaz. Bu iki kavram ilk kez Peter Todd tarafından 2013 yılında ortaya atıldı.[14]Geliştirilen RGB protokolü, Giacomo Zucco ve Maxim Orlovsky tarafından tasarlandı.

Müşteri tarafı doğrulama (Client-side validation), işlemde kullanılan verilerin ve kodların off-chain'de saklandığı ve genel olarak yayınlanmadığı bir durumdur. Bazı veriler sadece işlemi yapan taraflar arasında özel olarak değiştirilebilir ve işlemle ilgisi olmayan diğer kişilerin haberi olmayabilir. off-chain durumu BTC tarafından desteklenirken, blok zinciri Sayaç olarak kullanılır ve durumun sırasını kanıtlayabilir.

Ve tek kullanımlık mühür (single-use seal) - aynı zamanda istemci doğrulamanın en sık karşılaşılan şekli olan - dijital bir tek kullanımlık mühürdür. Her UTXO'nun yalnızca bir kez harcanabileceği özelliğinden faydalanarak, off-chain durumundaki bilgileri bir UTXO'ya yazabilir. Bu şekilde, bu UTXO bir noktada harcanırsa, durumun güncellendiğini ve güncellenmiş durum bilgisinin yeni oluşturulan UTXO'ya yazıldığını biliriz. Bu off-chain durum bilgisi, USDT Token'ın sahipliği olabilir veya bir sözleşmede kaç Token olduğu olabilir.

Örneğin, Alice, bir USDT'yi Bob'a aktarmak istediğinde, bu USDT BTCon-chain'de mevcut değildir, bilgisi off-chain'de tutulur, ancak Alice'in kontrolünde olan bir UTXO ile ilişkilidir. Bu bilgi, bu UTXO'yu oluşturan işlemdeki OP_RETURN alanında sıfır değerli bir UTXO olarak saklanır. Bu şekilde, sadece Alice bu USDT'yi harcayabilir ve Bob, bu USDT'nin önceki işlemlerde hangi UTXO'larda saklandığını, bu UTXO'ların geçerli olup olmadığını ve işlemin yasal olup olmadığını on-chain işlemlerle takip edebilir. Bu sayede, Alice işlemi başlattığında, bu USDT'nin taahhüt bilgilerini Bob'un kontrol ettiği bir UTXO'ya aktardığında, Bob, bu USDT'yi aldığından emin olabilir.

RGB de Lighting Ağı'nda çalışabilir çünkü durumu off-chain'dir, taahhütü on-chain veya Lighting Ağı'na yerleştirmek yeterlidir. Taproot güncellemesinden sonra, RGB taahhütü bir Taproot işlemine gömerek BTCon-chain'e daha esnek bir şekilde taahhüt edebilir.

RGB'yi daha iyi anlamak için RGB Blueprint'e bakın[15]

Yalnızca Token desteklenir, akıllı sözleşme desteklenmez: Taproot varlıkları

Taproot Asset, Lightning Network Daemon (LND) olarak bilinen bir sistemdir.[16][17]Projeyi geliştiren ekip. RGB'ye benzer şekilde çalışır, ancak karmaşık akıllı sözleşmeleri desteklemez, yalnızca jetonları destekler (bkz. Taproot terimi buraya).açıklama).

Client-Side Validation、RGB ve Taproot hakkında daha fazla bilgi için bkz:

1. İstemci tarafı doğrulama[18]
2. Zincir Dışı İşlemler: Bitcoin Varlık Protokollerinin Evrimi[19]
3. Karşı taraf vs RGB vs TARO[20]

Her bir Satoshi'yi farklı kılın: Sıralamalar ve İyonlar

Casey Rodarmor, 2023 başlarında Ordinal Protocol'ü yayınladı.[21]Proje aslen şu fikirden ortaya çıktı: Her bir satoshinin benzersiz bir sıra numarasına sahip olmasını sağlamak için nasıl numaralandırılır. Bu fikir, renkli paralarla aynı dönemde ortaya çıktı, ancak geçen yıl tekrar gündeme geldi. Ayrıca, SegWit ve Taproot'un eklenmesiyle, uygulanması artık o kadar zor değil. Ordinal, her bir satoshinin farklı olmasını sağlar, bu da NFT'nin doğrudan Bitcoin zinciri üzerinde yayınlanabilmesini sağlar.

Inions[22] Böyle bir NFT projesi de bunlardan biridir. NFT'nin verileri, önceki proje tarafından kullanılan ve boyutu 4 MB'a kadar meta verilere izin veren OP_RETURN alanı yerine işlemin tanık verilerinde saklanır. Ethereum'daki NFT'lerin aksine, Inion, meta veriler ve görüntüler dahil olmak üzere zincir üzerinde depolamadır.

Ordinals hakkında daha fazla bilgi için bkz: 01928374656574839201

1. Sıra sayıları: Ethereum ve Bitcoin maksimalistleri için ortak bir zemin mi?[23]
2. Bitcoin Sıralama ve İşlemler İçin Son Kılavuz[24]

Any UTXO chain with bidirectional binding: RGB++ Isomorphic Binding

RGB++[25][26]Başlangıçta BTC ve CKB (Nervos Network olarak kullanılanFarklı UTXO zincirleri arasında (CKB ve BTC arasında sınırlı olmamak kaydıyla) kullanılabilen, izomorfik bağlama protokolü (isomorphic binding protocol) olarak adlandırılan bir protokol ortaya çıktı.

RGB++, RGB'nin İstemci Tarafı Doğrulama ve Tek Kullanımlık Mühürler yaklaşımını daha da geliştirdi. Önceden belirtildiği gibi, RGB protokolünün en büyük sorunu verilerin kullanıcı tarafından yerel olarak saklanmasıdır. Kullanıcı yanlışlıkla verileri kaybederse, yedekleme yapmadığı ve geri alamadığı için kaybolur. Ayrıca, kullanıcılar yalnızca kendi Token'larıyla ilgili verileri sakladıkları için diğer verilerin doğrulanması daha zordur. Homojen bağlama katmanı çözümü, Token'ı yalnızca BTC UTXO'nun OP_RETURN alanına bağlamakla kalmaz, aynı zamanda ilgili BTC işlem bilgilerini CKB on-chain işlemine bağlar (CKB Hücresi içinde).[27]Lock 里，bir özel bir IB-lock kullanılarak gerçekleştirilir. CKB on-chain işleminin geçerli olup olmadığını belirlerken, Lock, CKB üzerindeki BTC hafif istemcinin verilerini kullanır ve ilgili UTXO'nun harcanıp harcanmadığını ve harcandıktan sonra yeni oluşturulan UTXO'nun şu anda bu Token işlemi bilgilerine bağlı olup olmadığını kontrol eder (imzasız kısmı olarak).

RGB++ özellikleri takip etmeye değer:

• Veri kullanılabilirliği sorununu çift yönlü bağlama ile çözme: CKB Hücreleri, UTXO'nun OP_RETURN alanına bağlıdır; UTXO bilgileri CKB işleminin Çıkış Hücresine bağlıdır.
• Lighting Ağı ve Fiber Network (CKB tabanlı Lighting Ağı) ile uyumludur
• Çoklu varlık desteği
• Herhangi bir UTXO zinciriyle bağlantı kurabilir

Daha fazla bilgi için RGB++'ya bakınız:

1. RGB++ Protokolü Işık Kağıdı[28]
2. RGB, RGB++ ve İstemci Tarafı Doğrulama İçin En İyi Kılavuz[29]

Her projenin avantajlarını ve sınırlamalarını daha iyi anlamak için, aşağıdaki tabloya bu projeleri karşılaştırmak için yerleştirdik. Özellikle takip etmek gereken göstergeler şunlardır:

• 数据可用性（Veri erişilebilirliği）：同构链（izomorfik zincir）ve Yan Zincir neredeyse aynıdır, ancak yan zincirin veri erişilebilirliği diğer çözümlerden daha zayıftır. Bu sıralama, güçlüden zayıfa şöyle: on-chain ≥ 同构链 ≥ Yan Zincir > off-chain；
• Varlık taşıyıcısı (Asset carrier): BTC ile doğrudan ilişkili Token çözümleri, dolaylı ilişkili çözümlerden daha iyidir;
• Homojenlik (Fungibility): Burada, bir projenin yerel Token'ının birbirleriyle değiştirilebilir olup olmadığı kastedilmektedir ve bu, bir projenin üretim Değiştirilemez Token'ı desteklemediği anlamına gelmez, bu sonuncusu ek protokoller ekleyerek gerçekleştirilebilir;
• İfade Edicilik: Karmaşık akıllı sözleşmeleri işleme yeteneği.

Mentioned links in the text:[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

knowledge-base/ultimate_guide_to_rgb_rgbpp_and_client_side_validation[29]