Önsöz

BTC'ye dayalı varlık ihraç etmek her zaman sıcak bir konu olmuştur. 2011'deki en eski Renkli Paralardan son zamanlarda popüler olan Ordinal protokolüne kadar, BTC topluluğu sürekli olarak yeni oyuncular ve fikir birliği bulmayı başardı, ancak çok azı ayakta kalmayı başardı. Ancak Lightning Labs, Taproot Assets'e dayalı stabilcoinler geliştirmeye yönelik iddialı planlarını açıkladı. Tether ayrıca Bitcoin'in 1. katmanında USDT basmak için RGB protokolünü kullanacağını duyurdu.

Bu, bir zamanlar ünlü olan OmniLayer'ın (eski adıyla Mastercoin) artık BTC ekosistemindeki en büyük oyuncu olmadığı anlamına geliyor. Ve istemci tarafı doğrulama (CSV) varlık protokolleri herkesin görüşüne girmeye başlıyor. Bu protokoller yalnızca geleneksel Bitcoin varlık protokollerinin bütünlüğünü korumakla kalmaz, aynı zamanda ölçeklenebilirliği de artırır. Bununla birlikte, Bitcoin ekosistemindeki bir dizi varlık protokolü, ilgili soruları gündeme getiriyor: Birbirlerinden nasıl farklılar ve bu manzaradaki fırsatlar nasıl yönlendirilmeli ve yakalanmalıdır?

Bu makale, Bitcoin tarihinde ortaya çıkan çeşitli varlık protokollerinin kapsamlı bir incelemesi yoluyla okuyuculara rehberlik etmeyi amaçlamaktadır. Ayrıca, öngörülebilir gelecekte Bitcoin tabanlı varlık protokollerinin evrimi için potansiyel yörüngeleri araştırmayı amaçlıyor.

Renkli Paralar

Renkli Paralar kavramı ilk olarak şu anda eToro'nun CEO'su olan Yoni Assia tarafından 27 Mart 2012'de "bitcoin 2.X (diğer adıyla Renkli bitcoin) " adlı ufuk açıcı makalesinde dile getirildi. Makale, Bitcoin'in temelindeki teknolojinin internet için HTTP kadar temel ve kusursuz olduğunu öne sürdü. Bu nedenle Renkli Paralar token protokolü BTC'nin üzerine tasarlandı.

Yoni Assia, bu yenilik yoluyla BTC 2.0 ekonomilerinin yaratılmasını öngördü ve herhangi bir topluluğun bu şekilde birden fazla para birimi üretmesine olanak tanıdı. İşlemlerin çözümü ve çifte harcamaların önlenmesi için Bitcoin'in temel teknolojisini kullanmak o zamanlar öncü bir fikirdi.

Renkli Paralar, Bitcoin blok zincirinde varlık ihraç etmek için tasarlanmış bir protokoldür. Diğer varlıkları belirtmek için bitcoinlerin belirli bir kısmını “renklendirerek” çalışır. Bu işaretli Bitcoinler hala orijinal işlevlerini koruyor ancak aynı zamanda başka bir varlığı veya değeri de temsil ediyorlar. Ancak asıl soru, bu fikrin Bitcoin ağında nasıl hayata geçirilebileceğiydi.

3 Temmuz 2014'te ChromaWay, geliştiriciler için renkli paralar oluşturma sürecini büyük ölçüde basitleştiren Gelişmiş Renkli Paralar Sıra Tabanlı Protokolü (EPOBC) geliştirerek önemli bir adım attı. Bu, Bitcoin Script'in OP_RETURN işlevini kullanan açılış protokolüydü.

Sonuç şöyle görünüyordu:

Böyle bir uygulama çok kısadır ancak birçok sorunu da beraberinde getirir:

1. Değiştirilebilirlik ve minimum bağlama değeri sorunu Renkli bir coinin oluşum işleminde 1000 sato bağlanarak o renkli coinin minimum birimi 1 sat olur. Bu, varlığın veya tokenın teorik olarak maksimum 1000 birime bölünebileceği anlamına gelir (ancak pratikte toz saldırılarını önlemek için daha düşüktür. Örneğin, minimum satoshi değeri bir zamanlar 546 SAT olarak belirlenmişti ve Ordinaller için bu daha da yüksekti).
2. Doğrulama zorlukları Renkli bir coinin orijinalliğini ve sahipliğini belirlemek için, işlem geçmişinin geriye doğru izlenmesi ve oluşum işleminden mevcut UTXO'ya kadar doğrulanması gerekir. Bu nedenle özel cüzdanların, tam düğümlerin ve hatta tarayıcıların geliştirilmesi gerekiyor.
3. Potansiyel madenci sansürü riski ColoredTransaction'ın çıktıya meta veri yazılması gibi farklı özellikleri vardır, bu da madenci sansürü olasılığını beraberinde getirir.

