一、初识

以太坊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的接口，可以对签名器进行可视化。目前已有的可视化签名器有：

• 基于Python的，如 QtSigner
• 基于golang的，如 Clef UI

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节点的账号管理模块的目标。究其原因，我认为有三点：

1. 应用场景受限。在Dapp应用中，一般使用MetaMask或其他钱包，用户使用自己的以太坊账号进行交易签名，而不会用到节点中的账号。
2. 使用成本高。在一些特定场景（如溯源）会使用一个服务账号发起交易，这时候就可以使用Clef进行签名，但前提是需要业务方维护一个Clef服务，无疑是增加了业务成本。
3. 有可替代方案。对与节点的账号管理与消息签名都有其他的方案，Clef并不是唯一的。

四、参考

• https://geth.ethereum.org/docs/clef/tutorial
• https://github.com/ethereum/go-ethereum/tree/master/cmd/clef
• https://www.jianshu.com/p/ea763d5599d2