今天我們探討EOS的許可權和許可問題

1.基本概念

我們先了解下EOS.IO許可權模型的三個基本概念：

1.  Wallets（錢包）——錢包是EOS.IO提供的用於管理金鑰對的客戶端，錢包支援鎖定和密碼解鎖。
2. Accounts (賬戶）——賬戶是公示在區塊鏈上的人工易讀（不是公鑰或短地址！！！）的名字。
3. Authorities and Permissions(許可權及授權驗證）——每個賬戶都內建owner和active許可權，owner冷藏用於恢復其他許可權。一般轉賬操作，都使用active許可權就可以了。

1.1許可權（Permission）定義的目標

EOSIO的賬戶許可權定義的目標在

EOS.IO software allows each account to define a mapping between a Named Message Handler Group of any account and their own Named Permission Level. For example, an account holder could map the account holder's social media application to the account holder's "Friend" permission group. With this mapping, any friend could post as the account holder on the account holder's social media. Even though they would post as the account holder, they would still use their own keys to sign the message. This means it is always possible to identify which friends used the account and in what way.

這段話明確了EOSIO允許賬戶持有者部分讓度許可權，而且許可權受讓者是用自己持有的金鑰簽名，以便明確區分授權行為是如何發生的。

2.賬戶(Account)如何生成

許可權是建立在賬戶的基礎之上的，那麼賬戶又是如何產生的呢？
首先要明確的一點是：

無論賬戶還是許可權，它們一定是通過簽名交易（signed transaction）來定義並在區塊鏈中公示的。——這是其他節點在執行合約時進行許可權驗證（Authorities）的基礎。

來看看利用EOSIO的命令互動，如何生成一個新賬戶：

$ cleos create account eosio tester EOS4toFS3YXEQCkuuw1aqDLrtHim86Gz9u3hBdcBw5KNPZcursVHq EOS7d9A3uLe6As66jzN8j44TXJUqJSK3bFjjEEqR4oTvNAB3iM9SA
 

命令的說明及返回在這裡
返回JSON文字比較長，不過讀懂它的每一部分含義你也就理解了EOSIO許可權模型的設計思路。這裡我們先看看與本文相關的幾處：

1. 每個賬戶預設攜帶owner和active兩個許可權，分別對應一對金鑰（*其中owner金鑰冷藏儲存，通常用active來幹活，方便用owner恢復active）
2. 該命令用賬戶eosio的active許可權簽名提交了一個交易
3. 交易呼叫了內建合約eos的newaccount行為
4. 命令傳入的公鑰分別作為新產生的tester賬戶的owner和active許可權公鑰

這裡一定有人會問：那麼這個最初的賬戶eosio是由什麼賬戶來簽名生成的呢？——它是在啟動區塊鏈時，在創世區塊的配置config.ini中直接定義的。

可以檢視config.ini檔案

producer-name = eosio

 3. Authorities （授權）和 Permissions（許可）

Authorities 決定特定message是否被正確授權。

每個賬戶都有兩個原生具名的permissions

• owner authority代表一個賬戶的所有權。只有少數transactions需要此authority，但任何需要改動owner authority的message都需要。總的來說，我們建議把owner冷儲存起來，不要和任何人共享。owner可以用來恢復另一個可能已經被損害的（compromised）permission.

• active authority可用來轉賬資金、給區塊生產者投票及進行另一些高階的賬戶改動

除了原生 permissions外, 賬戶可有自定義的具體名稱的permissions，以擴充套件對賬戶的管理功能。自定義permissions是非常靈活的，可以用於各種各樣的場景。這很大程度上取決於開發者社群 Much of this is up to the developer community in how they are employed, and what conventions if any, are adopted.

任何authority的Permission都可以被分配給一個或多個公鑰或一個有效的賬戶名。

4.utting it all Together（把他們放一起）

我們用簡單的Demo來說明一下。

4.1 預設賬戶配置 (Single-Sig)

這是某賬戶建立後如何配置的例子。該賬戶的owner和active permissions都各自有一個key, 兩個keys的權重都是1且閾值也是1。預設配置需要一個簽名來授權對於原生permissions的message。

@bob account authorities

在@bob賬戶這個例子中，依表格所示，@bob's的owner key的權重是1，在該authority下推送一個transaction所需要的閾值也是1。

如果需要在owner的authority下推送一個transaction，只需要@bob用它的owner key簽名一個transaction，此transaction即可被認為有效。這個key將被儲存在一個wallet中，並用eosc來管理。

4.2 Multi-sig 賬戶及自定義Permissions

下面的例子是一個虛構的名叫@multisig的賬戶。在此場景下，兩個使用者被授予owner 和 active permissions，而有三個使用者加權不同地被授予自定義的publish permission。

@multisig account authorities

• 在此場景下，要修改owner permission的加權閾值為2，也就是說因為每方本身加權都是1, 所有使用者需要都簽名該transaction它才能被完全授權。
• 而要傳送一個需要active authority的transaction，加權閾值是1。這意味著只需要一個具有active authority的賬戶簽名即可授權該message。

• 還有一個叫publish的自定名稱permission。這個publish permission的加權閾值是2，而@[email protected]* 和 @stacy的加權都是2，public key的加權是1。這樣的話@bob和@stacy都不需要額外簽名就可以釋出，但public key 則需要一個額外簽名才能使一個在public permission下的message通過授權。

上面的permissions表展現了@bob 和 @stacy作為賬戶的擁有者，具有類似於主席或者編輯的特權。儘管這個簡單的例子也有侷限性（尤其是可擴充套件性上），並不是一個好的設計，但它卻充分展現了EOS許可權系統的靈活性。

注意上面的表格中，permissions可以使用account name也可以使用一個key。乍看之下這可能不重要，但是這確實增加了靈活性。

備註

• @bob 和 @stacy可同時被顯式地設定成使用者的擁有者。
• @bob 和 @stacy 都有對於 publish許可權的特權。

2018年7月31日整理於深圳