Giriş

BTC'ye dayalı varlık ihraç etmek her zaman sıcak bir konu olmuştur. Renkli Paraların 2011'deki ilk ortaya çıkışından son zamanlarda popüler olan Ordinal Protokolüne kadar, BTC topluluğu her zaman yeni oyuncular ve fikir birliği ortaya çıkarmayı başardı. Ancak çok azı zamana direnmeyi başardı. İddialı Lightling Labs'ın Taproot Assets'in üzerine bir Stable Coin oluşturma planlarını duyurması ve Tether'in Bitcoin'in ilk katmanında USDT basmak için RGB seçimini açıklamasıyla birlikte, bir zamanların ünlü OmniLayer'ın (Mastercoin) artık en büyük olmadığı açık. BTC ekosistemindeki oyuncu. İstemci Tarafı Doğrulama (CSV) varlık protokolleri, Bitcoin'in ölçeklenebilirliğine yönelik özellikleri de içermesiyle geleneksel BTC varlık protokollerinden farklı olarak dikkat çekmeye başlıyor. Ancak BTC ekosisteminde bu kadar çok sayıda varlık protokolüyle karşı karşıya kaldığımızda şu soruyu sormak gerekir: Aralarındaki farklar nelerdir? Peki bu sayısız varlık protokolü arasından kendi fırsatlarımızı nasıl seçip bulmalıyız?

Bu makale, Bitcoin'in tarihinde ortaya çıkan çeşitli varlık protokollerini incelemede okuyuculara rehberlik etmeyi ve Bitcoin tabanlı varlık protokollerinin öngörülebilir gelecekte potansiyel yörüngesini araştırmayı amaçlamaktadır.

Renkli Paralar

Renkli Paralar fikri ilk olarak eToro'nun şu anki CEO'su Yoni Assia tarafından 27 Mart 2012'de yazılan "bitcoin 2.X (namı diğer Renkli bitcoin)" başlıklı bir makalede önerildi. Makale, HTTP'nin internetin temeli olması gibi, Bitcoin'in de temel bir teknoloji olarak mükemmel olduğunu öne sürdü. Bu nedenle, BTC'nin yeniden kullanılması temelinde Renkli Paralar token protokolü tasarlandı.

Yoni Assia, bu yöntemle BTC 2.0 ekonomisi yaratmayı hedefledi; herhangi bir topluluk bu şekilde çeşitli para birimleri yaratabilir. İşlemleri tamamlamak ve çifte harcamayı önlemek için Bitcoin'i temel teknoloji olarak kullanma yaklaşımı, o zamanlar şüphesiz çok cesur bir fikirdi.

Bitcoin'e dayalı varlıkların ihraç edilmesine yönelik bir protokol olarak Renkli Paraların yöntemi, bu varlıkları temsil etmek için belirli miktarda Bitcoin'i "renklendirmek"tir. Bu işaretli Bitcoin'ler işlevsel olarak Bitcoin olarak kalır ancak aynı zamanda başka bir varlığı veya değeri de temsil ederler. Peki bu fikir Bitcoin'e nasıl uygulanabilir?

3 Temmuz 2014'te ChromaWay, geliştiricilerin renkli paralar oluşturma sürecini basitleştiren Gelişmiş Komut Dosyasına Ödeme Karması (P2SH) tabanlı Renkli Paralar protokolünü (EPOBC) geliştirdi. Bu, Bitcoin Script'in OP_RETURN işlevselliğini benimseyen en eski protokoldü.

Nihai uygulama aşağıdaki resimde gösterilmektedir:

)

Bu uygulama çok kısa ve öz olmakla birlikte birçok sorunu da beraberinde getirir:

Homojenize Tokenlar ve Minimum Bağlama Değeri

Oluşum işleminde renkli bir coin 1000 sato ile bağlanmışsa bu renkli coinin en küçük bölünmüş birimi 1 satodur. Bu, varlığın veya tokenin maksimum 1000 parçaya bölünebileceği veya tahsis edilebileceği anlamına gelir (ancak bu yalnızca teoriktir, toz saldırılarını önlemek için, örneğin sat 546 SAT'a ve daha sonra daha yüksek olan ordinal olarak ayarlandı). ).

Doğrulama Sorunları

Renkli bir madalyonun orijinalliğini ve sahipliğini tespit etmek için varlığın oluşum işleminden mevcut UTXO'ya kadar takip edilmesi ve doğrulanması gerekir. Bu nedenle, özel bir cüzdan ve ona eşlik eden tam düğüm ve hatta bir tarayıcı geliştirmek çok önemlidir.

Madenci Sansürünün Potansiyel Riski

Çıktıya meta veri bilgisi yazmayı içeren ColoredTransaction'ın farklı özellikleri nedeniyle madenci sansürü olasılığı vardır.

Renkli paralar aslında varlık transferlerini izlemek için Bitcoin'in doğrulama kurallarını kullanan bir varlık takip sistemidir. Ancak herhangi bir spesifik çıktının (txout) belirli bir varlığı temsil ettiğini kanıtlamak için varlığın kaynağından günümüze kadar tam bir transfer zinciri gereklidir. Bu, bir işlemin meşruluğunun doğrulanmasının uzun bir kanıt zinciri gerektirebileceği anlamına gelir. Bu sorunu çözmek için OP_CHECKCOLORVERIFY'nin BTC'deki Renkli Para işlemlerinin doğruluğunun doğrudan doğrulanmasına yardımcı olması için bir teklif vardı, ancak bu teklif kabul edilmedi.

Kripto Para Sektöründe İlk ICO: Mastercoin

Mastercoin'in ilk konsepti JR Willett tarafından önerildi. 2012 yılında, daha sonra "MasterCoin" olarak anılacak olan Bitcoin'in mevcut blok zincirinde yeni varlıklar veya tokenlar oluşturma kavramını açıklayan "İkinci Bitcoin Teknik İncelemesi" başlıklı bir teknik inceleme yayınladı. Daha sonra Omni Layer olarak yeniden adlandırıldı.

Mastercoin projesi, 2013 yılında bir ilk token satışı (bugün ICO veya İlk Para Teklifi dediğimiz şey) gerçekleştirdi ve milyonlarca doları başarıyla topladı. Bu, tarihteki ilk ICO olarak kabul ediliyor. Mastercoin'in en dikkate değer uygulaması, başlangıçta Omni Layer'da piyasaya sürülen, en tanınmış fiat stablecoin olan Tether'dir (USDT).

Aslında Mastercoin kavramı Renkli Paralardan önce ortaya çıkmıştır. Burada ikinci kez ele alınmasının nedeni, Renkli Paralara kıyasla Mastercoin'in nispeten daha karmaşık bir çözüm olmasıdır. Mastercoin eksiksiz bir düğüm katmanı oluşturarak daha karmaşık işlevler (akıllı sözleşmeler gibi) sunarken, Renkli Paralar daha basit ve daha doğrudandı; esas olarak Bitcoin UTXO'ları diğer varlıkları temsil edecek şekilde "renklendirmeye" veya işaretlemeye odaklanıyordu.

Renkli Paralardan temel farkı, Mastercoin'in ilgili varlık bilgilerini kaydetmeden yalnızca zincir üzerinde çeşitli işlem davranışlarını yayınlamasıdır. Mastercoin düğümlerinde, zincir dışı düğümlerdeki Bitcoin blokları taranarak bir durum modeli veritabanı korunur.

Renkli Paralarla karşılaştırıldığında Mastercoin daha karmaşık bir mantık yürütebilir. Ve zincir üzerinde durum kaydetmediği ve doğrulama yapmadığı için işlemleri süreklilik (sürekli renklendirme) gerektirmez.

Ancak Mastercoin'in karmaşık mantığını uygulamak için kullanıcıların, düğümlerin zincir dışı veritabanındaki duruma güvenmesi veya doğrulama için kendi Omni Layer düğümlerini çalıştırması gerekiyor.

Özetle:

Mastercoin ve Colored Coins arasındaki temel fark, Mastercoin'in protokol için gereken tüm verileri zincir üzerinde tutmamayı seçmesidir. Bunun yerine, durumu zincir dışı bir veritabanında tutarken, kendi işlem yayınını ve siparişini uygulamak için asalak bir şekilde BTC'nin fikir birliği sistemini kullandı.

OmniBolt tarafından sağlanan bilgilere göre: Omni Layer, Tether'e, varlık bilgilerini tapleaf'e kodlamak ve koşullu ödemeler gibi işlevlere olanak sağlamak için Taproot yükseltmesini kullanacak yeni bir UBA (UTXO Tabanlı Varlık) varlık protokolü öneriyor. Bu arada OmniBolt, Stark'ı OmniLayer'ın Lightning Network altyapısına dahil ediyor.

İstemci Tarafı Doğrulama Kavramı

Müşteri tarafı doğrulama kavramını anlamak için Colored Coins ve Mastercoin'in ortaya çıkışından sonraki yıla, yani 2013 yılına dönmemiz gerekiyor. O yıl Peter Todd bir makale yayınladı: "Kripto Para Madenciliğini Çözmek: Zaman Damgası, Yayın Kanıtı ve Doğrulama." Her ne kadar makalenin başlığı doğrudan istemci tarafı doğrulamayla ilgili görünmese de, dikkatli bir okuma, bu makalenin istemci tarafı doğrulamayla ilgili en eski aydınlanma düşüncelerini içerdiğini ortaya koyuyor.

Bitcoin ve kriptografi alanında ilk araştırmacılardan biri olan Peter Todd, her zaman Bitcoin'in işleyişini daha verimli hale getirecek bir yöntem arıyordu. Zaman damgası kavramına dayalı olarak daha karmaşık bir istemci tarafı doğrulama kavramı geliştirdi. Ayrıca daha sonra değinilecek olan “tek kullanımlık mühür” kavramını da ortaya atmıştır.

Peter Todd'un düşüncelerini takip ederek öncelikle BTC'nin (Bitcoin) gerçekte çözdüğü sorunları anlayalım. Peter Todd'a göre BTC üç sorunu çözdü:

Yayın Kanıtı

Yayın kanıtının özü, çift harcama sorununu çözmektir. Örneğin Alice'in Bob'a aktarmak istediği bazı bitcoinleri var. Bob'a transfer etmek üzere bir işlem imzalasa da Bob, bu işlemin varlığından fiziksel olarak haberdar olmayabilir. Bu nedenle işlemlerin yayınlanacağı, herkesin sorgulayabileceği halka açık bir yerin olması gerekiyor.

Sipariş Uzlaşması

Bilgisayar sistemlerinde genellikle algıladığımız fiziksel zaman yoktur. Dağıtılmış sistemlerde zaman genellikle fiziksel zamanımızı ölçmeyen ancak işlemlerimizi düzenleyen Lamport zaman damgalarıyla temsil edilir.

Doğrulama (İsteğe bağlı)

BTC'de doğrulama, imzaların ve BTC transfer tutarlarının doğrulanmasını ifade eder. Ancak burada Peter Todd, bu doğrulamanın BTC üzerinde bir token sistemi oluşturmak için gerekli olmadığına, bunun yerine bir optimizasyon seçeneği olduğuna inanıyordu.

Bu noktada aklınıza daha önce bahsettiğimiz Ominilayer gelebilir. Ominilayer, durumun hesaplanmasını ve doğrulanmasını BTC'ye devretmez ancak yine de BTC'nin güvenliğini yeniden kullanır. Renkli Paralar ise durum takibini BTC'ye devreder. Her ikisinin de varlığı, doğrulamanın mutlaka zincir üzerinde gerçekleşmesi gerekmediğini göstermektedir.

Peki, istemci tarafı doğrulama, işlemleri etkili bir şekilde nasıl doğrular?

Öncelikle neyin doğrulanması gerektiğine bakalım:

• Durum (işlem mantığı doğrulaması)

• TxIn geçerliliğini girin (çifte harcamayı önlemek için)

BTC'de ihraç edilen varlıklar için, her işlemin, referans alınan girdinin harcanmadığından ve durumunun doğru olduğundan emin olmak için ilgili işlem geçmişinin tamamının doğrulanmasını gerektirdiği açıktır. Bu son derece verimsizdir. Peki nasıl geliştirilebilir?

Peter Todd, doğrulamanın odağını değiştirerek bu süreci basitleştirebileceğimize inanıyor. Bu yöntem, bir çıktının çifte harcanmadığını doğrulamak yerine, işlemin girdilerinin yayınlandığını ve diğer girdilerle çelişmediğini doğrulamaya odaklanır. Her bloktaki girişleri sıralayarak ve bir Merkle ağacı kullanarak, bu tür bir doğrulama daha verimli bir şekilde yapılabilir, çünkü her doğrulama, o girişin tüm zincir geçmişine değil, yalnızca küçük bir veri kısmına ihtiyaç duyar.

Peter Todd bir taahhüt ağacının yapısını şu şekilde önerdi:

CTxIn -> CTxOut -> <merkle path> -> CTransaction -> <merkle path> -> CTxIn

Peki böyle bir taahhüt ağacını zincirde nasıl saklayacağız? Bu bizi tek kullanımlık mühür kavramına götürüyor.

Tek Kullanımlık Mühür

Tek kullanımlık mühür, gerçek dünyada kargo nakliye konteynırlarını korumak için kullanılan fiziksel, tek kullanımlık mühürlere benzer şekilde, müşteri tarafı doğrulamayı anlamak için temel kavramlardan biridir. Tek kullanımlık mühür, bir mesajı tam olarak bir kez kapatabilen benzersiz bir nesnedir. Kısaca tek kullanımlık mühür, çifte harcamayı önlemek için kullanılan soyut bir mekanizmadır.

SealProtocol için üç öğe ve iki eylem vardır.

Basit elementler:

1. l: mühür, yani mühür
2. m: mesaj, mesaj
3. : tanık, tanık

Temel işlemler: İki temel işlem vardır:

1. Close(l,m) → w: messagemupper'ın kapanış mühründe bir tanık oluşturun。
2. Doğrula(l,w,m) → bool: Mührü doğrulaHaberlerde misiniz?mis kapalı.

Tek kullanımlık mühür uygulaması güvenlik açısından iki farklı mesajın saldırgan m1 ve m2 tarafından bulunamaması Verify fonksiyonunun aynı sealtrueof değerini döndürmesine neden olur.

Öncelikle Tek Kullanımlık Mühür, belirli bir varlığın veya verinin yalnızca bir kez kullanılmasını veya kilitlenmesini sağlayan bir kavramdır. Bitcoin bağlamında bu genellikle bir UTXO'nun (harcanmamış işlem çıktısının) yalnızca bir kez harcanabileceği anlamına gelir. Dolayısıyla bir Bitcoin işleminin çıktısı tek seferlik bir mühür sayılabilir ve bu çıktı başka bir işleme girdi olarak kullanıldığında mühür “kırılır” veya “kullanılır”.

BTC'deki CSV varlıkları için Bitcoin'in kendisi tek seferlik mühürlü bir "tanık" görevi görür. Bunun nedeni, bir Bitcoin işlemini doğrulamak için bir düğümün, işleme yapılan her girişin geçerli ve harcanmamış bir UTXO'ya referans verip vermediğini kontrol etmesi gerektiğidir. Bir işlem, halihazırda harcanmış olan bir UTXO'yu iki katına çıkarmaya çalışırsa, Bitcoin'in fikir birliği kuralları ve ağdaki dürüst düğümler, işlemi reddedecektir.

Daha basit olabilir mi?

tek kullanımlık mühür Yani herhangi bir blockchain veri tabanı olarak kabul edilir. Belirli bir mesajın vaadini bir şekilde bu veri tabanında saklıyoruz ve onun tüketildi veya tüketilecek durumunu koruyoruz.

Evet, bu kadar basit.

Özetlemek gerekirse, müşteri tarafından doğrulanan varlıklar aşağıdaki özelliklere sahiptir:

1. Zincir dışı veri depolama: Müşteri tarafından doğrulanan varlıkların işlem geçmişi, sahiplik ve diğer ilgili verilerinin çoğu zincir dışında depolanır. Bu, zincir üzerindeki veri depolama ihtiyaçlarını büyük ölçüde azaltır ve gizliliğin geliştirilmesine yardımcı olur.
2. Taahhüt mekanizması: Varlık verileri zincir dışında saklansa da, bu verilerde yapılan değişiklikler veya aktarımlar taahhütler aracılığıyla zincir üzerinde kaydedilecektir. Bu taahhütler, zincir içi işlemlerin zincir dışı durumlara referans vermesini sağlar, böylece zincir dışı verilerin bütünlüğünü ve değiştirilemezliğini sağlar.
3. Zincir içi tanık (mutlaka BTC değil): Verilerin ve doğrulamanın çoğu zincir dışı olsa da, müşteri tarafından doğrulanan varlıklar, gömülü taahhütler aracılığıyla yine de temel zincirin güvenliğinden (kanıtların yayınlanması, işlemlerin sıralanması) yararlanabilir. -zincir.
4. Doğrulama istemci tarafında yapılır: Doğrulama çalışmalarının çoğu kullanıcının cihazında yapılır. Bu, tüm ağ düğümlerinin her işlemin doğrulanmasına katılmasının gerekmediği, yalnızca ilgili katılımcıların işlemin geçerliliğini doğrulaması gerektiği anlamına gelir.

Varlıkların istemci tarafı doğrulamasını kullananlar için dikkat edilmesi gereken başka bir nokta daha var:

Zincir dışı alım satım yaparken ve müşteri tarafından doğrulanan varlıkları doğrularken, yalnızca varlığı tutan özel anahtarı göstermemelisiniz, aynı zamanda ilgili varlığın tam merkel yolunun kanıtını da göstermelisiniz.

İstemci Tarafı Doğrulamada (CSV) Öncü: RGB

RGB kavramı, 2015'ten sonra toplumun tanınmış isimlerinden Giacomo Zucco tarafından önerildi. Ethereum'un yükselişi ve ICO'ların yaygınlaşması nedeniyle ve ICO'lardan önce birçok kişi Mastercoin ve Colored Coins projeleri gibi Bitcoin dışında şeyler yapmaya çalışıyordu. .

Giacomo Zucco hayal kırıklığını dile getirdi. Bu projelerin Bitcoin'den daha düşük olduğuna inanıyor ve token'ları Bitcoin'e uygulamanın önceki yollarının uygunsuz olduğuna inanıyor. Bu süreçte Peter Todd'la tanıştı ve Peter Todd'un İstemci Tarafı Doğrulama fikrine hayran kaldı. Daha sonraRGBfikrini öne sürmeye başladı.

RGB ile önceki varlık protokolleri arasındaki en büyük fark, daha önce bahsedilen istemci tarafı varlık doğrulama özelliklerine ek olarak, Turing-complete sözleşme yürütme motorunu uygulamak için bir yürütme VM'si de eklemesidir. Ayrıca sözleşme verilerinin güvenliğini sağlamak amacıyla Şema ve Arayüz de tasarlanmıştır. Schema, Ethereum'a benzer, sözleşmenin içeriğini ve işlevlerini bildirir; Arayüz ise tıpkı programlama dillerindeki arayüz gibi belirli işlevlerin uygulanmasından sorumludur.

Bu sözleşmelerin şemaları, sırasıyla misli tokenlerin ve misli olmayan tokenların işlemlerine ilişkin bazı kısıtlamalardan sorumlu olan RGB20 ve RGB21 gibi, sanal makine çalıştırıldığında beklenen davranışı aşmayan davranışları kısıtlamaktan sorumludur.

RGB'nin Taahhüt Mekanizması: Pedersen Hash

Taahhüt mekanizmaları açısından RGB, Pedersen Hash'ı benimser. Avantajı, bir değeri ifşa etmeden taahhüt edebilmektir. Bir Merkle ağacı oluşturmak için Pedersen Karmasını kullanmak, içindeki değerleri gizleyen, gizlilik korumalı bir Merkle ağacı oluşturabileceğiniz anlamına gelir. Bu yapı, bazı anonim kripto para birimi projeleri gibi belirli gizlilik koruma protokollerinde kullanılabilir. Ancak daha sonra Taproot Assets ile karşılaştırmada bahsedilecek olan CSV varlıkları için uygun olmayabilir.

RGB'nin Sanal Makine Tasarımı: Basitlikten AluVM'ye

RGB, yalnızca müşteri tarafından doğrulanmış bir varlık protokolünü uygulamayı değil, aynı zamanda Turing-tam sanal makine yürütme ve sözleşme programlamasını da genişletmeyi amaçlamaktadır. RGB'nin ilk tasarımında Simplicity adlı bir programlama dili kullanıldığı iddia ediliyordu. Bu dil, ifadeleri çalıştırırken bir yürütme kanıtı oluşturması ve içinde yazılan sözleşmelerin resmi olarak doğrulanmasını kolaylaştırması (hataları önlemek için) ile karakterize edilir. Ancak bu dilin gelişimi ideal değildi ve sonunda zorluklarla karşılaştı. Bu doğrudan o yıl RGB protokolünün zor doğmasına yol açtı. Sonuçta RGB, başlangıçtaki Basitliğe benzer şekilde tanımsız davranışlardan kaçınmak amacıyla Maxim tarafından geliştirilen AluVM'yi kullanmaya başladı. Yeni AluVM'nin gelecekte yerini şu anda Rust kullanan Contractum adlı bir programlama dilinin alacağı söyleniyor.

RGB'nin Katman 2 Genişleme Yönü: Lightning Network mü, Yan Zincir mi?

Müşteri tarafından doğrulanan varlıklar, sürekli işlemleri zincir dışında güvenli bir şekilde gerçekleştiremez. Müşteri tarafından doğrulanan varlıklar, işlem yayınlama ve sıralama için hâlâ L1'e bağlı olduğundan işlem hızları, L1 tanıklarının blok oluşturma hızıyla sınırlıdır. Bu, eğer RGB işlemleri katı güvenlik gereksinimleri altında doğrudan Bitcoin üzerinde gerçekleştiriliyorsa, ilgili iki işlem arasındaki sürenin en az on dakika (BTC'nin blok süresi) olması gerektiği anlamına gelir. Kuşkusuz, bu tür işlem hızı çoğu durumda çoğunlukla kabul edilemez.

RGB ve Lightning Ağı

Basitçe söylemek gerekirse, Lightning Network'ün prensibi, bir işleme dahil olan iki tarafın zincir dışı bir dizi sözleşme (taahhüt işlemleri) imzalamasıdır. Bunlar, herhangi bir tarafın sözleşmeyi ihlal etmesi durumunda mağdur tarafın sözleşmeyi (taahhüt işlemi) uzlaşma için BTC'ye sunabilmesini, fonlarını geri alabilmesini ve diğer tarafı cezalandırabilmesini sağlar. Başka bir deyişle Lightning Network, zincir dışı işlemlerin güvenliğini protokol tasarımı ve oyun teorisi yoluyla sağlar.

RGB, kendisine uygun ödeme kanalı sözleşme kuralları tasarlayarak kendi Lightning Network altyapısını kurabilir ancak Lightning Network'ün karmaşıklığı son derece yüksektir ve bu sistemi kurmak kolay bir iş değildir. Ancak bunun aksine Lightnling Labs bu alanda uzun yıllardır çalışıyor ve LND %90'dan fazla pazar payına sahip.

RGB'nin Yan Zinciri: Prime

Şu anda RGB protokolünü koruyan LNP-BP, Maxim'in Haziran 2023'te müşteri tarafından doğrulanmış bir varlık genişletme planı olan Prime adlı bir teklifi yayınlamasıyla birlikte. İçinde mevcut yan zincir ve Lightning Network genişletme planlarını geliştirme aşamasında çok karmaşık olmakla eleştirdi. Maxim, Prime'ın yanı sıra diğer genişletme yöntemlerinin NUCLEUS çok düğümlü Lightning kanalları ve Ark/Enigma kanal fabrikalarını içerdiğine inandığını ve bunların her ikisinin de iki yıldan fazla geliştirme gerektirdiğine inandığını belirtti. Ancak Prime yalnızca bir yılda tamamlanabilir.

Prime, geleneksel bir blockchain tasarımı değil, müşteri doğrulaması için tasarlanmış, dört bölümden oluşan modüler bir kanıt yayın katmanıdır:

1. Zaman Damgası Hizmeti: Bir işlem sırasının 10 saniye gibi kısa bir sürede belirlenmesi.

2. Kanıt: PMT formatında saklanır, üretilir ve blok başlığıyla birlikte yayınlanır.

3. Tek Kullanımlık Mühür: Çift harcama koruması sağlayan soyut bir tek seferlik mühür protokolü. Bitcoin'e uygulanırsa mevcut RGB tasarımına benzer şekilde UTXO'ya bağlanabilir.

4. Akıllı Sözleşme Protokolü: Parçalanabilir Sözleşmeler - RGB (değiştirilebilir).

Prime, RGB işlem onay süreleri sorununu çözmek için zincir dışı işlemleri hızlı bir şekilde onaylamak ve işlemleri ve kimlikleri bloklar halinde kapsüllemek için bir zaman damgası hizmeti kullanıyor. Eş zamanlı olarak, Prime'daki işlem kanıtları PMT aracılığıyla daha da birleştirilebilir ve daha sonra kontrol noktalarına benzer bir şekilde BTC'ye sabitlenebilir.

Taproot Tabanlı CSV Varlık Protokolü: Taproot Varlıkları

Taproot Assets, Bitcoin blok zincirinde müşteri tarafından doğrulanan varlıkları yayınlamak için kullanılan, Taproot'a dayalı bir CSV varlık protokolüdür. Bu varlıklar Lightning Network üzerinden anında, büyük miktarlarda ve düşük maliyetle alınıp satılabilir. Taproot Assets'in özü, Bitcoin ağının güvenliğinden ve istikrarından ve Lightning Network'ün hızından, ölçeklenebilirliğinden ve düşük maliyetinden yararlanmaktır. Bu protokol, bu gezegende hem Bitcoin istemcisinin (BTCD) hem de Lightning Network istemcisinin (LND) geliştirilmesine kişisel olarak liderlik eden ve derin bir anlayışa sahip olan tek kişi olan Lightnling Labs'ın CTO'su roasbeef tarafından tasarlanmış ve geliştirilmiştir. BTC'nin.

Taproot işlemleri yalnızca varlık komut dosyasının kök karmasını taşır, bu da karmanın kendisi genel olduğundan ve herhangi bir veriyi temsil edebildiğinden harici gözlemcilerin Taproot Varlıklarını içerip içermediklerini belirlemelerini zorlaştırır. Taproot yükseltmesiyle Bitcoin, akıllı sözleşmeler (TapScript) özelliğini kazandı. Buna dayanarak Taproot Assets'in varlık kodlaması, ERC20 veya ERC721'e benzer bir token tanımı oluşturmaya benzer. Böylece Bitcoin, yalnızca varlık tanımlama işlevine değil aynı zamanda akıllı sözleşmeler yazma yeteneğine de sahip olup, Bitcoin üzerinde token akıllı sözleşme altyapısının temelini atmaktadır.

