Kernel Ventures: RGB能否複刻Ordinals的熱潮



作者| Jerry Luo Kernel Ventures

摘要:

現今的比特幣網絡上存在著多種智慧合約方案,其中最為主流的便是Ordinals協定與RGB協定。

  • Ordinals協定的誕生,使得比特幣網絡也可以實現智慧合約開發,並將其安全性與比特幣區塊鏈進行了綁定。 但是Ordinals資產轉帳的確認和記錄均在比特幣主網上進行,與1個sats的轉帳相綁定。 這帶來了高昂的手續費,同時也使TPS低下的比特幣主網更加擁堵。
  • 在RGB協定中,提出了鏈下通道以及批量打包交易的管道,這些管道使得RGB中資產轉移的手續費大幅下降,速度也得到提升。 同時,用戶端驗證的管道也大大减小了維持網絡正常運行所需記錄的數據量,從而提升了網絡可拓展性。
  • 雖然RGB協定通過以上管道改善了交易速度和可拓展性,但同時也帶來了許多新的問題。 鏈下通道在優化交易費用和速度的同時帶來了鏈下記錄的安全問題。 用戶端驗證减小記錄數據量的同時也大大拖慢了驗證速度。

本文從安全性、可拓展性、交易費、交易速度等維度比較了Ordinals與RGB協定,並分析了RGB敘事未來可能的走向。

1.市場總覽

當前BTC占整個加密市場市值的49%左右,但由於其指令碼語言不具備圖靈完備性,主網智慧合約缺失且交易速度較慢,其長遠發展受到嚴重阻礙。 為了對上述問題做出改進,比特幣開發者們在擴容和提速方面做出了大量嘗試,主要為以下4種解決方案:

  • RGB協定:RGB是一個建立在比特幣網絡上的二層協定,其覈心交易數據儲存在BTC主網上。 RGB利用比特幣的安全模型,支持在比特幣網絡上創建具有定制内容和智慧合約功能的代幣。 2016年,RGB協定最初由Peter Todd提出; 2023年,在比特幣上智慧合約生態的開發熱潮中,RGB協定再次得到關注。
  • 隔離見證:2017年8月,比特幣實施隔離見證(SegWit)陞級。 通過交易資訊與簽名資訊的分離,將有效區塊大小從1M提升到了4M,一定程度緩解了擁堵問題。 但受到比特幣區塊本身大小的限制,我們無法對一個區塊的存儲資訊無限擴容。 因而通過對區塊存儲資訊擴容提高效率的管道便到此為止了。
  • 閃電網絡:閃電網絡是基於比特幣的二層擴容方案,允許在不訪問區塊鏈的情况進行下交易,極大提高了輸送量。 閃電網絡已在比特幣主網上實現,現有的閃電網絡解決方案有OmniBOLT,Stacks等,但閃電網絡面臨著較大的中心化風險。
  • 側鏈科技:側鏈科技是在比特幣網絡之外搭建一條側鏈,側鏈上的資產按1:1與BTC錨定。 側鏈在交易效能上相對主網有較大改進,但永遠無法達到BTC主網的安全性。

BRC20交易數量變化,來源:Dune

今年3月以來,比特幣網絡的交易費用及BRC20協定資產的交易量都迎來激增。 5月初BTC主網交易費到達頂峰,雖然此後交易費用下滑,但BRC20資產的交易量仍維持在較高水準。 這表示比特幣網絡智慧合約生態的開發熱度,並沒有伴隨BTC生態中銘文熱度的下降而低迷,開發者們仍繼續嘗試尋找適合比特幣網絡智慧合約開發的最優解。

2. Ordinals協定

2.1 Satoshi編號

