一、初识
以太坊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后即授权通过。如下图所示。
image.png
更多命令可查看官网进行使用。
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 <API endpoint>将本地或远程Clef服务用作帐户管理。
$ 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并不是唯一的。
网友评论