ERC-777是一種新的代幣合約標準，解決了 ERC-20 的一些安全問題，可以讓合約創建者、代幣持有者和受眾在無需更改代幣合約的情況下擴展其功能。ERC-777 從 ERC-20 和 ERC-223 等標準處汲取了很多想法，并在此基礎上發展成為新一代標準，為開發者和用戶提供了很多強大的特性。

本文主要介紹了代幣合約，并講解了 ERC-777 代幣合約的特性、功能和用途。請注意，本文不涉及 ERC-20 。如果你想了解關于 ERC-20 代幣合約的信息，可以看看另一篇文章（編者注：中譯本見文末超鏈接《理解ERC-20 token合約》）。

什么是代幣合約？

代幣合約指的是一個包含了一組賬戶地址及其對應余額的智能合約，如下圖所示。余額表示由合約創建者定義的一種價值：代幣合約可以使用余額來表示實物、幣值或持幣者的聲譽。一個單位的余額就是我們通常所說的代幣。

需要注意的是，一個最終用戶可能會擁有任意多個地址。造成這種情況的原因有很多，例如，用戶想把自己所持有的代幣分散到不同的邏輯賬戶（儲蓄、稅務、開支等）中，或使用不同的賬戶來代表不同的來源（ICO、投資、服務費支付等）。

每當代幣從一個賬戶轉移到另一個賬戶，代幣合約就會更新這兩個賬戶的余額。例如，從 0x2299…3ab7 向 0x1f59…3492 轉移 10 個代幣之后，余額更新情況如下表所示：

可以通過鑄成新的代幣來增加其總供應量（通常是代幣合約所有者的功能）。例如，在 0x4ba5..ae22 中鑄成 100 個代幣，則余額的更新情況如下表所示：

代幣的總供給量可以通過銷毀已有代幣來減少（如果合約允許的話，任何代幣持有者都可以銷毀代幣）。例如，0x4919…413d 銷毀了 50 個代幣之后，余額的變化情況如下表所示：

簡單的代幣合約會將上述信息保存在地址與余額的映射表中。如果是在更復雜的場景下，如分紅等，通常會另外采用更加強大的結構。然而，無論具體的實現細節如何，代幣余額情況始終如上文的圖表所示。

ERC-777 代幣合約的運營者

ERC-777 代幣合約引入了 運營者 的概念。運營者是代表代幣持有者進行操作的第三方，可以將代幣從持有者的地址轉移出來。請注意，由于運營者擁有很大權力，應該謹慎添加。

每個地址都包含一個經授權的運營者列表，如上表所示：

如上表所示，代幣持有地址 0x1f59…3492 擁有兩個運營者，其他兩個地址各自擁有一個運營者。當然了，沒有運營者的地址也是有效的。

使用運營者的一個簡單例子是，用戶在多個地址代幣上都有代幣，必須分別管理這些地址。在一般情況下，在將代幣從一個地址發送到另一個地址之前，要先確保發送者的地址內有一筆 ETH ，足以用來支付 gas 費用。因此，在將 ETH 從一個賬戶發送到另一個賬戶之時，發送者需要先完成幾個交易，如下圖所示：

如上圖所示，地址 0x93f1…1b09 先向地址 0x1f59…3492 發送 ETH ，等待該交易完成后，地址 0x1f59…3492 向 0x4ba5…ae22 發送代幣。如此繁多的步驟既降低了用戶體驗，又加大了網絡負載量。

有了運營者之后，只要一個賬戶里有 ETH ，其他賬戶里有其他代幣，即可由持有 ETH 的賬戶進行代幣轉賬。接著上一個例子往下看，如果把 0x93f1…1b09 作為 0x1f59…3492 的運營者，那么由 0x1f59…3492 向 0x4ba5…ae22 發送代幣的過程就可以簡化為：

這就大大降低了用戶的負擔。此外，這可以讓用戶在通過一個運營者賬戶控制 ETH 資金的同時，確保其代幣分散于多個持幣賬戶之中。

