RGB++ Protokolü ve Bitcoin'in Geleceği: Bitcoin Singapur 2024'ten Cipher'ın İçgörüleri

9 Mart'ta Nervos Vakfı ve ABCDE tarafından ortaklaşa düzenlenen Bitcoin Singapur 2024 konferansında, CELL Studio'nun kurucusu ve RGB++ protokolünün yazarı Cipher, 'RGB++ Protokolüne Genel Bakış ve Beklentiler' başlıklı bir açılış konuşması sundu.

İşte Cipher'ın sunumundaki ana noktaların bir özeti:

RGB Protokolünün Karşılaştığı Zorluklar

RGB protokolü uzun yıllardan beri varlığını sürdürüyor ancak çeşitli faktörlerden dolayı yaygın olarak benimsenmedi:

İnteraktif Operasyonlarla İlgili Zorluklar

BTC , ETH vb. içeren işlemlerde, alıcının yalnızca bir adres vermesi yeterlidir ve gönderen, parayı bugün veya yarın aktarabilir ki bu da çok uygundur. Bunun aksine, her RGB işlemi, alıcının öncelikle bir fatura düzenlemesini gerektirir. Daha sonra gönderenin bir RGB işlemi oluşturması ve alıcıya gönderilmek üzere bir varlık geçmişi kanıtı oluşturması gerekir. Bu kanıtı aldıktan sonra alıcının istemci tarafı doğrulaması (CSV) yapması gerekir. Başarılı doğrulamanın ardından, bu kanıtı gelecekteki işlemler için saklamaları gerekir.

Bu nedenle, RGB işlemleri yalnızca her iki tarafın da çevrimiçi olmasına değil, aynı zamanda her iki tarafın da ilgili geçmiş verileri depolamasına da bağlıdır. Bu durum tüketici odaklı ürünler için önemli bir engel oluşturmaktadır.

Veri Kullanılabilirliği (DA) Sorunları

RGB işlemlerinde varlığın tarihsel kanıtını eklemek önemlidir. Bu kanıtın kaybolması, özel anahtarın kaybedilmesi kadar kritiktir. Kullanıcıların varlıklarını korumalarına kimin yardımcı olacağı sorusu veri kullanılabilirliğiyle ilgili bir sorundur. Gizliliği korumayı amaçlayan orijinal RGB protokolünde, başka hiç kimse kullanıcılar için varlıkları saklamaz; bu da kullanıcıların kendi veri depolama sorumluluğunu üstlenmesi gerektiği anlamına gelir.

Uygun veri depolama olsa bile Alice'in RGB varlıklarını Bob'a aktarmak istediği bir senaryoyu düşünün. Bu varlıkların tarihsel kanıtlarını ona nasıl gönderecek? E-posta veya Whatsapp mı kullanıyorsunuz? Açıkçası, herhangi bir merkezi kanal üzerinden iletim yapmak uygun değildir ve özel bir P2P kanalının kullanılmasını gerektirir. Ancak P2P kanalları gizlilik sorunlarını gündeme getiriyor: Birisi neden bu hassas verilerin iletilmesine yardımcı olsun ki? Bu, bir dizi karmaşık soruna yol açar.

Birlikte Çalışabilirlik Sorunları

RGB varlıklarının geçmiş kanıt verileri kullanıcılar tarafından saklanır ve işlemler sırasında alıcıya iletilir, ancak kamuya açıklanmaz. Bu, verilerin ağdaki her bireye dağılmasına neden olur. İster merkezi ister merkezi olmayan bir ticaret platformu inşa eden biri için, RGB'nin küresel durumunu korumak için birden fazla kaynaktan gelen verilere ihtiyaç vardır. Bu verileri uygulama geliştiricileri için merkezileştiren ve saklayan bazı RGB servis sağlayıcıları var ancak bu yaklaşım RGB'nin gizliliğini azaltıyor. Bu çözüme rağmen, farklı kullanıcıların RGB verilerini tutan çeşitli hizmet sağlayıcılar arasında veri aktarımının kolaylaştırılması gibi zorluklar devam etmektedir.

Akıllı Sözleşme/Komut Dosyası Yürütme Ortamı ile ilgili sorunlar

RGB'deki akıllı sözleşme veya komut dosyası yürütme ortamlarıyla ilgili önemli zorluklar vardır. AluVM adında bir Sanal Makine (VM) kullanıyor ancak programlama dilinin özellikleri henüz kesinleşmedi. Üstelik derleyiciler ve hata ayıklayıcılar gibi kritik geliştirme araçları da tam olarak geliştirilmemiştir. Ayrıca paylaşılan durumlar ve merkezi olmayan (sahipsiz) sözleşmeler için destekten yoksundur. Şu anda AluVM'nin hala çok erken aşamada olduğu açıktır.

Bu nedenle RGB, her biri ciddi zaman ve çaba gerektiren çok sayıda karmaşık sorunla karşı karşıyadır. Bu zorluklar, RGB'nin etkili bir şekilde uygulanmasındaki gecikmelere önemli ölçüde katkıda bulunmaktadır.

RGB++ Protokolüne Genel Bakış

RGB işlemleri, bir eşleme süreci aracılığıyla Bitcoin işlemlerine karmaşık bir şekilde bağlanır. Ek olarak RGB işlemleri, Veri Kullanılabilirliği (DA), müşteri tarafı doğrulaması, P2P ağı, sanal makineler, paylaşılan durumlar ve merkezi olmayan sözleşmeleri kapsayan zincir dışı bir altyapı gerektirir. Böyle bir altyapı göz önüne alındığında, veri yönetimi, doğrulama, sanal makine entegrasyonu, P2P ağı, teşvik ve akıllı sözleşmelerdeki yetenekleri göz önüne alındığında doğal olarak akla blockchain geliyor. RGB++ protokol konsepti bu temel sezgiye dayanmaktadır ve RGB'nin gerektirdiği zincir dışı altyapının yerine UTXO model tabanlı ve Turing-tam CKB blok zincirinin kullanılmasını önermektedir.

RGB++ izomorfik bağlama teknolojisi adı verilen bir kavramı sunar. Her Bitcoin işlemi bir çıktı içerir. Bir RGB işlemi durumunda, Bitcoin çıkışına bir OP_RETURN segmentinin dahil edilmesini gerektirir. Bu segment, taahhüt olarak adlandırılan belirli hash verilerini tutar. Bu taahhüt, başka bir halka açık blok zincirindeki bir işlemin hash'iyle çakışıyorsa ve her iki işlemin girdileri ve çıktıları izomorfikse - yani yapı olarak karşılık geliyorlarsa - ve bu alternatif blok zincirinin UTXO'sunun (Harcanmamış İşlem Çıkışı) Turing-tam hesaplamaya sahip olduğu varsayılırsa ve depolama yeteneklerinin durumu, daha sonra Bitcoin blok zincirindeki işlem, diğer blok zincirindeki işlemle tamamen entegre veya bağlı hale gelir. CKB (Ortak Bilgi Tabanı) blok zinciri bu ön koşulları karşılar. Dolayısıyla Bitcoin üzerinde bir işlem gerçekleştirmek, CKB zincirinde buna karşılık gelen bir işlemin gerçekleştirilmesine etkili bir şekilde eşittir. Bitcoin işleminin durumundaki herhangi bir değişiklik, CKB'de mevcut sözleşme kısıtlamalarına bağlı kalarak CKB zincirindeki işlemin durumundaki bir değişikliği yansıtır. Bu, izomorfik bağlama teknolojisinin özünü özetlemektedir. Ancak bu kavram, işlem tutarlılığının sürdürülmesi ve çifte harcamanın önlenmesi de dahil olmak üzere şu anda ayrıntılı olarak ele alınmayan çok sayıda karmaşık teknik hususu kapsamaktadır.

İzomorfik bağlama teknolojisi, Bitcoin'in durum yeteneklerinin geliştirilmesini sağlar. Örneğin aşağıdaki şemada gösterilen btc_utxo#1'i ele alalım. Bu Bitcoin UTXO (Harcanmamış İşlem Çıkışı) genellikle yalnızca iki durumu gösterir: bir kilitleme komut dosyası ve bir miktar; ikincisi bakiyeyi temsil eder. Ancak şemada gösterildiği gibi CKB (Ortak Bilgi Tabanı) blok zincirindeki ilgili mavi Hücrede yetenekler daha geniştir. Bitcoin UTXO'nun yalnızca dengeyi göstermeye yönelik sınırlı işlevselliğinden farklı olarak, CKB zincirindeki bu izomorfik Hücre yalnızca denge verilerini değil aynı zamanda diğer çeşitli veri türlerini de depolayabilir.

