【幣圈術語進階篇Part2 走跳Twitter必備】
這次來介紹更進階的幣圈術語給大家，Twitter 一直都是老韭菜最愛的一個獲取新資訊的管道，但是平常較少接觸英文的讀者可能會看得很頭痛，再加上幣圈有許多專業用語，可能需要一段時間才能適應，所以我們這次整理了一些外國人常用的幣圈術語給大家，如果全部都看懂恭喜你已經晉升為更高等級的老韭菜了 😆

#cryptoacronym

🟡 #SHILL

形容某人無來由的吹捧某個幣，背後實際可能沒有任何價值或是用處，通常被社群視為是負面行為，指讓大家接盤的意思

🟡 #Get Rekt

源自於英式英語，字面上為輸了一切，通常指遇到買了 SCAM 的 ICO、代幣破發或是玩 DeFi 慘遭被駭等事件

🟡 #Big Holder

持有一個正在失去其價值的 token，但不願承認其錯誤出售該 token 的加密貨幣投資者

👀 V神曾說過，Coinmarketcap 上 90% 的 ERC20 token 完全沒用

🟡 Weak Hands

形容現貨握不住，常常因為消息受影響頻繁進出市場的人，通常指缺乏紀律或是策略操作的散戶投資者

🟡 Diamond Hands

鑽石手，與 weak hands 完全相反，意指對該 token 極為有信心的投資人，就算被套牢也在所不惜（？），直到達成目標價才甘願出場
-------------------------------------------------------------
🥳Avalanche 香港交流群上線了！🥳
想知道AVAX最新空投幣、AMA等市場動態及最新優惠？立刻加入 Avalanche 香港交流群，與一眾用家互相討論見解，Desmond也會不定期在這裡優先分享DeFi生態的項目分析，不想錯過的話就按這裡加入
👉🏻https://bit.ly/3hksa7z

【Bybit 獨家開戶優惠🎉】
新用戶幣研獨家優惠，只要充值1000USDT即可獲取高達125 USD體驗金（優惠碼【21515】）
註冊及入金教學👉🏻：https://bit.ly/3DPMY0e

「每日幣研｜幣市分析&最新優惠」TG Channel 🔍
想了解更多加密貨幣最新市場資訊及優惠的話，歡迎追蹤我們「每日幣研｜幣市分析&最新優惠」TG Channel，我們會在群內發佈幣圈第一手消息及分享投資小技巧！馬上加入頻道和我們一起發掘幣圈隱藏商機吧！
立即加入頻道👉🏻：https://bit.ly/2YzVK2p

📜 [專欄新文章] 給忙碌人的 EIP1559 簡史

✍️ Ping Chen

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

以太坊倫敦升級將大幅改變交易手續費的收取方式

1. 要解決的問題

交易手續費競爭

目前包括比特幣、以太坊在內的區塊鏈都有效能的限制，比特幣的 TPS（每秒交易數）是 7，以太坊大約是 15，而一旦待處理的交易數量超過區塊鏈的處理上限，負責產出區塊的驗證者（礦工）就會從中選擇手續費高的交易打包，讓「誰的交易先被處理」的問題交由市場機制解決。

這樣的設計乍看之下合理，卻會對日常使用者造成額外的認知負擔。

礦池直接告訴你目前待處理交易的手續費分佈，加深使用者的焦慮

一般來說，當我們送交易的時候都是希望越快被處理越好，但是付的錢要越少越好，所以這時候出價的策略就會變成「先看看別人都出多少」，再用略高一點點的價格贏過別人。這件事會要求使用者去「預測」區塊鏈的擁擠程度，才能用最少的錢擠進下一個區塊，徒增困擾。而且當很多人都急著發交易的時候，手續費會被無情的推高，直到多數人付不起為止，而這些爆高的手續費進到礦工口袋，在利益分配上也不是最佳的。

區塊資源缺乏彈性

另一個 EIP1559 想要解決的問題是區塊鏈資源的尖離峰調度。

手續費有明顯的尖峰時段

目前，每一個區塊能夠塞的交易量是固定的，但使用的需求卻會有高低起伏，通常是週間比週末多，亞洲時間的晚上到深夜又比白天多。偶爾也會出現像 ICO 或 NFT 發售之類的突發需求，短時間內大幅推高手續費到非常誇張的境界，對於不願意出那麼高價的使用者而言，相當於區塊鏈暫時癱瘓。

