EOS原始碼分析(5)賬號

尹成發表於2018-05-13
原始碼
# EOS 賬號
EOS 的賬號系統可以說在當前的公鏈系統中是非常完善的，在進一步理解EOS的賬號系統以前，讓我們先看一下區塊鏈中其他公鏈的賬戶系統是怎樣設計的。

大家都知道，區塊鏈上的第一個應用就是比特幣，它建立了一種點對點的電子貨幣系統。由於是一套貨幣系統，因此它主要針對的是貨幣的產生，點對點貨幣支付等場景，在這套系統中，設計的視角是從貨幣出發的，系統中僅有交易地址的概念，並沒有賬號的概念。

相比於交易地址，賬號一般都會有餘額的概念，系統為每個賬戶存放了餘額資訊，任何時候你都可以查詢到此餘額，而比特幣交易地址並沒有這些餘額資訊，比特幣所儲存的資訊主要就是交易資訊本身，餘額資訊是通過交易推算出來的，交易的過程類似於我們在生活中使用法幣的場景。試想一下你兜裡目前有3張一元和一張五元的紙幣，當你要購買一個價格為2.5 角的冰激凌的時候，你可以考慮拿三張一元的紙幣，也可以考慮直接使用一張五元的紙幣，對方會根據你的紙幣金額再找零給你。在任何一個時間點，其實沒有一個固定的餘額數字告訴你兜裡還有多少錢，但你的餘額可以根據你所有的交易資料推算出來，每個賬戶的餘額就是你交易地址所涉及的所有未花費交易輸出（UTXO: unspent transaction outputs)。比特幣的這種賬號系統的優勢就在於他完全是無狀態的，從技術的角度來說，無狀態的系統更容易擴充套件，更容易並行處理。

與比特幣的UTXO模型不同，以太坊是有賬戶體系的，它的賬戶包含四個部分：

1. 隨機數，用於確定每筆交易只能被處理一次的計算器
2. 賬戶目前的以太幣餘額
3. 賬戶的合約程式碼，如果有的話
4. 賬戶的儲存（預設為空）

以太坊有兩種型別的賬戶：外部賬戶和智慧合約賬號，其中外部賬號是沒有程式碼的。人們可以通過建立和簽名一筆交易從外部賬號傳送訊息，每當智慧合約賬戶收到訊息後，其內部程式碼會被啟用，允許程式碼對賬戶內部儲存進行讀取和寫入。可以看到，賬戶系統對於智慧合約功能的支援來說是必須的，有了賬戶的概念，智慧合約中才能更方便的訪問賬戶中的資訊。

以太坊賬戶系統已經提供了一些通用的資訊和功能，但這個賬戶系統在實際應用使用中，還是不夠完善，主要集中在三個方面：

1. 賬戶的地址是一個20位元組的地址，不方便記憶
2. 賬戶不支援許可權管理，不能應用在需要複雜許可權管理的場景
3. 金鑰一旦丟失，再也無法使用此賬號

正是看到了以上這些問題，EOS系統在設計的時候，力求打造一套具備完善功能的賬號體系，這樣能夠更好的支援各類應用場景需要，具體特性包括：

1. 採用了方便人類閱讀的字串（2-32字元）來建立賬號
2. 支援域的概念，例如@domain 賬號的擁有者是唯一能夠建立@user.domain 賬號的人
3. 支援完善的許可權管理體系
4. 賬戶間訊息傳送和處理
5. 恢復被盜竊的金鑰
# 許可權管理
## 基於角色的許可權管理
所謂許可權管理，簡單的來說就是判定某條訊息是否被正確的授權，此處的訊息泛指EOS中一切呼叫，包括交易和對智慧合約的呼叫。在區塊鏈中，比較常見的一種許可權管理方式是判定一筆交易是否包含有效的簽名，比特幣中每筆交易都會做類似的判定，這種許可權管理方式屬於很簡單的一種型別，它的審查範圍是針對每筆交易，沒有細化到賬號級別，並且在這類判定中，操作所需許可權（簽名）都是已知的，而在實際情況中，許可權一般都會繫結到賬號或者多人賬號級別，並且賬號所擁有的許可權和操作所需要的許可權是分別控制的，EOS 提供的這種宣告式的許可權系統可以在賬戶級別提供細粒度和高緯度的控制，它可以有效的管理什麼賬號可以在什麼時間做什麼事情。

認證和許可權管理必須標準化，並且與應用程式的業務邏輯分開，這樣可以通過開發工具以通用的方式來管理許可權，並且為效能優化提供可能。

每個賬號都能被其他多個賬號和私鑰按照權重組合進行控制，這就創造了一種分層級的許可權結構，它真實反映了現實中的許可權分配方式，並且讓多使用者共同管理資產變得從未如此簡單。這種多賬戶控制機制，能對賬戶的安全性提供保障，減少被黑客攻擊而造成的資金損失風險。EOS甚至還允許定義某種多賬戶和私鑰的組合可以傳送特定的訊息型別給另外一個賬號。舉個例子，可以指定一個金鑰給一個使用者的社交媒體賬號，同時另一個金鑰訪問交易所。甚至可以授權其他賬號來代表本賬號而無需把自己的金鑰分配給他們。

## 命名的許可權級別
EOS 中每個賬號都會有兩個固有的命名許可權，如下：

- `owner`
`owner` 表示賬戶的所有權（是賬戶最高許可權），此許可權能夠對賬號做所有的操作，甚至可以重新恢復那些已經被洩漏的許可權，一般只有很少的操作需要此許可權。通常情況下，建議你把此許可權對應的私鑰進行冷儲存，不要把它與任何人分享。
- `active`
`active`許可權可以用來進行轉幣，投票和其他的一些高階別的操作。

除了系統固有的這兩種命名許可權外，賬號還可以新增定製的命名許可權來擴充賬號管理功能，並且這種許可權可以從更高階別的命名許可權繼承。每一個命名許可權都支援多重簽名閥值校驗，其中的多重簽名可以包含金鑰和/或其他賬戶的命名許可權級別。

針對上面所說的許可權級別，這裡舉一個例子。在Steem區塊鏈應用中，包含了三個硬編碼的命名許可權級別，分別是`owner`, `active`和`posting`, `posting` 許可權只能進行如投票和發帖的社交活動，`active`許可權可以做除了變更擁有之外的所有操作。`owner`許可權則可以做包括冷儲存在內的所有的事情。

## 命名的訊息處理群組
EOS允許賬號可以根據命名的巢狀群組來定義其訊息處理函式。這個命名的訊息處理群組可以在其他賬號配置他們許可權級別時被引用。

最高階別的訊息處理群組是賬戶名稱，最低階別的是一個賬戶所接收到的單獨的訊息型別，這個群組可以被這樣引用：
`@accountname.groupa.subgroupb.MessageType`

在這樣的模型下，交易所合約可以通過將掛單的建立和取消分組，從而與充值提現分離開。交易所合約的這種分組對使用者而言帶來了方便。

## 簽名
### 單籤（預設賬戶配置）
賬號在建立的時候，預設會有兩個許可權，分別是`owner` 和`active`，每個許可權對應一套金鑰（一個公鑰，一個私鑰），每套金鑰對應的權重都是1，許可權的驗證閥值也是1，因此訊息的授權只需要某一個許可權的單獨簽名即可，如下：

| Permission | Account | Weight | Threshold |
|:--|:--|:--|:--|
| owner | | | 1 |
| | EOS5EzTZZQQxdrDaJAPD9pDzGJZ5bj34HaAb8yuvjFHGWzqV25Dch | 1 | |
| active | | | 1 |
| | EOS61chK8GbH4ukWcbom8HgK95AeUfP8MBPn7XRq8FeMBYYTgwmcX | 1 | |

在以上@bob賬號中，bob的`owner`的許可權權重是1，交易簽名所需要的授權閥值也是1，因此當bob需要傳送交易訊息的時候，只需要使用owner的key對交易訊息進行簽名即可通過驗證。

### 多籤與定製許可權
以下我們虛構一個需要多簽名的賬戶@multisig. 在這個場景中，@multisig 賬號的`owner`和`active`許可權分別有需要兩個賬戶的授權，`publish`許可權則需要三個簽名，包括兩個賬戶和一個`key`，並且這三個簽名的權重是不一樣的，具體如下：

| Permission | Account | Weight | Threshold |
|:--|:--|:--|:--|
| owner | | | 2 |
| | @bob | 1 | |
| | @stacy | 1 | |
| active | | | 1 |
| | @bob | 1 | |
| | @stacy | 1 | |
| publish | | | 2 |
| | @bob | 2 | |
| | @stacy | 2 | |
| | EOS7Hnv4iBWo1pcEpP8JyFYCJLRUzYcXSqtQBcEnysYDFTEbUpi6y | 1 | |

在以上場景中，由於`owner`的許可權閥值是2，而`owner`許可權下的兩個賬號的權重都是1，因此，當需要對交易訊息進行簽名的時候，需要這兩個賬號同時授權才可以。

如果所傳送的交易訊息需要`active`許可權，由於此許可權的閥值是1，這就意味著只需要`active`許可權下任何一個賬號授權就可以了。

這裡還有一個自定義的命名許可權叫做`publish`, 此許可權的閥值是2，而其下的賬號@bob和@stacy的權重都是2，另外一個key的權重是1，這就意味著@bob和@stacy都可以獨立的進行簽名，而key則需要另外一個簽名一起才可以進行授權。

在以上案例中，許可權的設定同時使用了**賬號**和**key** 的形式，這種形式初看起來覺得意義不大，但其實引入了一種非常靈活的維度。

## 許可權對映
命名許可權級別和訊息處理群組這兩個概念之間可以做對映，也就是說，可以將某個訊息處理群組分配到某個許可權級別上。舉個例子：一個賬戶所有者可以將自己社交媒體應用與自己的“朋友”許可權群組建立對映，有了這個對映，任何朋友都可以以這一賬戶的身份在社交媒體上發帖，但儘管他們能夠以賬戶所有者的身份發帖，他們仍然使用自己的金鑰來簽名訊息，這意味著總可以辨別出是哪一個朋友在以何種方式使用賬戶。

## 評估許可權
當@alice傳送一條型別為“Action”的訊息給@bob 時，EOS首先會檢查是否存在一條@alice許可權和@bob.groupa.subgroup.Action操作之間的對映，如果沒有找到，會繼續檢查@bob.groupa.subgroup與@alice許可權之間是否存在對映，然後是@bob.groupa,最後@bob將被檢查，如果都沒有找到，那麼就假定對映為命名許可權@alice.active。
一旦某個對映被識別，則通過閥值多簽名流程驗證許可權是否有效，如果失敗了，則會找尋其父許可權，直至擁有者許可權@alice.owner.

![evaluating permission](images/3.1.eval-perm.png?raw=true)

請看以上事例，圖中@USER是一個賬戶，@EXCHANGE.CONTRACT是個交易所智慧合約。@USER賬號對應著一組許可權，分別是`OWNER`, `ACTIVE`, `FAMILY`, `FRIENDS`,`LAWYER`，其中`OWNER`,`ACTIVE`為EOS提供的賬號固有許可權，其他則為自定義的許可權。他們之間有繼承關係，`FRIENDS`許可權是繼承自`FAMILY`的。

@EXCHANGE.CONTRACT 智慧合約中定義了一些訊息型別，其中`WITHDRAW MESSAGE`和`TRADE GROUP`是平行的訊息型別，`BUY`,`SELL`,`CANCEL`訊息都是掛在`TRADE GRAOUP`下的。

圖中@User 把交易所智慧合約的訊息型別和賬戶的許可權做了對映，`CONTRACT`及其下的`TRADE` 型別的訊息對映到`FAMILY`許可權下，此處相當於在`FAMILY`許可權下有兩個對映。`WITHDRAW`型別的訊息對映到`LAWYER`許可權下面，這樣的對映形成了如下規則：

1. `FRIENDS`許可權下能夠做的做的事情，`FAMILY`許可權都可以做，因為它是`FRIENDS`的父許可權
2. `FAMILY`許可權可以傳送除`WITHDRAW`訊息外其他任何訊息，這是因為`WITHDRAW`訊息在其他許可權下做了特殊的對映，`FAMILY`許可權無法覆蓋此訊息
3. `LAWYER`許可權可以傳送`WITHDRAW`訊息，但無法傳送其他訊息

當使用者向智慧合約傳送`BUY`訊息的時候，系統會按照如下規則判斷許可權是否符合：

