以太坊版本1.8.4开始，增加了独立签名人Clef功能，该功能目前尚处在alpha阶段。它主要实现了签署交易、签署数据和管理账户。它的README中是这样描述的：
Clef可以用来签署交易和数据，并且可以代替geth的账户管理。
这使DApps不依赖于geth的账户管理。 当DApp想要签署数据时，它可以将数据发送给签名者，然后签名者将向用户提供上下文并要求用户签署数据。 如果用户授予签名请求，签名者将签名发送回DApp。
此设置允许DApp连接到远程以太坊节点并发送本地签名的事务。 这可以在DApp连接到远程节点的情况下提供帮助，因为本地以太坊节点不可用，不与同步链或没有内置（或有限）帐户管理的特定以太坊节点同步。
Clef可以在同一台机器上作为守护进程运行，也可以在usb-stick（如usb armory）中运行，或者在QubesOS类型的os设置中运行单独的虚拟机。
乍听起来好像没什么新鲜的，目前以太坊DApp通过web3接口就可以完成的功能。通过通读代码和文档说明后发现，其实它最大的亮点有两个：
- 人机交互，实现对一笔发起的交易进行另一方批准确认；
- 规则引擎，实现自动化交易确认。
Clef内置了一个JS解释器引擎，使用JS编写自动化批准规则，来达到自动化交易确认的目的。以下是我对Clef服务的理解：
clef_ structure.png
Clef命令行做三件事：
- 初始化一个密码，用以后续加密以太坊账户密码、加密规则集文件信息摘要值，以及其他需要加密的信息；
- 添加一个规则集文件摘要信息，并保存规则集文件；
- 添加一个以太坊账户和密码，信息会以加密方式保存；
之后启动Clef，它会提供HTTP RPC服务，调用它的接口，发起交易；经过规则引擎确认，使用以上第三步保存的以太坊账户，从keystore中用密码解开账户私钥，对交易进行离线打包，并返回打包后的结果。这里的初始化密码很重要，它是一切加密存储的源头，Clef文档中提到该密码需要由用户自行保管，就像是用户保管ssh key一样。
每一个Clef RPC请求都会用单独的JS解释器引擎处理，因此全局变量在规则集文件中是没有作用的。可以通过磁盘存储文件的方式共享变量。
规则引擎很强大，可以做一些智能合约做不到的事情，比如定时转账、24小时内转账限额等等。可以说弥补了智能合约的不足，并且可想象的空间有很多。目前Clef和以太坊并未完全打通，Clef返回值只会吐出离线签名后的原始数据，还需要客户端自行将原始数据发送给以太坊节点；并且Clef安全性也有待考证，一旦初始化密码被窃取，用户的以太坊账户就有被盗走的风险。
BOX (A business wallet solution)在保护企业私钥方面考虑得比较多，企业的私钥由多人共管，缺少任何一个人的口令都无法还原私钥。并且BOX的私钥保存在签名机内存中，受到守护程序的保护，一旦检测到异常情况，守护程序会将签名机杀死，签名机在停机前会清零私钥所在内存数据。
BOX对签名机私钥所在内存也做了防护，在私钥所在内存段前后设置内存守护页，所以如果任何操作尝试读写这些页的话，SIGSEGV就会抛出一个访问冲突，进而保护私钥不被窃取。
Clef的规则引擎很好，BOX或许将借鉴Clef的优秀思想，扩充基础功能。
