1. Alice & Bob 转账与打电话的故事
在正式介绍 Celo 的基于地址加密方法前，让我们回想一下从用户角度来看 BTC 或者 ONT 等如何进行转账。假设 Alice 向本体新用户 Bob 转移1 ONT。Bob 首先需要下载本体的官方钱包 ONTO 或者 OWallet，创建一个地址，保存和这个地址对应的私钥。
注意！！！这个地址对于普通人来说，是很难记住的一个超长字符串。然后，Bob 需要通过其它渠道，比如电话或者邮件等，把他的地址告诉 Alice。至此，Alice 可以向 Bob 的地址转 ONT。
再考虑另外一个场景，Alice 和 Bob 都在某个集团的不同部门工作，Alice 想给 Bob 打个电话进行某项工作内容的交流。这时候，该集团在内部公开的电话簿起到了重大作用。Alice 记得 Bob 的名字和他的工作部门，她通过电话簿根据 Bob 工作的部门快速找到了 Bob 的名字，上面赫然印着 Bob 的电话号码。于是，Alice 拨通 Bob 的电话，和 Bob 进行了愉快的交流。
在上面两个例子中，一个主要的区别在于，第二个场景中存在一个基础设施，一个电话簿，这保证了用户和他的信息进行对应。通过这个基础设施，用户可以快速方便地查找到另外一个用户。
2. 如何把工作邮箱作为公钥？
在如今的互联网世界中，公钥一般是一串不可记忆的字符串，比如 RSA 加密算法的公钥可能是长达2048位的比特串，用户的公钥和用户信息绑定主要通过 PKI 完成。那么，是否有方法把用户邮箱，比如 [email protected] 等，作为用户公钥呢？
答案是肯定的，那就是基于身份的加密。在基于身份的加密中，可以将用户邮箱作为公钥，用用户邮箱将要发给用户的消息加密。用户收到密文后，用其对应的私钥进行解密。这其中带出了一个问题，用户的公钥是确定的，比如就是他的邮箱，那如何确定用户的私钥呢？
我们知道在一般的密码系统中，私钥随机生成，公钥都是由私钥生成的。而在基于身份的加密中，要求在用户公钥（邮箱等）确定的情况下生成用户的私钥。为了解决这个看似不可能的需求，基于身份的加密引入了一个可信第三方，或者称为密钥生成中心的机构，它拥有系统的一个主密钥，它根据主密钥和用户公钥（邮箱等）派生出该公钥对应的私钥，再将私钥分发给用户。
3. Celo 提出的基于地址的加密
在基于身份的加密中，密钥生成中心的存在会使得其应用受限，尤其是在一些开放、无需许可的环境中。Celo 根据基于身份加密的理念，提出了基于地址的加密。其主要思想是用一个由多个验证者组成的 P2P 网络来维护<地址，公钥>的映射关系数据库，其中地址可能是邮件地址、电话号码或者 IP 地址等，而公钥是由用户按照传统的公私钥对生成方法来生成。就像上一篇技术视点中指出的一样，通过这个映射关系，用户可以使用任意账号（如手机号等）作为公钥将 Celo 货币发送给朋友，从而可以轻松地向联系人付款。同时，即使朋友尚未下载钱包，用户也可以将 Celo 货币发送给朋友。
这个由多个验证者组成的 P2P 网络开放无需许可，任何人都可以自由加入网络中成为验证者，而验证者可以自由离开和重新加入。验证者不仅存储<地址，公钥>映射关系的数据库，同样也为需要加入的记录进行证明。
当 Alice 想把自己的映射关系<[email protected]，039…c85>加入到该数据库中，她需要向系统的认证合约发起请求，并支付该次认证所需的费用。认证合约会从系统的验证者中随机挑选一个并向被挑中的验证者发送一个消息。该验证者把消息签名后发送给 Alice。Alice 在此基础上同样对消息进行签名，然后发给认证合约，当认证合约对签名验证成功后，将会记录此次认证。认证可以根据应用的需要进行多次。
对认证进行收费可以抵抗 DDoS 攻击，多个验证者的存在可以抵抗单点失败。如果要防止单个验证者做恶，可以在验证者集合之间对认证请求的处理进行共识，以防止恶意验证者将自己的公钥映射到其他人的地址上。另外一个问题是，对于<地址，公钥>这样公开的映射关系数据库，如果直接将用户邮箱作为地址，将会暴露用户隐私。因此，Celo 采用了将地址进行加盐哈希操作的方法，即存储的是<Hash(地址)，公钥>这样的映射关系。另外，对于易用性和其它隐私性考虑等方面，Celo 也给出了一些可能的解决方案，如使用一个地址对应多个不同用途的公钥等。
4. 结 论
从本质上来说，Celo 基于身份的加密，就是采用多点维护的<地址，公钥>数据库来记录用户地址和公钥的映射关系，一群验证者来保证这个数据库中记录的正确性。其他用户或者应用可以根据这个数据库来查询用户的公钥。但是当地址进行哈希后，其本身具有的一些优点如易记忆性也将消失。
我们将持续关注 Celo，也希望和对 Celo 技术特点感兴趣的小伙伴进行交流。