如今挚躯，我們常采用的是賬本機制赐劣。而賬本機制往往相關聯(lián)的是一種被稱為“賬戶”的身份認證方式倡怎。所謂的“賬戶”常見工作模式就是“賬號”和 “密碼”趟薄。
賬本的維護機構利用賬號與密碼識別用戶的身份，從而確定賬本上記錄的數據的金額的所有者魄藕。在這種模式下内列，“賬號”代表的是用戶的身份標識，密碼是一種確定用戶身份標識正確性的工具背率。
賬本模式中記錄身份的信息大致長這樣：
在這個模式中话瞧，當張三想要向其他人轉賬的時候，向賬本提供自己需要操作的賬號寝姿，同時還有自己提前 預留在賬本維護者中的密碼信息交排。賬本維護者會根據賬號與密碼進行認證，確保是張三真實在操作賬 本饵筑。
實際上埃篓，密碼只是一種認證方式。在具體的實現當中翻翩，還可以采用手機號都许，郵箱等各種方式稻薇。只要能夠保證，驗證用戶提交的“密碼”信息是曾經預留在賬本維護者這邊的信息即可胶征。這里的“密碼”泛指任何一種可以用于認證用戶身份的信息塞椎。
這種模式是一種非常簡單的身份認證模式。因為只需要保證“現在”用戶提供的身份認證信息與“曾經”用 戶在賬本維護者這里提供的身份認證信息一致睛低。
這種模式的優(yōu)勢點在于可以兼容多種身份認證模式案狠。但這種模式有一個很大的弊端，因為<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>骂铁。
打通記錄數據
在現實生活中，我們會遇到一個很常見的場景罩抗，就是我們可能會在不同的銀行都擁有不同的賬戶拉庵。
每當我們在銀行創(chuàng)建新的賬戶時，銀行會為我們的賬戶創(chuàng)建一個賬戶ID套蒂。同時钞支，會讓我們預留一個密 碼，通過這個密碼我們就可以方便地認證我們的身份操刀。
如果我們需要多個賬戶烁挟，只需要重復著一個過程。不同銀行的開戶也都是采用的相同模式骨坑。
在這里我們會遇到一個問題撼嗓。
本質上，每一家銀行所維護的賬本信息都是不同的欢唾。一旦我們想要跨賬本進行操作且警，便會變得很困難。因為每一個賬本都會維護自有的一套賬號體系匈辱。在這個體系中振湾，如何進行賬本信息的打通便是一個困難的事情杀迹。
出于安全考慮亡脸，作為用戶我們不可能直接把自己的密碼信息交給其他人，代替我們進行操作树酪。但是跨賬本的操作又是客觀存在的問題浅碾。為了解決這樣的問題，往往需要維護一個復雜的系統(tǒng)來進行跨賬本的信息共享续语。
那么垂谢，有沒有辦法能夠解決這個問題？
現有的跨系統(tǒng)賬本數據溝通往往是在賬本本身動心思疮茄。通過直接對賬本上的數據傳輸來實現跨系統(tǒng)賬本操作滥朱。這種模式的難點就在于根暑，我們需要復雜的中間協(xié)調系統(tǒng)在各個賬本系統(tǒng)之間進行協(xié)調。
但這個問題如果在DCEP的環(huán)境下徙邻，就會簡單許多排嫌。
密碼學與非對稱加密
首先，DCEP由于本身并不采取賬本的方式實現數字貨幣的功能缰犁，而是采用“真實貨幣”的方式淳地。因此，現有的帅容、基于賬戶的跨系統(tǒng)流轉與身份認證方式便不可行了颇象，我們需要一套新的模式來進行。
基于賬戶體系的模式下并徘，我們會為每一個用戶提供一個唯一的用戶ID遣钳，這個ID用來標記用戶的身份。同 時麦乞，用戶需要在系統(tǒng)中提前放置一個密碼耍贾，系統(tǒng)會根據密碼來驗證用戶的身份。這兩個數據都需要放置在系統(tǒng)中進行記錄路幸。
但這種模式存在的問題是荐开，由于密碼是用戶與系統(tǒng)都知道的一個信息，當系統(tǒng)在試圖打通其他的系統(tǒng)的時候简肴，不能隨意的共享密碼晃听。
賬本體系中的賬號與密碼是相對獨立的，這其實是導致我們沒辦法隨意共享密鑰的問題關鍵砰识。
理想情況下能扒，密碼應該只有用戶知道的。接下來辫狼，只需要讓用戶的ID與密碼關聯(lián)即可初斑。也就是說，我們可以用用戶的身份驗證來用戶提交的信息的正確性膨处。在這個過程中并不需要泄露密碼见秤。
實際上這個問題在現代密碼學中已經存在一套標準的方式來處理這些事情，這種方式被稱為<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>真椿。
不同于賬號密碼體系中鹃答，非對稱密碼體系使用公鑰與私鑰代替了賬號于密碼。其中公鑰可以用于標識用 戶的身份突硝，也就是原本賬號的功能测摔；私鑰用于證明用戶的身份，也就是原本密碼的功能。但是不同于賬 號密碼之間的無關聯(lián)性锋八，公鑰與私鑰是有關聯(lián)性的浙于。用戶可以私鑰推算出公鑰，然后只需要將公鑰記錄 在系統(tǒng)中即可挟纱。
由于密碼學原理路媚，我們可以根據私鑰推出公鑰，但是不能從公鑰推斷出私鑰樊销。因此整慎，將公鑰存儲在外部系統(tǒng)，即便是完全公開也不會出問題围苫，不會導致私鑰泄露裤园。
交易的驗證過程
在賬號體系下，進行操作之前需要首先將密碼提交給系統(tǒng)進行登陸剂府，驗證用戶的身份正確之后才能進行 下一步操作拧揽。這個流程中，用戶需要向賬戶系統(tǒng)提交密碼腺占。
但是使用公鑰的話淤袜，用戶提交操作不需要前置的登陸過程。取而代之的是衰伯，在每次提交之前將提交的數 據使用私鑰進行簽名铡羡，然后把得到的簽名用戶的操作指令一起發(fā)給系統(tǒng)，系統(tǒng)可以直接認證用戶的操作意鲸。
仔細觀察這個模式烦周，在具體的傳輸過程中，并不存在私鑰的提交過程怎顾。只需要把簽名和交易指令提交读慎，再加上之前提交的公鑰就可以驗證用戶的身份了。
因此槐雾，在不對用戶系統(tǒng)進行任何修改的情況下夭委，我們也可以將同一套規(guī)則對應到不同的賬戶系統(tǒng)，保證一套用戶系統(tǒng)可以支持多個賬戶系統(tǒng)募强， 實現數據的跨系統(tǒng)流轉株灸。
由于簽名算法與驗證算法的規(guī)則是有標準所規(guī)定的，不同的系統(tǒng)在實現的時候可以保證實現的一致性钻注。 同時蚂且，由于私鑰不會被暴露，所以一套客戶端可以同時對接在不同的系統(tǒng)上幅恋，實現系統(tǒng)的通用化處理。
