對可互換通證（ERC-20 系列）的通證 ERC 的比較

通證標準的現狀

在以太坊平台上，通證標準的現狀出奇的簡單：ERC-20 通證 token 標準是通證介面中唯一被採用（ EIP-20）和接受的通證標準。

它在 2015 年被提出，最終接受是在 2017 年末。

在此期間，提出了許多解決 ERC-20 缺點的 以太坊意見徵集 Ethereum Requests for Comments （ERC），其中的一部分是因為以太坊平台自身變更所導致的，比如，由 EIP-150 修復的 重入 re-entrancy bug。其它 ERC 提出的對 ERC-20 通證模型的強化。這些強化是通過收集大量的以太坊區塊鏈和 ERC-20 通證標準的使用經驗所確定的。ERC-20 通證介面的實際應用產生了新的要求和需要，比如像許可權和操作方面的非功能性需求。

這篇文章將淺顯但完整地對以太坊平台上提出的所有通證（類）的標準進行簡單概述。我將儘可能客觀地去做比較，但不可避免地仍有一些不客觀的地方。

通證標準之母：ERC-20

有成打的 非常好的 關於 ERC-20 的詳細描述，在這裡就不一一列出了。只對在文章中提到的相關核心概念做個比較。

提取模式

用戶不太好理解 ERC-20 介面，尤其是從一個 外部所有者帳戶 externally owned account （EOA）轉賬 通證的模式，即一個終端用戶（「Alice」）到一個智能合約的轉賬，很難正確理解 approve/transferFrom 模式。

從軟體工程師的角度看，這個提取模式非常類似於 好萊塢原則 Hollywood Principle （「不要給我們打電話，我們會給你打電話的！」）。那個調用鏈的想法正好相反：在 ERC-20 通證轉賬中，通證不能調用合約，但是合約可以調用通證上的 transferFrom。

雖然好萊塢原則經常用於去實現 關注點分離 Separation-of-Concerns （SoC），但在以太坊中它是一個安全模式，目的是為了防止通證合約去調用外部合約上的未知的函數。這種行為是非常有必要的，因為會出現 調用深度攻擊 Call Depth Attack ，直到 EIP-150 被啟用才解決。在這個硬分叉之後，這個重入 bug 將不再可能出現了，並且提取模式也不能提供任何比直接通證調用更好的安全性。

但是，為什麼現在它成了一個問題呢？可能是由於某些原因，它的用法設計有些欠佳，但是我們可以通過前端的 DApp 來修復這個問題，對嗎？

因此，我們來看一看，如果一個用戶使用 transfer 去發送一些通證到智能合約會發生什麼事情。Alice 對通證合約的合約地址進行轉賬，

….啊啊啊，它不見了！

是的，通證沒有了。很有可能，沒有任何人再能拿回通證了。但是像 Alice 的這種做法並不鮮見，正如 ERC-223 的發明者 Dexaran 所發現的，大約有 $400.000 的通證（由於 ETH 波動很大，我們只能說很多）是由於用戶意外發送到智能合約中，並因此而丟失。

即便合約開發者是一個非常友好和無私的用戶，他也不能創建一個合約以便將它收到的通證返還給你。因為合約並不會提示這類轉賬，並且事件僅在通證合約上發出。

從軟體工程師的角度來看，那就是 ERC-20 的重大缺點。如果發生一個事件（為簡單起見，我們現在假設以太坊交易是真實事件），對參與的當事人應該有一個提示。但是，這個事件是在通證的智能合約中觸發的，合約接收方是無法知道它的。

目前，還不能做到防止用戶向智能合約發送通證，並且在 ERC-20 通證合約上使用這種不直觀的轉賬將導致這些發送的通證永遠丟失。

帝國反擊戰：ERC-223

第一個嘗試去修復 ERC-20 的問題的提案是 Dexaran 提出來的。這個提議通過將 EOA 和智能合約賬戶做不同的處理的方式來解決這個問題。

強制的策略是去反轉調用鏈（並且使用 EIP-150 解決它現在能做到了），並且在正在接收的智能合約上使用一個預定義的回調（tokenFallback）。如果回調沒有實現，轉賬將失敗（將消耗掉發送方的燃料，這是 ERC-223 最常被批評的一個地方）。

好處：

• 創建一個新介面，有意使用這個廢棄的函數來不遵守 ERC-20
• 允許合約開發者去處理收到的通證（即：接受/拒絕）並因此遵守事件模式
• 用一個交易來代替兩個交易（transfer vs. approve/transferFrom）並且節省了燃料和區域鏈的存儲空間

