本节继续 Blockstack 这个话题，稍微展开来讲讲 Gaia 是如何工作的，App 又是如何跟 Gaia 通信的呢？

传统应用的存储架构

首先咱们来看看 Web2.0 时代的应用是如何跟数据库通信的。

现在有两个用户，Alice 和 Bob ，两个人都运行了自己的客户端软件，可能是 Web 应用，也可能是手机原生应用。他们会和同一台服务器进行通信，服务器上运行某种数据库。这是云计算架构的基本特征了。

那么各方之间如何通信呢？ 假设 Alice 要给 Bob 发一条实时信息。首先 Alice 的信息要先发送到服务器上，然后服务器把信息再转发给 Bob 。Alice 和 Bob 之间并不是直接传递信息的。整个的通信过程是由这个服务器背后的平台公司控制的。这种方式的优点是结构比较简单：因为 Alice 和 Bob 都连接同一个服务器，同一个数据库，所以双方要找到对方是比较简单的。相当于双方的客户端都会到一个地方读写信息。但是这种方式的缺点是基于信任，Alice 信息发出去之后，自己是不知道信息会最终到谁手里的，只能选择信任平台公司会忠实的把信息转给 Bob ，所以会对平台形成信任，不能自由的决定自己的数据要存储在哪里，也不能真正拥有自己的数据。

Gaia 给出的解决方案

对应上面的问题，用去中心化的思路可以给出下面的解决方案。

首先要去掉信任，让 Alice 和 Bob 直接用加密通信的方式进行沟通。其次是要解除数据对平台的绑定关系，允许客户创建自己私人的存储区域。解决方案最终的凝结，就是 Gaia 系统。

Gaia 让用户创建自己的小私有云，它最大的特征有两点。第一，每个用户都需要有自己的加密密钥。第二，数据不再存储到单一的服务器上，而是由每个用户单独存储自己的数据。Alice 会用客户端软件跟自己的私有云，也就是部署了 Gaia 系统的服务器进行沟通，读写过程都是加密的，Bob 也是同样的过程。

这里会变得复杂一些的就是当 Bob 想要读取 Alice 的信息的时候，他需要先找到 Alice 的云，如何才能找到呢？第一步是要解析 Alice 的用户名，通过 BNS （ Blockstack Naming System ）系统，就可以找对 Alice 的数据存在哪里了。第二步，要找到两个人正在使用的是哪个应用，每个应用的数据都存储到自己的文件夹内。第三步，按照 Gaia 的读接口，去读取 Alice 的数据。

Gaia 的主要接口

Gaia 定义了接口来完成上面需要的工作。

PUT /store/<public-key-hash>/<filename>

帮助 public-key 对应的用户往自己的存储区写数据。提交请求的时候，一般还需要同时提交这个 public-key 对应的私钥签名，以确保发出写请求的人的确有这个权限。

读取这个 public-key 对应的用户的数据，就执行

GET /<public-key-hash>/<filename>

也可以用

GET /hub_info/

读取存储区相关信息。

如何构建一个 Gaia 服务器

一个 Gaia 服务器上会运行多个用户的存储区域。Blockstack 官方也会为每一个用户提供数据存储区。服务器会对客户端提供 GET/PUT 接口，来完成 读/写 操作。写操作需要用户提供 ECDSA （椭圆曲线签名算法）签名。每个 Blockstack 用户都默认会有 ECDSA 密钥。

Gaia 对微软的 Azure 和亚马逊的 S3 服务都有默认的支持，用户可以方便的在这些平台上搭建属于自己的 Gaia 服务。

总结

最后说句题外话，整个去中心的架构虽然是可行的，但是推进过程不可能一步到位，而是可以分步骤进行，也就是说，去中心化的系统也可以临时性的依赖一一些中心化的基础设施，例如，这里 Gaia 的运行暂时还要依赖现有的中心化的 DNS 系统。因为 Blockstack 自己的 BNS 系统，要想在全球都充分扩展，保证足够的访问速度，并不是一蹴而就的事。