2. 解決方案的演進

第二價格拍賣

原本的交易手續費是你出多少就會被收多少（第一價格拍賣），所以導致大家要處心積慮的選出一個不高不低的數字。如果換成第二價格拍賣法，也就是「不論原始出價多少，同一個區塊內的交易，統一收取相同的費用」，手續費由這批交易中的最低價者決定。這樣一來，使用者不用多想，只要出自己真正願意付的最高價就好，反正超過最低價的部分會被退回。

燒毀手續費

然而，第二價格拍賣有個明顯的漏洞，那就是會被礦工操縱。當礦工由高到低排好了要打包的交易之後，他可以把出價最低的幾筆交易換掉，故意自己製造一些高手續費的無用交易，反正手續費最後都會回到礦工身上，而且墊高最低手續費後，排在前面的交易也要付更多錢給礦工，礦工賺。

https://vitalik.ca/files/misc_files/EIP_1559_Fee_Structure.pdf

為了解決礦工操縱手續費的問題，最乾脆的解法就是這筆錢誰也不要拿了，交易手續費通通燒掉！礦工用自己的錢去墊高手續費只會虧更多。

系統手續費 + 小費

EIP1559 最後定了一個有趣的方案：系統根據需求自動調整手續費。

首先把原本的區塊大小上限變成目標的兩倍，如果希望一個區塊用掉 15,000,000 gas，就把上限設成 30,000,000 gas。礦工還是可以盡情塞滿區塊，但是這個區塊的滿溢程度會決定下一個區塊的系統手續費，每個區塊可以有正負 12.5% 的手續費調整。

舉例來說，如果系統手續費原本是 20 Gwei，區塊剛好裝到半滿的 15M gas，下個區塊的系統手續費就保持 20 Gwei；如果這個區塊是空的，下次的手續費降到 17.5 Gwei；如果這個區塊塞滿 30M gas，下個區塊的手續費提升到 22.5 Gwei。

新系統的設計立意和第二價格拍賣的市場供需決定論類似，但是很大程度的降低了礦工操弄的空間，而且讓整個區塊鏈對突發的高需求有更多彈性去應付，系統可以暫時以兩倍速處理交易，雖然會快速墊高手續費，但是等到離峰時段自然會慢慢降下來，等於是跟未來「借」了一些容量來用。

不過如果遇到像是 NFT 開賣這種瞬間壅塞的情況，兩倍的空間可能還是不夠用，而且每個區塊 12.5% 的手續費漲幅也許不足以熄滅買家的熱情，所以 EIP1559 還是保留了「小費」，也就是給礦工塞錢的機制，讓你在極端狀況時還是可以靠買通礦工來加速交易。

3. 社群反應

礦工好生氣好生氣

這搞不好是開發者們意料之外的發展也說不定。

以太坊核心開發者和礦工起爭議也不是第一次，包括之前降低區塊獎勵，以及取消 ProgPoW 升級都曾讓礦工揚言搞事。而且在可見的未來，PoS 也會讓礦工徹底失業。相較之下，這次只是拔掉手續費收入，礦工理論上應該已經習慣逆來順受了才對。

但恰好 2020 年適逢 DeFi 流動性挖礦起飛，交易需求飆高，經常有破百甚至好幾百的手續費持續很久，讓礦工的收入結構的手續費佔比從本來的 5–10% 忽然升高到幾乎跟區塊獎勵 1:1，甚至超過，這時後說要燒掉手續費收入，礦工當然就非常有感覺了。

崩潰的礦工開始在社群上各種哭鬧，一下說開發者搶錢，一下說這樣會破壞區塊鏈的安全性（實際上相反，高手續費佔比會導致區塊重組），與礦池友好的區塊鏈專欄作家也在此事上無情批判提出 EIP1559 的人的經濟學應該要當掉重修云云，最後大礦池們甚至再度連署號召硬分叉頑抗到底。

不過勒，現在以太坊上有超防叉的 DeFi，信標鏈又已經在跑，PoS 也是隨時準備上線的狀態…

礦工想搞分叉？ ¯\_(ツ)_/¯

通縮迷因

另一個有趣的戰場在以太坊的 Twitter 意見領袖群。

過去，當比特幣和以太坊社群互酸互嘴的時候，以太幣沒有發行量上限這件事常常被比特幣擁護者調侃，說你有智慧合約有 DeFi 又怎樣，這種亂印鈔通膨的幣根本比不上有總量限制的數位黃金比特幣。