Renkli Paralar, esasen varlık transferlerini izlemek için Bitcoin'in doğrulama kurallarını kullanan bir varlık izleme sistemidir. Ancak herhangi bir çıktının (txout) belirli bir varlığı temsil ettiğini kanıtlamak için varlığın kaynağından tüm transfer zincirini sağlamanız gerekir. Bu, bir işlemin geçerliliğinin doğrulanmasının uzun bir kanıt zinciri gerektirebileceği anlamına gelir. Bu sorunu çözmek için Colored Coin işlemlerinin doğrudan BTC üzerinde doğrulanmasına yardımcı olmak amacıyla OP_CHECKCOLORVERIFY gibi önerilerde bulunuldu ancak teklif kabul edilmedi.

Kriptoda İlk ICO: Mastercoin

Mastercoin kavramı ilk olarak JR Willett tarafından önerildi. 2012 yılında, mevcut Bitcoin blok zincirinin üzerinde yeni varlıklar veya tokenler oluşturma fikrini özetleyen "İkinci Bitcoin Teknik İncelemesi " başlıklı bir teknik inceleme yayınladı. Bu konsept sonunda “MasterCoin” olarak bilinmeye başlandı ve daha sonra Omni Layer olarak yeniden adlandırıldı.

2013 yılında Mastercoin projesi, bugün ICO (İlk Para Teklifi) olarak adlandırdığımız şeyin ilk versiyonunu gerçekleştirdi ve başarıyla milyonlarca dolar topladı. Bu tarihteki ilk ICO olarak kabul ediliyor. Mastercoin'in en dikkate değer uygulamalarından biri, başlangıçta Omni Layer'da piyasaya sürülen, iyi bilinen fiat teminatlı stabilcoin olan Tether'dir (USDT).

Aslında Mastercoin fikri Renkli Paralardan önce ortaya çıktı. Bunu ikinci kez tartışmamızın nedeni ise Colored Coins'e kıyasla MasterCoin'in nispeten daha kapsamlı bir çözüm olmasıdır. MasterCoin, akıllı sözleşmeler gibi daha karmaşık işlevler sunan bir tam düğüm katmanı oluşturdu. Buna karşılık, Renkli Paralar daha basit ve daha doğrudandır; öncelikle Bitcoin UTXO'ları diğer varlıkları temsil edecek şekilde "renklendirmeye" veya işaretlemeye odaklanır.

İkisi arasındaki en önemli fark, Mastercoin'in blockchain üzerinde yalnızca çeşitli işlem davranışlarını kaydetmesi ve ilgili varlık bilgilerini saklamamasıdır. Mastercoin düğümlerinde, Bitcoin bloklarının taranmasıyla durum modelinin bir veri tabanı korunur ve bu veri tabanı, blok zincirinin dışındaki düğümlerde bulunur.

Renkli Paralarla karşılaştırıldığında Mastercoin daha karmaşık bir mantık yürütebilir. Ayrıca, blockchain üzerindeki durumları kaydetmediğinden veya doğrulamadığından, işlemlerinin ardışık (sürekli renkli) olması gerekmez.

Ancak Mastercoin'in karmaşık mantığını uygulamak için kullanıcıların, düğümler içindeki zincir dışı veritabanında tutulan duruma güvenmesi veya doğrulamaları gerçekleştirmek için kendi Omni Layer düğümlerini çalıştırması gerekir.

Özetle:

Mastercoin ve Renkli Paralar arasındaki temel fark, Mastercoin'in protokol için gereken tüm verileri blok zincirinde tutmamasıdır. Bunun yerine, kendi işlem yayınlama ve sıralama işlemlerini yönetmek için Bitcoin'in fikir birliği sistemini kullanıyor ve ardından durumu zincir dışı bir veritabanında tutuyor.

OmniBolt tarafından sağlanan bilgilere göre: Omni Layer, Tether'e Taproot yükseltmesini kullanacak yeni bir UBA (UTXO Tabanlı Varlık) varlık protokolü öneriyor. Bu protokol, varlık bilgilerini tapleaf'e yerleştirecek ve koşullu ödemeler gibi işlevleri etkinleştirecek. OmniBolt aynı zamanda Stark'ı Omni Layer'ın Lightning Network altyapısına entegre etmek için de çalışıyor.

İstemci Tarafı Doğrulama Kavramı

Müşteri Tarafı Doğrulama (CSV) kavramını anlamak istiyorsak, Colored Coins ve Mastercoin'in ortaya çıkışından sonraki yıla, yani 2013 yılına dönmemiz gerekiyor. O yıl, ilk Bitcoin ve kriptografi araştırmacılarından biri olan Peter Todd, "Kripto Para Madenciliğini Çözmek: Zaman Damgası, Yayın Kanıtı ve Doğrulama" başlıklı bir makale yayınladı.“ Her ne kadar başlıkta Müşteri Tarafı Doğrulama'dan açıkça bahsedilmese de, dikkatli bir okuma bunun kavramı tanıtan ilk yazılardan biri olduğunu ortaya koyuyor.

Peter Todd, Bitcoin'in işleyişini daha verimli hale getirmenin yollarını arıyor. Zaman damgaları fikrine dayalı olarak daha karmaşık bir istemci tarafı doğrulama konsepti geliştirdi. Ayrıca daha sonra bahsedilecek olan “tek kullanımlık mühür” kavramını da ortaya attı.

