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
比較特別的就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
※ 編輯: DarkerDuck (114.27.80.199 臺灣), 12/17/2023 20:48:10
※ 編輯: DarkerDuck (114.27.80.199 臺灣), 12/17/2023 21:13:14
推
12/17 20:54,
4月前
, 1F
12/17 20:54, 1F
推
12/17 20:58,
4月前
, 2F
12/17 20:58, 2F
推
12/17 21:13,
4月前
, 3F
12/17 21:13, 3F
推
12/17 21:19,
4月前
, 4F
12/17 21:19, 4F
推
12/17 21:26,
4月前
, 5F
12/17 21:26, 5F
推
12/17 21:28,
4月前
, 6F
12/17 21:28, 6F
推
12/17 21:53,
4月前
, 7F
12/17 21:53, 7F
推
12/17 22:05,
4月前
, 8F
12/17 22:05, 8F
→
12/17 22:05,
4月前
, 9F
12/17 22:05, 9F
推
12/17 22:17,
4月前
, 10F
12/17 22:17, 10F
→
12/17 22:17,
4月前
, 11F
12/17 22:17, 11F
→
12/17 22:17,
4月前
, 12F
12/17 22:17, 12F
推
12/17 23:20,
4月前
, 13F
12/17 23:20, 13F
推
12/17 23:35,
4月前
, 14F
12/17 23:35, 14F
→
12/17 23:35,
4月前
, 15F
12/17 23:35, 15F
推
12/17 23:36,
4月前
, 16F
12/17 23:36, 16F
推
12/18 00:17,
4月前
, 17F
12/18 00:17, 17F
推
12/18 01:04,
4月前
, 18F
12/18 01:04, 18F
※ 編輯: DarkerDuck (122.121.132.61 臺灣), 12/18/2023 01:11:35
推
12/18 03:05,
4月前
, 19F
12/18 03:05, 19F
推
12/18 05:17,
4月前
, 20F
12/18 05:17, 20F
→
12/18 05:17,
4月前
, 21F
12/18 05:17, 21F
推
12/18 09:54,
4月前
, 22F
12/18 09:54, 22F
推
12/18 10:13,
4月前
, 23F
12/18 10:13, 23F
→
12/18 10:13,
4月前
, 24F
12/18 10:13, 24F
→
12/18 10:13,
4月前
, 25F
12/18 10:13, 25F
推
12/18 10:37,
4月前
, 26F
12/18 10:37, 26F
推
12/18 12:21,
4月前
, 27F
12/18 12:21, 27F
推
12/18 13:06,
4月前
, 28F
12/18 13:06, 28F
推
12/18 13:43,
4月前
, 29F
12/18 13:43, 29F
推
12/19 12:01,
4月前
, 30F
12/19 12:01, 30F
→
12/19 12:09,
4月前
, 31F
12/19 12:09, 31F
推
12/19 12:11,
4月前
, 32F
12/19 12:11, 32F
推
12/19 14:40,
4月前
, 33F
12/19 14:40, 33F
推
12/19 16:38,
4月前
, 34F
12/19 16:38, 34F
推
12/19 19:19,
4月前
, 35F
12/19 19:19, 35F
推
12/19 21:27,
4月前
, 36F
12/19 21:27, 36F
推
12/20 01:40,
4月前
, 37F
12/20 01:40, 37F
推
12/20 10:46,
4月前
, 38F
12/20 10:46, 38F
推
12/20 13:27,
4月前
, 39F
12/20 13:27, 39F
推
12/20 13:40,
4月前
, 40F
12/20 13:40, 40F
推
12/21 02:48,
4月前
, 41F
12/21 02:48, 41F
→
12/21 02:49,
4月前
, 42F
12/21 02:49, 42F
→
12/21 02:51,
4月前
, 43F
12/21 02:51, 43F
→
12/21 02:51,
4月前
, 44F
12/21 02:51, 44F
推
12/21 02:53,
4月前
, 45F
12/21 02:53, 45F
推
12/21 02:58,
4月前
, 46F
12/21 02:58, 46F
推
12/21 10:21,
4月前
, 47F
12/21 10:21, 47F
推
12/21 16:00,
4月前
, 48F
12/21 16:00, 48F
推
12/21 22:06,
4月前
, 49F
12/21 22:06, 49F
→
12/21 22:06,
4月前
, 50F
12/21 22:06, 50F
※ 編輯: DarkerDuck (36.236.242.187 臺灣), 12/22/2023 18:25:37
※ 編輯: DarkerDuck (36.236.167.70 臺灣), 12/22/2023 19:50:47
→
12/24 08:30,
4月前
, 51F
12/24 08:30, 51F
討論串 (同標題文章)
完整討論串 (本文為第 1 之 2 篇)：
