DCEP与现有的电子支付系统有一个最大的不同点在于，DCEP整体系统的设计是一个分布式的系统，整个支付流程需要多个系统与用户的终端协同完成工作。而现有的电子支付，例如微信支付宝等产品，则是只采用了一个支付中心，用户的设备仅仅是作为一个收集信息的终端。
DCEP所具有的货币流通属性，其流通过程的细节，以及对离线支付的要求，需要系统以分布式的形式运行。
因此，作为一个分布式系统，DCEP的设计势必会受到一些分布式系统的基本逻辑与理论的影响。同时，DCEP的设计也会反映出这些逻辑与理论。
CAP理论
CAP理论是原本来自分布式数据库中的一个理论，这个理论描述了一个分布式系统设计中的取舍依据。
CAP是分布式系统中一致性（Consistency），可用性（Availability）与分区容错性（Partition tolerance）三个单词的简写。
这个理论的基本描述是，<u style="border-bottom-color: currentColor; border-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-source: none; border-image-width: 1; border-left-color: currentColor; border-left-style: none; border-left-width: 0px; border-right-color: currentColor; border-right-style: none; border-right-width: 0px; border-top-color: currentColor; border-top-style: none; border-top-width: 0px; box-sizing: border-box; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; -webkit-tap-highlight-color: transparent;">分布式系统中三者最多只能实现两点，不能同时兼顾</u>。实际上这样的三选其二的理论有很多，不仅仅是在分布式系统领域有体现。
这三者分别具体地表达了如下的含义：
- 一致性：指的是分布式系统中所有节点被写入数据后，能立即的在任何一个其他的节点中能够读取到写入的值。
- 可用性：指的是整个系统能够一直正常的进行操作，来自客户端的请求可以一直得到系统的正常响应。
- 分区容错性：指的是其中部分节点离线，或网络出现故障的情况下，系统仍然能够正常使用。
实际上，分布式系统的设计逻辑，阐述的是分布式系统的三个属性中，只能有两个是强限制的，而另外一个是弱限制的即可。
CAP理论中三元素可以两两组合,形成三种组合方式：
- 优先保证一致性与可用性，放弃分区容错性：实际上不存在这样设计的系统。因为一旦系统放弃了分区容错性，那就意味着这个系统不再是一个分布式系统的构建方式。
- 优先保证一致性与分区容错性，采用弱可用性：所谓的优先一致性与分区容错性，就是设计系统能够保证所有系统的一致，即便这种一致性在有节点离线的情况下也能保证。实际上系统会不断的重复在系统的组成节点上进行数据同步，并且是强一致的同步。这就导致了系统中某一个节点存在写入行为时，其他的节点不能够写入，只有数据同步后才可以完成。实际上大多数区块链系统，尤其是经典的比特币系统就是这样的设计。在区块链系统的一个区块周期中，只有一个节点可以向网络中写入数据，其他节点的写入都需要等待下一个区块时间。
- 优先保证可用性与分区容错性，采用弱一致性：这种情况下，系统往往会牺牲一定的一致性来保证整个系统可以一直接收来自外部的写入请求。但是牺牲一致性不是不保证一致性，而是整个系统会随着时间的推进，逐渐的达成一致的要求。
根据DCEP的设计逻辑，在一次的具体交易流程中，参与交易的双方终端与数字货币登记系统构成了一个分布式系统。其中设备终端与登记系统都是这个系统中的节点。由于DCEP要求能够进行离线交易，也就意味着在一次交易中，即便有节点完全无法在线，最终在网络回复之后系统依旧能对交易的过程进行验证，保证交易的正确性。
从这个角度来看，DCEP的设计是一种优先保证AP的设计。
但是<u style="border-bottom-color: currentColor; border-bottom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; border-image-source: none; border-image-width: 1; border-left-color: currentColor; border-left-style: none; border-left-width: 0px; border-right-color: currentColor; border-right-style: none; border-right-width: 0px; border-top-color: currentColor; border-top-style: none; border-top-width: 0px; box-sizing: border-box; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; -webkit-tap-highlight-color: transparent;">这样的设计会导致一个问题，那就是DCEP一定程度上放弃了一致性</u>，会使得进行货币交易的时候有一定的双花风险。DCEP通过双重手段来降低与解决这种风险。
首先，DCEP的设计将系统出现不一致性的可能性不断降低，保证非恶意情况下不会出现交易不一致的问题，同时能够一定程度上抵御恶意的双花。
同时，DCEP通过技术之外的手段保证了一旦发生恶意双花情况，可以对进行违规操作的人进行追责与管理。
从这个角度上来说，DCEP的核心设计逻辑中，优先保障系统的可用性与系统的分区容错性，在满足这个前提的情况下尽量的提升系统的一致性。
离线支付与FLP不可能定理
上面从CAP理论的角度描述的了DCEP的整体设计逻辑。但实际上，在分布式系统领域有一个更基础的理论，这个理论被称为FLP不可能定理。
FLP定理讲的是一个分布式的一个下限，原话说的是：在异步通信场景，即使只有一个节点失败，也没有任何算法能保证非失败节点达到一致性。
展开来说，这里的异步场景指的是，节点与节点间的通讯，通讯双方是不可能知道通讯失败的事实的。
因为网络中没有预设节点发送信息的到达时间，所以节点收不到信息，只能被认为消息延迟了，而不是节点离线导致通讯失败。
而在这样的异步网络环境下分布式系统是无法正常的运作的。
因为只要有一个节点出现问题，整个网络中所有节点上的数据无法达成一致，即满足上文所说的一致性。FLP定理指出了分布式系统正常运作的最低要求，只要我们的网络环境不低于FLP中的要求，系统就能够正确的运行。
放在DCEP的场景中，NLP定理同样也指出了离线支付的最低限度，同时也表明了系统可能出现问题的地方。
DCEP如果想要保证离线支付完成的绝对正确性，就需要抛弃异步通讯假设，也就是需要对网络通讯中钱包的离线时间做出限定，当钱包过久离线，交易就可能出现不一致的情况，可能会导致双花问题的产生。
但如果我们真正需要这个场景，可以参考Paxos的实现，降低此情况下可能产生不一致的可能性，最后采用法律手段或者惩罚性手段保证系统的正常运行，由于DCEP的设计能够保证系统识别双花的出现，并且会自动将最后一笔交易作废，通过这样的方式，为违规使用DCEP花费的行为提供了依据。