Peter Todd'un düşüncesini takip etmek için öncelikle Bitcoin'in gerçekte hangi sorunu çözdüğünü anlamamız gerekiyor. Peter Todd'a göre Bitcoin üç konuyu ele alıyor:

1. Yayın kanıtı: Yayın kanıtının özü, çift harcama sorununu çözmektir. Örneğin Alice, Bob'a bir miktar bitcoin aktarmak istiyorsa, Bob'a transfer etmek için bir işlem imzalamış olmasına rağmen Bob, böyle bir işlemin varlığından fiziksel olarak haberdar olmayabilir. Bu nedenle işlemlerin yayınlanacağı halka açık bir yere ihtiyacımız var ve herkes oradan işlemleri sorgulayabilir.
2. Sıra fikir birliği: Bilgisayar sistemlerinde genellikle yaşadığımız fiziksel zaman mevcut değildir. Dağıtılmış sistemlerde zaman genellikle fiziksel zamanımız için bir ölçü sağlamayan ancak işlemlerimizi düzenleyen Lamport zaman damgalarıdır.
3. Doğrulama (İsteğe bağlı): Bitcoin'de doğrulama, imzaların ve BTC işlemlerinde aktarılan tutarların doğrulanmasını içerir. Ancak Peter Todd, Bitcoin'in üzerine bir token sistemi oluşturmak için bu doğrulamanın gerekli olmadığına inanıyor; bu sadece bir optimizasyon seçeneğidir.

Bu noktada daha önce bahsettiğimiz OmniLayer'ı hatırlayacaksınız. OmniLayer, durum hesaplamasını ve doğrulamasını Bitcoin'e devretmez, ancak Bitcoin'in güvenliğini yeniden kullanır. Renkli Paralar ise durum takibini Bitcoin'e emanet ediyor. Bu iki sistemin varlığı, doğrulamanın mutlaka blockchain üzerinde gerçekleşmesi gerekmediğini zaten göstermiştir.

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

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

1. Durum (işlem mantığı doğrulaması)
2. Çift harcamayı önlemek için girişlerin (TxIn) geçerli olduğunu doğrulayın.

Bitcoin'de ihraç edilen varlıklar için, her işlemin, referans alınan girdilerin harcanmadığından ve durumun doğru olduğundan emin olmak için ilgili işlem geçmişinin tamamının doğrulanmasını gerektirdiğini fark etmek kolaydır. Bu son derece pratik değildir. Peki bunu nasıl geliştirebiliriz?

Peter Todd, doğrulamanın odağını değiştirerek bu süreci basitleştirebileceğimizi öne sürüyor. Bu yöntem, çıktının çifte harcanmadığını doğrulamak yerine, bir işlemin girdilerinin yayımlandığından ve diğer girdilerle çakışmadığından emin olmaya 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ü girişin tüm zincir geçmişine değil, her seferinde yalnızca küçük bir veri kısmına ihtiyaç duyar.

Peter Todd tarafından önerilen taahhüt ağacı yapısı aşağıdaki gibidir:

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

Peki böyle bir taahhüt ağacını blockchain üzerinde nasıl saklayabiliriz? “Tek kullanımlık mühür” kavramını burada tanıtabiliriz.

Tek Kullanımlık Mühür

Tek Kullanımlık Mühür, CSV'yi anlamak için temel kavramlardan biridir. Kargo konteynırlarını korumak için kullanılan fiziksel, tek kullanımlık mührün benzeridir. Tek kullanımlık mühür, mesaj üzerinde tam olarak bir kez kapatılabilen benzersiz bir nesnedir. Basit bir ifadeyle 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. ben: mühür
2. m: bilgi veya işlem olan mesaj
3. w: tanık, mührü doğrulayabilecek kişi veya şey

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

1. Kapat(l, m) → w: m mesajındaki l mührünü kapatın, bir w tanığı oluşturun.
2. Verify(l, w, m) → bool: m mesajında l mührünün kapatılıp kapatılmadığını doğrulayın.

Tek kullanımlık mühür uygulamasının güvenliği, bir saldırganın iki farklı m1 ve m2 mesajını bulamayacağı ve böylece Verify fonksiyonunun aynı mühür için true değerini döndüreceği anlamına gelir.

Basit bir ifadeyle Tek Kullanımlık Mühür, belirli bir varlığın veya veri parçasının yalnızca bir kez kullanılmasını veya kilitlenmesini sağlar. Bitcoin bağlamında bu genellikle bir UTXO'nun yalnızca bir kez harcanabileceği anlamına gelir. Yani Bitcoin işlem çıktıları tek kullanımlık mühürler olarak görülebilir ve bir çıktı başka bir işlemde girdi olarak kullanıldığında o mühür “kırılır” veya “kullanılır”.

