Runes協議及“公開銘刻"發行機制

中級4/22/2024, 7:37:07 AM
本文結合Runes的一些最新話題,就Runes與Ordinals協議的過往,以及類似的資產發行方式進行開發性的探索。

轉發原文標題《關於Runes協議及“公開銘刻”發行機制的拓展討論》

2024年3月2日,Runes生態基礎設施項目Rune alpha的創始人,在Github的公開議題中,與Runes協議創始人Casey展開了討論,雙方對如何拓展Runes協議的「公開銘刻」機制進行了探討。話題包括:

·要不要放寬「公開銘刻」不可預留的要求?

·指出了採用「公開銘刻」發行方式的Runes符文不存在管理權的觀點

·提出了一套基於銘文NFT和符文FT互相配合的發行機制設想

出於對比特幣衍生資產協議的濃厚興趣,本文作者結合上述Runes的一些最新話題,寫作了此篇文章,就Runes與Ordinals協議的過往,以及類似的資產發行方式進行開發性的探索,相信能夠對大家了解比特幣生態帶來幫助。

什麼是Runes協議

所謂的Runes協議,是在比特幣網路上發行同質化代幣的協議,由Ordinals創始人Casey在發布Ordinals方案後,又重新構建的同質化代幣方案,基於比特幣UTXO的特性而構建,整體的設計思路非常簡潔。

值得一提的是,Runes協議計劃在比特幣2024年減半時(區塊高度840000),也即是今年四月下旬上線主網。現在Runes協議仍然處於優化和版本迭代的過程中。

在簡要科普Runes的原理前,讓我們先快速了解下來龍去脈,以及所謂的【公開銘刻】到底代表什麼。

Runes的提出者Casey在一開始並沒有要做同質化代幣協議的idea,早在2022年12月時,Casey就發布了Ordinals協議,意圖是將NFT數據永久上鏈Bitcoin,簡單說就是將NFT元數據像銘文一樣,記錄在比特幣交易的見證數據witness中(witness主要包含數字籤名信息),這樣就能夠將任意形式的內容(如文本、圖像等)銘刻在指定的聰上。