運營者也有可能是合約的形式（即 “代幣運營者合約”），而且在代幣合約創建的時候就可以為所有持幣者預先定義好代幣運營者合約。這樣一來，運營者可以為所有持幣用戶提供服務，同時其功能又被限制在智能合約的功能范圍內，代幣合約就可以不費吹灰之力地為持有者提供更多功能。后文將詳細闡述代幣合約運營者擁有哪些權力。

ERC-777 代幣合約的定義

每個部署到以太坊上的 ERC-777 代幣合約都會被分配一個地址，即代幣地址。這個代幣合約將會包含一些定義合約操作的參數。

首先要理解的是，由于代幣合約缺少一個中心化的注冊表，無法保證名稱或符號具有唯一性。這樣一來，獲得并保有唯一身份的最佳方法就是公開你的代幣合約。一旦你創建了一個代幣合約，就應該把它添加到一些常用網站上，如 Etherscan、MyEtherWallet、MyCrypto 和 CoinMarketCap 等等，不過要確保遵守每個網站的要求，這樣你的提交得到接受的可能性才最大。

代幣合約的 name 就是用來指代合約本身的長名稱，例如 “My token”。名稱的長度并沒有限制，但是一些錢包應用可能會將過長的名稱截短，因此要將名稱的長度控制在較短的范圍內。

代幣合約的 symbol 就是用來指代合約本身的短符號，例如 “MYT”。這個符號跟股票代碼差不多，雖然沒有長度限制，但是通常都在 3 至 4 個字符左右。

Solidity（以太坊主要使用的編程語言）不支持小數，但是可分割性對于代幣來說是一個常見需求。ERC-777 采用的解決方案是，所有代幣的內部所示數額均使用其實際數額的 1018 整數倍來表示。例如，終端用戶看到的 1.2345 代幣其實在內部是用 1.2345×1018 來表示的。這樣一來，即使一個代幣被分割成了 0.000000000000000001 ，在內部也依舊是以整數表示的，如下表所示：

一些代幣合約的創建者可能不想讓他們的代幣分割得這么細。例如，有一名用戶創建了一個軟件許可證代幣合約，他可能不想看見一個完整的許可證被分割的情況。又或者，有一名用戶創建了一個黃金代幣合約，用 1 token 代表 1 Kg 黃金，他可能想將轉賬金額限制在 0.01 Kg 及以上。

代幣合約的 granularity（粒度） 是代幣內部所示數額的最小可分割單位。緊接著上面的例子，許可證代幣的粒度應當是 1018 （因為 1018/ 1018 = 1），而黃金代幣的 粒度應當是 1016（因為 1016/1018 = 0.01）。

可以預期的是，絕大多數代幣合約的粒度都是 1 ，也就是說，這個代幣可以被分割成 1/1018 ，或是 0.000000000000000001 。根據上面給出的例子，如果對代幣的可分割性有具體要求，可以選擇不同的粒度。

不妨來探究一下 ERC-777 的粒度和 ERC-20 的小數之間的區別。雖然二者的都可以實現代幣的可分割性，ERC-20 是基于具體的值來移動小數點的位置，而 ERC-777 的小數點位置是固定的。這樣一來，ERC-777 代幣的值就更容易在用戶界面上顯示，因為小數點的位置始終是固定的，只是去掉了后面一連串的 0 。

ERC-777 代幣合約的功能

ERC-777 代幣合約具有很多功能，可以讓用戶查找賬戶余額，并且在不同條件下將代幣從一個賬戶轉到另一個賬戶上。這些函數的詳情如下。

totalSupply（）函數說明了所有地址持有的代幣總量。如果有新的代幣被鑄造出來，這個值就會增加，如果已有的代幣被銷毀，這個值就會減少。

balanceOf（） 函數說明了特定地址所持有的代幣數量。要注意的是，任何人都可以詢問任意地址的余額，因為區塊鏈上的所有數據都是公開的。

send（）函數將一定數量的代幣從信息發送方的地址轉到另一個地址上。相比于 ERC-20 代幣，ERC-777 代幣的發送功能更完善，詳情見后文。

burn（） 函數會銷毀信息發送方所持有的一部分代幣。相比于 ERC-20 代幣，ERC-777 代幣的銷毀功能更完善，詳情見后文。

