認識下以太坊Clef—獨立交易簽名器
Clef本質上是一個獨立的交易簽名器。Clef 背後的思想是將帳戶管理與Geth客戶端其它功能分開。
一、初識
以太坊go-ethereum在1.8.4版本中就開始引入了Clef，並在1.9.0版本中進行了較大的升級，其主要目的是以一種更安全、獨立的方式替代以太坊節點的賬號管理模塊。
1、Clef是什麼
官方文檔對Clef的描述是：
Clef最終目標是代替Geth的節點賬號管理，可用來對交易進行簽名。Clef可以使DApp不必依賴Geth的帳戶管理，當DApp需要對數據（或交易）進行簽名時，可以將數據發送給Clef，在經過授權同意後，Clef將把簽名返回給DApp。
從官網的描述中，並沒有看出Clef的獨特之處，甚至是存在的必要。賬號管理在Geth的JSON-RPC API中提供的personal命名空間下的方法就挺全面的。交易簽名功能在web3中也有提供。那麼爲什麼要獨立出一個Clef模塊呢？
2、爲什麼要有Clef
Clef本質上是一個獨立的交易簽名器。Clef 背後的思想是將帳戶管理與Geth客戶端其它功能分開。Clef通過 IPC 或 HTTP 暴露了一個輕量API，可以被Dapp用作簽名工具。
Clef最大的特點是提供了：
- 請求確認，實現一方請求一方確認；
- 規則引擎，實現自動化請求確認。
二、探索
1、Clef啓用
初始化啓用Clef服務需要先進行初始化，初始化時需要輸入一個密碼，這個密碼是用來加密master種子的。初始化命令：
clef init
啓動服務初始化後就可以啓動服務了，啓動時我這裏指定了keystore目錄、chainid、開啓了HTTP-RPC服務，端口使用模塊8550
clef --keystore ./keystore/ --chainid 4 --rpc
請求測試啓動成功後可以重新打開一個shell，運行查看賬號列表的命令，進行簡單測試，命令爲：
echo '{"id": 1, "jsonrpc": "2.0", "method": "account_list"}' | nc -U ~/.clef/clef.ipc
在clef服務的shell窗口中，此時可以看到是否授權查看，輸入 y 後即授權通過。如下圖所示。
更多命令可查看官網進行使用。
2、規則引擎
Clef的規則引擎是一個很強大的東西，可以通過設置規則，讓某些請求自動批准執行。
比如我們上邊的查看賬號列表的命令，需要Clef管理員手動確認，我們通過配置如下規則（一段js代碼），可以實現免授權。
function ApproveListing() {
return "Approve"
}
規則文件計算hash
> sha256sum rules.js 8d089001fbb55eb8d9661b04be36ce3285ffa940e5cdf248d0071620cf02ebcd rules.js
證明規則文件證明規則文件的目的是防止有人對規則文件進行修改，這裏將規則文件的hash使用attest命令進行證明。
> clef attest 8d089001fbb55eb8d9661b04be36ce3285ffa940e5cdf248d0071620cf02ebcd
使用規則文件啓動clef
clef --keystore ./keystore/ --chainid 4 --rpc --rules rules.js
此時，我們在運行獲取賬號列表命令，不需要批准就可以獲得結果。
更復雜的規則可參考官網文檔： https://github.com/ethereum/go-ethereum/blob/master/signer/rules/rules.go
3、外部API
客戶端可以通過外部API與Clef服務進行交互，Clef支持的外部API有：
- account_new 創建賬號
- account_list 列表賬號列表
- account_signTransaction 交易簽名
- account_signData 簽名數據
- account_signTypedData 對符合 EIP712 的結構化數據進行簽名
- account_ecRecover 解析已簽名數據對應的賬號地址
- account_import 賬號導入
- account_export 賬號導出
可以看到外部API和Geth中的賬號管理的 personal 模塊提供的方法類似。
4、UI API
除了外部API，Clef也提供了UI API，通過 --stdio-ui 命令可以開啓一個本機的基於控制檯的標準輸入輸出UI。
通過集成UI API的接口，可以對簽名器進行可視化。目前已有的可視化簽名器有：
5、與Geth整合
在Geth v1.9.0內置了通過--signer
$ geth --rinkeby --signer=~/.clef/clef.ipc console
> eth.accounts
["0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3", "0x086278a6c067775f71d6b2bb1856db6e28c30418"]
> personal.listWallets
[{
accounts: [{
address: "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
url: "extapi://$HOME/.clef/clef.ipc"
}, {
address: "0x086278a6c067775f71d6b2bb1856db6e28c30418",
url: "extapi://$HOME/.clef/clef.ipc"
}],
status: "ok [version=6.0.0]",
url: "extapi://$HOME/.clef/clef.ipc"
}]
> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[0]})
在發起查看賬號列表時，需要我們在Clef服務中進行確認。
三、後話
雖然Clef已經發展了2年多，但一直沒有真正應用起來，更沒有實現其替代Geth節點的賬號管理模塊的目標。究其原因，我認爲有三點：
- 應用場景受限。在Dapp應用中，一般使用MetaMask或其他錢包，用戶使用自己的以太坊賬號進行交易簽名，而不會用到節點中的賬號。
- 使用成本高。在一些特定場景（如溯源）會使用一個服務賬號發起交易，這時候就可以使用Clef進行簽名，但前提是需要業務方維護一個Clef服務，無疑是增加了業務成本。
- 有可替代方案。對與節點的賬號管理與消息簽名都有其他的方案，Clef並不是唯一的。
四、參考
- https://geth.ethereum.org/docs/clef/tutorial
- https://github.com/ethereum/go-ethereum/tree/master/cmd/clef
- https://www.jianshu.com/p/ea763d5599d2
一、初識
以太坊go-ethereum在1.8.4版本中就開始引入了Clef，並在1.9.0版本中進行了較大的升級，其主要目的是以一種更安全、獨立的方式替代以太坊節點的賬號管理模塊。
1、Clef是什麼
官方文檔對Clef的描述是：
Clef最終目標是代替Geth的節點賬號管理，可用來對交易進行簽名。Clef可以使DApp不必依賴Geth的帳戶管理，當DApp需要對數據（或交易）進行簽名時，可以將數據發送給Clef，在經過授權同意後，Clef將把簽名返回給DApp。
從官網的描述中，並沒有看出Clef的獨特之處，甚至是存在的必要。賬號管理在Geth的JSON-RPC API中提供的personal命名空間下的方法就挺全面的。交易簽名功能在web3中也有提供。那麼爲什麼要獨立出一個Clef模塊呢？
2、爲什麼要有Clef
Clef本質上是一個獨立的交易簽名器。Clef 背後的思想是將帳戶管理與Geth客戶端其它功能分開。Clef通過 IPC 或 HTTP 暴露了一個輕量API，可以被Dapp用作簽名工具。
Clef最大的特點是提供了：
- 請求確認，實現一方請求一方確認；
- 規則引擎，實現自動化請求確認。
二、探索
1、Clef啓用
初始化啓用Clef服務需要先進行初始化，初始化時需要輸入一個密碼，這個密碼是用來加密master種子的。初始化命令：
clef init
啓動服務初始化後就可以啓動服務了，啓動時我這裏指定了keystore目錄、chainid、開啓了HTTP-RPC服務，端口使用模塊8550
clef --keystore ./keystore/ --chainid 4 --rpc
請求測試啓動成功後可以重新打開一個shell，運行查看賬號列表的命令，進行簡單測試，命令爲：
echo '{"id": 1, "jsonrpc": "2.0", "method": "account_list"}' | nc -U ~/.clef/clef.ipc
在clef服務的shell窗口中，此時可以看到是否授權查看，輸入 y 後即授權通過。如下圖所示。
更多命令可查看官網進行使用。
2、規則引擎
Clef的規則引擎是一個很強大的東西，可以通過設置規則，讓某些請求自動批准執行。
比如我們上邊的查看賬號列表的命令，需要Clef管理員手動確認，我們通過配置如下規則（一段js代碼），可以實現免授權。
function ApproveListing() {
return "Approve"
}
規則文件計算hash
> sha256sum rules.js 8d089001fbb55eb8d9661b04be36ce3285ffa940e5cdf248d0071620cf02ebcd rules.js
證明規則文件證明規則文件的目的是防止有人對規則文件進行修改，這裏將規則文件的hash使用attest命令進行證明。
> clef attest 8d089001fbb55eb8d9661b04be36ce3285ffa940e5cdf248d0071620cf02ebcd
使用規則文件啓動clef
clef --keystore ./keystore/ --chainid 4 --rpc --rules rules.js
此時，我們在運行獲取賬號列表命令，不需要批准就可以獲得結果。
更復雜的規則可參考官網文檔： https://github.com/ethereum/go-ethereum/blob/master/signer/rules/rules.go
3、外部API
客戶端可以通過外部API與Clef服務進行交互，Clef支持的外部API有：
- account_new 創建賬號
- account_list 列表賬號列表
- account_signTransaction 交易簽名
- account_signData 簽名數據
- account_signTypedData 對符合 EIP712 的結構化數據進行簽名
- account_ecRecover 解析已簽名數據對應的賬號地址
- account_import 賬號導入
- account_export 賬號導出
可以看到外部API和Geth中的賬號管理的 personal 模塊提供的方法類似。
4、UI API
除了外部API，Clef也提供了UI API，通過 --stdio-ui 命令可以開啓一個本機的基於控制檯的標準輸入輸出UI。
通過集成UI API的接口，可以對簽名器進行可視化。目前已有的可視化簽名器有：
5、與Geth整合
在Geth v1.9.0內置了通過--signer
$ geth --rinkeby --signer=~/.clef/clef.ipc console
> eth.accounts
["0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3", "0x086278a6c067775f71d6b2bb1856db6e28c30418"]
> personal.listWallets
[{
accounts: [{
address: "0xd9c9cd5f6779558b6e0ed4e6acf6b1947e7fa1f3",
url: "extapi://$HOME/.clef/clef.ipc"
}, {
address: "0x086278a6c067775f71d6b2bb1856db6e28c30418",
url: "extapi://$HOME/.clef/clef.ipc"
}],
status: "ok [version=6.0.0]",
url: "extapi://$HOME/.clef/clef.ipc"
}]
> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[0]})
在發起查看賬號列表時，需要我們在Clef服務中進行確認。
三、後話
雖然Clef已經發展了2年多，但一直沒有真正應用起來，更沒有實現其替代Geth節點的賬號管理模塊的目標。究其原因，我認爲有三點：
- 應用場景受限。在Dapp應用中，一般使用MetaMask或其他錢包，用戶使用自己的以太坊賬號進行交易簽名，而不會用到節點中的賬號。
- 使用成本高。在一些特定場景（如溯源）會使用一個服務賬號發起交易，這時候就可以使用Clef進行簽名，但前提是需要業務方維護一個Clef服務，無疑是增加了業務成本。
- 有可替代方案。對與節點的賬號管理與消息簽名都有其他的方案，Clef並不是唯一的。
四、參考
本文參與登鏈社區寫作激勵計劃 ，好文好收益，歡迎正在閱讀的你也加入。
- 發表於 18分鐘前
- 閱讀 ( 10 )
- 學分 ( 0 )
- 分類：以太坊