Hücre, veri bileşenine ek olarak bir tür komut dosyasına da sahiptir. Bu komut dosyası belirli bir amaca hizmet eder: Varlıkların alındığı koşulları tanımlar ve varlık türlerine kısıtlamalar getirir.

Ayrıca Hücre, bu durumda açıkça btc_utxo#1'e bağlanan bir kilit komut dosyası içerir. Bu bağlantı, CKB blok zincirindeki Hücrenin yalnızca btc_utxo#1 harcandığında harcanabileceği anlamına gelir.

CKB platformunda bir Bitcoin ışık düğümü uyguladık. Bir Bitcoin işlemi başlatıldığında, bir Aktarma mekanizması tarafından yakalanır ve daha sonra bu işlem, bir kanıt biçimi olarak CKB blok zincirine aktarılır. Bu süreç, işlemin Bitcoin ışık düğümünde varlığının doğrulanmasını ve taahhüdün işlemle izomorfik olmasını sağlamayı içerir.

Bu yaklaşım sayesinde Bitcoin'in işlevlerini önemli ölçüde genişletiyoruz. Geniş bir yelpazedeki varlıkların doğrudan Bitcoin üzerinden ihraç edilmesinin önünü açıyor ve Turing-complete sözleşmelerinin genişletilmesini kolaylaştırıyor.

Bu yaklaşımın avantajı, Bitcoin Katman 1 (L1) ile neredeyse aynı güvenlik durumunu korurken, Turing-complete komut dosyasını Bitcoin alanına başarıyla tanıtmış olmamızdır. Bunun nedeni, tüm geçmiş kayıtların, işlemlerin ve taahhütlerin Bitcoin L1 üzerindeki UTXO zinciri aracılığıyla bağlantılı olmasıdır.

Ancak takas mahremiyette hafif bir azalmadır. RGB durumunda veriler bireysel kullanıcılar arasında dağıtılır ve bu da diğerlerinin belirli bir kullanıcının RGB verilerine erişmesini zorlaştırır. RGB++ ile tüm zincir dışı veriler, bu durumları koruyan CKB blok zincirinde yayınlanır ve bu da gizliliğin azalmasına yol açar. Ancak en kötü senaryo, yalnızca Bitcoin işlemlerinde bulunan gizlilik düzeyinin azalmasıdır; IP adreslerini veya kişisel kimlik bilgilerini açığa çıkarmaz.

Aslında CKB'ye gelişmiş bir gizlilik katmanı uygulayabiliriz. Dört yıl önce, bu gelişmiş gizlilik katmanını oluşturmak için CKB'de Mimblewimble teknolojisinin kullanımını tartışan bir makale yazmak üzere Grin topluluğuyla işbirliği yaptık. Gelecekte, bu katmanı RGB++'a entegre ederek yalnızca işlem tutarlarının gizlenmesini değil aynı zamanda işlem geçmişindeki bağlantıların da kesilmesini sağlayabiliriz. Ortaya çıkan gizlilik RGB'den daha güçlü olacaktır.

Özetle RGB'nin vizyonunu daha basit bir şekilde hayata geçirdik ve yeteneklerini daha da genişlettik.

Bitcoin L1 Varlıklarının Potansiyelinin Kilidini Açmak

İşte sıçrama konseptine basitleştirilmiş bir giriş.

Bitcoin'e uygulanabilen homomorfik bağlama teknolojisi , Litecoin, Liquid ve diğer UTXO tabanlı zincirlere de aynı şekilde uygulanabilir. Daha önce de belirtildiği gibi, hem RGB hem de RGB++ sistemlerinde alacaklı, tek harcama yetkisine sahip olan Bitcoin UTXO'dur. Bitcoin üzerinde bir RGB++ işlemi oluşturduğumda, alacaklıyı Bitcoin UTXO olarak değil Litecoin UTXO olarak belirleme seçeneğim var. Sonuç olarak, bu varlık Litecoin'e 'sıçrıyor' çünkü sonraki harcamaları Litecoin UTXO tarafından kilidin açılmasını gerektiriyor. Benzer şekilde bu varlık Liquid'e sıçrayabilir, hatta Bitcoin'e geri sıçrayabilir.

Elbette dikkate alınması gereken özel bir durum var. Bir varlık CKB blok zincirine sıçradığında, veri yorumlama katmanı, sözleşme katmanı ve sahipliğinin tamamı CKB'de olur. Bu, artık başka bir zincire bağımlı olmadığı ve doğrudan CKB üzerinde işlem yapabileceği ve akıllı sözleşmelerle etkileşime geçebileceği anlamına geliyor. Bu L2'ye sıçramak olarak tanımlanabilir. L2'de kullanıcılar, birisi varlığı Bitcoin'e geri döndürmeye karar verene kadar binlerce, hatta onbinlerce işlem gerçekleştirebilir. Buna işlem katlama diyoruz. İster RGB ister RGB++ olsun, işlemler madencilik ücretlerinin pahalı olduğu Bitcoin blok zincirinde gerçekleşir. Bununla birlikte, bir varlık CKB'ye sıçradığında ve işlem katlamaya tabi tutulduğunda ücretler önemli ölçüde düşer ve herhangi bir zamanda kolayca Bitcoin blok zincirine geri dönebilir. Tüm bu süreç herhangi bir çoklu imza köprüsüne veya herhangi bir kişiye duyulan güvene dayanmamaktadır; tek gereklilik birkaç blok onayı daha beklemektir. Bitcoin blok zincirinden CKB blok zincirine geçiş, 6 Bitcoin blok onayının beklenmesini gerektirir. CKB blok zincirinden Bitcoin'e geri dönmek için blok geri dönüşlerini önlemek amacıyla 24 CKB blok onayına ihtiyaç vardır.

Bu nedenle yeni bir paradigma getirdiğimizi söylüyoruz. Elbette bu bizim buluşumuz değil, RGB varlıklarının farklı UTXO zincirleri arasında geçiş yapabileceği, RGB'nin ilk materyallerinde var olan bir fikir. Turing'in eksiksizliğini CKB'ye geçişle birleştirdikten sonra, potansiyel uygulamaların kapsamlı olduğunu ve Ethereum'un çoklu imza köprülerinin geleneksel anlatımından oldukça farklı olduğunu keşfettik.

Gelecek görünüşü

Şimdi ölçeklenebilirliği tartışalım. Bitcoin'in işlem hızı saniyede yaklaşık 7 işlem (TPS) iken CKB, 200 TPS civarında zirveye ulaşıyor. Sözleşme yürütme ve komut dosyası doğrulama maliyetlerini de hesaba katarsanız, TPS yaklaşık 50'ye düşebilir; bu, Bitcoin ile karşılaştırıldığında on kattan daha az bir artıştır. Bu neredeyse yeterli değil, peki ölçeği büyütme seçenekleri nelerdir? İki ana yön görüyoruz:

• Durum Kanalları : Durum kanalları, çok yüksek performanslı bir tavan sunan nihai bir ölçeklendirme çözümünü temsil eder. Ancak zorluk, çok taraflı sözleşmelerin uygulanmasının karmaşıklığında yatıyor; bu da devlet kanallarını ödeme işlemleri ve birey-sunucu etkileşimleri için daha uygun hale getiriyor. Jan, eyalet kanallarına ilişkin araştırmaların ilerletilmesinde ekibe öncülük etmeye hazırlanıyor.

  
  

• AppChain Stack : UTXO modeline dayalı bir Katman 2 (L2) çözümü oluşturan L2 AppChain, CKB'ye sabitlenmesini ve onunla izomorfik olarak hizalanmasını sağlayacaktır. Bu yaklaşım, bu yeni paradigma dahilinde yenilikçi ölçeklendirme stratejileri geliştirmemize olanak tanır. Bu aynı zamanda önümüzdeki yıl CELL Studio'nun ana odak noktasıdır.

  
  

Son olarak RGB++'nın misyonunu ve yol haritasını özetlemek istiyorum. RGB++, üçüncü taraf geliştiriciler ve kullanıcılar tarafından kolay kullanım ve entegrasyonu kolaylaştırmak için temel protokol modülleri geliştirmeyi amaçlamaktadır. RGB++ protokolünün yol haritası şu şekilde olup, protokol halihazırda Bitoin ana ağında yayındadır ve RGB++ SDK 3 Nisan'da yayınlanmıştır.

CELL Studio'nun kurucusu ve RGB++ protokolünün yazarı Cipher tarafından.