但現在情況不同了，EIP1559 看起來似乎能改變以太幣的發行趨勢，如果每次交易都會燒幣，那豈不是要比總量固定更讚，直接變成會通縮的超稀缺資源嗎？如果比特幣是 sound money（健全的貨幣），那改版後的以太幣根本就是 ultra sound money（超音波…貨幣？）了呀。

於是這些以太坊的網紅公知，像是 Bankless 的兩個創辦人和 EthHub 的兩個創辦人，你可以簡單理解為區塊鏈世界的朱學恆或周玉蔻吧，便開始帶起這個吹捧通縮迷因的風潮，在名字旁邊放上蝙蝠和聲音的 emoji(🦇🔊)，說以太幣這下肯定要起飛啦，又 DeFi 又 2.0 又通縮，市值遲早超越比特幣。

不過呢，EIP1559 實際上並沒有保證通縮，交易手續費是會被銷毀沒錯，但區塊獎勵還是會印出新的幣，有可能多也有可能少。長期而言，最穩定的情況應該是在通膨和通縮間擺盪才對。

有些腦袋清醒的人選擇不隨通縮迷因起舞，比方說 MyCrypto 的創辦人就跳出來力戰群雄，勸那些網紅收斂一點，以太坊本來就很好，不需要用誤導性的說詞。另一邊，開發者社群倒是沒什麼聲音，可能幣價和跟比特幣輸贏本來就不是關心的重點，有 EIP 狂粉幫忙在氣勢上壓制礦工也不錯，他們更在乎測試鏈運作的狀況，以及專心為主鏈升級做好準備。

4. EIP1559 實際影響

以太幣會不會漲

不知道。

0 gas 交易死去

原本在 Flashbot 和 ArcherDAO 的研究之下，有幾個用 MEV searcher 發免手續費交易的方案出現，概念上就是你發交易的時候 gas 欄位填 0，但是在合約執行期間直接送錢到礦工地址（block.coinbase），藉此讓沒有以太幣但是有 ERC20 token 的錢包也能發交易。

這個做法升級後將變得不可行，因為 0 gas 會違反系統強制收手續費燒掉的限制，只能暫時退回比較原始的 meta transaction relayer，也許等未來帳號抽象的方案做出來再看有沒有機會了。

手續費設置自動化

這應該才是 EIP1559 的本意，升級後，使用者發送交易不太需要再觀察區塊鏈 mempool 的狀況，只要參考上個區塊的手續費再多加一點，就有很高的機率會在下幾個區塊被執行。不過對於那些想要設得比目前市價更低、願意慢慢等來省錢的人來說，交易打包的時間還是要看運氣就是了。

給忙碌人的 EIP1559 簡史 was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

📜 [專欄新文章] Optimistic Rollup 就這樣用（2）

✍️ Juin Chiu

📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

ERC721 的儲值、轉移與提領

TL;DR

本文會跳過 Optimistic Rollup 的介紹而直接實際演示，關於 Optimistic Rollup 的概念與設計原理筆者將在日後另撰文說明，有興趣的讀者可以先參考下列三篇文章（由淺入深）：1. OVM Deep Dive 2. (Almost) Everything you need to know about Optimistic Rollup 3. How does Optimism’s Rollup really work?

本文將演示一個 Optimism Rollup 的 ERC721 範例，程式碼在這裡。

本演示大量參考了以下範例：Optimistic Rollup Example: ERC20。

本演示所使用的 ERC721 Gateway 合約來自這個提案，目前尚未成為官方標準。

環境設置

Git

Node.js

Yarn

Docker

Docker-compose

筆者沒有碰到環境相容問題，但是建議都升到最新版本， Node.js 使用 v16.1.0 或以上版本

Optimism 服務啟動

有關 Optimisim 的所有服務，都包裝在 Optimism 這個超大專案當中了，直接使用原始碼進行組建：

$ git clone git@github.com:ethereum-optimism/optimism.git$ cd optimism$ yarn$ yarn build

組建完成後，就可以在本機啟動服務了：

$ cd ops$ docker-compose build$ docker-compose up

這個指令會啟動數個服務，包括：

L1 Ethereum Node (EVM)

L2 Ethereum Node (OVM)

Batch Submitter

Data Transport Layer

Deployer

Relayer

Verifier

