不得不感慨，“幣圈一天，人間一年” 這句話不是白叫的。web3的創新速度快地驚人。距離Brc-20協議釋出僅兩天之後，就有另外一位Hirosystem的開發者Hugo受其啟發並提出了一個改進版的協議BOP（Bitcoin ordinals protocols,比特幣序數協議)。
該協議同樣也是實驗性質的，brc-20協議的作者對其也表示了認可，並轉發了推文。“改進brc20協議”就像接力棒一樣在一個個開發者手中傳遞下去。（注：Hiro是一個幫助在比特幣二層網路stacks上構建智慧合約的基礎設施）
BOP的由來
Hugo發明BOP協議是基於一次對於brc-20協議的討論，有人提出了質疑，“任何有意義的同質化代幣協議都不應該使用JSON格式”（不清楚brc-20協議格式的，可以檢視《BTC鏈上也能自主發幣了？帶你瞭解brc-20協議》），理由是：“作為底層協議，我們可以銘刻任意位元組，json雖然提高了可讀性，但是同時也增大了銘文的體積，第三方服務讀取資料時，無需考慮協議的可讀性，我們需要一個更加輕量的協議”。於是，Hugo受此啟發，就創作了BOP協議(https://github.com/hugocaillard/bop)。
BOP的協議的格式
作者已經將第一版草案製作成銘文永久刻在了區塊鏈上，編號是#420142
2575466c50a2137ac12b8cfb55e38609018264cbb9b1b0091c56c8992b7d1917i0
當我看到的第一眼，心裡直呼:“好傢伙好傢伙，這是個啥？”，第二眼能看懂但又沒完全看懂，接下來讓我帶大家一步一步拆解這個協議。
#d.0.bft的意思就是宣告一個ID為0，名稱為bft的代幣標準，並且以後使用同樣ID號或者名稱的協議都會被忽略。
從第二行開始就宣告瞭bft協議的發行標準，包括deploy,mint 和 transfer三個方法宣告。
首先來看方法0：deploy
接下來再來看方法1：mint
方法2：transfer
如果有過程式設計經驗的朋友看到這裡肯定會聯想到初學程式設計時的“函式宣告”,函式宣告的意思是給功能起名字和規定引數，方便在程式得其他地方直接呼叫。有了“函式宣告”，那必然就有“函式實現”，呼叫bop協議的過程稱為"Call a BOP",都要以"#c"開頭，接下來我將以作者發行的第一個代幣"idro"作為例子進行講解。
部署idro
#c.0.0,呼叫ID號為0的協議（也就是上面的bft）的第0個方法（即部署方法）
0，idro這個代幣的ID號，其他代幣的ID號會遞增
idro, 代幣名稱
21e12, 代幣總量，一共是 21000000000000個
[[144,2048] ....[1728,1]],表示從部署的區塊開始（區塊高度780310）每隔144個區塊，每次mint的數量減半，從2048開始，差不多每隔一天就會減半。
以下是代幣減產表,可以根據當前的區塊高度算出每次可以mint的最大數量。
鑄造idro
下一步就是大家最關心的如何鑄造的問題，鑄造的程式碼很短，就一行
#c.0.1 呼叫ID號為0的協議（也就是上面的bft）的第1個方法（即鑄造方法）
0，idro這個代幣的ID號
這裡預設了數量，會根據當前區塊高度按照最大的數量鑄造，如果想要指定數量可以在後面新增數量，如一次鑄造10個，"#c.0.1&0,10"
還有兩點特別值得注意：
1.在使用第三方鑄造工具時,如果它是先mint到自己的內建錢包，然後再轉移到你的錢包，代幣的餘額會儲存在工具的錢包中，所以不能使用。
2.如果同一區塊內發生兩個餘額變化事件，則費用較高的優先。因此，每個地址每個塊只能實現 1 個鑄幣操作。所以不能使用同一個錢包批量鑄造
在這裡介紹一下我們國人團隊開發的鑄造工具unisat的使用方法：
輸入網址：https://unisat.io/inscribe 來到主頁，選擇 "Text"
選擇”Single“(單次鑄造，旁邊是批量鑄造)，貼上文字 "#c.0.1&0" ,點選"Next"
貼上自己的Taproot 錢包地址（bc1p開頭），然後選擇合適的費率，推薦使用“Normal”以上。
下拉到付款按鈕，點選 “submit & pay invoice”
最後用你自己的錢包，向指定的地址付相應數量的btc即可。
轉移idro
#c.0.2 呼叫ID號為0的協議（也就是上面的bft）的第2個方法（即轉移方法）
0，idro這個代幣的ID號
100，轉移的代幣數量
將該文字鑄造成銘文之後，並且傳送到要轉移的地址即可。
和ERC20對比
說到代幣標準，那麼不可避免地會提到以太坊上的代幣標準erc20,這是由Fabian Vogelsteller 於2015年11月提出的標準，主要包括名稱、符號、總供給量、賬戶餘額和轉移等方法。
從目前Bop的標準來看，名稱、ID、最大供應量、鑄造和轉移方法都有了，賬戶餘額和轉移代幣都還需要一個鏈上索引器和一個前端來展示，和erc20相比已經初具雛形。
和brc20相比，我覺得該協議標準更像一門程式語言，更具有程式設計性，可擴充套件性和可組合性並且更加輕量化，我覺得這是它的進步。
當然作者也多次強調這是實驗性質的，希望別的開發者可以在此基礎上繼續優化。
總結
整個btc上的同質化代幣協議還處於設想階段，我們沒有辦法確認哪一個協議最終會被認可，但我們能做的是一直跟隨生態的發展，一直到一套完整的解決方案出現。如果還有其他問題，
