如今，我们常采用的是账本机制。而账本机制往往相关联的是一种被称为“账户”的身份认证方式。所谓的“账户”常见工作模式就是“账号”和 “密码”。
账本的维护机构利用账号与密码识别用户的身份，从而确定账本上记录的数据的金额的所有者。在这种模式下，“账号”代表的是用户的身份标识，密码是一种确定用户身份标识正确性的工具。
账本模式中记录身份的信息大致长这样：
在这个模式中，当张三想要向其他人转账的时候，向账本提供自己需要操作的账号，同时还有自己提前 预留在账本维护者中的密码信息。账本维护者会根据账号与密码进行认证，确保是张三真实在操作账 本。
实际上，密码只是一种认证方式。在具体的实现当中，还可以采用手机号，邮箱等各种方式。只要能够保证，验证用户提交的“密码”信息是曾经预留在账本维护者这边的信息即可。这里的“密码”泛指任何一种可以用于认证用户身份的信息。
这种模式是一种非常简单的身份认证模式。因为只需要保证“现在”用户提供的身份认证信息与“曾经”用 户在账本维护者这里提供的身份认证信息一致。
这种模式的优势点在于可以兼容多种身份认证模式。但这种模式有一个很大的弊端，因为<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>。
打通记录数据
在现实生活中，我们会遇到一个很常见的场景，就是我们可能会在不同的银行都拥有不同的账户。
每当我们在银行创建新的账户时，银行会为我们的账户创建一个账户ID。同时，会让我们预留一个密 码，通过这个密码我们就可以方便地认证我们的身份。
如果我们需要多个账户，只需要重复着一个过程。不同银行的开户也都是采用的相同模式。
在这里我们会遇到一个问题。
本质上，每一家银行所维护的账本信息都是不同的。一旦我们想要跨账本进行操作，便会变得很困难。因为每一个账本都会维护自有的一套账号体系。在这个体系中，如何进行账本信息的打通便是一个困难的事情。
出于安全考虑，作为用户我们不可能直接把自己的密码信息交给其他人，代替我们进行操作。但是跨账本的操作又是客观存在的问题。为了解决这样的问题，往往需要维护一个复杂的系统来进行跨账本的信息共享。
那么，有没有办法能够解决这个问题？
现有的跨系统账本数据沟通往往是在账本本身动心思。通过直接对账本上的数据传输来实现跨系统账本操作。这种模式的难点就在于，我们需要复杂的中间协调系统在各个账本系统之间进行协调。
但这个问题如果在DCEP的环境下，就会简单许多。
密码学与非对称加密
首先，DCEP由于本身并不采取账本的方式实现数字货币的功能，而是采用“真实货币”的方式。因此，现有的、基于账户的跨系统流转与身份认证方式便不可行了，我们需要一套新的模式来进行。
基于账户体系的模式下，我们会为每一个用户提供一个唯一的用户ID，这个ID用来标记用户的身份。同 时，用户需要在系统中提前放置一个密码，系统会根据密码来验证用户的身份。这两个数据都需要放置在系统中进行记录。
但这种模式存在的问题是，由于密码是用户与系统都知道的一个信息，当系统在试图打通其他的系统的时候，不能随意的共享密码。
账本体系中的账号与密码是相对独立的，这其实是导致我们没办法随意共享密钥的问题关键。
理想情况下，密码应该只有用户知道的。接下来，只需要让用户的ID与密码关联即可。也就是说，我们可以用用户的身份验证来用户提交的信息的正确性。在这个过程中并不需要泄露密码。
实际上这个问题在现代密码学中已经存在一套标准的方式来处理这些事情，这种方式被称为<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>。
不同于账号密码体系中，非对称密码体系使用公钥与私钥代替了账号于密码。其中公钥可以用于标识用 户的身份，也就是原本账号的功能；私钥用于证明用户的身份，也就是原本密码的功能。但是不同于账 号密码之间的无关联性，公钥与私钥是有关联性的。用户可以私钥推算出公钥，然后只需要将公钥记录 在系统中即可。
由于密码学原理，我们可以根据私钥推出公钥，但是不能从公钥推断出私钥。因此，将公钥存储在外部系统，即便是完全公开也不会出问题，不会导致私钥泄露。
交易的验证过程
在账号体系下，进行操作之前需要首先将密码提交给系统进行登陆，验证用户的身份正确之后才能进行 下一步操作。这个流程中，用户需要向账户系统提交密码。
但是使用公钥的话，用户提交操作不需要前置的登陆过程。取而代之的是，在每次提交之前将提交的数 据使用私钥进行签名，然后把得到的签名用户的操作指令一起发给系统，系统可以直接认证用户的操作。
仔细观察这个模式，在具体的传输过程中，并不存在私钥的提交过程。只需要把签名和交易指令提交，再加上之前提交的公钥就可以验证用户的身份了。
因此，在不对用户系统进行任何修改的情况下，我们也可以将同一套规则对应到不同的账户系统，保证一套用户系统可以支持多个账户系统， 实现数据的跨系统流转。
由于签名算法与验证算法的规则是有标准所规定的，不同的系统在实现的时候可以保证实现的一致性。 同时，由于私钥不会被暴露，所以一套客户端可以同时对接在不同的系统上，实现系统的通用化处理。