Deployer 服務中的一個參數要特別注意： FRAUD_PROOF_WINDOW_SECONDS，這個就是 OPtimistic Rollup 的挑戰期，代表使用者出金（Withdraw）需等候的時長。在本篇演示中預設為 0 秒。

如果有需要重啟，記得把整個 Docker Volume 也清乾淨，例如： docker-compose down -v

Optimism 整合測試

在繼續接下來的演示之前，我們需要先確認 Optimism 是否有順利啟動，特別是 Relayer 是否運作正常，因此我們需要先進行整合測試：

$ cd optimism/integration-tests$ yarn build:integration$ yarn test:integration

確保 L1 <--> L2 Communication 相關測試通過後再繼續執行接下來的演示內容。

啟動服務及部署合約需要花費一些時間，運行一段時間（約 120 秒）之後再執行測試，如果測試結果全部皆為 Fail，可能是 Optimism 尚未啟動完成，再等待一段時間即可。

ERC721 合約部署

Optimism 啟動成功並且完成整合測試後，接下來進行 ERC721 合約的部署。筆者已將合約及部署腳本放在 optimistic-rollup-example-erc721 這個專案中：

$ git clone git@github.com:ethereum-optimism/optimistic-rollup-example-erc721.git$ cd optimistic-rollup-example-erc721$ yarn install$ yarn compile

接下來我們需要部署以下合約：

ERC721，部署於 L1

L2DepositedEERC721，部署於 L2

OVM_L1ERC721Gateway，部署於 L1

OVM_L1ERC721Gateway 只部署在 L1 上，顧名思義它就是 L1 <=> L2 的「門戶」，提供 Deposit / Withdraw 兩個基本功能，使用者必須透過這個合約來進出 L2。

雖然 OVM_L1ERC20Gateway 是 Optimistic Rollup 官方提供的合約。但是開發者也可以依需求自行設計自己的「門戶」。

OVM_L1ERC20Gateway 目前沒有 Optimism 的官方實作，本演示所使用的 ERC721 Gateway 合約來自這個提案，目前尚未成為官方標準。

接下來，我們直接用腳本進行部署：

$ node ./deploy.jsDeploying L1 ERC721...L1 ERC2721 Contract Address: 0xFD471836031dc5108809D173A067e8486B9047A3Deploying L2 ERC721...L2 ERC721 Contract Address: 0x09635F643e140090A9A8Dcd712eD6285858ceBefDeploying L1 ERC721 Gateway...L1 ERC721 Gateway Contract Address: 0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547ccInitializing L2 ERC721...

ERC721 鑄造、儲值、轉移與提領

鑄造（L1）

初始狀態如下，所有帳戶皆尚未持有任何代幣：

接下來，我們將鑄造 2 個代幣以進行接下來的演示。首先，進入 ETH（L1） 的 Console：

$ npx hardhat console --network ethWelcome to Node.js v16.1.0.Type ".help" for more information.>

取得 Deployer / User 帳戶：

// In Hardhat ETH Console

> let accounts = await ethers.getSigners()

> let deployer = accounts[0]

> let user = accounts[1]

取得 ERC721 及 OVM_L1ERC721Gateway 合約物件，合約地址可以從部署訊息中取得：

// In Hardhat ETH Console

> let ERC721_abi = await artifacts.readArtifact("ExampleToken").then(c => c.abi)

> let ERC721 = new ethers.Contract("0xFD471836031dc5108809D173A067e8486B9047A3", ERC721_abi)

> let Gateway_abi = await artifacts.readArtifact("OVM_L1ERC721Gateway").then(c => c.abi)

> let Gateway = new ethers.Contract("0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", Gateway_abi)

鑄造兩個 ERC721 代幣：

// In Hardhat ETH Console

> await ERC721.connect(deployer).mintToken(deployer.address, "foo")

{ hash: "...", ...}

> await ERC721.connect(deployer).mintToken(deployer.address, "bar")

{ hash: "...", ...}

只有合約的 Owner（deployer） 可以進行鑄造的操作。

確認 Deployer 餘額：

> await ERC721.connect(deployer).balanceOf(deployer.address)

BigNumber { _hex: '0x02', _isBigNumber: true } // 2

確認代幣的 TokenID 與 Owner：

> await ERC721.connect(deployer).ownerOf(1)

'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer

> await ERC721.connect(deployer).ownerOf(2)

'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer

儲值（L1 => L2）

完成以上步驟後，目前的狀態如下：