壞處：

• 如果 tokenFallback 不存在，那麼合約的 fallback 功能將運行，這可能會產生意料之外的副作用
• 假如合約使用通證轉賬功能的話，比如，發送通證到一個特定的像多簽名錢包一樣的賬戶，這將使 ERC-223 通證失敗，它將不能轉移（即它們會丟失）。

程序員修練之道：ERC-677

ERC-667：transferAndCall 通證標準 嘗試將 ERC-20 和 ERC-223 結合起來。這個創意是在 ERC-20 中引入一個 transferAndCall 函數，並保持標準不變。ERC-223 有意不完全向後兼容，由於不再需要 approve/allowance 模式，並因此將它刪除。

ERC-667 的主要目標是向後兼容，為新合約向外部合約轉賬提供一個安全的方法。

好處：

• 容易適用新的通證
• 兼容 ERC-20
• 為 ERC-20 設計的適配器用於安全使用 ERC-20

壞處：

• 不是真正的新方法。只是一個 ERC-20 和 ERC-223 的折衷
• 目前實現 尚未完成

重逢：ERC-777

ERC-777：一個先進的新通證標準，引入它是為了建立一個演進的通證標準，它是吸取了像帶值的 approve() 以及上面提到的將通證發送到合約這樣的錯誤觀念的教訓之後得來的演進後標準。

另外，ERC-777 使用了新標準 ERC-820：使用一個註冊合約的偽內省，它允許為合約註冊元數據以提供一個簡單的內省類型。並考慮到了向後兼容和其它的功能擴展，這些取決於由一個 EIP-820 查找到的地址返回的 ITokenRecipient，和由目標合約實現的函數。

ERC-777 增加了許多使用 ERC-20 通證的經驗，比如，白名單操作者、提供帶 send(…) 的以太兼容的介面，為了向後兼容而使用 ERC-820 去覆蓋和調整功能。

好處：

• 從 ERC-20 的使用經驗上得來的、經過深思熟慮的、進化的通證介面
• 為內省要求 ERC-820 使用新標準，接受了增加的功能
• 白名單操作者非常有用，而且比 approve/allowance 更有必要，它經常是無限的

壞處：

• 剛剛才開始，複雜的依賴合約調用的結構
• 依賴導致出現安全問題的可能性增加：第一個安全問題並不是在 ERC-777 中 確認（並解決的），而是在最新的 ERC-820 中

（純主觀的）結論（輕噴）

目前為止，如果你想遵循 「行業標準」，你只能選擇 ERC-20。它獲得了最廣泛的理解與支持。但是，它還是有缺陷的，最大的一個缺陷是因為非專業用戶設計和規範問題導致的用戶真實地損失金錢的問題。ERC-223 是非常好的，並且在理論上找到了 ERC-20 中這個問題的答案了，它應該被考慮為 ERC-20 的一個很好的替代標準。在一個新通證中實現這兩個介面並不複雜，並且可以降低燃料的使用。

ERC-677 是事件和金錢丟失問題的一個務實的解決方案，但是它並沒能提供足夠多的新方法，以促使它成為一個標準。但是它可能是 ERC-20 2.0 的一個很好的候選者。

ERC-777 是一個更先進的通證標準，它應該成為 ERC-20 的合法繼任者，它提供了以太坊平台所需要的非常好的成熟概念，像白名單操作者，並允許以優雅的方式進行擴展。由於它的複雜性和對其它新標準的依賴，在主鏈上出現第一個 ERC-777 標準的通證還需要些時日。

鏈接

1. 在 ERC-20 中使用 approve/transferFrom 模式的安全問題： https://drive.google.com/file/d/0ByMtMw2hul0EN3NCaVFHSFdxRzA/view
2. ERC-20 中的無事件操作：https://docs.google.com/document/d/1Feh5sP6oQL1-1NHi-X1dbgT3ch2WdhbXRevDN681Jv4
3. ERC-20 的故障及歷史：https://github.com/ethereum/EIPs/issues/223#issuecomment-317979258
4. ERC-20/223 的不同之處：https://ethereum.stackexchange.com/questions/17054/erc20-vs-erc223-list-of-differences

via: http://blockchainers.org/index.php/2018/02/08/token-erc-comparison-for-fungible-tokens/

作者：Alexander Culum 選題：lujun9972 譯者：qhwdw 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive