解鎖超級鏈去中心化的許可權系統

買賣虛擬貨幣
中心化的許可權系統使用場景受限,同時增加了網路運維成本以及使用者使用成本。百度超級鏈基於ACL許可權模型實現了一套去中心化的許可權系統,同時保持著可擴充套件、易用的特性,有助於開發者快速上手。本期超級鏈學院線上微課堂就帶你解鎖超級鏈去中心化的許可權系統!明星講師超哥將主要圍繞以下幾點展開:1.許可權系統在區塊鏈中有哪些作用?2.超級鏈許可權系統是如何構建的?3.使用者如何快速上手超級鏈許可權系統?4.使用過程有哪些常見問題需要避免?
5.超級鏈許可權系統與其他系統的異同點?快來繼續往下看吧!Q1:賬戶與許可權系統的定義是什麼?賬戶用於標識區塊鏈網路中不同身份,而許可權控制用於約束資源獲取/更新等能力。賬戶與許可權系統就是指結合賬戶與許可權控制兩個要素,以賬戶為粒度對資源獲取/更新等能力進行約束的一種系統要素。這裡的賬戶包括普通賬戶以及合約賬戶。Q2:賬戶與許可權系統有哪些常見模型?
區塊鏈中常見的許可權控制模型包括:基於ACL的許可權控制模型、基於RBAC的許可權控制模型以及基於ABAC的許可權控制模型。Q3:賬戶與許可權系統在區塊鏈中有哪些作用?許可權系統用於保障區塊鏈網路中普通使用者資產、合約使用者資產的安全,只有擁有相應許可權的使用者才能訪問/更新相應的資料,做到使用者對自己的資料具有所有權。常見的許可權系統包括以聯盟鏈為代表的MSP身份認證系統,以公鏈為代表的去中心化許可權系統。Q4:超級鏈採用的哪種賬戶與許可權模型呢?超級鏈其實已經實現了一套基於CA的許可權控制系統,適用於聯盟鏈應用場景。為了不僅適用於聯盟鏈場景,同時適用於公鏈場景的需求,超級鏈還自研了一套基於ACL許可權控制模型的去中心化的賬戶與許可權系統。當初設計去中心化的賬戶與許可權系統主要是為了公鏈場景下,支援智慧合約資料資產的訪問許可權控制,保障合約資產資料的安全。
到目前為止,超級鏈中普通賬戶的許可權認證也走去中心化許可權系統,實現了許可權認證的入口統一。目前,超級鏈自研的許可權控制系統支援簽名閾值策略、AK集簽名策略等。閾值策略是指每個使用者持有一定權重的許可權,當授權使用者的總權重達到一定閾值時,表明鑑權透過。AK集策略是指集合中的AK之間的與以及集合之間的或邏輯表示式,來決定是否鑑權透過。Q5:超級鏈是如何實現賬戶與許可權系統的?許可權系統主要包括賦權與鑑權兩個部分,這兩個方法以系統合約的形式實現。在建立合約賬戶、設定合約賬戶許可權列表、設定合約方法許可權列表時,會分別呼叫賦權與鑑權這兩類系統合約。(1)超級鏈是如何實現賦權的?什麼操作涉及到賦權?賦權是指為合約賬戶或者合約方法設定訪問許可權列表,涉及到更新資料庫資料。
一般在建立合約賬戶、設定合約賬戶許可權列表、設定合約方法許可權列表時都會涉及到賦權操作。主要操作就是將一個<key,value>寫入資料庫,value通常為json格式的許可權配置檔案,而key就是合約賬戶的ID或者合約方法的ID。賦權過程中,還會對引數進行有效性驗證,比如合約賬戶命名規範是否合法,許可權列表數量是否達到上限。(2)超級鏈是如何實現鑑權的?什麼操作涉及到鑑權?鑑權是指驗證一組簽名是否具有足夠許可權執行特定的操作,比如呼叫某個合約的某個方法、普通使用者轉賬等。主要透過許可權樹模型進行許可權認證流程,具體流程如下:
①根據實體的鏈上許可權規則構造出許可權樹,並快取每個非葉子節點的具體許可權規則;②按層遍歷許可權樹,從最底層的節點進行鑑權;a.如果節點是一個普通的address,直接判斷是否滿足實體的許可權需求;b.如果節點是一個合約賬號,則遞迴判斷其所有子節點是否獲得授權;③如果當前節點為根節點,則按照(2)中的鑑權規則判斷,得到最終的鑑權結果;通常,涉及到資料更新的地方都需要鑑權。
Q6:應該如何使用超級鏈的賬戶與許可權系統?只需要正確填寫Initiator以及AuthRequire以及對應的簽名即可。Initiator通常從data/keys/address檔案中獲取,AuthRequire通常從data/acl/addrs檔案中獲取。我們以建立一個合約賬戶為例,說明如何使用。step1: 準備一個acl配置檔案,命名為newAccount.json,內容如下:{
    "module_name": "xkernel",    "method_name": "NewAccount",    "args" : {        "account_name": "1111111111111111",        "acl": "{\"pm\": {\"rule\": 1,\"acceptValue\": 0.6},\"aksWeight\": {\"AK1\": 0.5,\"AK2\": 0.5}}"    }
}其中,module_name是指建立合約賬戶呼叫的系統合約名字;method_name是指建立合約賬戶呼叫的系統合約方法名字;account_name是指待建立的合約賬戶名字;acl就是具體的許可權配置規則,其中rule是指特定的許可權模型,acceptValue是許可權閾值,aksWeight是指具體的許可權比重配置。step2: 發起預執行,命令如下:
./xchain-cli multisig gen - -desc newAccount.jsonstep3: 對預執行結果進行簽名,命令如下:./xchain-cli multisig sign --output my.signstep4: 將預執行結果以及簽名組裝成一個完整的交易並轉發到網路,命令如下:./xchain-cli multisig send my.sign my.signQ7:超級鏈許可權模型與其他模型有何異同點呢?
Fabric:實現了一套基於MSP的許可權認證系統,透過CA進行證書授權,基於ABAC進行許可權訪問控制。只適用於聯盟鏈場景,不適用於公鏈,且ABAC方式較複雜。EOS:基於RBAC實現一套賬戶許可權系統,RBAC將角色與許可權掛鉤。Ethereum:
許可權控制都是靠每個合約自己在程式碼中定義。Bitcoin:沒有許可權控制。分享結束後,群裡湧現出的精彩問題,摘取部分分享給各位。問:超級鏈的許可權模型是不是不使用CA證書?因為在我的理解中,CA是個中心化的東西。答:我們支援CA模型,不過當前開源的版本沒有實現CA。我們的聯盟鏈解決方案包含了CA,但目前開源版本的許可權系統是獨立於CA存在的,是一種完全去中心化的許可權系統。
問:普通賬戶許可權認證的去中心化許可權系統是在哪個版本升級了?普通使用者該如何使用許可權系統呢?答:普通賬戶的許可權驗證一直都是在鏈上完成的,後來將普通賬戶的許可權驗證介面統一到了許可權系統中了。普通使用者的許可權驗證就是公私鑰驗證。問:物聯網的海量資料接入鏈會發生什麼事?是否有具體有關充電樁場景應用的案例呢?答:這種場景對網路的效能有要求。如果網路效能不行,容易阻塞。超級鏈之前恰好有過汽車充電樁資料接入區塊鏈的案例,在這個案例中,我們透過LCV輕量級節點植入到充電樁中,從源頭保證資料可信採集,並將實際充電結算資料上鍊,解決了充電樁服務商、電力部門和使用者之間的資料互信問題。
問:rule是指特定的許可權模型,acceptValue是許可權閾值,aksWeight是指具體的許可權比重配置。那許可權模型、閾值、許可權比重配置,可以說明一下這3個嗎?答:許可權模型是指使用什麼樣的ACL規則模型來驗證許可權,可選的有閾值模型和AK集模型。如果選擇閾值模型,那麼ACL中每個address可以配置一個權重,這個權重配置列表就是aksWeight,那麼將所有簽名Address的權重累加,如果超過acceptValue這個閾值,就說明許可權驗證成功。問:EOS實現RBAC將角色與許可權掛鉤。這種是不是更適合聯盟鏈業務場景?超級鏈選擇的acl的優勢是什麼?答:超級鏈的ACL並不是傳統意義的訪問控制列表,而是一種基於賬戶列表的可擴充套件的許可權模型。舉例來說,我們提供的AK集模型就可以支援賬戶集合之間的邏輯關係判斷。所以基於這種可擴充套件的許可權模型,使用者甚至可以定製出自己的RBAC模型,這種靈活性要比RBAC更高。問:由於企業內部可能存在賬號系統中使用者資訊被惡意洩露的問題,超級鏈中的授權鑑權能否發展成為企業內部賬號系統?或者說未來有沒有可能打造一款類似產品,部署在企業內部做私有鏈?答:對於企業賬戶資訊洩露的問題,可以從兩個角度考慮,第一個角度是單個使用者密碼洩露導致的單個使用者資訊洩露,這個在區塊鏈場景下如果使用者私鑰洩露也同樣會洩露個人資訊;第二個角度是因為使用者資料中心化儲存帶來的中心化系統資料洩露問題,這種情況透過區塊鏈可以將使用者資訊作為個人隱私資料保留在個人賬戶中,典型的例如去中心化身份系統,可以做到不會因為中心化系統被攻破而洩露所有使用者的資訊。
問:有方法實現去中心化的身份認證系統嗎?答:DID去中心化身份系統有標準實現,我們也會在未來開源我們自己的DID解決方案。問:Fabric中的CA認證能不能拓展到其他場景呢?例如:登陸某一網站或者APP,透過掃描二維碼,進行CA授權及許可權劃分。答:超級鏈不是Fabric,不過我們也有CA。除此之外,我們的許可權系統是一種更靈活、可擴充套件的許可權模型。理論上,可以透過擴充套件許可權模型來支援外部驗證系統,不過外部系統資料不在鏈上,當外部使用者發生變化時,鏈上並無法及時得知,有可能導致資料不一致問題。

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;