我们先来设计几个基于存储网络的数据分享的原则：

1、数据分享过程中只有数据的接收者能看到明文。其他人，当然也要包括存储网络都看不到数据的明文章。这一点特别重要，中心化的分享方案一般情况下存储服务提供商都是可以看到信息明文的，并且可能进行一定的审查。这样你的信息就有被泄漏的风险。

2、数据的加密、传输尽量使用存储网络的运算能力及带宽。这也正是我们使用存储网络时行数据共享的意义所在。如果不使用有存储网络，而采用双方直接分享（如拷贝、点对点的文件直传）则不会有今天的讨论了。

上面两点显而易见，这里就不多作讨论。

公钥直接加密法
我们先来看看如果直接分享，我们有什么简单的方法安全的进行数据的分享。下面以Alice（数据拥有者）向Bob（数据接收者）分享一份文件为例，说明公钥直接加密法。

1、Alice使用Bob的公钥对文件进行加密。

2、将数据分享给Bob。

3、Bob解密文件，获取信息。

这个过程简单而直接，这就是公钥直接加密法。但如果面对使用存储网络进行数据分享的情况公钥直接加密法有没有优势呢？

由于数据存储在存储网络中，且自己的私钥不能泄漏，所以Alice需要先下载文件，解密、重新使用Bob的公钥加密再上传到存储网络中，然后Bob可以从存储网络中获取文件。

还有一个问题，如果Alice有一天又想把数据分享给Julia，那么他需要再重新将上面的操作进行一遍。

分析上面的问题，我们其实只使用了存储网络的存储功能，而没有使用存储网络的计算功能。所以“直接公钥加密”是一种非常笨拙的方法。

代理重加密
如果仔细分析上面的过程，我们会发现，其实这个过程很简单很简单。这个过程中，输入是用Alice的公钥加密过的文件，输出是经过Bob公钥加密过的文件。那么Alice能不能在不泄漏自己的私钥给存储网络的同时，又做到这一点呢？

简单一点说，就是Alice能不能在不泄漏自己私钥的情况下，让存储网络将经Alice公钥加密过的文件转化为给Bob的公钥加密的文件呢？当然可以，这种方法就叫做代理重加密。

在上面的图示中，Alice上传的仍然是经自己的公钥加密的文件。如果Alice想要把此文件转化为经Bob的公钥加密过的文件，Alice就将Bob的公钥和自己的私钥进行一些运算（不可逆运算），将运算结果（上图的RKA-B）发送给存储网络，存储网络就可以使用RKA-B对文件进行转换，转换完成后自然就可以分享了。

现在大家理解了“代理重加密”这个词了吧？代理就是指的存储网络（云存储服务提供商），重加密的意思是将文件从Alice公钥加密过的版本，转变为Bob的公钥加密的版本。

这种算法是不是很神奇，没有数据泄漏风险，也没有安全隐患。其实PDash（CPChain的一个小项目）就实现了这样一个功能。

代理重加密会是终极的解决方案吗？
我只能说，以我的技术能力来看，代理重加密还有很长的路要走。

1、针对特定人群的分享。比方说我想把我的文件分享给公司同部门的员工，现在代理重加密只能一个一个的进行重加密，消耗的大量的计算资源，也消耗了大量的存储资源。当然，这一点GNX的技术黄皮书里面也提到过，叫针对属性的分享。

2、使数据在特定的智能合约上分享。智能合约可以很好的控制时间、空间上的条件，所以说这一点很重要。这一点代理重加密可以实现，但需要公链的配合。现在只发现有项目有过设想，没有看到实际产品。

最后总结
今天就写到这里，代理重加密是一种数据分享的非常基础的算法，了解这种算法如何工作不仅对理解GNX的工作原理有帮助，对于理解其他所有的具有数据分享功能的公链都有很大帮助。