区块链的从技术角度讲，本质上是一个分布式的数据库。区块链技术单纯理解起来较为复杂，因此我们从分布式的数据库角度来探讨区块链技术。分布式数据库包括数据存储、点对点可靠传输、存储过程与触发器（智能合约）、数据安全四个部分，接下来详细展开讨论：
1、分布式数据存储
区块链技术的数据共享是一个分布式的记账簿，交易记录具备多个副本，因此首先要解决分布式数据存储的问题。
1）区块链存储的基本单元是区块，区块采用链式结构，即新增的区块（类似数据库一行记录）都知道自己前一个区块（前一行记录）是什么，可以一直追溯到根，区块的标识是区块的哈希值，同时链式结构保留了业务产生的轨迹，可以在新增交易的时候根据前面的记录做校验，保证了区块的内容不容易篡改。
这种模式，我们在传统的数据库设计也会采用，例如拉链表的形式，每次对数据的更新都采用追加（Insert而不是Update）模式，有起始时间、失效时间和是否生效标识，保持全部交易历史。区块链把这一点变成了一种底层固有模式，加入了哈希、时间戳等机制在技术上保证链条的正确性，因此非常有价值。
2）既然是分布式、多中心的存储方式，就必须解决存储时的分布式一致性问题。在区块链的前身比特币应用中，解决这一问题的方式是工作量证明（POW Proof-Of-Work）方式，即通过工作以获得指定成果，用成果来证明曾经付出的努力。这一问题归结为共识问题，工作量证明是达成共识的一种方式。
于是就产生了权益证明（POS Proof of Stake）方式，是一种通过业务规则达成共识的方式；实用拜占庭容错（PBFT Practical Byzantine Fault Tolerance）方式，是一种通过技术规则达成共识的机制；定向工作量证明机制（DPOW）是一种随机验证机制，由UENC实验室首创，同时也应用在UENC公链中。
2、点对点可靠传输
区块链技术是一组技术的组合，既然是一个分布式的记账簿，就要解决数据可靠传输问题。包括记账节点（信任节点）之间、非记账节点（非信任节点）、客户端与记账节点（信任节点）之间的数据传输。在以前我们的方案中，往往通过可靠消息或者P2P方式解决数据传输问题，这些技术也被用于区块链技术中。
但必须说明的是，在真实业务场景下，不可能把所有的数据都记录在记账簿中，部分业务数据还是要保存在自己的系统中，这就还需要在技术框架上做到本地业务数据与区块链的记账簿保持一致，后面微服务架构与区块链技术整合时会具体阐述，总之，区块链平台只能保证自身数据之间的一致，业务不能完全依赖区块链平台保证数据一致性。
3、智能合约：触发器与存储过程
智能合约是指当一定条件满足的情况下，可以被自动执行的数字化合约。实现这一特性，在数据库中就是由触发器和存储过程完成的。虽然在目前流行的应用架构中，都不建议把逻辑写在存储过程中，但触发器和存储过程还是常用的工具，尤其在数据迁移相关的运维活动中。区块链技术中智能合约就是触发器和存储过程，他是一个在沙箱中运行的脚本，用于执行区块链业务中的业务逻辑，也可以用于各种检查。
举个例子，A产生一笔支付时，可以通过智能合约在数据链上进行检查，如果发现A的余额无法支付这笔交易，就可以中止这笔交易。和存储过程相比，智能合约运行在沙箱之中，不能对外部API做调用。这也比较好理解，如果允许外部调用，就可能无法保证自身的数据一致性，后面我们会讲到这种缺陷如何弥补。美中不足的是目前的智能合约并不支持SQL语法。
4、数据安全
交易数据是透明的，但不是全部透明，而是相对透明，这是区块链技术的一个难点，关键有二：（1）如何保护隐私，仅仅能看到自己可见的数据；（2）密钥分配问题，例如新加入链中的一个节点会被分配一个新的密钥，如何用这个密钥解读以前链中存储的信息。可见与不可见，这是一个矛盾，理论上没有一个完美的方案。
举个例子，在一个小企业支付的联盟链中，核心企业包括某银行、企业A，为A的上下游企业提供信贷业务，对于所有交易的数据，银行和核心企业A都是可见的，他们拥有记账节点，对于其他加盟企业，只拥有非记账节点，他们虽然也有全部的数据，但是只能看到自己相关的数据。
很明显，加盟企业放弃了自己的部分隐私权，但也得到了生意的机会，这种方式加盟企业是可以接受的，就好比贷款企业要向银行提供经营数据一样。数据安全问题，在技术上很难解决，但通过业务手段是可以规避的，这也是很多人看好联盟链的重要原因。