authorizeOperator（） 函數允許消息發送方將自己的代幣授權給另一個地址（譯者注：即給運營者授權）。

revokeOperator（） 函數可以將撤銷現有運營者控制消息發送方代幣的權限。

isOperatorFor（） 說明了某個地址是否是某個代幣持有者的運營者。

只要發送方擁有某個賬戶的運營者權限，就可以通過 operatorSend（） 函數將一定數量的代幣從那個賬戶發送至另一個賬戶。

defaultOperators（）函數提供了一個代幣運營者合約列表，列表中的運營者均已得到所有代幣的全部權限；關于這個功能，可以參見下文的 “代幣運營者合約” 一節。

ERC-777 代幣合約所涉及的事件

ERC-777 定義了一些事件，可以用來追蹤一個代幣合約的個體和整體信息。

一旦有新的代幣被鑄造出來，就會觸發Minted（） 事件。該事件包含了新鑄代幣的數量，及其目標地址的信息。

一旦現有代幣被銷毀，就會觸發 Burned（） 事件。該事件包含了被銷毀代幣的數量及源地址的信息。

一旦有代幣從一個地址轉移到另一個地址，就會觸發 Sent（） 事件。該事件包含了被轉移代幣的數量，以及持有者地址和接收者地址的信息。

除了上述幾個事件之外，ERC-777 代幣標準還包含了兩個管理型事件。一旦用戶為己方地址添加了一個運營者，就會觸發 AuthorizedOperator（） 事件。一旦用戶將己方地址的某個運營者移除，就會觸發 RevokedOperator（） 事件。要注意的是，這些事件不會包含關于代幣數量和所有權變化的信息。

詳解 ERC-777 代幣合約的發送功能

將 ERC-777 代幣從一個地址發送到另一個地址需要經過幾個步驟來完成。在這一流程，ERC-777 代幣標準在功能性和安全性上都展現出了優越之處。

常見的代幣發送流程如下圖所示：

具體步驟如下：

· 驗證：確保輸入參數是有效的，需驗證該地址是否有足額代幣可用來發送，以及所發送數額是否是該代幣粒度的倍數

· 授權：確保發送方有權發送代幣，發送方必須是這些代幣的持有者或是擁有對應地址權限的運營者

· 發送：執行代幣轉賬，更新代幣合約上每個地址的持幣信息

· 日志：發送包含所有操作細節的事件

ERC-777 在上述步驟的基礎上又新增了兩個步驟，如下圖所示：

可以看到，ERC-777 在常見流程中新增了 tokensToSend（） 和 tokensReceived（） 這兩個步驟。

tokensToSend（） 的調用放在了驗證交易信息以及完成授權之后，但是在更新合約地址的持幣信息之前。

tokensReceived（） 的調用放在了更新合約地址的持幣信息之后。

乍一看，新增的步驟似乎沒有讓整個流程變得很復雜。但是， tokensToSend（） 和 tokensReceived（） 的強大之處在于，它們不是由合約地址定義的，而是分別位于代幣發送方和接收方的合約內。由此一來，發送方和接收方就有權決定是否要達成交易，還可以實現更高級的功能。

tokensToSend（） 允許持幣者以 “在代幣離開該賬戶之前” 的形式提供條件和操作。

tokensReceived（） 允許代幣接收方以 “代幣何時到達該賬戶。..” 的形式提供條件和操作。

tokensToSend（） 的目的

想象一個場景。假設有一家公司的首席財務官制定了多種貨幣資金的轉出規則。這個首席財務官允許財務經理在遵守公司規則的情況下使用資金，同時保留對規則以及資金的控制權，就如下圖所示：

如果這筆資金采用的是 ERC-777 代幣的形式，就可輕松實現上圖中的設置。需要執行以下步驟：

1. 首席財務官制定的規則被編碼進了一個代幣控制合約內，且該合約被應用于該公司的持幣地址

2. 首席財務官授權財務經理成為公司持幣地址的運營者

3. 財務經理使用 operatorSend（） 發送資金

首席財務官可以制定哪些規則？幾乎所有規則都可以被編碼進智能合約內，下面舉了幾個例子：