Taproot Assets'in kodlama yapısı şu şekildedir: [Açıklama burada sona ermektedir ve makalenin bir sonraki bölümünün muhtemelen Taproot Assets kodlama yapısının teknik ayrıntılarına gireceğini göstermektedir.]

Lightning Labs CTO roasbeef aracılığıyla görüntü

CSV (CoinSwap) varlık protokolleri olarak Taproot Assets, RGB'ye kıyasla daha akıcı olacak şekilde tasarlanmıştır. Taproot yükseltmesi ve PSBT (Kısmen İmzalı Bitcoin İşlemleri) gibi BTC ekosistemindeki mevcut gelişmelerin kullanımını en üst düzeye çıkarırlar. Uygulama genişletilebilirliği açısından Taproot Assets ile RGB arasındaki en önemli fark, VM'nin (Sanal Makine) yürütülmesinde yatmaktadır. Taproot Assets, BTC tarafından kullanılan yerel VM ile aynı olan TaprootScriptVM'yi kullanır. Son yıllarda BTC için yapılan birçok altyapı çalışması TapScript'e dayandırılıyor. Ancak BTC yükseltmelerinin yavaş ilerlemesi nedeniyle bu çalışmalar hızlı bir şekilde uygulanmadı ve bu da Taproot Assets'i bu yeni fikirler için potansiyel bir test alanı haline getiriyor.

Taproot Varlıkları ve RGB'nin farkı nerede?

1. İşlem Doğrulaması ve Işık Düğümü Kolaylığı

Toplama ağacının uygulanması nedeniyle, Taproot Assets yüksek doğrulama verimliliğine ve güvenliğine sahiptir (doğrulama ve işlem, tüm işlem geçmişinin üzerinden geçilmeden, yalnızca bir tutma kanıtı ile gerçekleştirilebilir). Buna karşılık, RGB'nin Pedersen taahhütlerini kullanması, girdilerin etkili bir şekilde doğrulanmasını engeller ve RGB'nin işlem geçmişini geriye doğru izlemesini gerektirir ve bu da zamanla önemli bir yük haline gelir. Merkel toplam ağacının tasarımı, BTC üzerine kurulu önceki varlık protokollerinde bulunmayan bir özellik olan Taproot Assets'te ışık düğümü doğrulamasını da kolaylaştırıyor.

1. Yürütme VM'si