Bitcoin üzerindeki varlıklar için, Bitcoin'in kendisi tek kullanımlık mührün "tanığı" (w) olarak hareket eder. Bunun nedeni, bir Bitcoin işlemini doğrulamak için düğümlerin, işlemin her girişinin geçerli ve harcanmamış bir UTXO'ya referans verip vermediğini kontrol etmesi gerektiğidir. Bir işlem, halihazırda kullanılmış bir UTXO'yu iki kez harcamaya çalışırsa, Bitcoin'in fikir birliği kuralları ve dürüst düğümlerden oluşan ağ, bu işlemi reddedecektir.

Daha da basitleştirmek gerekirse:

Tek kullanımlık mühür, herhangi bir blok zincirini, belirli bir mesaja yönelik taahhüdü sakladığımız ve durumunu harcanmış veya harcanmamış olarak koruduğumuz bir veritabanı gibi ele alır.

Yukarıdakileri özetlersek, istemci tarafı doğrulamayı kullanan varlıklar aşağıdaki özelliklere sahiptir:

1. Zincir Dışı Veri Depolama: İstemci tarafı doğrulamayı kullanan varlıkların işlem geçmişi, mülkiyeti ve diğer ilgili verileri çoğunlukla zincir dışında depolanır. Bu, zincir üstü veri depolama ihtiyacını büyük ölçüde azaltır ve gizliliğin artırılmasına yardımcı olur.
2. Taahhüt Mekanizması: Varlık verileri zincir dışında saklansa da bu verilerdeki değişiklikler veya aktarımlar taahhütler aracılığıyla zincir üzerinde kaydedilir. Bu taahhütler, zincir içi işlemlerin zincir dışı durumlara referans vermesine olanak tanıyarak, zincir dışı verilerin bütünlüğünü ve değişmezliğini sağlar.
3. Zincir İçi Tanıklar (Mutlaka BTC Değil): Verilerin ve doğrulamanın çoğu zincir dışında gerçekleşse de, müşteri tarafı doğrulamayı kullanan varlıklar, yerleşik taahhütler aracılığıyla temeldeki blok zincirinin güvenliğinden (yayın kanıtı, işlem siparişi) hala yararlanabilir. -zincir.
4. İstemci Tarafında Yapılan Doğrulama Çalışması: Doğrulama işinin çoğu kullanıcının cihazında yapılır. Bu, ağdaki her düğümün her işlemin doğrulanmasına katılmasının gerekmediği anlamına gelir; yalnızca ilgili tarafların işlemin geçerliliğini doğrulaması gerekir.

İstemci tarafı doğrulamalı varlıkları kullananlar için dikkat edilmesi gereken ek bir nokta daha var:

Varlıkları zincir dışı istemci tarafı doğrulamayla işlem yaparken ve doğrularken, yalnızca varlığı tutan özel anahtarı sunmak değil, aynı zamanda ilgili varlık için tam bir Merkle yolu kanıtı sağlamak da gereklidir.

RGB, CSV'nin öncüsü

RGB kavramı, 2015'ten sonra toplumun tanınmış isimlerinden Giacomo Zucco tarafından önerildi. Bu, Ethereum'un yükselişte olduğu, ICO'ların (İlk Para Teklifleri) çoğaldığı ve Mastercoin ve Renkli Paralar gibi Bitcoin'in ötesinde projeler yaratmak için birçok girişimde bulunulduğu bir dönemdi.

Giacomo Zucco bu gelişmeler karşısında hayal kırıklığına uğradı. Bu projelerin hiçbirinin Bitcoin'in potansiyeline uymadığına ve daha önce Bitcoin'de token uygulama girişimlerinin yetersiz olduğuna inanıyordu. Bu süre zarfında Peter Todd'la tanıştı ve Todd'un İstemci Tarafı Doğrulama (CSV) hakkındaki fikirlerine hayran kaldı. Bu onu RGB fikrini öne sürmeye yöneltti.

İstemci tarafı doğrulamayı kullanan varlıkların daha önce bahsedilen özelliklerinin dışında, RGB ve daha önceki varlık protokolleri arasındaki en büyük fark, Turing-tamamlanmış sözleşme yürütmesi için bir yürütme VM'sinin (Sanal Makine) eklenmesidir. Sözleşme verilerinin güvenliğini sağlamak amacıyla Şema ve Arayüz tasarlandı. Şema, Ethereum'a benzer şekilde bir sözleşmenin içeriğini ve işlevlerini bildirirken Arayüz, programlama dillerindeki arayüzlere benzer şekilde belirli işlevlerin uygulanmasından sorumludur.

Bu sözleşmelerin şemaları, VM yürütme sırasında beklentileri aşan davranışları kısıtlamaktan sorumludur. Örneğin, RGB20 ve RGB21, işlemler sırasında misli ve misli olmayan tokenlara belirli kısıtlamalar getirmekten sırasıyla sorumludur.

RGB'de kullanılan taahhüt mekanizması Pedersen Hash

