Re: [Coin] 銘文Token合約

很久沒發技術文了，因為這波就是沒什麼新技術啊，meme幣整天博傻，動物園都快蓋好了。 就算是最近被吹上天的BRC-20講的好像BTC的Defi summer， https://www.blocktempo.com/is-the-bitcoin-ecosystem-unable-to-replicate 但實際上類似的東西，10年前的BTC在還未有ETH生態系就玩過了。 mastercoin可以玩代幣，counterparty還可以玩智能合約咧。 BCH之前也早就玩過SLP token了，USDT甚至有在SLP上發行咧。 https://i.imgur.com/g9zbGoe.png https://tether.to/en/transparency/#usdt 但這種代幣玩法實際上就是劣化版的ERC-20，更不用談什麼defi summer了。 既然原PO講到了，就來講一下技術上BRC-20與ERC-20上的不同。 ERC-20是由圖靈完備的EVM所執行的程式語言代幣標準，EVM是由礦工執行與驗證的。 所以ERC-20上的mint, transferFrom等方法當然都是由礦工執行與驗證的。 而且因為最新的state都是已經和智能合約儲存在區塊鏈上了。 所以所有的代幣參與者都可以從區塊鏈上取得最新的"共識"。 整個交易安全都是由區塊鏈確保的，因為礦工已經幫忙驗證過了，所以不用重新驗證。 更重要的因為是由EVM所執行的，所以自訂化程度很高，也可以和後續的DeFi相容。 像是DEX交易，staking，AMM等DeFi玩法，要更詳細的資訊可以看下面文章。 https://www.toptal.com/ethereum/create-erc20-token-tutorial 而BTC並不支援圖零完備智能合約， 所以從以前到現在的玩法就是把BTC的區塊鏈當作資料庫使用。 以前用OP_return可以在BTC上寫入額外的資料， 不過Luke等開發者不想讓BTC太好用就限縮了OP_return的使用，免得spam attack https://www.panewslab.com/zh_hk/sqarticledetails/4nl41tx7aw2u.html https://i.imgur.com/pwzLSUN.png 直到Bitcoin Core用萬能的soft-fork完成了taproot升級。 被人發現taproot有bug，不~~是feature。可以用taproot程式碼繞過交易大小限制。 可以把整個區塊用taproot交易的程式碼區段塞滿滿，當然也就可以塞資料進去 https://web3plus.bnext.com.tw/article/271? https://i.imgur.com/WronFGn.png 這種方式就是ordinal協議，可以在區塊鏈上附加任何資訊，既然可以加上圖片。 那當然也可以也可以附加純文字檔。 就有人想到程式語言的通用資料格式json用來附加交易資訊。這時BRC-20就誕生了。 https://domo-2.gitbook.io/brc-20-experiment/ https://i.imgur.com/KWsUieG.png 譬如創建一個BRC-20代幣ORDI就是上面那個json指令。把各個欄位定義好就行。 https://i.imgur.com/rFibDxB.png 其他的操作也是簡單到有點簡陋了。 https://i.imgur.com/yEw1kYd.png https://i.imgur.com/owNLKej.png 比較特別的就transfer是直接用UTXO機制，ordinal的UTXO跑到哪邊就是誰的， 所以只需要填數量就好。 那為什麼說這其實是劣化版的ERC-20呢？ 因為上面的這些操作指令"礦工不驗證"，所以其實可以亂寫都沒差。 譬如說我只有1 ORDI，但是我transfer寫我傳1000 ORDI都可以被"礦工確認"。 所以就需要靠額外的index server去"驗證"那些BRC-20交易是"真的有效"。 這問題就導致了中心化index server的產生， 一般人只能去"相信"這些index server是誠實不作惡的。而非trustless。 就算server誠實，但這也會是安全性的single point of failure。 要入侵單一server比入侵整個區塊鏈網路簡單太多了。 https://twitter.com/0xmetazen/status/1723734111704244487 另外一個問題就是這些index server會變成整個系統的效能瓶頸。 這問題以前在BCH SLP上就發生過了，index server常常會overload或是離線。 那就不要只跑一個index server，去中心化跑很多個就好了啊~~~ 然後你又會得到一個新問題，可憐啊~~ https://abmedia.io/asset-security-brc-20-version-discrepancy https://abmedia.io/what-are-the-security-risks-from-inadequate-brc-20 這本身已經是劣化版的ERC-20在劣化的區塊鏈BTC上，問題只會更嚴重。 永恆牛市需要永恆mempool https://jochen-hoenicke.de/queue/#BTC,24h,weight https://i.imgur.com/EgTYcBV.png 然後就有這種玩法： https://news.cnyes.com/news/id/5412431 https://twitter.com/evilcos/status/1735685957662441563 用低BTC手續費卡住mempool，漲價了就用tailTodd發明的RBF加速交易。 跌價了就ToTheMempool，等它自然被踢出mempool就好。 也難怪Luke把這東西當作bug，還寫到CVE list裡面了。 https://tinyurl.com/brjms38t https://i.imgur.com/pwzLSUN.png 因為這種做法問題實際上很多。 所以BCH後來就用CashToken這種礦工驗證的代幣標準來取代SLP標準了。 回到正題，假如真的要用ETH智能合約寫BRC-20這種玩法可以怎麼寫呢? 首先當然就是摒棄ERC-20標準，因為ERC-20標準裡的方法與資料結構都是礦工驗證的。 我們只需要把區塊鏈當作資料庫使用就好。 下面就隨便寫一個把智能合約當作字串資料庫的程式碼， 沒經過任何驗證檢查，只是要方便講概念。 pragma solidity ^0.8.0; contract LongStringArray { string[] public strings; function write(string memory newString) public { strings.push(newString); } function read() public view returns (string[] memory) { return strings; } } 有最簡單write和read function可以讀寫這個字串資料庫。 所以只要用write(newString)寫入BRC-20標準的json字串進去理論上就可以使用了。 index server則是用read去讀這個字串陣列資料庫去驗證交易並且得出所有餘額。 不過BRC-20有些操作必須改一下，就是因為ETH等EVM鏈是account模式。 所以mint與transfer的操作必須加上地址欄位。 可以額外寫這些function， 讓合約操作者方便呼叫這些function就可以把這些json格式的指令寫入到strings中。 後面就不寫了，在EVM鏈上做這種事情真的是沒有意義的事情。 有興趣的人自己研究吧。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.27.80.199 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/DigiCurrency/M.1702815946.A.F8D.html