· 只允許運營者花費一定量的資金（代幣）

· 對運營者設置 每日/每周/每月 的支出限額

· 運營者只能向一組經過授權的收款方發送資金

· 只有提供了對首席財務官批準過的發票的引用，運營者才可以花費這筆資金

· 等等

要留意的一點是，既可以針對公司所持有的不同種類的 ERC-777 代幣制定多套規則，也可以對多種 ERC-777 代幣實行同一套規則。這樣一來，首席財務官就可以制定合乎自己公司情況的規則了，財務經理也只能遵守這些規則。

同一個地址也可以擁有多個運營者。因此，如果財務經理有代理人的話，只要其代理人也遵守同樣的規則（或其他規則），就有權訪問這筆資金。

tokensToSend（） 旨在通過對交易制定規則來控制一個或多個賬戶內資金的轉出。說白了，tokensToSend（） 就是讓用戶把 “在代幣離開我的賬戶之前。..” 這句話補充完整。這些規則是在代幣控制合約中定義的。同一個代幣控制合約可用于多個 ERC-777 代幣合約，以及多個賬戶之間，從而保證各賬戶之間規則的統一。

tokensReceived（） 的目的

與 tokensToSend（） 類似，tokensReceived（） 會收到代幣已轉入該賬戶的通知。接著上文的例子，該公司有一個會計部門負責付款。每次收到付款，都需要核對是否與發票相符，并且分配給公司內部的部門。收到這筆資金之后，會計部門需要執行以下步驟：

· 如果收到的資金帶有發票參考號，則將其與發票進行核對，并記入相應部門的貸方

· 如果收到的資金來自一個已知的發送方，則直接記入相應部門的貸方

· 除上述情況之外，將資金存入持幣賬戶并進行調查

就 tokensToSend（） 而言，上述過程只是一個實例，它實際上可以描述一切規則。例如，提早付款可享折扣（推遲付款需額外收費），只接受哪幾種貨幣，等等。這只需要一個步驟：

1.該部門的流程被編程進了一個代幣控制合約，且該合約被應用于該公司的收款地址

通常來說，tokensReceived（） 之所以沒有 tokensToSend（） 那么復雜，是因為兩個原因。第一，tokensReceived（） 通常只包含一個參與者（收款地址），而 tokensToSend（） 會涉及運營者。第二，相比收款來說，用戶通常更關注付款。盡管如此，tokensReceived（） 是一個非常強大的功能，可以幫助像交易所之類的大型組織來管理已收到的資金。

tokensReceived（） 旨在通過對交易制定規則來控制進入一個或多個賬戶的資金。說白了，tokensReceived（） 就是讓用戶把 “當代幣進入我的賬戶之時。..” 這句話補充完整。這些規則都是在代幣控制合約中定義的。同一個代幣控制合約可用于多個 ERC-777 代幣合約，以及多個賬戶之間，從而保證各賬戶之間規則的統一。

對 tokensToSend（） 和 tokensReceived（） 的要求

tokensToSend（） 是可選項；如果不選的話，就會按照常見流程發送代幣。tokensReceived（） 也是可選的，除非收款賬戶是合約，在這種情況下就是強制的。強制所有收到代幣的合約執行 tokensReceived（） ，就可以確保代幣只會被發送到主動說明可以處理這這些代幣的合約處。這是 ERC-223 的主要目標。除此之外， ERC-777 還實施了其他保障措施，就是強制收款方登記是否能夠接收 ERC-777 代幣和 ERC-1820 代幣。

代幣運營者合約

如上文所述，代幣運營者合約就是在 ERC-777 代幣合約上調用 operatorSend（） 的合約。這類合約的強大之處就在于，它們能夠在不需要改變 ERC-777 代幣合約本身的情況下擴展 ERC-777 的功能。

當持幣者想要把代幣發送到另一個地址之時，他會直接在該代幣合約上調用 send（） ，如下圖所示：

但是，任何用戶也都可以通過調用代幣運營者合約來發送代幣。通過該合約，任何用戶都可以代表持有者發送代幣，如下圖所示：