Avantajı, bir değeri ifşa etmeden taahhüt edebilme yeteneğinde yatmaktadır. Bir Merkle ağacı oluşturmak için Pedersen Hash'i kullanmak, değerlerini gizleyebilen, gizliliği koruyan bir Merkle ağacı oluşturabileceğiniz anlamına gelir. Bu yapı, bazı anonim kripto para birimi projeleri gibi gizliliği koruyan bazı protokollerde kullanışlıdır. Ancak daha sonra Taproot Assets ile karşılaştırmalı olarak bahsedilecek olan CSV varlıkları için uygun olmayabilir.

RGB Basitliği için Sanal Makine Tasarımı → AluVM

RGB, yalnızca istemci tarafı doğrulanmış bir varlık protokolünü uygulamayı değil, aynı zamanda Turing'in eksiksiz sanal makine yürütmesini ve sözleşme programlamasını da genişletmeyi amaçladı. Başlangıçta RGB, bir yürütme kanıtı oluşturan ve içinde yazılan sözleşmelerin resmi olarak doğrulanmasına (hataları önlemek için) olanak tanıyan Simplicity adlı bir programlama dili kullandığını iddia etti. Ancak bu dilin gelişimi planlandığı gibi gitmedi ve sonuçta tüm RGB protokolünü engelleyen komplikasyonlara yol açtı. Sonunda RGB, orijinal Simplicity'e benzer şekilde tanımsız davranışlardan kaçınmak amacıyla Maxim tarafından geliştirilen AluVM adlı bir VM kullanmaya başladı. Yeni AluVM'nin gelecekte, mevcut Rust kullanımından uzaklaşarak Contractum adı verilen bir programlama diliyle değiştirileceği söyleniyor.

RGB katman2 ölçeklendirme yönü: Yıldırım ağı mı yoksa Yan Zincir mi?

Müşteri tarafı doğrulanmış varlıklar, işlemin yayınlanması ve sipariş edilmesi için hâlâ L1'e bağlı oldukları için zincir dışında sürekli olarak güvenli bir şekilde ticaret yapamazlar. Bu, katman 2 ölçeklendirme çözümü olmadan işlem hızlarının hala L1 tanıklarının blok üretim hızıyla sınırlı olduğu anlamına gelir. Bu, eğer RGB işlemleri katı güvenlik gereklilikleri altında doğrudan Bitcoin üzerinde gerçekleştiriliyorsa, ilgili iki işlem arasındaki sürenin en az on dakika aralıklarla (BTC'nin blok süresi) olması gerektiği anlamına gelir ki bu da genellikle kabul edilemeyecek kadar yavaştır.

RGB ve Lightning Ağı

Basit bir ifadeyle Lightning Network, bir işlemin taraflarının zincir dışında bir dizi sözleşme (taahhüt işlemleri) imzalamasını sağlayarak çalışır. Bu sözleşmeler, 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 ihlal edeni cezalandırabilmesini sağlar. Başka bir deyişle Lightning Network, protokol ve oyun teorik tasarımı aracılığıyla zincir dışı işlemlerin güvenliğini sağlar.

RGB, ödeme kanalı sözleşme detaylarını RGB'ye uygun şekilde tasarlayarak kendi Lightning Network altyapısını oluşturabilir. Ancak Lightning Network'ün yüksek karmaşıklığı nedeniyle, özellikle Lightning Labs'ın bu alanda uzun yıllara dayanan çalışmaları ve LND'nin %90'ın üzerindeki pazar payı göz önüne alındığında, böyle bir altyapının inşa edilmesi kolay değil.

RGB'nin Sidechain Prime'ı

RGB protokolünün şu anki koruyucusu olan LNP-BP, Haziran 2023'te Maxim tarafından Prime adlı müşteri tarafı doğrulanmış bir varlık ölçeklendirme çözümü için bir teklif yayınladı. Maxim, mevcut yan zincir ve Lightning Network ölçeklendirme çözümlerini geliştirme aşamasında çok karmaşık olmakla eleştirdi. Prime dışında NUCLEUS çok düğümlü Lightning kanalları ve Ark/Enigma kanal fabrikaları dahil diğer genişletme yöntemlerinin iki yıldan fazla bir geliştirme gerektireceğine inandığını ifade etti. Ancak Prime sadece bir yılda tamamlanabildi.

Prime geleneksel bir blockchain olarak tasarlanmamıştır. Bunun yerine, özellikle istemci tarafı doğrulaması için oluşturulmuş modüler bir prova yayınlama katmanıdır. Dört ana bileşenden oluşur:

1. Zaman Damgası Hizmeti: Bu hizmet, bir dizi işlemi 10 saniye gibi kısa bir sürede tamamlayabilmektedir.
2. Kanıtlar: Bunlar Kısmi Merkle Ağaçları (PMT'ler) biçiminde saklanır ve blok başlıklarıyla birlikte üretilip yayınlanır.
3. Tek Kullanımlık Mühürler: Bu, çifte harcamayı önlemek için tasarlanmış soyut bir tek kullanımlık mühür protokolüdür. Bitcoin'e uygulandığında mevcut RGB tasarımına benzer şekilde UTXO'lara bağlanabilir.
4. Akıllı Sözleşme Protokolü: RGB için parçalanmış sözleşmeler (değiştirilebilir)

Buradan, RGB'deki işlem onay süreleri sorununu çözmek için Prime'ın, zincir dışı işlemleri hızlı bir şekilde onaylamak ve bunları kimliklerle birlikte bloklar halinde paketlemek için bir zaman damgası hizmeti kullandığını görebiliriz. Aynı zamanda, Prime'daki işlem kanıtları PMT'ler aracılığıyla daha da konsolide edilebilir ve ardından kontrol noktası benzeri bir şekilde BTC'ye sabitlenebilir.

Taproot tabanlı CSV Varlıkları Protokolü: Taproot Varlıkları

Taproot Assets, Bitcoin blok zincirinde varlık yayınlamak için tasarlanmış, Taproot'u temel alan 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 temelinde Bitcoin'in güvenlik ve istikrarının yanı sıra Lightning Network'ün hızı, ölçeklenebilirliği ve düşük maliyetinin kullanılması yer alır. Protokol, Lightning Labs'ın CTO'su roasbeef tarafından tasarlandı ve geliştirildi. Roasbeef muhtemelen gezegende hem Bitcoin istemcisinin (BTCD) hem de Lightning Network istemcisinin (LND) geliştirilmesine kişisel olarak liderlik eden ve BTC hakkında derin bir anlayış gösteren tek kişidir.

Taproot işlemleri yalnızca varlık komut dosyasının kök karmasını taşır, bu da harici gözlemcilerin bunların Taproot Varlıklarını içerip içermediğini belirlemesini zorlaştırır çünkü karmanın kendisi geneldir ve her türlü veriyi temsil edebilir. Taproot yükseltmesiyle Bitcoin, akıllı sözleşmeleri (TapScript) yürütme yeteneğini kazandı. Buna dayanarak, Taproot Assets'in varlık kodlaması esas olarak ERC20 veya ERC721'e benzer bir token tanımı oluşturur. Böylece Bitcoin yalnızca varlıkları tanımlama yeteneği kazanmakla kalmıyor, aynı zamanda akıllı sözleşmeler yazma yeteneği de kazanarak Bitcoin için token akıllı sözleşme altyapısının temelini atıyor.

Taproot Assets'in kodlama yapısı aşağıdaki gibidir:

Yazan: roasbeef, Aydınlatma Laboratuvarları CTO'su

Ayrıca bir CSV varlık protokolü olarak Taproot Assets, RGB'ye kıyasla daha özlü bir tasarıma sahiptir. Uygulama ölçeklenebilirliği açısından Taproot Assets ile RGB arasındaki en büyük fark, VM yürütmede yatmaktadır; Taproot Assets, BTC'nin yerel varsayılanı ile aynı TaprootScript VM'yi kullanır. Son yıllarda BTC için yapılan araştırmaların çoğu Son yıllarda BTC için yapılan birçok altyapı araştırması TapScript'e dayanmakta ancak BTC'nin yavaş yükseltmesi nedeniyle kısa sürede uygulanamamaktadır. Taproot Assets'in gelecekte bu yeni fikirler için bir test alanı olacağı öngörülebilir.

Taproot Varlıkları ve RGB arasındaki farklar

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

Taproot Assets, toplam ağacın uygulanması nedeniyle yüksek doğrulama verimliliğine ve güvenliğe sahiptir. Durum doğrulamasının ve işlemlerin, tüm işlem geçmişinin üzerinden geçmeye gerek kalmadan, yalnızca bir kanıta sahip olarak yürütülmesine olanak tanır. Buna karşılık, RGB'nin Pedersen taahhütlerini kullanması, girdilerin geçerliliğinin etkili bir şekilde doğrulanmasını zorlaştırıyor. Sonuç olarak RGB, girdilerin işlem geçmişinin geriye doğru izlenmesini gerektirir ve bu, zaman içinde işlemler biriktikçe önemli bir yük haline gelebilir. Merkel toplam ağacının tasarımı aynı zamanda Taproot Assets'in, daha önce Bitcoin üzerine inşa edilen varlık protokollerinde bulunmayan bir özellik olan ışık düğümü doğrulamasını kolayca kolaylaştırmasını sağlar.

2. Yürütme VM'si

Taproot Assets, Bitcoin ağının Taproot yükseltmesine yanıt olarak geliştirildi. Taproot yükseltmesinin ardından Bitcoin ile birlikte gelen komut dosyası yürütme motoru olan TaprootScriptVM'yi kullanır. Dahası, Bitcoin'in PSBT'sinin bir çeşidi olan vPSBT'yi kullanıyor; bu da Taproot Assets yıldırım kanalı mekanizması geliştirildiğinde LND'nin (Lightning Network Daemon) mevcut tüm altyapısının yanı sıra Lightning Labs'ın (LND) önceki ürünlerini anında yeniden kullanabileceğini gösteriyor. şu anda yıldırım ağında %90'ın üzerinde pazar payına sahiptir). Ek olarak, son zamanlarda popüler olan BitVM teklifi TaprootScript'e dayanıyor; bu da teorik olarak tüm bu iyileştirmelerin sonunda Taproot Assets'e fayda sağlayabileceği anlamına geliyor.

Ancak RGB biraz farklı çalışır. Sanal makinesi ve doğrulama kuralları (SCHEMA), kendi kendine yeten bir sistemin parçasıdır ve biraz kapalı bir ekosistem oluşturur. RGB kendi ekosistemi içerisinde faaliyet göstermektedir ve daha geniş Bitcoin ekosistemi ile ilişkisi bazılarının düşündüğü kadar yakın değildir. Örneğin, Taproot yükseltmesiyle ilgili olarak, RGB'nin tek gerçek etkileşimi taahhüt verilerini Witness TapLeaf'teki blok zincirine kodlamaktır. Bu, RGB ve Taproot yükseltmesinin yalnızca minimum düzeyde bağlantılı olduğunu gösterir.

3. Akıllı Sözleşmeler

RGB'nin mevcut uygulamasında sözleşmeler ve VM yoğun bir şekilde vurgulanmaktadır. Ancak Taproot Assets'te akıllı sözleşmelere odaklanılmış gibi görünmüyor, en azından henüz. Mevcut RGB uygulaması, Küresel Durumda yapılan değişikliklerin bireysel sözleşme parçalarıyla (UTXO) nasıl senkronize edildiğini henüz açıklamadı. Üstelik Pedersen'in taahhütleri varlıkların toplam miktarını garanti altına alsa da, bu konuda pek fazla açıklama yapılmadığı için diğer devletlerin kurcalamaya karşı nasıl korunacağı da belirsiz.

Öte yandan, Taproot Assets daha basit bir tasarıma sahip ancak şu anda yalnızca varlık bakiyelerini saklıyor ve daha karmaşık durumları ele almıyor, bu da akıllı sözleşme tartışmalarını erken hale getiriyor. Ancak Lightning Labs'a göre gelecek yıl Taproot Assets için akıllı sözleşme tasarımına odaklanma planları var.

4. Senkronizasyon Merkezi

Müşteri tarafında doğrulanan varlıklarla ilgili olarak daha önce bahsedilen temel prensip, Kanıtı tutmanın, özel anahtarı tutmak kadar önemli olduğunu gösterir. Ancak müşteri tarafında tutulduğu için Kanıtı kaybetme riski vardır. Bu nasıl çözülebilir? Taproot Assets'te bu sorun bir "evren" kullanılarak önlenebilir. Evren, bir veya daha fazla varlığı kapsayan, kamuya açık olarak denetlenebilen seyrek bir Merkle ağacıdır. Standart bir Taproot varlık ağacının aksine, Taproot varlıklarını korumak için bir evren kullanılmaz. Bunun yerine, bir veya daha fazla varlık geçmişinin bir alt kümesini taahhüt eder.

RGB sisteminde bu rol, zincir dışı kanıt verilerini eşler arası (p2p) ağ aracılığıyla senkronize eden Storm tarafından yerine getirilir. Ancak RGB geliştirme ekibiyle ilgili tarihsel nedenlerden dolayı bu ekipler şu anda uyumsuz prova formatları kullanıyor. RGB ekosistem ekibi DIBA, bu sorunu çözmek için "karbonado " geliştireceğini belirtti ancak ilerlemesi belirsiz.

5. Mühendislik Uygulaması

Lightning Labs'ın kendi Bitcoin istemcisi (BTCD), Lightning Network istemcisi (LND) ve çok çeşitli cüzdan kitaplığı uygulamaları olduğundan, Taproot Assets tarafından kullanılan tüm kitaplıklar iyi bir şekilde test edilmiştir. Bunun aksine, RGB uygulaması için kullanılan kitaplıkların çoğu kendi kendine tanımlanır. Endüstri standartları açısından bakıldığında RGB'nin uygulanması hâlâ deneysel aşamadadır.

BTC ölçeklendirmesinin geleceğine kısa bir bakış

Tartışmaya devam edildiğinde, müşteri tarafından doğrulanan varlık protokollerinin geleneksel protokollerin kapsamının ötesine geçtiği ve artık hesaplamalı ölçeklendirmeye doğru ilerlediği açıkça görülüyor.

Birçok kişi gelecekte Bitcoin'in 'dijital altın' olarak var olacağını, diğer blockchainlerin ise uygulama ekosistemleri yaratacağını iddia ediyor. Ancak ben farklı bir görüşe sahibim. Bitcoin forumlarındaki pek çok tartışmada görüldüğü gibi, çeşitli altcoinler ve onların geçici ömürleri hakkında çok fazla konuşma yapılıyor. Bu altcoinlerin hızlı ölümü, onları çevreleyen sermayeyi ve emeği balonlara dönüştürdü. Güçlü bir fikir birliği temeli olarak Bitcoin'e zaten sahibiz; yalnızca uygulama protokolleri için yeni Katman 1 (L1) çözümleri oluşturmaya gerek yoktur. Yapmamız gereken şey, daha uzun vadeli merkezi olmayan bir dünya inşa etmek için bu sağlam altyapı olan Bitcoin'den yararlanmaktır.

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

Uygulama tasarımı açısından bakıldığında, Bitcoin ilk başta zincir içi hesaplamaya değil doğrulamaya (Akıllı sözleşmeler için Turing bütünlüğü ve durumu) odaklanan bir felsefe seçti. Blockchain'in özü kopyalanmış bir durum makinesidir. Bir blockchain'in fikir birliği zincir içi hesaplamaya odaklanıyorsa, ağdaki her düğümün bu hesaplamaları tekrarlamasının makul veya ölçeklenebilir bir yaklaşım olduğunu iddia etmek zordur. Odak noktası doğrulama ise zincir dışı işlemlerin doğrulanması Bitcoin'in ölçeklenebilirliği için en uygun yaklaşım olabilir.

Doğrulama nerede yapılır? Bu çok önemli.

Bitcoin'in üzerinde protokoller oluşturan geliştiriciler için, kritik doğrulama için Bitcoin'in nasıl kullanılacağı, hatta doğrulamanın zincir dışına nasıl yerleştirileceği ve güvenli şemaların nasıl tasarlanacağı, protokol tasarımcılarının kendilerini ilgilendiren konulardır. Zincirin kendisi ile ilişkilendirilmemeli ve ilişkilendirilmeleri gerekmez. Doğrulamanın nasıl uygulanacağı BTC için farklı ölçeklendirme çözümlerine yol açacaktır.

Doğrulamaya dayalı uygulamalar açısından bakıldığında ölçeklendirmeye yönelik üç yönümüz vardır:

1. Zincir üzerinde doğrulama (OP-ZKP)

OP-ZKP'nin doğrudan TaprootScriptVM'de uygulanması, Bitcoin'in kendisine ZKP doğrulaması yapma yeteneği kazandıracaktır. Bu, bazı Covenant tasarım uzlaşma protokolleriyle birleştiğinde, Bitcoin'in güvenliğini devralan bir Zk-Rollup ölçeklendirme çözümü oluşturabilir. Bununla birlikte, Ethereum'da bir doğrulama sözleşmesi dağıtmanın aksine, Bitcoin'in yükseltmeleri doğası gereği yavaştır ve bu kadar uzmanlaşmış, potansiyel olarak yükseltmeye ihtiyaç duyan bir işlem kodunun eklenmesinin zor olması kaçınılmazdır.

2. Yarı zincir üzerinde doğrulama (BitVM)

BitVM'nin tasarımı, sıradan işlem mantığına yönelik olmamasını sağlar. 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ü doğrulama hesaplamalarının çoğu zincir üzerinde değil zincir dışında gerçekleşir. Bitcoin'in Taproot'u etrafında tasarım yapmanın önemli nedeni, gerektiğinde hesaplamalı doğrulama için TapScriptVM'yi kullanmak ve teorik olarak Bitcoin'in güvenliğini devralmaktır. Bu süreç aynı zamanda, İyimser Toplamalar olarak bilinen 'n' doğrulayıcı arasında yalnızca bir dürüst doğrulayıcıya ihtiyaç duyulması gibi bir doğrulama güven zinciri de oluşturur.

BitVM, zincir üzerinde önemli miktarda ek yüke neden olur, ancak verimlilik kazanımları 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 bağlı ve bu da bizi OP-ZKP yaklaşımının zorluklarına geri götürüyor.

3. Zincir dışı doğrulama (İstemci Tarafı Doğrulaması, Lightning Network)

Tam zincir dışı doğrulama, daha önce tartışılan CSV varlık protokollerini ve Lightning Network'ü ifade eder. Önceki tartışmalarda görüldüğü gibi CSV tasarımlarında gizli anlaşmayı tamamen engelleyemiyoruz. Yapabileceğimiz şey, kötü niyetli gizli anlaşmalardan kaynaklanan hasarı kontrol edilebilir sınırlar içinde tutmak ve bu tür eylemleri kârsız hale getirmek için kriptografi ve protokol tasarımı kullanmaktır.

Zincir dışı doğrulamanın avantajları ve dezavantajları da aynı derecede açıktır. Avantajı, minimum zincir içi kaynak kullanması ve büyük ölçeklenebilirlik potansiyeline sahip olmasıdır. Dezavantajı ise Bitcoin'in güvenliğini tam olarak devralmanın neredeyse imkansız olmasıdır, bu da gerçekleştirilebilecek zincir dışı işlemlerin türlerini ve yöntemlerini büyük ölçüde sınırlamaktadır. Ek olarak, zincir dışı doğrulama aynı zamanda verilerin zincir dışında tutulduğu ve kullanıcıların kendileri tarafından 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ın kararlılığı konusunda daha yüksek talepler doğurur.

Ölçeklendirme Evrimi Eğilimi

Şu anda, Ethereum'daki popüler Katman 2 çözümleri, paradigma açısından, Katman 2 hesaplamalarını Katman 1 aracılığıyla doğrulamaktadır; bu, durum hesaplamasının Katman 2'ye itildiği ancak doğrulamanın hala Katman 1'de tutulduğu anlamına gelir. Gelecekte benzer şekilde doğrulama hesaplaması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.