比特幣網絡上的Satoshi不同於乙太坊上的wei以數據的形式記載,它通過每個地址所擁有的UTXO計算得來。 為了對不同的sats進行區分,首先要區分不同的UTXO,繼而對同一UTXO下的sats進行區分。 前者相對簡單,不同UTXO被挖出的區塊不同,會對應不同的區塊高度。 只有挖礦會產生最初的sats,因而僅需對coinbase交易中的UTXO編號即可。 難點主要在如何對同一UTXO下的sats進行編號。 Ordinals協定提出了新的解決方案,即根據先入先出的原則進行編號。

  • 不同UTXO的區分:BTC Builder從UTXO被挖出的時候開始記錄,每個UTXO對應著唯一的區塊,而每個區塊在比特幣網絡上擁有唯一的區塊高度,通過不同的區塊高度可以對不同的UTXO進行區分。
  • 同一UTXO下sats的區分:首先通過區塊高度可以確定出UTXO下sats的大致範圍,比如最早一個區塊可以挖出100個BTC,也就是1010個sats,那麼對應區塊高度為0的區塊中,sats編號為[01010–1],區塊高度為1的區塊中sats編號為[1010,2∗1010–1], 區塊高度為2的區塊中sats編號為[2∗1010,3∗1010–1],後續依此類推。 如果要對該UTXO下的某一特定sats進行具體區分,則要通過UTXO的消耗過程實現。 Ordinals協定按照先入先出的原則,在該筆UTXO作為輸入產生的輸出中,靠前的輸出對應等量序號靠前的sats,比如現在挖出區塊高度為2的礦工A要將自己這100個BTC中的50個轉移給B,其中靠前的輸出分配給了A,而自己獲得的是靠後的輸出,那麼A將獲得編號為[2∗1010,2.5∗1010–1]的sats, B所獲得的則是序號為[2.5∗1010,3∗1010–1]的sats。

Satoshi編號,來源:Kernel Ventures

2.2 Ordinals inscription

比特幣網絡最早通過加入OP_ RETURN操作符為每筆交易提供了一個80位元組大小的存儲空間。 但是80位元組的區域無法滿足複雜程式碼邏輯的編寫,並且數據寫入區塊鏈也會提高交易成本,增大網絡堵塞的可能性。 為了解决該問題,比特幣網絡先後進行了SegWit與Taproot兩層軟分叉。 通過一份由OP_ FALSE操作碼開頭且不會執行的Tapscript腳本,比特幣交易過程提供了一個4M大小的空間。 在這個區域我們可以寫入ordinals銘文,實現文字、圖片上鏈或者BRC20協定token發放等等。

2.3 Ordinals的不足

Ordinals大大提高了比特幣網絡的可程式設計性,打破了BTC生態敘事和發展受到的限制,提供給比特幣網絡交易之外的功能,但其中許多問題仍然受BTC生態開發者們的詬病。

1、Ordinals的中心化性:雖然ordinals協定中對於狀態的記錄和更改都在鏈上進行,但ordinals協定本身的安全性是無法和比特幣網絡掛等號的。 ordinals無法防止銘文的重複上鏈,對無效銘文的識別需要由鏈外的ordinals協定進行。 這一新興協定未經長時間的測試,存在諸多潜在問題。 同時如果ordinals協定的底層服務出現問題,也可能導致用戶資產的損失。

2、交易費用與交易速度的局限性:因為銘文的篆刻是通過隔離驗證區進行的,也就是說完成一次ordinals資產的轉移必須對應一筆UTXO花費。 限於比特幣網絡10分鐘上下的出塊速度,交易過程無法加速。 同時,銘文的上鏈也會帶來交易成本的新增。

3、損害比特幣原有内容:由於ordinals上的資產與比特幣網絡本身具有價值的sats進行綁定,所以ordinals的使用本身就會造成對比特幣原有資產的异化,同時銘文的上鏈又帶來了礦工費的激增。 許多BTC支持者擔心,這會損害到比特幣原有的支付功能。

3. RGB協定