1. 判斷是否有 @exchange.contract.buy 和賬號許可權對映，如果有，直接返回對應的許可權，如果沒有，則繼續
2. 判斷是否有 @exchange.contract 和賬號許可權對映，如果有，直接返回對應的許可權，如果沒有，則直接返回 @active 許可權
3. 判斷訊息所附帶的授權是否能夠滿足訊息所需要的許可權

## 並行許可權評估
由於許可權評估的過程是隻讀的，並且交易執行對許可權的變更在一個區塊結束之前是不會起作用的，這就意味著：

1. 所有的許可權評估都是可以並行執行的
2. 無需再啟動一個可能會引起回滾的高成本的應用邏輯去實現快速的許可權驗證，並行許可權驗證已經是一種快速解決方案了
3. 當收到需要等待的交易（pending transactions)時，系統可以直接對其進行許可權評估，而無需等到此交易在執行時再被評估，這樣可以節約交易執行時間

並且，由於許可權驗證的操作佔據了驗證類交易計算量的很大比例，因此，許可權評估過程的只讀和併發執行的特性將會使整體效能有一個質的飛躍。
# 訊息和處理程式
在EOS中，每個賬號都可以向其他賬戶傳送結構化的訊息，並且可以定義指令碼來處理他們接收到的訊息。同時，EOS 還給每個賬戶提供了只有自己的訊息處理指令碼才能訪問的私有資料庫。訊息處理指令碼同樣能夠給其他賬戶傳送訊息，訊息和自動化訊息處理的結合構成了EOS的智慧合約。

## 帶強制性延遲的訊息
時間是安全中的一個關鍵組成部分。在大多數情況下，一個私鑰在沒有被使用前都無從知曉它是否被盜竊。當一個需要金鑰的應用在你的某臺每天聯網的電腦上執行時，基於時間的安全會更加重要。EOS 允許應用開發者指定某條訊息在加入到區塊之後需要等待多久才能被執行，在這段等待時間，可以隨時取消這條訊息。

使用者會在訊息廣播出去後通過郵件或者文字的形式收到通知，如果他們沒有授權相關操作，則可以使用賬戶恢復流程來恢復賬號，並收回訊息。

這個延遲的長短取決於操作的敏感性。如果是為一杯咖啡付款，可以無需設定任何延遲，幾秒內交易就不可逆了。而購買一套房子也許需要72小時的結算期。轉移整個賬號的控制則可能需要長達30 天。具體的延遲時間由開發者和使用者來做選擇。
# 恢復被盜竊的金鑰
EOS系統提供給使用者一種找回失竊金鑰控制權的方式。賬戶的恢復需要有以下兩個要素：

1. 過去30 天活躍的任意的`owner key`
2. 指定的賬戶恢復合作伙伴所給出的批准

以上兩個條件缺一不可。

那對於已經獲取了賬號控制權的黑客來說，他會嘗試去執行這個賬戶恢復流程嗎？正常來說應該不會，因為他已經取得了賬號控制權，再走這個流程對他沒有太大的意義。當然，也許這位黑客想完全控制此賬戶，他希望通過重置`owner key`而完全擁有它，但當他走這個賬戶恢復過程的時候，賬戶恢復合作伙伴將會通過多種方式進行身份驗證（例如電話，郵箱等）。這將是的黑客做出讓步或者無功而返。

賬號恢復流程看上去也需要多個賬戶的合作，有點類似多簽名交易的過程，但其實它們是完全不同的兩個流程。在多簽名流程中，其他參與賬號需要針對每筆執行的交易都要進行簽名。但在賬號恢復流程中，賬號恢復合作者只能參與到賬號恢復的流程，而無權參與到日常的交易訊息簽名。這大大降低了賬號恢復合作者的成本和法律責任。






網址：http://www.qukuailianxueyuan.io/



欲領取造幣技術與全套虛擬機器資料

區塊鏈技術交流QQ群：756146052  備註：CSDN

尹成學院微信：備註：CSDN





網址：http://www.qukuailianxueyuan.io/



欲領取造幣技術與全套虛擬機器資料

區塊鏈技術交流QQ群：756146052  備註：CSDN

尹成學院微信：備註：CSDN

相關文章