初识Clef
以太坊版本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命令行做三件事:
- 初始化一个密码,用以后续加密以太坊账户密码、加密规则集文件信息摘要值,以及其他需要加密的信息;
- 添加一个规则集文件摘要信息,并保存规则集文件;
- 添加一个以太坊账户和密码,信息会以加密方式保存;
之后启动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的优秀思想,扩充基础功能。