Taproot Varlıkları, Taproot yükseltmesinin ardından ortaya çıktı. Bitcoin'in Taproot sonrası yükseltmesinde bulunan komut dosyası yürütme motoru olan TaprootScriptVM'yi ve BTC'nin PSBT'sinin bir çeşidi olan vPSBT'yi kullanıyorlar. Taproot Assets'in yıldırım kanalı mekanizması tamamlandığında, mevcut tüm LND altyapısını ve geçmiş Lightning Labs ürünlerini anında yeniden kullanabilir (LND şu anda yıldırım ağının %90'ından fazlasına hakimdir). Yine TaprootScript'i temel alan son BitVM teklifi teorik olarak Taproot Assets'i destekliyor. Ancak RGB'nin VM'si ve doğrulama kuralları (SCHEMA) bağımsızdır ve nispeten kapalı bir ekosistem oluşturur. RGB'nin gelişimi büyük ölçüde kendi ekosistemiyle sınırlıdır ve Bitcoin ekosistemiyle entegrasyonu sanıldığı kadar yakın değildir. Örneğin, RGB'nin Taproot yükseltmesiyle tek ilişkisi, zincir taahhüt verilerinin Tanık'ın TapLeaf'ine kodlanmasıdır.

1. Akıllı Sözleşmeler

RGB'nin mevcut uygulamasında sözleşmeler ve VM yoğun bir şekilde vurgulanmaktadır. Ancak akıllı sözleşmeler henüz Taproot Assets'te görünmedi. Şu anda RGB, Küresel Durumdaki değişikliklerin bireysel sözleşme parçalarıyla (UTXO) nasıl senkronize edildiğini veya yalnızca toplam varlık miktarını garanti eden Pedersen taahhütlerinin diğer durumlara yapılan müdahaleleri nasıl tespit ettiğini açıklamıyor. Bunun aksine, Taproot Assets, daha basit tasarımıyla şu anda yalnızca varlık bakiyelerini saklıyor ve kapsamlı durum depolamasından yoksun, bu da akıllı sözleşmelerin tartışılmasını erken hale getiriyor. Ancak Lightning Labs, Taproot Assets'in gelecek yıl akıllı sözleşme tasarımına odaklanacağını belirtti.

1. Senkronizasyon Merkezi

İstemci tarafı varlık doğrulamasının temel prensiplerinden anlaşılacağı üzere Proof'un tutulması, özel anahtarın tutulması kadar önemlidir. Peki ya Kanıt kullanıcının istemci tarafında kaybolursa? Taproot Assets'te bu sorun bir 'evren' aracılığıyla çözülebilir. Evren, bir veya daha fazla varlığı kapsayan, kamuya açık olarak denetlenebilen seyrek bir Merkle ağacıdır. Geleneksel Taproot varlık ağaçlarının aksine Universe, Taproot varlıklarını barındırmaz. Bunun yerine, bir veya daha fazla varlık geçmişinin bir alt kümesini taahhüt eder. RGB'de bu rol, zincir dışı kanıt verilerini P2P aracılığıyla senkronize eden Storm tarafından oynanır. Ancak RGB geliştirme ekiplerinin tarihsel sebeplerinden dolayı bu prova formatları şu anda uyumlu değildir. RGB'nin ekosistem ekibi DIBA'nın bu sorunu çözmek için 'karbonado' geliştirdiği bildiriliyor, ancak ilerleme belirsiz.

1. Mühendislik Uygulaması

Lightning Labs'ın kendi Bitcoin istemcisi (BTCD), Lightning Network istemcisi (LND) ve çok sayıda cüzdan kütüphanesi uygulaması olduğundan, Taproot Assets tarafından kullanılan tüm kütüphaneler zamana göre test edilmiştir. Buna karşılık, RGB'de kullanılan kitaplıkların çoğu kendi kendine tanımlanır ve endüstriyel standart bakış açısından RGB'nin uygulanması hâlâ deneysel aşamadadır."

BTC Genişlemesinin Geleceği Üzerine Kısa Bir Tartışma

Tartışma ilerledikçe, varlık protokollerinin istemci tarafı doğrulamasının, protokol spesifikasyonları alanının ötesine geçtiği ve hesaplamalı genişlemeye doğru yöneldiği açıkça ortaya çıkıyor.

Pek çok kişi, Bitcoin'in gelecekte dijital altın olarak var olacağına ve diğer zincirlerin uygulama ekosistemini oluşturacağına inanıyor. Ancak benim farklı bir fikrim var. BTC forumlarındaki birçok tartışmada görüldüğü gibi, bunlar genellikle çeşitli altcoinler ve bunların kısa ömürlü varlığı etrafında dönüyor. Bu altcoinlerin hızlı ölümü, onları çevreleyen sermayeyi ve çabaları balonlara dönüştürüyor. Bitcoin'in güçlü fikir birliği temeli sayesinde uygulama protokolleri için yeni bir L1 oluşturmaya gerek yoktur. Yapmamız gereken şey, daha uzun vadeli merkezi olmayan bir dünya inşa etmek için Bitcoin'in bu sağlam altyapısından yararlanmaktır.

Daha az zincir içi hesaplama, daha fazla zincir içi doğrulama

Tasarım açısından bakıldığında, Bitcoin başlangıçta zincir içi hesaplamaya odaklanmamayı, bunun yerine doğrulama merkezli bir felsefeye (Akıllı sözleşmeler için Turing bütünlüğü ve durumu) odaklanmayı seçti. Blockchain aslında kopyalanmış bir durum makinesidir. Bir zincirin fikir birliği zincir içi hesaplamaya dayanıyorsa, ağdaki tüm düğümlerin bu hesaplamaları tekrarlamasının mantığını ve ölçeklenebilirliğini haklı çıkarmak zordur. Doğrulamaya odaklanırsak zincir dışı işlemlerin etkinliğini doğrulamak BTC için en uygun genişleme stratejisi olabilir.

Doğrulama nerede gerçekleşir? Bu önemli

Bitcoin'in yanı sıra protokol geliştiricileri için, kritik doğrulamalar için Bitcoin'in nasıl kullanılacağı, hatta doğrulamaların zincir dışına nasıl yerleştirileceği ve güvenlik planlarının nasıl tasarlanacağı, protokol tasarımcılarının kendilerini ilgilendiren konulardır. Bunlar zincirin kendisi ile ilişkilendirilmemeli ve ilişkilendirilmemelidir. Bu nedenle doğrulamanın nasıl uygulandığı BTC için farklı genişleme stratejilerine yol açacaktır.

Doğrulama uygulaması perspektifine dayanarak genişleme için üç yönümüz var:

1. 1.Zincir üstü doğrulama (OP-ZKP)
2. OP-ZKP'nin doğrudan TaprootScriptVM'de uygulanması, ZKP doğrulama yeteneklerinin BTC'nin kendisine entegre edilmesi, uzlaşma protokolleri için bazı Covenant tasarımlarıyla birleştirilmesi ve BTC'nin güvenliğini devralan bir Zk-Rollup genişletme planı oluşturulması anlamına gelir. Bununla birlikte, Ethereum'da bir doğrulama sözleşmesi dağıtmanın aksine, BTC'nin yavaş yükseltme süreci, bu kadar uzmanlaşmış ve potansiyel olarak yükseltme gerektiren bir işlem koduyla birleştiğinde, bunu zorlaştırıyor.
4. 2. Yarı zincir üzerinde doğrulama (BitVM)
5. BitVM'nin tasarımı düzenli işlem mantığına hizmet etme amacı taşımamaktadır. Robin Linus ayrıca BitVM'nin geleceğinin çeşitli SideChain'ler için ücretsiz bir zincirler arası pazar yaratmada yattığını belirtti. BitVM'nin yaklaşımı yarı zincir olarak kabul edilir çünkü bu doğrulama hesaplamalarının çoğu zincir üzerinde değil, zincir dışında gerçekleşir. Bununla birlikte, BTC'nin Taproot'u etrafında tasarım yapmanın önemli bir nedeni, gerektiğinde hesaplamalı doğrulama için TapScriptVM'yi kullanmak ve teorik olarak BTC'nin güvenliğini devralmaktır. Bu süreç aynı zamanda bir doğrulama güven zinciri de oluşturur. Örneğin, 'n' doğrulayıcılardan birinin, İyimser Toplamalara benzer şekilde dürüst olması yeterlidir.
6. BitVM'nin zincir içi maliyetleri yüksek ancak verimliliği artırmak için ZK dolandırıcılık kanıtlarını kullanabilir mi? Cevap hayır, çünkü ZK dolandırıcılık kanıtlarının uygulanması zincir üzerinde ZKP doğrulaması gerçekleştirme yeteneğine dayanıyor ve bu da bizi OP-ZKP planının ikilemine geri getiriyor.
8. 3. Zincir Dışı Doğrulama (İstemci Tarafı Doğrulama, Lightning Network)
9. Doğrulamanın tamamen zincir dışında gerçekleşmesiyle, daha önce tartışılan CSV varlık protokollerine ve Lightning Network'e geri dönüyoruz. Önceki tartışmalarda, CSV tasarımında gizli anlaşmalı kurcalamayı tamamen önleyemeyeceğimiz belirtilmişti. Yapabileceğimiz şey, kötü niyetli gizli anlaşma hasarını kontrol edilebilir bir aralıkta tutmak ve bu tür davranışları kârsız hale getirmek için kriptografi ve protokol tasarımı kullanmaktır.
10. Zincir dışı doğrulamanın artıları ve eksileri açıktır. Avantajı, zincir üstü kaynakların minimum düzeyde kullanılması ve muazzam genişleme potansiyelidir. Dezavantajı ise BTC'nin güvenliğinden tam olarak yararlanmanın neredeyse imkansız olmasıdır, bu da zincir dışı işlemlerin türlerini ve yöntemlerini büyük ölçüde sınırlandırmaktadır. Dahası, zincir dışı doğrulama aynı zamanda verilerin kullanıcılar tarafından zincir dışında tutulduğu ve yönetildiği anlamına da gelir; bu da yazılım yürütme ortamının güvenliği ve yazılım kararlılığı için daha yüksek gereksinimler gerektirir.

Genişleme Evrimi Eğilimi

Şu anda, Ethereum'daki popüler Layer2, özünde, Layer2'nin hesaplama etkinliğini doğrulamak için Layer1'i kullanıyor. Yani durum hesaplamaları Katman2'ye aktarılır ancak doğrulama Katman1'de kalır. Gelecekte benzer şekilde doğrulama hesaplamalarını zincir dışına itebilir ve mevcut blockchain altyapısının performansını daha da açığa çıkarabiliriz.

Yasal Uyarı:

1. Bu makale [ayna] adresinden yeniden basılmıştır. Tüm telif hakları orijinal yazara [Ben77] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.