接下來，授權 OVM_L1ERC721Gateway使用 TokenID 為 2 的代幣：

// In Hardhat ETH Console

> await ERC721.connect(deployer).approve("0xcbEAF3BDe82155F56486Fb5a1072cb8baAf547cc", 2)

{ hash: "...", ...}

在 OVM_L1ERC721Gateway 合約呼叫 Deposit，儲值 TokenID 為 2 的代幣：

// In Hardhat ETH Console

> await Gateway.connect(deployer).deposit(2)

{ hash: "...", ...}

我們可以到 Optimism (L2) 的 Console 確認入金是否成功：

$ npx hardhat console --network optimismWelcome to Node.js v16.1.0.Type ".help" for more information.>

取得 Deployer / User 帳戶：

// In Hardhat Optimism Console

> let accounts = await ethers.getSigners()

> let deployer = accounts[0]

> let user = accounts[1]

取得 L2DepositedERC721 合約物件，合約地址可以從部署訊息中取得：

// In Hardhat Optimism Console

> let L2ERC721_abi = await artifacts.readArtifact("OVM_L2DepositedERC721").then(c => c.abi)

> let L2DepositedERC721 = new ethers.Contract("0x09635F643e140090A9A8Dcd712eD6285858ceBef", L2ERC721_abi)

確認入金是否成功：

// In Hardhat Optimism Console

> await L2DepositedERC721.connect(deployer).balanceOf(deployer.address)

BigNumber { _hex: '0x01', _isBigNumber: true } // 1

> await L2DepositedERC721.connect(deployer).ownerOf(2)

'0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266' // deployer

ERC721 轉移（L2 <=> L2）

完成以上步驟後，目前的狀態如下：

接下來，我們在 L2 從 Deployer 轉移代幣給 User：

// In Hardhat Optimism Console

> await L2DepositedERC721.connect(user).balanceOf(user.address)

BigNumber { _hex: '0x00', _isBigNumber: true } // 0

> await L2DepositedERC721.connect(deployer).transferFrom(depoyer.address, user.address, 2)

{ hash: "..." ...}

> await L2DepositedERC721.connect(user).balanceOf(user.address)

BigNumber { _hex: '0x01', _isBigNumber: true } // 1

> await L2DepositedERC721.connect(user).ownerOf(2)

'0x70997970C51812dc3A010C7d01b50e0d17dc79C8' // user

ERC721 提領（L2 => L1）

完成以上步驟後，目前的狀態如下：

接下來，我們用 User 帳戶提領資金，在 L2DepositedERC721 合約呼叫 Withdraw：

// In Hardhat Optimism Console

> await L2DepositedERC721.connect(user).withdraw(2)

{ hash: "..." ...}

> await L2DepositedERC721.connect(user).balanceOf(user.address)

BigNumber { _hex: '0x00', _isBigNumber: true }

最後，檢查在 L1 是否提領成功：

// In Hardhat ETH Console

> await ERC721.connect(user).balanceOf(user.address)

BigNumber { _hex: '0x01', _isBigNumber: true } // 1

> await ERC721.connect(deployer).balanceOf(deployer.address)

BigNumber { _hex: '0x01', _isBigNumber: true } // 1

> await ERC721.connect(user).ownerOf(2)

'0x70997970C51812dc3A010C7d01b50e0d17dc79C8' // user

由於挑戰期為 0 秒，因此提領幾乎無需等待時間，頂多只需數秒鐘

做完上述所有操作，最終狀態應該如下：

總結

本文演示了：

Optimistic Rollup 相關服務的本機部署

ERC721 L1 => L2 的儲值（Deposit）

ERC721 L2 帳戶之間轉移（Transfer）

ERC721 L2 => L1 的提領（Withdraw）

筆者未來將繼續擴充此系列的教學內容，例如支援其他標準的合約如 ERC1155，以及如何運行 Optimistic Rollup 生態系中最重要的驗證者（Verifier），敬請期待。

參考資料

OVM Deep Dive

(Almost) Everything you need to know about Optimistic Rollup

How does Optimism’s Rollup really work?

Optimistic Rollup Official Documentation

Ethers Documentation (v5)

Optimistic Rollup Example: ERC20(Github)

Optimism (Github)

optimism-tutorial (Github)

l1-l2-deposit-withdrawal (Github)

Proof-of-concept ERC721 Bridge Implementation (Github)

Optimistic Rollup 就這樣用（2） was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