在網絡交易量激增的情况下,ordinals協定的缺陷便凸顯了出來。 長期來說,如果不能妥當解决這一問題,比特幣的智慧合約生態難以和具有圖靈完備性的公鏈生態進行競爭。 在ordinals的諸多替代方案中,許多開發者選擇了RGB協定,它在可拓展性、交易速度和隱私性等方面較ordinals均做出了較大突破。 理想情况下,基於RGB協定構建的比特幣生態資產在交易速度和可拓展性方面,可以和圖靈完備性公鏈上的資產達到相近水准。

3.1 RGB核心技術

用戶端驗證

不同於比特幣主網中對交易數據的廣播,RGB協定將這一過程放在了鏈下,資訊僅在發送者和接收者間傳輸。 接收者對該筆交易進行驗證後,不需要像比特幣主網一樣實現全網節點的同步,記錄下網絡中所有的交易數據。 接收節點只需記載和該筆交易相關的數據,已達到上鏈驗證的需求即可,這一改進大大提高了網絡的可拓展性與隱私性。

用戶端驗證,來源:Kernel Ventures

一次性密封條

在實際生活的資料上交過程中,資料往往要經過多次的轉手,這對資料的真實性和完整性都構成極大威脅。 現實生活中為了防止資料在提交驗證前受到惡意篡改,人們採用了添加封條的方法,通過封條的完整性判斷裡面的內容是否被篡改。 RGB網絡中一次性密封條的作用與此類似,其具體體現是比特幣網絡中天然具有一次性内容的電子封條 —  UTXO。

類似於乙太坊上的智慧合約,RGB協定下發行Token也要指定發幣的名稱和總量。 不同之處在於RGB網絡並不存在一條具體的公鏈作為載體,RGB中的每一個Token必須指定比特幣網絡上某個特定的UTXO與之對應。 某人擁有了比特幣網絡中的某個UTXO,也就擁有了RGB協定中所記錄的該UTXO對應的RGB Token。 如果想完成對RGB token的轉移,持有人就需要花費掉該UTXO。 由於UTXO的一次性,一旦花費就沒有了,在RGB協定中對應的就是花費掉了這筆RGB資產。 這一花費UTXO的過程便是將一次性封條打開的過程。

一次性密封,來源:Kernel Ventures

UTXO盲化

在比特幣網絡中,每一筆轉帳都可以找到對應的輸入UTXO與輸出UTXO。 這提高了比特幣網絡上UTXO溯源的效率同時有效防止了雙花攻擊,但由於交易過程完全透明,雙方的隱私性便無法得到顧及。 為了提高交易隱私性,RGB協定中提出了盲源UTXO的方案。

在RGB Token的轉移過程中,Token的發送方A將無法得到接收UTXO的具體地址,而只能得到一個接收UTXO地址接上一段隨機密碼值後Hash的結果。 而接收方B要對接收到的RGB協定Token進行使用時,則不僅需要告知接收者C其UTXO對應的地址,還要發送給接收者C其對應密碼值,以向接收者C驗證,之前A確實是將RGB協定Token發送到了B手上。

UTXO盲化,來源:Kernel Ventures

3.2 RGB與Ordinals對比

1、安全性:Ordinals智慧合約的每筆交易或狀態轉移均需要通過一筆UTXO花費實現,而在RGB中這一過程大量借助閃電網絡或是鏈下RGB通道實現。 RGB交易過程中的大量資料存儲在了RGB用戶端(客戶本地緩存或者雲服務器),這一過程存在高度中心化性,數據有被中心化機构利用的可能。 同時一旦服務器宕機或者本地緩存遺失將對客戶資產造成損失。 從安全性方面來講,Ordinals更有優勢。

2、驗證速度:由於RGB採用用戶端驗證,所以每驗證一筆交易,在RGB協定中都需要從頭開始,這將花費大量時間對交易過程中的每一步RGB資產轉移進行確定,這大大延緩了驗證速度。 囙此驗證速度上Ordinals更有優勢。

