很多人開始關注比特幣的RGB協議,真的很開心。但是大部分人對於這樣一個協議(尤其是技術相對復雜的協議)比較陌生,也不知道如何去研究和嘗試該協議的內容和生態。
所以,特別寫一篇持續更新的Mirror,來匯總相關的學習資料,提供一個相對來說合理的學習路徑;同時,也作爲個人學習RGB的一個記錄。
第一部分:科普部分-初步認識RGB
很多人看到RGB這三個字,會想到“三原色:red green blue”。如果從圖標上看,還真是這麼回事,這是因爲RGB協議有利用到早期的“染色硬幣”的概念。
這裏我們說的RGB是一個協議,一個可以在比特幣主網、閃電網絡或者類似網路上運行,極端隱私的、可擴展的智能合約系統協議。
這個協議目前由LNP/BP協議維護和更新,bitfinex也參與部分代碼工作。
你很難將RGB簡單劃分爲比特幣L2的範疇,它沒有自己的鏈、它沒有自己的層、他可以運作在BTC的其他L2上,所以,準確來說:它是一項通用性的技術。
在業界,普遍認爲RGB和Bitvm會是BTC拓展的終極形態,因爲他們都可以基於BTC原生性實現BTC生態的可擴展性,相對於Bitvm的遙遙無期,RGB已經在逐步落地。
值得一提的是:RGB是一項不局限於crypto的技術,它可以廣泛運用到我們非crypto的場景中,等到協議越來越成熟,我們會看到越來越多的用例。
從官方的介紹中,我們可以看到RGB協議可以實現的功能:
如果我們歸類一下,可以看出:
從這個角度看,RGB可以讓BTC具有現在EVM的絕大部分功能,但是它不是採用類似於“兼容EVM”的非原生形式實現的,而是原生實現的,不得不說這一套理論和設計理念很牛。
事實上,值得注意的是,RGB 智能合約系統與之前的方法都有很大不同,無論是基於比特幣(彩色幣、Counterparty、OMNI)還是非比特幣(以太坊、EOS 等),它有自己獨特的特性:
第一條的意思是,智能合約將進行更好的分層,發行人僅在發行時刻享有合約的權利,之後都是由狀態所有者在不斷的狀態演化過程中享有權利;
第二條意思是,它將代碼保留在鏈下,可以節省鏈上空間,提升運行速度,降低開發難度,但是又可以通過機制保證安全性;
第三條揭示了它的安全背書層(區塊鏈),同時它是圖靈完備的,可以支持簡單的語言操作。
所以,下圖可能更接近於正確的理解:
從Dr. Maxim Orlovsky的教學視頻中,我們可以看到官方認定的RGB特性包括:
我們來逐一拆分講解:
1️⃣極端隱私性
2️⃣高度安全性
這兩點我還不怎麼懂,需要研究下
3️⃣高度可擴展性
4️⃣不擁堵
5️⃣極高的融合性
所以,其實在我的眼裏,RGB對於BTC更像是下面這樣:
RGB協議相對於其他協議,有自己非常獨特的技術點,這裏簡單科普幾個重要的部分:
4.1 一次性密封
該技術最早由Peter Todd在2016年提出,主要意思是“把一條消息加上一個密封條,確保這個消息只能被使用一次,因爲你要知道消息就必須拆除密封條”。
一種簡單的方法是設置一個公證的第三方服務端,每當某一個密封條打開或者鎖上時就在公開的註冊處發布證書,這樣任何人都能驗證自己關心的密封條的狀態。
如果不使用一個受信任的實體來實現一次性密封的功能,可以使用比特幣的UTXO來作爲密封條。因爲比特幣的任何一個UTXO只能被花費一次。因此,把UTXO作爲密封條,就可以在UTXO創建的時候鎖上,在花費它的時候打開。
RGB利用了這樣的“一次性密封”技術,它將RGB資產的信息、合約的狀態等都“包裹”在UTXO裏面,當UTXO被花費的時候,資產的所有權、合約的狀態就發生了轉變。這意味着,每當一筆 RGB 交易發生時,實際上就是發送者給某個合約(定義了被轉移的權利的那個)創建了一次狀態變更。
以RGB20爲例:
1️⃣首先,合約的發行者設定了合約的創始狀態,定義了合約的細節:資產的名稱、總供應量等,並且發行者有權移動這些供應量的 UTXO;
2️⃣當資產被第一次轉移時,第一個 UTXO 的所有者就可以創建一次狀態變更,定義哪一個 UTXO 將持有這項資產;
3️⃣狀態變更可以應用在變更資產所有權的權利上,也可以應用在別的類型的權利上,例如,二次發行的權利,或者是添加/改變 資產的特定屬性(例如:元數據)的權利等。
4.2 客戶端驗證
RGB的驗證和傳統的“全球共識”驗證不同,採用的是“客戶端驗證”的技術。
傳統的比特幣驗證,一個連接到網路的節點會持續不斷地下載和驗證區塊以及交易池中的交易(全節點)。這樣的節點對整條鏈上的 UTXO 集(區塊鏈上所有未花費的輸出的集合)有一個實時更新的試圖,當它看到一筆新交易時,要驗證其有效性,只需要驗證該交易的所有輸入都是該 UTXO 集的最新狀態的一部分即可。
但是對於RGB而言,沒有全局傳播的數據,因此也沒有這樣的UTXO集的全局視圖。一個 RGB 客戶端在接受一筆交易後,不僅需要驗證交易的最新狀態是有效的,還必須對與交易相關的以往所有的狀態轉化作同樣的驗證,一路追溯到發行合約的創始狀態。
這看起來會會帶來一個明顯的缺點:導致驗證時間很長
但是這僅僅出現在“一項具有很長的交易歷史的資產時”才會出現,而且可以通過一個數據分享層(自願的情況下)提前開始驗證這部分交易歷史數據。
這同時可以帶來明顯的優點:客戶端不需要知道、也不需要驗證全局中發生的所有交易
因爲它只需要知道跟自己錢包相關的交易即可,它不需要驗證其他的交易,因此每個客戶端要驗證的數據量都更小,系統擴展性明顯增強。
4.3 確定性的比特幣承諾
RGB如何防止“雙花”,是通過RGB承諾來實現的,這樣的承諾需要實現:
1️⃣涉及合約的多次狀態轉換可以承諾到單筆比特幣交易中
2️⃣每一次合約的狀態轉換都只能被承諾進比特幣交易一次
實現的具體方式是:
1️⃣首先,跟某一個合約(或者說資產 ID)相關的所有狀態轉換,要確定性地聚合成一個承諾
2️⃣然後,所有被轉移的資產的承諾,要被聚合成一棵默克爾樹
3️⃣最終的根哈希值,就是最終的 RGB 承諾;
4️⃣爲了保證跟其它無關 RGB、但同樣也需要使用確定性比特幣承諾的協議的兼容性,RGB 承諾和其它協議的承諾要再一次聚合(如 LNPBP-4 標準所述),如此得到的哈希值,才是實際上被嵌入比特幣交易中的消息。
4.4 批處理
由上節可以知道,我們可以將任何數量的狀態變化“包裹”在單個比特幣承諾裏面,那麼大規模的批處理理論上也是有可能的。
場景:A想同時給多人支付,給B轉移一個RGB20資產,給C轉移一個RGB21資產,給D轉移一個合約的所有權
結果:A只需爲B、C、D各創建一個狀態轉換,並將所有的狀態轉換都承諾到同一筆比特幣交易中,就可以了,不需要佔用更多字節。這意味着,每筆 RGB 支付的鏈上手續費邊際成本都可以非常小,因爲同一筆手續費被任意數量的轉帳平攤了。
但是我們也需要看到這裏的局限性,即:這些狀態轉換信息必須要“包裹”在同一個UTXO裏面,如果是存在多個,那麼就需要增加這筆交易的輸入,相應的成本等也會提高。但是相對於傳統的每一個都需要一筆交易的情況,已經可以實現極大的改善。
這種批處理的能力對於使用合並UTXO的服務供應商來說非常重要,會有非常多的應用場景。
4.5 客戶端之間的通信
爲了達成一筆 RGB 轉帳,參與的客戶端需要彼此分享一些數據。
如果你具體了解過RGB資產的轉移步驟,那麼可以知道,發送者需要給接收者(們)分享 consignment,這種數據結構包含了驗證轉帳所需的一切信息,包括可以追溯到合約創始狀態的所有狀態轉換。
consignment需要從發送者通過通信方式轉移給接收者,但是RGB 協議不關心用於這種數據分享操作的通信渠道,因爲有很多的方式可以去操作。但是,作爲整體的一部分, 在 RGB 軟件中主要有兩種分享數據的方法:
大致有了對RGB協議的概念之後,我覺得這時候,我們可以去了解一下協議是怎麼一步步發展起來的。任何這個級別的協議都不是一蹴而就的,必然經歷了很多的更迭和革新。
設想階段
RGB 最初由 Giacomo Zucco 和 Peter Todd 設想, Peter Todd 提出了客戶端驗證和一次性密封概念
開發階段
最開始,由BHB Network、inbitcoin維護一段時間,並得到Poseidon Group的支持
隨後,主要開發者變成 Alekos Filini
2019年中至今,Pandora Core AG 和 Maxim Orlovsky 博士已成爲技術開發的主要貢獻者
逐步成熟階段
自2019年,RGB協議得到了很多貢獻者、行業機構的幫助,逐步走向成熟。並且成爲一個基於 LNP/BP 標準協會維護的一組標準的項目。
比如:在這個階段,RGB從代幣協議重構爲通用智能合約系統,吸收了機密交易的許多部分,並使用了Blockstream的防彈技術。整體工作得到了 Bitfinex/Tether Inc 和 Fulgur Ventures 的財務支持。(這也是RGB協議的開發工作能夠持續進行下去的基礎)
Adam Back 的建議和 Blockstream 工程師在其RGB的技術設計中發揮的重要作用,包括 Andrew Poelstra(防彈、mimblewimple、機密交易)、Peter Wuille(機密交易、防彈)和 Christian Decker(閃電網絡、系統)建築設計)作品。所以這也是我關注Liquid的另一個重要原因,在理論基礎上二者有非常多的交流,對於未來二者的結合我是十分看好。
RGB的主體協議開發工作完成的差不多,在v0.10版本資產發行等功能已經可以很方便的使用,但是在對接bolt-ln(當前的bolt閃電網絡)時遇到一些問題,所以設計了bifrost標準協議用於智能合約的拓展,並進一步提出了Storm標準。
目前v0.11版本正在進行安全審計,預計在24年初將完成並發布,v0.11版本相對於v0.10有較大更新,二者的合約確定不再兼容,可能到時候會有方案進行資產的橋接,也可能沒有,畢竟現在的版本均屬於測試版本。
我比較期望v0.11協議版本會成爲一個大的穩定版本,這將爲協議下的生態項目開發帶來一定的確定性。
接下來,我詳細說一下RGB協議現存的問題:
1️⃣開發進度較慢
這個問題被很多人詬病,其原因有很多因素造成:
—LNP/BP協會的開發人員很少,主要的代碼工作由Maxim博士和bitfinex完成
—LNP/BP爲非盈利性組織,運營基本靠捐贈,雖然有Bitfinex/Tether Inc 和 Fulgur Ventures財務支持,但是資金使用上也需要精打細算(比如每年想搞一次線下會議都不一定有預算)
2️⃣不穩定性較強
這個不穩定性指的是“協議更新可能對於舊版本的破壞程度
例如這一次的v0.10對於v0.11在合約上的破壞(不兼容)就會造成較大的不確定性。
協議下的生態項目如果基於v0.10開發的功能在v0.11可能需要重做,這會帶來很高的風險成本。但是從協會本身而言,它是爲了整體的更新和規劃,不怎麼會在現階段考慮這個問題。
3️⃣錯配問題
協會本身考量的是協議整體的發展規劃,與市場的需求不一定匹配。
4️⃣資金關注度不夠
目前關注到RGB的大資金方還很少,機構還是沉浸在能很快看的到的敘事上,比如銘文等,對於像RGB這種大而深入的協議關注度不夠,所以生態的發展上暫時也沒有太多的起色(雖然相比之前已經好了一些,但我個人認爲是資金的溢出效應造成的)
在表達觀點的時候,我非常喜歡給出我的理由,因爲這也是我做判斷的依據;我不喜歡無腦去喊單,去fomo,那不符合我的本心。所以,我們先來梳理一下:
—BTC生態發展是當前礦工、老資金等共同希望的結果,市場上也需要新的敘事;
—BTC生態發展的基礎技術條件已經具備,其中taproot升級就是很重要的一環;
—資產發行是生態發展的第一步,如果沒有資產什麼都玩不了。所以我們可以看到基於btc上發行資產的各個協議,並且逐步溢出到其他公鏈;
—生態發展不能僅僅是資產發行,它只能是第一步,第二步就是要對這些資產做應用場景,也就是要對資產進行處理、交換等,這需要智能合約,簡單到復雜;
—當前的各個協議,目前我看到的基於原生的只有RGB和Bitvm,然後正如我前面所說,RGB走的更落地。
這就是我看好他的原因!
然而,事物的發展過程往往不會和想象中那麼一致,借用一張圖來表示一下:
第二部分:協議部分—認識LNP/BP
LNP:Lighting network protocol(閃電網絡協議)
BP:Bitcoin protocol(比特幣協議)
這是一家瑞士的非營利組織,負責監督比特幣和閃電網絡的第 2 層和第 3 層開放標準和協議。他們是 RGB、Bifrost、Storm、Prometheus、Kaleidscope 等 L2 和 L3 協議的創建者,也是閃電網絡上#BiFi(比特幣金融)生態系統的積極構建者。該協會由@dr-orlovsky和@giacomozucco於 2019 年創立
github中包含了大量關於RGB及相關協議的開源資料,有技術的朋友可以好好看一看
LNP/BP的捐贈機構陣容非常強大,裏面包含:
並且,泰達曾經多次表示:要在RGB協議上發行USDT,力推RGB協議的發展!
2.1 LNPBP-1:公鑰
待續…
第三部分:常見問題匯總
在這一部分,我將會把在學習中、社區運營中遇到的各種關於RGB和BTC技術的問題進行持續的匯總並更新在這個地方。
比特地地址類型主要有四種:
1️⃣遺留(Legacy)/支付公鑰哈希(P2PKH)地址
這類事傳統比特幣地址,就是早期創建的時候的地址形式,所以也叫“遺留地址”或者“支付公鑰哈希 (P2PKH) 地址”,因爲在 2009 年比特幣推出時,其生成方式是從公鑰/私鑰對的生成開始,在當時,這是創建地址的唯一方法。
這類地址都是以「1」開頭的,因爲在交易中使用最多的空間,因此也是最貴的地址類型。
2️⃣支付腳本哈希 Pay-to-Script-Hash(P2SH)地址
這類地址用的不是公鑰的hash運算結果,而是利用某些腳本的哈希運算記過,可用於要求多重籤名的轉帳事宜等。
這類地址以「3」開頭,因爲可以利用隔離見證節省交易費用,發送到 P2SH 地址比使用舊地址的錢包便宜約 26%。
3️⃣隔離見證地址(SegWit)Bech32 地址
Segwit 地址也稱爲 Bech32 地址,這種類型的比特幣地址減少了交易中存儲的信息量,它們不在交易中存儲籤名和腳本,而是在見證(commit)中。
這類地址以「bc1q 」開頭,相對 P2SH 地址,Segwit 地址可以節省大約 16% 的交易費用,相對傳統地址,節省 38% 以上的費用
4️⃣主根(Taproot)地址
爲了提高區塊空間的效率並改善費用,SegWit 在地址的構造方式上引入了一些變化。因此在 SegWit 地址的基礎之上,開發出了 Taproot 地址,翻譯爲主根地址。
這類地址以「bc1p 」開頭,其進一步減小了存儲空間,提高了交易效率,並提供了更好的隱私性。
這是BTC上常用的一個技術手段:HD Wallet
這種技術允許一對“公私鑰”生成無數個子公鑰,也就是我們看到的地址;這種特性是爲了保護btc錢包使用者的隱私性。
因爲在傳統使用時,爲了確認交易,使用者會暴露自己的公鑰,那麼就有泄露自己真實身分的風險(可以去持續的追蹤),但是在採用了HD Wallet之後,每一次使用後,都會轉換成另外一個子公鑰,這樣就無法追蹤。
具體可以參考下面的文檔:
HD Wallets | Hierarchical Deterministic Wallets
An explanation of what an HD Wallet is, how they work in Bitcoin, and their history.
很多人會去爭論“第一個”這個名頭,因爲人們喜愛追逐第一
如果要說RGB上的第一個資產,那很可能是Maxim博士自己嘗試的時候發行的,當然,你我都沒有看到
如果說LNP/BP協會開放的RGB示例資產,那麼可以參考下面的網站
如果說是在RGB協議下項目方bitmask上發行的資產,可以參考下面的網站
但是bitmask也僅僅只是RGB協議下的一個項目方,因爲RGB是“客戶端驗證”的,所以只要你能夠搭建一個客戶端,利用“命令行”也可以發行自己的“第一個RGB資產”
所以,爭論誰是第一對於短期的宣傳我認爲有意義,但是從長久來看,資產能夠內含的價值才更有意義。這種價值有可能是社區精神,也有可能是賦能等等。
事實上,並不能這麼問,因爲:RGB利用比特幣網路是爲了“安全性背書”“防止雙花”的,原則上它可以運用在具備這種特性的任何其他網路上。
如果RGB交易運行在主網,那麼它的交易就是在主網實時上鏈的;如果RGB交易運行在閃電網絡上,那麼它的交易數據是實時上閃電網絡的,閃電網絡的數據是鏈下存儲的,只有在提現的時刻才會在BTC主網上鏈;如果RGB交易運行在其他網路上,也是根據其他網路的情況來決定數據的上鏈情況。
還必須指出的是:RGB的實際交易數據是存儲在客戶端的,上鏈的是關於交易的承諾(committee)的聚合。
對於我而言,我認爲RGB是一項可以對接L1/L2/L3的通用技術,可以做很多事情,同時是BTC生態發展非常關鍵的一環;它可以實現BIFI,即bitcoin+fi,這個可以是defi,nftfi,gamefi,也可以是其他形式的fi
事實上很多人關注RGB在crypto中的應用,但是RGB可以做的更多,比如債券、國債、現實資產與虛擬資產的結合等等
RGB協議可以運行在主網上,也可以運行在閃電網絡上,甚至未來運行在側鏈上也是可能的。
RGB被設計在運行在閃電網絡上,是爲了擴展性考慮的,因爲運行智能合約,主網的tps顯然滿足不了這種要求,而閃電網絡的高tps可以滿足,但是當前的bolt閃電網絡是不能滿足RGB復雜的智能合約要求的,所以需要升級到bifrost才能夠成爲完全體;
當前是因爲閃電網絡通道的大小問題造成的,而且閃電網絡設計之初就是爲了小額支付;當然,如果你自己建立一個大的通道,也可以實現大額的支付(一般大額都走主網)
爲什麼採用閃電網絡而不是側鏈的原因我認爲有兩個:
1️⃣側鏈普遍被認爲原生性不夠,因爲側鏈都是有自己的鏈、自己的節點、自己的區塊和自己的共識機制,你甚至可以說它和BTC主網的關係不大;但是閃電網絡可以理解爲就是掛在BTC主網上的一個東西,原生性很強,被稱爲L2
2️⃣閃電網絡理論上的TPS遠高於側鏈
這種擔憂我也有,特別是目前看起來捐贈也不多(其實對於泰達公司等這樣的投資回賠率很高),但是我還是贊賞協會的這種精神,以一種非營利性的方式來做這樣偉大的事情。
主體上來說,RGB協議的大部分工作已經完成,當然後續依然後很多的任務;我覺得如果RGB協議得到了越來越多人的關注,隨着越來越多dev的加入,開發工作會變快。
是的,並且多次表示
截止2023年12月17日,大家都在等v0.11的更新,本次更新涉及到了智能合約、錢包等的更新;希望v0.11成爲一個較大的穩定版本,這樣生態下的項目方才能比較安心的開發。
如果v0.11 release,那麼很快基於閃電網絡的rgb資產的發行和轉移就能實現(會非常快),但是復雜的智能合約依然有賴於bifrost閃電網絡的開發。
bitmask/bitlight:非常正規的兩個項目方,前者是在LNP/BP主頁上公告的,聚焦於錢包和diba(nft市場)的開發,後者是聚焦於錢包、dex的開發;
pprgb:第一個有市場熱度的rgb meme,暫時發行在liquid上的項目(注意定語)
seal:希望在rgb上發行NFT及賦能token的項目,堅持要在rgb上發行
UTXO exchange:想做rgb上的dex,採用零擼的方式空投,它發行的資產肯定是rgb資產,但是鑑於當前的形式,推測是採用中心化的形式,自行評估風險
BiHelix:原名叫infinity,後來改名叫intas,後來又改名叫Bihelix,寫了很多的文章,做了很多的布道工作,但是早期和LNP/BP協議之間產生了不愉快,被認定爲scam,我建議他們要好好處理這個問題,不然在這個賽道會比較難做
rgbdoge:推測是華人項目(我對於國人還是國外無所謂,看項目質量和策略),行動力很強,但是方向性不足(從最開始的“第一”之爭,到要做平台,到要去liquid上發行)
bitrgb:一個要做RGB智能合約的平台,目前採用的是nostrasset的方式在做,之前推薦過zealy任務(擼白思路),但是鑑於“團隊匿名/投資機構匿名/收費mint(價格好像不低)”,感覺風險很高
最近發現在LNP/BP tg裏面,被maxim博士認定爲scam
Inscriptionwar:這個就完全是蹭的,就不用參與了
鏈下安全性依賴於項目方或者客戶端本身,所以需要協會針對存儲等建立統一的標準,從而保證資產等的安全性。
主要的數據存儲在鏈下的客戶端,客戶端之間未來可以通過storm節點來共享信息和通信。
我簡要介紹一下,Adam Back創建了blockstream公司,這個公司旗下有很多產品,比如elements側鏈開發平台,他們還有green wallet產品,還有真實的礦池,還有與礦池相關的理財產品、金融產品等;
Liquid就是用elements這個平台開發出來的L2,sideswap是Liquid上的一個項目。
鏈下數據的存儲安全性是由項目方來提供,用戶可以通過備份數據的形式來保護自己的資產安全;當然,如果項目方數據出現問題,用戶自己也沒有備份數據,那麼資產就會出現問題。
一些有惡意的項目方可能通過創建惡意軟件來犯罪,但是 RGB的使用機制可以避免機制上的詐騙,當然rug這種其實在所有區塊鏈中都很難防。
是的,使用Storm協議, 對等點之間的數據是共享的,但是目前的開發已經超期了
不可以。項目方無法收集有關個人交易的信息,可能只能收集應用程序內部完成的號碼傳輸(例如總統計數據)。
當然,我個人認爲如果用戶授權相關的權限,那麼應用程序就能夠訪問這些數據(會有點類似於Liquid上的揭盲密鑰查看致盲信息)
是的,但每家公司都需要遵守有關證券的監管。
1)資產具有 ContractID 和 genesis 初始值
2)與RGB錢包兼容
3)開源
這樣就能知道是否是RGB資產
UTXO 就是“公共”資產層,但僅限於相同資產之間, 例如:USDT<>USDT;未來我們可以實現讓不同資產之間“互操作”,但是這需要 Bifrost
這是可能的,但目標鏈必須支持 UTXO 模型及其他可用模型,以便與 RGB Core 和交叉庫集成。這種時候,資產需要遵循RGB20模型的規範。
實際上,RGB 與 LN 是兼容的,你可以在任何 LN 實施中使用它,例如插入 CLN 或 LND。當使用 Storm時,每個示例在LN上確認是可能的; 在 L1 上,僅當您打開/關閉通道或使用 HTLC 進行掃描時才會確認並對資產進行路由傳輸。
是的,這需要很多支持庫來共同作用,
理論上可以通過授權的方式來簡化流程,當然,只是理論上
第四部分:參考連結
在這裏,可以了解到:
1️⃣RGB是什麼,能做什麼,優點是什麼(跳轉)
2️⃣如何嘗試RGB庫,例如命令行,安裝節點、調取API等等(跳轉)
3️⃣通過官方的視頻來學習RGB(當然,對於非英語的,有難度)(跳轉)
Scalable & confidential smart contracts for Bitcoin & Lightning
該文檔解釋了設計原理,並提供了有關 RGB 系統如何構造和工作的深入技術見解,包括:
1️⃣協議設計的概述和目標(跳轉)
2️⃣“客戶端驗證”介紹,講述了“Single-use-seals”和“Deterministic bitcoin commitments”(跳轉)
3️⃣“RGB合約、狀態和操作”的說明(跳轉)
4️⃣“嘗試RGB合約”的一些內容:包括撰寫合約,與合約交互、P2P通信,與錢包交互等(跳轉)
RGB Blackpaper | RGB Blackpaper
Turing-complete, Scalable & Confidential Smart Contract Layer for Bitcoin & LN
如果遇到問題,可以先看這個官方文檔有沒有解答
在這裏,可以了解LNP/BP協會開發的圖靈完備的Alu虛擬機
1️⃣CoinEx Research
A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin
Blog | CoinEx - The Global Cryptocurrency Exchange
2️⃣Federico Tenga
Understanding the RGB protocol
@FedericoTenga">Federico Tenga – Medium
@FedericoTenga">Read writing from Federico Tenga on Medium. Working on Bitcoin stuff. Every day, Federico Tenga and thousands of other voices re…
@FedericoTenga">medium.com
3️⃣Bitfinex
How Can RGB Improve Bitcoin?
How Can RGB Improve Bitcoin? - Bitfinex blog
4️⃣Waterdrip Capital
詳解 RGB 協議:另闢蹊徑,創造比特幣資產發行新二層
5️⃣ RGB 協議的設計
Compartilhar
Conteúdo
很多人開始關注比特幣的RGB協議,真的很開心。但是大部分人對於這樣一個協議(尤其是技術相對復雜的協議)比較陌生,也不知道如何去研究和嘗試該協議的內容和生態。
所以,特別寫一篇持續更新的Mirror,來匯總相關的學習資料,提供一個相對來說合理的學習路徑;同時,也作爲個人學習RGB的一個記錄。
第一部分:科普部分-初步認識RGB
很多人看到RGB這三個字,會想到“三原色:red green blue”。如果從圖標上看,還真是這麼回事,這是因爲RGB協議有利用到早期的“染色硬幣”的概念。
這裏我們說的RGB是一個協議,一個可以在比特幣主網、閃電網絡或者類似網路上運行,極端隱私的、可擴展的智能合約系統協議。
這個協議目前由LNP/BP協議維護和更新,bitfinex也參與部分代碼工作。
你很難將RGB簡單劃分爲比特幣L2的範疇,它沒有自己的鏈、它沒有自己的層、他可以運作在BTC的其他L2上,所以,準確來說:它是一項通用性的技術。
在業界,普遍認爲RGB和Bitvm會是BTC拓展的終極形態,因爲他們都可以基於BTC原生性實現BTC生態的可擴展性,相對於Bitvm的遙遙無期,RGB已經在逐步落地。
值得一提的是:RGB是一項不局限於crypto的技術,它可以廣泛運用到我們非crypto的場景中,等到協議越來越成熟,我們會看到越來越多的用例。
從官方的介紹中,我們可以看到RGB協議可以實現的功能:
如果我們歸類一下,可以看出:
從這個角度看,RGB可以讓BTC具有現在EVM的絕大部分功能,但是它不是採用類似於“兼容EVM”的非原生形式實現的,而是原生實現的,不得不說這一套理論和設計理念很牛。
事實上,值得注意的是,RGB 智能合約系統與之前的方法都有很大不同,無論是基於比特幣(彩色幣、Counterparty、OMNI)還是非比特幣(以太坊、EOS 等),它有自己獨特的特性:
第一條的意思是,智能合約將進行更好的分層,發行人僅在發行時刻享有合約的權利,之後都是由狀態所有者在不斷的狀態演化過程中享有權利;
第二條意思是,它將代碼保留在鏈下,可以節省鏈上空間,提升運行速度,降低開發難度,但是又可以通過機制保證安全性;
第三條揭示了它的安全背書層(區塊鏈),同時它是圖靈完備的,可以支持簡單的語言操作。
所以,下圖可能更接近於正確的理解:
從Dr. Maxim Orlovsky的教學視頻中,我們可以看到官方認定的RGB特性包括:
我們來逐一拆分講解:
1️⃣極端隱私性
2️⃣高度安全性
這兩點我還不怎麼懂,需要研究下
3️⃣高度可擴展性
4️⃣不擁堵
5️⃣極高的融合性
所以,其實在我的眼裏,RGB對於BTC更像是下面這樣:
RGB協議相對於其他協議,有自己非常獨特的技術點,這裏簡單科普幾個重要的部分:
4.1 一次性密封
該技術最早由Peter Todd在2016年提出,主要意思是“把一條消息加上一個密封條,確保這個消息只能被使用一次,因爲你要知道消息就必須拆除密封條”。
一種簡單的方法是設置一個公證的第三方服務端,每當某一個密封條打開或者鎖上時就在公開的註冊處發布證書,這樣任何人都能驗證自己關心的密封條的狀態。
如果不使用一個受信任的實體來實現一次性密封的功能,可以使用比特幣的UTXO來作爲密封條。因爲比特幣的任何一個UTXO只能被花費一次。因此,把UTXO作爲密封條,就可以在UTXO創建的時候鎖上,在花費它的時候打開。
RGB利用了這樣的“一次性密封”技術,它將RGB資產的信息、合約的狀態等都“包裹”在UTXO裏面,當UTXO被花費的時候,資產的所有權、合約的狀態就發生了轉變。這意味着,每當一筆 RGB 交易發生時,實際上就是發送者給某個合約(定義了被轉移的權利的那個)創建了一次狀態變更。
以RGB20爲例:
1️⃣首先,合約的發行者設定了合約的創始狀態,定義了合約的細節:資產的名稱、總供應量等,並且發行者有權移動這些供應量的 UTXO;
2️⃣當資產被第一次轉移時,第一個 UTXO 的所有者就可以創建一次狀態變更,定義哪一個 UTXO 將持有這項資產;
3️⃣狀態變更可以應用在變更資產所有權的權利上,也可以應用在別的類型的權利上,例如,二次發行的權利,或者是添加/改變 資產的特定屬性(例如:元數據)的權利等。
4.2 客戶端驗證
RGB的驗證和傳統的“全球共識”驗證不同,採用的是“客戶端驗證”的技術。
傳統的比特幣驗證,一個連接到網路的節點會持續不斷地下載和驗證區塊以及交易池中的交易(全節點)。這樣的節點對整條鏈上的 UTXO 集(區塊鏈上所有未花費的輸出的集合)有一個實時更新的試圖,當它看到一筆新交易時,要驗證其有效性,只需要驗證該交易的所有輸入都是該 UTXO 集的最新狀態的一部分即可。
但是對於RGB而言,沒有全局傳播的數據,因此也沒有這樣的UTXO集的全局視圖。一個 RGB 客戶端在接受一筆交易後,不僅需要驗證交易的最新狀態是有效的,還必須對與交易相關的以往所有的狀態轉化作同樣的驗證,一路追溯到發行合約的創始狀態。
這看起來會會帶來一個明顯的缺點:導致驗證時間很長
但是這僅僅出現在“一項具有很長的交易歷史的資產時”才會出現,而且可以通過一個數據分享層(自願的情況下)提前開始驗證這部分交易歷史數據。
這同時可以帶來明顯的優點:客戶端不需要知道、也不需要驗證全局中發生的所有交易
因爲它只需要知道跟自己錢包相關的交易即可,它不需要驗證其他的交易,因此每個客戶端要驗證的數據量都更小,系統擴展性明顯增強。
4.3 確定性的比特幣承諾
RGB如何防止“雙花”,是通過RGB承諾來實現的,這樣的承諾需要實現:
1️⃣涉及合約的多次狀態轉換可以承諾到單筆比特幣交易中
2️⃣每一次合約的狀態轉換都只能被承諾進比特幣交易一次
實現的具體方式是:
1️⃣首先,跟某一個合約(或者說資產 ID)相關的所有狀態轉換,要確定性地聚合成一個承諾
2️⃣然後,所有被轉移的資產的承諾,要被聚合成一棵默克爾樹
3️⃣最終的根哈希值,就是最終的 RGB 承諾;
4️⃣爲了保證跟其它無關 RGB、但同樣也需要使用確定性比特幣承諾的協議的兼容性,RGB 承諾和其它協議的承諾要再一次聚合(如 LNPBP-4 標準所述),如此得到的哈希值,才是實際上被嵌入比特幣交易中的消息。
4.4 批處理
由上節可以知道,我們可以將任何數量的狀態變化“包裹”在單個比特幣承諾裏面,那麼大規模的批處理理論上也是有可能的。
場景:A想同時給多人支付,給B轉移一個RGB20資產,給C轉移一個RGB21資產,給D轉移一個合約的所有權
結果:A只需爲B、C、D各創建一個狀態轉換,並將所有的狀態轉換都承諾到同一筆比特幣交易中,就可以了,不需要佔用更多字節。這意味着,每筆 RGB 支付的鏈上手續費邊際成本都可以非常小,因爲同一筆手續費被任意數量的轉帳平攤了。
但是我們也需要看到這裏的局限性,即:這些狀態轉換信息必須要“包裹”在同一個UTXO裏面,如果是存在多個,那麼就需要增加這筆交易的輸入,相應的成本等也會提高。但是相對於傳統的每一個都需要一筆交易的情況,已經可以實現極大的改善。
這種批處理的能力對於使用合並UTXO的服務供應商來說非常重要,會有非常多的應用場景。
4.5 客戶端之間的通信
爲了達成一筆 RGB 轉帳,參與的客戶端需要彼此分享一些數據。
如果你具體了解過RGB資產的轉移步驟,那麼可以知道,發送者需要給接收者(們)分享 consignment,這種數據結構包含了驗證轉帳所需的一切信息,包括可以追溯到合約創始狀態的所有狀態轉換。
consignment需要從發送者通過通信方式轉移給接收者,但是RGB 協議不關心用於這種數據分享操作的通信渠道,因爲有很多的方式可以去操作。但是,作爲整體的一部分, 在 RGB 軟件中主要有兩種分享數據的方法:
大致有了對RGB協議的概念之後,我覺得這時候,我們可以去了解一下協議是怎麼一步步發展起來的。任何這個級別的協議都不是一蹴而就的,必然經歷了很多的更迭和革新。
設想階段
RGB 最初由 Giacomo Zucco 和 Peter Todd 設想, Peter Todd 提出了客戶端驗證和一次性密封概念
開發階段
最開始,由BHB Network、inbitcoin維護一段時間,並得到Poseidon Group的支持
隨後,主要開發者變成 Alekos Filini
2019年中至今,Pandora Core AG 和 Maxim Orlovsky 博士已成爲技術開發的主要貢獻者
逐步成熟階段
自2019年,RGB協議得到了很多貢獻者、行業機構的幫助,逐步走向成熟。並且成爲一個基於 LNP/BP 標準協會維護的一組標準的項目。
比如:在這個階段,RGB從代幣協議重構爲通用智能合約系統,吸收了機密交易的許多部分,並使用了Blockstream的防彈技術。整體工作得到了 Bitfinex/Tether Inc 和 Fulgur Ventures 的財務支持。(這也是RGB協議的開發工作能夠持續進行下去的基礎)
Adam Back 的建議和 Blockstream 工程師在其RGB的技術設計中發揮的重要作用,包括 Andrew Poelstra(防彈、mimblewimple、機密交易)、Peter Wuille(機密交易、防彈)和 Christian Decker(閃電網絡、系統)建築設計)作品。所以這也是我關注Liquid的另一個重要原因,在理論基礎上二者有非常多的交流,對於未來二者的結合我是十分看好。
RGB的主體協議開發工作完成的差不多,在v0.10版本資產發行等功能已經可以很方便的使用,但是在對接bolt-ln(當前的bolt閃電網絡)時遇到一些問題,所以設計了bifrost標準協議用於智能合約的拓展,並進一步提出了Storm標準。
目前v0.11版本正在進行安全審計,預計在24年初將完成並發布,v0.11版本相對於v0.10有較大更新,二者的合約確定不再兼容,可能到時候會有方案進行資產的橋接,也可能沒有,畢竟現在的版本均屬於測試版本。
我比較期望v0.11協議版本會成爲一個大的穩定版本,這將爲協議下的生態項目開發帶來一定的確定性。
接下來,我詳細說一下RGB協議現存的問題:
1️⃣開發進度較慢
這個問題被很多人詬病,其原因有很多因素造成:
—LNP/BP協會的開發人員很少,主要的代碼工作由Maxim博士和bitfinex完成
—LNP/BP爲非盈利性組織,運營基本靠捐贈,雖然有Bitfinex/Tether Inc 和 Fulgur Ventures財務支持,但是資金使用上也需要精打細算(比如每年想搞一次線下會議都不一定有預算)
2️⃣不穩定性較強
這個不穩定性指的是“協議更新可能對於舊版本的破壞程度
例如這一次的v0.10對於v0.11在合約上的破壞(不兼容)就會造成較大的不確定性。
協議下的生態項目如果基於v0.10開發的功能在v0.11可能需要重做,這會帶來很高的風險成本。但是從協會本身而言,它是爲了整體的更新和規劃,不怎麼會在現階段考慮這個問題。
3️⃣錯配問題
協會本身考量的是協議整體的發展規劃,與市場的需求不一定匹配。
4️⃣資金關注度不夠
目前關注到RGB的大資金方還很少,機構還是沉浸在能很快看的到的敘事上,比如銘文等,對於像RGB這種大而深入的協議關注度不夠,所以生態的發展上暫時也沒有太多的起色(雖然相比之前已經好了一些,但我個人認爲是資金的溢出效應造成的)
在表達觀點的時候,我非常喜歡給出我的理由,因爲這也是我做判斷的依據;我不喜歡無腦去喊單,去fomo,那不符合我的本心。所以,我們先來梳理一下:
—BTC生態發展是當前礦工、老資金等共同希望的結果,市場上也需要新的敘事;
—BTC生態發展的基礎技術條件已經具備,其中taproot升級就是很重要的一環;
—資產發行是生態發展的第一步,如果沒有資產什麼都玩不了。所以我們可以看到基於btc上發行資產的各個協議,並且逐步溢出到其他公鏈;
—生態發展不能僅僅是資產發行,它只能是第一步,第二步就是要對這些資產做應用場景,也就是要對資產進行處理、交換等,這需要智能合約,簡單到復雜;
—當前的各個協議,目前我看到的基於原生的只有RGB和Bitvm,然後正如我前面所說,RGB走的更落地。
這就是我看好他的原因!
然而,事物的發展過程往往不會和想象中那麼一致,借用一張圖來表示一下:
第二部分:協議部分—認識LNP/BP
LNP:Lighting network protocol(閃電網絡協議)
BP:Bitcoin protocol(比特幣協議)
這是一家瑞士的非營利組織,負責監督比特幣和閃電網絡的第 2 層和第 3 層開放標準和協議。他們是 RGB、Bifrost、Storm、Prometheus、Kaleidscope 等 L2 和 L3 協議的創建者,也是閃電網絡上#BiFi(比特幣金融)生態系統的積極構建者。該協會由@dr-orlovsky和@giacomozucco於 2019 年創立
github中包含了大量關於RGB及相關協議的開源資料,有技術的朋友可以好好看一看
LNP/BP的捐贈機構陣容非常強大,裏面包含:
並且,泰達曾經多次表示:要在RGB協議上發行USDT,力推RGB協議的發展!
2.1 LNPBP-1:公鑰
待續…
第三部分:常見問題匯總
在這一部分,我將會把在學習中、社區運營中遇到的各種關於RGB和BTC技術的問題進行持續的匯總並更新在這個地方。
比特地地址類型主要有四種:
1️⃣遺留(Legacy)/支付公鑰哈希(P2PKH)地址
這類事傳統比特幣地址,就是早期創建的時候的地址形式,所以也叫“遺留地址”或者“支付公鑰哈希 (P2PKH) 地址”,因爲在 2009 年比特幣推出時,其生成方式是從公鑰/私鑰對的生成開始,在當時,這是創建地址的唯一方法。
這類地址都是以「1」開頭的,因爲在交易中使用最多的空間,因此也是最貴的地址類型。
2️⃣支付腳本哈希 Pay-to-Script-Hash(P2SH)地址
這類地址用的不是公鑰的hash運算結果,而是利用某些腳本的哈希運算記過,可用於要求多重籤名的轉帳事宜等。
這類地址以「3」開頭,因爲可以利用隔離見證節省交易費用,發送到 P2SH 地址比使用舊地址的錢包便宜約 26%。
3️⃣隔離見證地址(SegWit)Bech32 地址
Segwit 地址也稱爲 Bech32 地址,這種類型的比特幣地址減少了交易中存儲的信息量,它們不在交易中存儲籤名和腳本,而是在見證(commit)中。
這類地址以「bc1q 」開頭,相對 P2SH 地址,Segwit 地址可以節省大約 16% 的交易費用,相對傳統地址,節省 38% 以上的費用
4️⃣主根(Taproot)地址
爲了提高區塊空間的效率並改善費用,SegWit 在地址的構造方式上引入了一些變化。因此在 SegWit 地址的基礎之上,開發出了 Taproot 地址,翻譯爲主根地址。
這類地址以「bc1p 」開頭,其進一步減小了存儲空間,提高了交易效率,並提供了更好的隱私性。
這是BTC上常用的一個技術手段:HD Wallet
這種技術允許一對“公私鑰”生成無數個子公鑰,也就是我們看到的地址;這種特性是爲了保護btc錢包使用者的隱私性。
因爲在傳統使用時,爲了確認交易,使用者會暴露自己的公鑰,那麼就有泄露自己真實身分的風險(可以去持續的追蹤),但是在採用了HD Wallet之後,每一次使用後,都會轉換成另外一個子公鑰,這樣就無法追蹤。
具體可以參考下面的文檔:
HD Wallets | Hierarchical Deterministic Wallets
An explanation of what an HD Wallet is, how they work in Bitcoin, and their history.
很多人會去爭論“第一個”這個名頭,因爲人們喜愛追逐第一
如果要說RGB上的第一個資產,那很可能是Maxim博士自己嘗試的時候發行的,當然,你我都沒有看到
如果說LNP/BP協會開放的RGB示例資產,那麼可以參考下面的網站
如果說是在RGB協議下項目方bitmask上發行的資產,可以參考下面的網站
但是bitmask也僅僅只是RGB協議下的一個項目方,因爲RGB是“客戶端驗證”的,所以只要你能夠搭建一個客戶端,利用“命令行”也可以發行自己的“第一個RGB資產”
所以,爭論誰是第一對於短期的宣傳我認爲有意義,但是從長久來看,資產能夠內含的價值才更有意義。這種價值有可能是社區精神,也有可能是賦能等等。
事實上,並不能這麼問,因爲:RGB利用比特幣網路是爲了“安全性背書”“防止雙花”的,原則上它可以運用在具備這種特性的任何其他網路上。
如果RGB交易運行在主網,那麼它的交易就是在主網實時上鏈的;如果RGB交易運行在閃電網絡上,那麼它的交易數據是實時上閃電網絡的,閃電網絡的數據是鏈下存儲的,只有在提現的時刻才會在BTC主網上鏈;如果RGB交易運行在其他網路上,也是根據其他網路的情況來決定數據的上鏈情況。
還必須指出的是:RGB的實際交易數據是存儲在客戶端的,上鏈的是關於交易的承諾(committee)的聚合。
對於我而言,我認爲RGB是一項可以對接L1/L2/L3的通用技術,可以做很多事情,同時是BTC生態發展非常關鍵的一環;它可以實現BIFI,即bitcoin+fi,這個可以是defi,nftfi,gamefi,也可以是其他形式的fi
事實上很多人關注RGB在crypto中的應用,但是RGB可以做的更多,比如債券、國債、現實資產與虛擬資產的結合等等
RGB協議可以運行在主網上,也可以運行在閃電網絡上,甚至未來運行在側鏈上也是可能的。
RGB被設計在運行在閃電網絡上,是爲了擴展性考慮的,因爲運行智能合約,主網的tps顯然滿足不了這種要求,而閃電網絡的高tps可以滿足,但是當前的bolt閃電網絡是不能滿足RGB復雜的智能合約要求的,所以需要升級到bifrost才能夠成爲完全體;
當前是因爲閃電網絡通道的大小問題造成的,而且閃電網絡設計之初就是爲了小額支付;當然,如果你自己建立一個大的通道,也可以實現大額的支付(一般大額都走主網)
爲什麼採用閃電網絡而不是側鏈的原因我認爲有兩個:
1️⃣側鏈普遍被認爲原生性不夠,因爲側鏈都是有自己的鏈、自己的節點、自己的區塊和自己的共識機制,你甚至可以說它和BTC主網的關係不大;但是閃電網絡可以理解爲就是掛在BTC主網上的一個東西,原生性很強,被稱爲L2
2️⃣閃電網絡理論上的TPS遠高於側鏈
這種擔憂我也有,特別是目前看起來捐贈也不多(其實對於泰達公司等這樣的投資回賠率很高),但是我還是贊賞協會的這種精神,以一種非營利性的方式來做這樣偉大的事情。
主體上來說,RGB協議的大部分工作已經完成,當然後續依然後很多的任務;我覺得如果RGB協議得到了越來越多人的關注,隨着越來越多dev的加入,開發工作會變快。
是的,並且多次表示
截止2023年12月17日,大家都在等v0.11的更新,本次更新涉及到了智能合約、錢包等的更新;希望v0.11成爲一個較大的穩定版本,這樣生態下的項目方才能比較安心的開發。
如果v0.11 release,那麼很快基於閃電網絡的rgb資產的發行和轉移就能實現(會非常快),但是復雜的智能合約依然有賴於bifrost閃電網絡的開發。
bitmask/bitlight:非常正規的兩個項目方,前者是在LNP/BP主頁上公告的,聚焦於錢包和diba(nft市場)的開發,後者是聚焦於錢包、dex的開發;
pprgb:第一個有市場熱度的rgb meme,暫時發行在liquid上的項目(注意定語)
seal:希望在rgb上發行NFT及賦能token的項目,堅持要在rgb上發行
UTXO exchange:想做rgb上的dex,採用零擼的方式空投,它發行的資產肯定是rgb資產,但是鑑於當前的形式,推測是採用中心化的形式,自行評估風險
BiHelix:原名叫infinity,後來改名叫intas,後來又改名叫Bihelix,寫了很多的文章,做了很多的布道工作,但是早期和LNP/BP協議之間產生了不愉快,被認定爲scam,我建議他們要好好處理這個問題,不然在這個賽道會比較難做
rgbdoge:推測是華人項目(我對於國人還是國外無所謂,看項目質量和策略),行動力很強,但是方向性不足(從最開始的“第一”之爭,到要做平台,到要去liquid上發行)
bitrgb:一個要做RGB智能合約的平台,目前採用的是nostrasset的方式在做,之前推薦過zealy任務(擼白思路),但是鑑於“團隊匿名/投資機構匿名/收費mint(價格好像不低)”,感覺風險很高
最近發現在LNP/BP tg裏面,被maxim博士認定爲scam
Inscriptionwar:這個就完全是蹭的,就不用參與了
鏈下安全性依賴於項目方或者客戶端本身,所以需要協會針對存儲等建立統一的標準,從而保證資產等的安全性。
主要的數據存儲在鏈下的客戶端,客戶端之間未來可以通過storm節點來共享信息和通信。
我簡要介紹一下,Adam Back創建了blockstream公司,這個公司旗下有很多產品,比如elements側鏈開發平台,他們還有green wallet產品,還有真實的礦池,還有與礦池相關的理財產品、金融產品等;
Liquid就是用elements這個平台開發出來的L2,sideswap是Liquid上的一個項目。
鏈下數據的存儲安全性是由項目方來提供,用戶可以通過備份數據的形式來保護自己的資產安全;當然,如果項目方數據出現問題,用戶自己也沒有備份數據,那麼資產就會出現問題。
一些有惡意的項目方可能通過創建惡意軟件來犯罪,但是 RGB的使用機制可以避免機制上的詐騙,當然rug這種其實在所有區塊鏈中都很難防。
是的,使用Storm協議, 對等點之間的數據是共享的,但是目前的開發已經超期了
不可以。項目方無法收集有關個人交易的信息,可能只能收集應用程序內部完成的號碼傳輸(例如總統計數據)。
當然,我個人認爲如果用戶授權相關的權限,那麼應用程序就能夠訪問這些數據(會有點類似於Liquid上的揭盲密鑰查看致盲信息)
是的,但每家公司都需要遵守有關證券的監管。
1)資產具有 ContractID 和 genesis 初始值
2)與RGB錢包兼容
3)開源
這樣就能知道是否是RGB資產
UTXO 就是“公共”資產層,但僅限於相同資產之間, 例如:USDT<>USDT;未來我們可以實現讓不同資產之間“互操作”,但是這需要 Bifrost
這是可能的,但目標鏈必須支持 UTXO 模型及其他可用模型,以便與 RGB Core 和交叉庫集成。這種時候,資產需要遵循RGB20模型的規範。
實際上,RGB 與 LN 是兼容的,你可以在任何 LN 實施中使用它,例如插入 CLN 或 LND。當使用 Storm時,每個示例在LN上確認是可能的; 在 L1 上,僅當您打開/關閉通道或使用 HTLC 進行掃描時才會確認並對資產進行路由傳輸。
是的,這需要很多支持庫來共同作用,
理論上可以通過授權的方式來簡化流程,當然,只是理論上
第四部分:參考連結
在這裏,可以了解到:
1️⃣RGB是什麼,能做什麼,優點是什麼(跳轉)
2️⃣如何嘗試RGB庫,例如命令行,安裝節點、調取API等等(跳轉)
3️⃣通過官方的視頻來學習RGB(當然,對於非英語的,有難度)(跳轉)
Scalable & confidential smart contracts for Bitcoin & Lightning
該文檔解釋了設計原理,並提供了有關 RGB 系統如何構造和工作的深入技術見解,包括:
1️⃣協議設計的概述和目標(跳轉)
2️⃣“客戶端驗證”介紹,講述了“Single-use-seals”和“Deterministic bitcoin commitments”(跳轉)
3️⃣“RGB合約、狀態和操作”的說明(跳轉)
4️⃣“嘗試RGB合約”的一些內容:包括撰寫合約,與合約交互、P2P通信,與錢包交互等(跳轉)
RGB Blackpaper | RGB Blackpaper
Turing-complete, Scalable & Confidential Smart Contract Layer for Bitcoin & LN
如果遇到問題,可以先看這個官方文檔有沒有解答
在這裏,可以了解LNP/BP協會開發的圖靈完備的Alu虛擬機
1️⃣CoinEx Research
A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin
Blog | CoinEx - The Global Cryptocurrency Exchange
2️⃣Federico Tenga
Understanding the RGB protocol
@FedericoTenga">Federico Tenga – Medium
@FedericoTenga">Read writing from Federico Tenga on Medium. Working on Bitcoin stuff. Every day, Federico Tenga and thousands of other voices re…
@FedericoTenga">medium.com
3️⃣Bitfinex
How Can RGB Improve Bitcoin?
How Can RGB Improve Bitcoin? - Bitfinex blog
4️⃣Waterdrip Capital
詳解 RGB 協議:另闢蹊徑,創造比特幣資產發行新二層
5️⃣ RGB 協議的設計