在創建代幣合約之時，就可為所有持有者都啟用代幣運營者合約（即 默認運營者 ），或是在有需要的情況下，為個別持有者啟用該合約。

代幣持有者合約可以為代幣持有者提供額外的功能。例如，批量發送代幣是一大常見需求，但是沒有在 ERC-777 標準中注明。在部署 ERC-777 代幣合約之前，有可能會新增批量發送的功能，但是這樣會為代幣合約引入自定義屬性，因此更容易出現錯誤。

另一種解決方案是，編寫一個可實現批量發送的獨立代幣運營者合約，并單獨進行部署。這個代幣運營者合約可以接受來自持幣者的交易，并根據交易中所記錄的將哪種代幣發送給哪些收款方的細節，反復調用 operatorSend（） 來發送這些代幣。

為了實現批量轉賬的功能，在部署一個標準 ERC-777 代幣合約的同時會指定一個批量發送運營者合約作為默認的運營者?，F在，任何持幣者都可以在代幣運營者合約上調用 send（） 函數，僅通過一個交易就可以將多種代幣從自己的賬戶上發送出去。如果代幣合約沒有注明將批量發送運營者合約作為默認的運營者合約，則持幣者可以針對賬戶進行自定義配置。

請注意，由上圖可見，代幣運營者合約只有一個send（） 函數，但是復雜的代幣運營者合約可以有多個 send（） 函數。例如，一個批量發送代幣運營者合約可能具備以下功能，即，向多個收款方發送相同數量的代幣，向多個收款方發送不同數量的代幣，等等。

除了上述例子中提到的功能之外，調用代幣運營者合約的用戶也可以是除持幣者之外的人。讓外人代替持幣者發送代幣，這種做法可能聽起來很危險，但實際上在很多場景下都非常有用。將持幣者和要求轉賬的用戶分開，就可以實現更多功能，例如：

· 在獲得持幣者授權的情況下發送代幣（“免手續費轉賬”）

· 通過發送代幣來換取其他代幣（例如，ICO、分布式交易）

· 一旦滿足特定條件，立即發送代幣（基于績效的獎勵、根據時間鎖定的代幣）

簡言之，代幣運營者合約可以通過修改規則來規定代幣在何時可以從一個賬戶轉移到另一個賬戶。這是一個非常強大的功能，需要用戶充分信任代幣運營者合約?？梢栽O想的是，以太坊主網上將會部署一些知名的代幣運營者合約，用來實現特定的功能。代幣合約創建者和個人持幣者通過選擇自己想要的代幣運營者合約就可以擴展功能，從而提高代幣轉賬的效率和安全性。

在下一篇文章中，我們將更深入地探究代幣運營者合約。

代幣運營者合約和代幣控制合約之間的差別

乍一看，代幣運營者合約跟代幣控制合約中的 tokensToSend（） 差異不大，其實二者還是有一些差別的。

代幣運營者合約是可選的；任何持幣者都可以忽視這個功能，直接調用 send（） 。而代幣控制合約是強制性的，不能被忽視。

任何人都可以調用代幣運營者合約。代幣控制合約是作為 send（） 和 operatorSend（） 操作的一部分調用的，因此只能由持幣者（或該持幣者的運營者）調用。

一般而言，代幣運營者合約側重于擴展代幣合約的功能。代幣控制合約則側重于控制來自賬戶的代幣流。

下表匯總了代幣運營者合約和代幣控制合約之間的不同點：

與 ERC-20 的兼容性

敏銳的讀者可能已經注意到了，雖然 ERC-20 和 ERC-777 提供的功能差不多，但是二者對這些功能的命名都不盡相同；ERC-20 使用的名稱是transfer（）/approve（）/transferFrom（） ，而 ERC-777 使用的名稱是send（）/operatorSend（） 。這就意味著，同一個代幣合約有可能提供相同的 ERC-20 和 ERC-777 功能。ERC-777 標準中詳細說明了具體的操作方式和觸發事件。

ERC-777 實現

ERC-777 帶有一個參考實現，其中還包括了一個可兼容 ERC-20 標準的版本。代幣運營者合約和代幣控制合約的樣本可單獨獲得。
責任編輯；zl