3、隱私性:RGB資產的轉移和交易驗證過程均在區塊鏈之外進行,建立了一個發送者和接收者之間的特有通道。 同時還以盲化UTXO的形式使得即便發送者也無法對UTXO的去向進行追溯。 而ordinals資產的轉移過程則是通過比特幣上的UTXO花費記錄,UTXO的輸入者和輸出者都可以在比特幣網絡上進行査詢,無隱私性可言。 故而隱私性角度RGB協定更有優勢。

4、交易費用:RGB中的轉帳大量借助用戶端的RGB通道或者閃電網絡進行,這一過程幾乎0交易費用。 無論中間有多少筆交易,最終只需要提交到區塊鏈上使用花費一個UTXO進行確定即可。 但是ordinals的每一步轉帳都需要在tapscript腳本中進行記錄,加之記錄銘文的成本,交易過程中將產生一筆不小的手續費。 同時RGB協定提出了批量打包交易的方法,在一個tapscript腳本中可以指定RGB資產的多個接收者,而ordinals中默認輸出UTXO的接收者為ordinals資產的接收者,只能一對一轉帳,而RGB通過分攤的管道大大降低了這一過程的成本。 囙此交易費用上RGB協定更有優勢。

5、可拓展性:在RGB的智慧合約中,交易驗證和資料存儲是由用戶端(接收節點)完成的,不在BTC鏈上進行,不需要在主網上進行廣播和和全域驗證,每個節點只需保證對於某筆交易有關資料的確認。 而ordinals中的銘文數據都需要進行上鏈操作,鑒於比特幣網絡自身的處理速度和可拓展性,對於交易量的承受能力將受到極大限制。 因而在可拓展性上RGB協定更有優勢。

4. RGB生態項目

RGB v0.10.0版本發佈後,為開發者在RGB網絡上的開發提供了一個相對此前版本更友好的環境。 囙此RGB協定生態大規模開發距今僅半年時間,下列RGB生態項目大多數也還在發展初期:

1、Infinitas:Infinitas是一個圖靈完備的比特幣應用生態系統,結合閃電網絡和RGB協定的優勢,並相互支持和補充,實現了更加高效的比特幣生態系統。 值得一提的是,Infinitas還提出了遞迴零知識證明的方法來解决用戶端驗證的低效問題,如果該方法有效實施,將很大程度解决RGB網絡驗證速度上存在的問題。

2、RGB Explorer:RGB Explorer是最早支持RGB資產査詢及資產(Fungible token and None Fungible token)發送的瀏覽器,支持的資產有RGB20,RGB21,RGB25三種標準資產。

3、Cosminmart:Cosminimart本質是一個可以相容RGB協定的比特幣閃電網絡。 嘗試打造一個可以部署智慧合約的比特幣全新生態。 不同於上述項目單一的功能,Cosminmart提供了錢包,衍生品交易市場和早期項目發掘市場。 它為比特幣網絡的智慧合約開發到產品推廣及交易提供了一站式服務。

4、DIBA:DIBA借助了閃電網絡和RGB協定,致力於打造比特幣網絡的NFT市場。 現時還在比特幣測試網上運行,預計不久將在主網上線。

5. RGB未來展望

伴隨著RGB v0.10.0版本的問世,協定程式的總體框架趨於穩定,版本更新時可能的大規模不相容問題正在被逐漸改進。 同時,開發者工具和各式API介面趨於完善,開發者使用RGB進行開發的難度也可以大大降低。

最近Tether官方發文,將比特幣二層網絡上USDT合約的部署從OmniLayer轉移至RGB。 Tether的這一舉措被視作是Crypto巨頭嘗試進軍RGB的訊號。 RGB現在已經有了成熟的開發協定,龐大的開發者社區以及Crypto巨頭的認可。 最後,RGB開發者現在在嘗試使用遞迴零知識證明對用戶端驗證的體量進行壓縮,如果能完成這一改進,RGB網絡的驗證速度將大大提高,從而緩解在大規模使用時面臨的網絡延時問題。

閱讀原文

聯系郵箱:0xniumao@gmail.com