(圖片來源:https://yishi.io/a-beginner-guide-to-the-ordinals-protocol/)

隨後,歷史的齒輪開始轉動,2023年3月8日,匿名開發者@domodata基於Ordinals這個典型的NFT發行協議,迂回的搞出一套發行同質化代幣的BRC-20標準,就是以銘文的方式,對那些需要上傳到比特幣鏈上的衍生資產數據,規定出統一的格式和屬性(Token名稱、總供應量、單次最大鑄造量等),再通過索引器去解析並追蹤這些信息,展示出BRC-20代幣相關的錢包帳戶和資產數額。

關鍵來了,BRC-20的發行,要依賴於Ordinals這種比特幣銘文NFT協議,所以在初始的發行機制上變得和NFT鑄造過程類似,天然具備「先到先得」的特性,誰先Mint誰就擁有,完全不同於以太坊ERC-20資產發行時“項目方先部署資產合約,定義資產分配機制,官方想怎麼控盤都可以”。

這種Fair Launch的特性,使得大多數人有了公平參與同質化代幣初始發行的機會,項目方無預留無鎖倉,每個人都可以在資產最初發行的第一時間參與。很快,BRC20就帶來了比特幣鏈上衍生資產的發行熱潮,甚至直接啓動了這輪牛市。由此可知,我們今天重點討論的「公開銘刻」的發行方式,對於Runes協議而言非常重要。

但BRC-20也帶來了很多問題:BRC-20資產的每一次操作,都要在比特幣鏈上發起特定的交易,隨着BRC-20資產的火爆,比特幣UTXO數據集也快速膨脹,這使得BTC核心開發者對BRC-20產生公開質疑。

Ordinals創始人Casey不僅反對BRC-20,更是對基於Ordinals之上發行的FT資產不予認可,但是BRC-20的火爆,讓他覺得雖然99%的代幣都是騙局和噱頭,但這些東西仍會像賭場一樣無法消失。

同時,BRC-20在比特幣鏈上留下了“過多的痕跡”,爲比特幣節點帶來了數據承載上的負擔,但如果有人提出一套,能夠在上鏈數據方面“減負”的資產協議,或許能減緩BRC-20帶來的問題。

所以Casey決定爲比特幣構建一種“更好的同質化代幣協議”,隨後在2023年9月25日,他發布了Runes協議的初步構想。

從技術角度看,Runes協議基於比特幣UTXO和附加信息而構建,每一筆交易的觸發,都要把鏈下生成的數字籤名信息on chain,我們可以在籤名信息中攜帶特定格式的消息。Runes協議通過OP_RETURN操作碼來標記出“特定消息”,這些特定消息就是與Runes資產變更相關的信息。

相比於BRC-20協議,Runes 優勢很多,其中最重要在於:

1.交易步驟簡化,且不會生成多餘的無用UTXO,能更好的爲比特幣節點“減輕負擔”。此外,BRC-20的一筆轉帳交易僅支持一個接收者和一種代幣,而Runes支持同時向多個接收者轉帳,且可轉帳多種Runes代幣。

2.資產數據的存儲與索引更簡潔:BRC-20的數據以JSON格式存儲在特定交易的witness數據中,且BRC-20基於帳戶模型,資產餘額與指定的帳戶相關聯。而Runes協議的數據存儲在特定交易的OP_RETURN字段中,資產的記錄方式採用UTXO模型,可以直接與比特幣鏈上的UTXO“同構綁定”。

在確認一個人的Runes資產狀況時,只需驗證這個人擁有的、與Runes資產相綁定的特殊UTXO,雖然還是要追溯部分信息完成計算,但無需像BRC-20那樣掃描比特幣鏈上的完整UTXO集合,這種輕量化的方式對數據索引更友好。

3.與UTXO功能拓展層兼容:Runes基於UTXO的設計,使其能夠與CKB、Cardano、Fuel等基於UTXO的功能拓展層更好地兼容。通過類似於RGB++的“UTXO同構綁定”,上述功能拓展層可以爲Runes提供智能合約場景。

簡要談完了技術,我們回到本文最開始談論的發行機制的事情。Casey爲Runes符文設計了兩套發行方式,即「固定總量」和「公開銘刻」:

1.固定總量就是發行方直接銘刻所有Runes符文,然後再進行分發,相對更中心化。

2.公開銘刻就是對Runes符文的發行方式設定參數,比如指明一個區塊高度或時間戳,在符合規則的時間段內,用戶Mint了多少資產,最後該符文的總量就是多少。

兩種發行方式對應的場景與機制完全不同,下文中我們只聊「公開銘刻」。

事實上,Sondotpin從Runes的Issues#124議題中,就開始討論此話題,並得到了Casey的認可。

而Issues#165具體內容如下:

Sondotpin:目前的公開發行,項目方/發行方不能提前預留Runes符文,這限制了項目方設計優秀通證經濟模型的機會。

Casey:請查看之前的Issues#124。我正在考慮放寬這個要求,允許發行方在發行時以合理的方式安排符文,甚至超出參數的設定範圍。如果這樣設計,相關信息會在Runes符文的詳情頁做非常突出的展示。

Sondotpin:是不是可以設計一個多次發行的機制,比如能有兩輪「公開銘刻」Runes符文,然後每一輪發行設定不同的參數?

Casey:我並不傾向於這樣的做法,因爲Runes符文本質上並沒有「管理者」。發行的權限不應該掌握在有特別權限的單一實體手上。但是你可以在發行符文的時候添加一個銘文,然後在這個銘文的基礎上再發行新的符文,這樣就可以實現兩次發行的符文都是同一個資產。當然,你也可以採用預挖的方式,然後用其他的分配方式進行發行。

如果未來 CTV 的功能能夠順利啓動,就不需要協議支持了,CTV 直接可以預先設定條件模板,達到條件後就可以做符合條件設置的空投和公開發行。

圍繞Casey和SondotPin的討論,個人看法:

1.在發起項目的早期,預留部分Token確有必要

在早期,項目方想要實現業務的自舉,需要有一定的Token儲備去激勵核心團隊、凝聚社區。如果可以按照本次討論去實現協議,是對「公開銘刻」的公平和全民參與價值的補充,可以讓更多有價值基礎項目方通過「公開銘刻」的方式參與到Runes生態中。

2.是否預留、如何預留,是將自證的手段交給發行方

事實上,Casey曾多次在Youtube視頻裏直言,同質化通證99.9%都是騙局,大家也別冠冕堂皇的說自己要改變世界,坦率地承認這是一個充滿賭博和投機的行業,以誠相待,對所有人都好。IT’S JUST FOR FUN!

是從issue#124到#165,可以看到Casey對同質化通證的使用場景有了更多認可。「公開銘刻」的方式勿需質疑,在此基礎上進行拓展,比如增加預留機制,是將選擇的權利、自證的手段交給發行方,也是防止劣幣驅逐良幣的好方法。

3.銘文NFT和符文FT將會有更多的創新空間

Casey提出的銘文NFT和符文FT互相配合進行多輪次的發行機制設想,相當有趣。背景知識裏我們說到,Ordinals和Runes都是Casey設計的協議,應該算是兩個平行關係協議,但是在Github上都做到Ord這個項目裏,技術上不少交叉和配合,比如共用了同步區塊這類底層邏輯。

當下熱點Runestone和Runecoin等項目,也是銘文和符文互相組合創新。Runecoin的玩兒法是最主流的銘文預挖礦,持有Runecoin發行的RSIC銘文,就會持續不斷的挖出項目的符文,然後4月底Runes協議上線再分配FT。期待未來有更多項目可以推陳出新,帶來更新穎的玩兒法。

4.採用「公開銘刻」發行方式的Runes符文不存在所有權

Casey原文中只表達了「Rune不存在所有權」,但是筆者認爲這應該是特指採用「公開銘刻」發行方式的Runes符文不存在所有權。SondotPin提出的兩輪「公開銘刻」方案,就一定會有一個擁有極高權限的地址的地址來操作,這並不是Crypto加密領域希望看到的。

就像項目Runecoin在發完21000張RSIC銘文NFT後,很快就將父銘文打到了中本聰地址,相當於沒有人能夠再次使用,也就是通過技術手段承諾不做增發。這波操作本身就爲其帶來一大波好評,非常漲路人緣。

PS:什麼是父銘文?因爲在BTC做交互速度慢且gas高昂,所以當操作數量比較大的時候,爲提高效率,一般會先設置一個父銘文,在父銘文的那一次交易裏,直接批量處理多個子銘文,這樣可以在交互的時候,節約區塊鏈的存儲空間和處理時間。

最後說一下Casey提到的CTV,即「Check Template Verify」。

CTV是一個比特幣提議的協議升級,旨在通過允許用戶在創建交易時,指定未來交易的模板,從而增強比特幣網路的智能合約和鎖定功能。CTV的激活將使得用戶能夠創建更復雜的交易類型,例如可信賴的空投和開放式蝕刻,而無需協議的顯式支持。

這個CTV提案增加了比特幣網路的可編程性和靈活性,在這次討論中提到,簡單來說就是可以創建一個使用UTXO的解鎖條件模板,有機會給Runes創造更多玩法。舉個例子,通過「Runes協議+CTV」,可以讓10個用戶聯合使用CTV技術,共同Mint符文,然後預設未來的一些比特幣支付交易的承諾之類。

聲明:

  1. 本文轉載自[極客web3],原文標題《關於Runes協議及“公開銘刻”發行機制的拓展討論》, 著作權歸屬原作者[MiX ],如對轉載有異議,請聯系Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。

Runes協議及“公開銘刻"發行機制

中級4/22/2024, 7:37:07 AM
本文結合Runes的一些最新話題,就Runes與Ordinals協議的過往,以及類似的資產發行方式進行開發性的探索。

轉發原文標題《關於Runes協議及“公開銘刻”發行機制的拓展討論》

2024年3月2日,Runes生態基礎設施項目Rune alpha的創始人,在Github的公開議題中,與Runes協議創始人Casey展開了討論,雙方對如何拓展Runes協議的「公開銘刻」機制進行了探討。話題包括:

·要不要放寬「公開銘刻」不可預留的要求?

·指出了採用「公開銘刻」發行方式的Runes符文不存在管理權的觀點

·提出了一套基於銘文NFT和符文FT互相配合的發行機制設想

出於對比特幣衍生資產協議的濃厚興趣,本文作者結合上述Runes的一些最新話題,寫作了此篇文章,就Runes與Ordinals協議的過往,以及類似的資產發行方式進行開發性的探索,相信能夠對大家了解比特幣生態帶來幫助。

什麼是Runes協議

所謂的Runes協議,是在比特幣網路上發行同質化代幣的協議,由Ordinals創始人Casey在發布Ordinals方案後,又重新構建的同質化代幣方案,基於比特幣UTXO的特性而構建,整體的設計思路非常簡潔。

值得一提的是,Runes協議計劃在比特幣2024年減半時(區塊高度840000),也即是今年四月下旬上線主網。現在Runes協議仍然處於優化和版本迭代的過程中。

在簡要科普Runes的原理前,讓我們先快速了解下來龍去脈,以及所謂的【公開銘刻】到底代表什麼。

Runes的提出者Casey在一開始並沒有要做同質化代幣協議的idea,早在2022年12月時,Casey就發布了Ordinals協議,意圖是將NFT數據永久上鏈Bitcoin,簡單說就是將NFT元數據像銘文一樣,記錄在比特幣交易的見證數據witness中(witness主要包含數字籤名信息),這樣就能夠將任意形式的內容(如文本、圖像等)銘刻在指定的聰上。


(圖片來源:https://yishi.io/a-beginner-guide-to-the-ordinals-protocol/)

隨後,歷史的齒輪開始轉動,2023年3月8日,匿名開發者@domodata基於Ordinals這個典型的NFT發行協議,迂回的搞出一套發行同質化代幣的BRC-20標準,就是以銘文的方式,對那些需要上傳到比特幣鏈上的衍生資產數據,規定出統一的格式和屬性(Token名稱、總供應量、單次最大鑄造量等),再通過索引器去解析並追蹤這些信息,展示出BRC-20代幣相關的錢包帳戶和資產數額。

關鍵來了,BRC-20的發行,要依賴於Ordinals這種比特幣銘文NFT協議,所以在初始的發行機制上變得和NFT鑄造過程類似,天然具備「先到先得」的特性,誰先Mint誰就擁有,完全不同於以太坊ERC-20資產發行時“項目方先部署資產合約,定義資產分配機制,官方想怎麼控盤都可以”。

這種Fair Launch的特性,使得大多數人有了公平參與同質化代幣初始發行的機會,項目方無預留無鎖倉,每個人都可以在資產最初發行的第一時間參與。很快,BRC20就帶來了比特幣鏈上衍生資產的發行熱潮,甚至直接啓動了這輪牛市。由此可知,我們今天重點討論的「公開銘刻」的發行方式,對於Runes協議而言非常重要。

但BRC-20也帶來了很多問題:BRC-20資產的每一次操作,都要在比特幣鏈上發起特定的交易,隨着BRC-20資產的火爆,比特幣UTXO數據集也快速膨脹,這使得BTC核心開發者對BRC-20產生公開質疑。

Ordinals創始人Casey不僅反對BRC-20,更是對基於Ordinals之上發行的FT資產不予認可,但是BRC-20的火爆,讓他覺得雖然99%的代幣都是騙局和噱頭,但這些東西仍會像賭場一樣無法消失。

同時,BRC-20在比特幣鏈上留下了“過多的痕跡”,爲比特幣節點帶來了數據承載上的負擔,但如果有人提出一套,能夠在上鏈數據方面“減負”的資產協議,或許能減緩BRC-20帶來的問題。

所以Casey決定爲比特幣構建一種“更好的同質化代幣協議”,隨後在2023年9月25日,他發布了Runes協議的初步構想。

從技術角度看,Runes協議基於比特幣UTXO和附加信息而構建,每一筆交易的觸發,都要把鏈下生成的數字籤名信息on chain,我們可以在籤名信息中攜帶特定格式的消息。Runes協議通過OP_RETURN操作碼來標記出“特定消息”,這些特定消息就是與Runes資產變更相關的信息。

相比於BRC-20協議,Runes 優勢很多,其中最重要在於:

1.交易步驟簡化,且不會生成多餘的無用UTXO,能更好的爲比特幣節點“減輕負擔”。此外,BRC-20的一筆轉帳交易僅支持一個接收者和一種代幣,而Runes支持同時向多個接收者轉帳,且可轉帳多種Runes代幣。

2.資產數據的存儲與索引更簡潔:BRC-20的數據以JSON格式存儲在特定交易的witness數據中,且BRC-20基於帳戶模型,資產餘額與指定的帳戶相關聯。而Runes協議的數據存儲在特定交易的OP_RETURN字段中,資產的記錄方式採用UTXO模型,可以直接與比特幣鏈上的UTXO“同構綁定”。

在確認一個人的Runes資產狀況時,只需驗證這個人擁有的、與Runes資產相綁定的特殊UTXO,雖然還是要追溯部分信息完成計算,但無需像BRC-20那樣掃描比特幣鏈上的完整UTXO集合,這種輕量化的方式對數據索引更友好。

3.與UTXO功能拓展層兼容:Runes基於UTXO的設計,使其能夠與CKB、Cardano、Fuel等基於UTXO的功能拓展層更好地兼容。通過類似於RGB++的“UTXO同構綁定”,上述功能拓展層可以爲Runes提供智能合約場景。

簡要談完了技術,我們回到本文最開始談論的發行機制的事情。Casey爲Runes符文設計了兩套發行方式,即「固定總量」和「公開銘刻」:

1.固定總量就是發行方直接銘刻所有Runes符文,然後再進行分發,相對更中心化。

2.公開銘刻就是對Runes符文的發行方式設定參數,比如指明一個區塊高度或時間戳,在符合規則的時間段內,用戶Mint了多少資產,最後該符文的總量就是多少。

兩種發行方式對應的場景與機制完全不同,下文中我們只聊「公開銘刻」。

事實上,Sondotpin從Runes的Issues#124議題中,就開始討論此話題,並得到了Casey的認可。

而Issues#165具體內容如下:

Sondotpin:目前的公開發行,項目方/發行方不能提前預留Runes符文,這限制了項目方設計優秀通證經濟模型的機會。

Casey:請查看之前的Issues#124。我正在考慮放寬這個要求,允許發行方在發行時以合理的方式安排符文,甚至超出參數的設定範圍。如果這樣設計,相關信息會在Runes符文的詳情頁做非常突出的展示。

Sondotpin:是不是可以設計一個多次發行的機制,比如能有兩輪「公開銘刻」Runes符文,然後每一輪發行設定不同的參數?

Casey:我並不傾向於這樣的做法,因爲Runes符文本質上並沒有「管理者」。發行的權限不應該掌握在有特別權限的單一實體手上。但是你可以在發行符文的時候添加一個銘文,然後在這個銘文的基礎上再發行新的符文,這樣就可以實現兩次發行的符文都是同一個資產。當然,你也可以採用預挖的方式,然後用其他的分配方式進行發行。

如果未來 CTV 的功能能夠順利啓動,就不需要協議支持了,CTV 直接可以預先設定條件模板,達到條件後就可以做符合條件設置的空投和公開發行。

圍繞Casey和SondotPin的討論,個人看法:

1.在發起項目的早期,預留部分Token確有必要

在早期,項目方想要實現業務的自舉,需要有一定的Token儲備去激勵核心團隊、凝聚社區。如果可以按照本次討論去實現協議,是對「公開銘刻」的公平和全民參與價值的補充,可以讓更多有價值基礎項目方通過「公開銘刻」的方式參與到Runes生態中。

2.是否預留、如何預留,是將自證的手段交給發行方

事實上,Casey曾多次在Youtube視頻裏直言,同質化通證99.9%都是騙局,大家也別冠冕堂皇的說自己要改變世界,坦率地承認這是一個充滿賭博和投機的行業,以誠相待,對所有人都好。IT’S JUST FOR FUN!

是從issue#124到#165,可以看到Casey對同質化通證的使用場景有了更多認可。「公開銘刻」的方式勿需質疑,在此基礎上進行拓展,比如增加預留機制,是將選擇的權利、自證的手段交給發行方,也是防止劣幣驅逐良幣的好方法。

3.銘文NFT和符文FT將會有更多的創新空間

Casey提出的銘文NFT和符文FT互相配合進行多輪次的發行機制設想,相當有趣。背景知識裏我們說到,Ordinals和Runes都是Casey設計的協議,應該算是兩個平行關係協議,但是在Github上都做到Ord這個項目裏,技術上不少交叉和配合,比如共用了同步區塊這類底層邏輯。

當下熱點Runestone和Runecoin等項目,也是銘文和符文互相組合創新。Runecoin的玩兒法是最主流的銘文預挖礦,持有Runecoin發行的RSIC銘文,就會持續不斷的挖出項目的符文,然後4月底Runes協議上線再分配FT。期待未來有更多項目可以推陳出新,帶來更新穎的玩兒法。

4.採用「公開銘刻」發行方式的Runes符文不存在所有權

Casey原文中只表達了「Rune不存在所有權」,但是筆者認爲這應該是特指採用「公開銘刻」發行方式的Runes符文不存在所有權。SondotPin提出的兩輪「公開銘刻」方案,就一定會有一個擁有極高權限的地址的地址來操作,這並不是Crypto加密領域希望看到的。

就像項目Runecoin在發完21000張RSIC銘文NFT後,很快就將父銘文打到了中本聰地址,相當於沒有人能夠再次使用,也就是通過技術手段承諾不做增發。這波操作本身就爲其帶來一大波好評,非常漲路人緣。

PS:什麼是父銘文?因爲在BTC做交互速度慢且gas高昂,所以當操作數量比較大的時候,爲提高效率,一般會先設置一個父銘文,在父銘文的那一次交易裏,直接批量處理多個子銘文,這樣可以在交互的時候,節約區塊鏈的存儲空間和處理時間。

最後說一下Casey提到的CTV,即「Check Template Verify」。

CTV是一個比特幣提議的協議升級,旨在通過允許用戶在創建交易時,指定未來交易的模板,從而增強比特幣網路的智能合約和鎖定功能。CTV的激活將使得用戶能夠創建更復雜的交易類型,例如可信賴的空投和開放式蝕刻,而無需協議的顯式支持。

這個CTV提案增加了比特幣網路的可編程性和靈活性,在這次討論中提到,簡單來說就是可以創建一個使用UTXO的解鎖條件模板,有機會給Runes創造更多玩法。舉個例子,通過「Runes協議+CTV」,可以讓10個用戶聯合使用CTV技術,共同Mint符文,然後預設未來的一些比特幣支付交易的承諾之類。

聲明:

  1. 本文轉載自[極客web3],原文標題《關於Runes協議及“公開銘刻”發行機制的拓展討論》, 著作權歸屬原作者[MiX ],如對轉載有異議,請聯系Gate Learn團隊,團隊會根據相關流程盡速處理。
  2. 免責聲明:本文所表達的觀點和意見僅代表作者個人觀點,不構成任何投資建議。
  3. 文章其他語言版本由Gate Learn團隊翻譯, 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。
Start Now
Sign up and get a
$100
Voucher!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.