本篇文章轉譯自 IEEE – Blockchain-Based System for Multiparty Electronic Registered Delivery Services 的內容，歐洲法規規定了電子化支付（電子化識別和信任服務），而一個合格的電子註冊交付是信託服務之一並包含在法規中，它要求不可否認原產地及誠信的資料。
摘要
故事介紹
歐洲法規規定了電子化支付（電子化識別和信任服務），而一個合格的電子註冊交付是信託服務之一並包含在法規中，它要求不可否認原產地及誠信的資料。這些服務基本上會依賴於信任的第三方，仍會有很大的溝通及使用障礙。
【科普小學堂】
「若想要讀得更詳細，請參閱最底下資料來源」
1. 交付：交付是動產、物權變動的公示方式。動產種類繁多，數量巨大，變動頻繁，不適宜採用登記方式。
2. 信託：委託人將財產權移轉或為其他處分，使受託人依信託本旨，為受益人之利益或為特定之目的，管理或處分信託財產之關係。
eDelivery
- 在文章中，作者採用區塊鏈技術來解決問題（將 eDelivery 計劃減少受信任的第三方），並且滿足歐盟註冊 eDeliveries 的規範。
- 由於機密性不被視為強制性財產，作者提出了兩個協議。
- 第一個：適合不太在乎消息或資料機密性，甚至是可以公開訪問的。
- 第二個：允許除了接收方以外，隱藏他人的消息。
第一章節：介紹
區塊鏈提供了一個不可修改的資料註冊系統，可為傳統應用程式提供新的解決方案。 舉例：經過認證的電子郵件帳號，可以經過區塊鏈技術來證明他已發送信件或其他類型的服務。 在之前，為了解決傳遞中之公平性問題，皆會透過 TTP（Trusted Third Party , 可信任之第三方）來解決。在典型的 eDelivery 案例中，要交換的是資料以及不可否認之來源證明。
合格的電子註冊遞送系統
2016年7月，歐盟信息安全網的法規 910/2014（也稱為 eIDAS 法規）開始適用。該法規為內部市場的電子交易制定了電子識別和信託服務規則，涵蓋了所有28個成員國。
文件（Document）中定義了幾種信任服務：電子簽名（Electronic Signature）、密封（Seals）、時間戳記（TimeStamps）、已註冊的交付服務和用於網站驗證的證書。該法規引入了合格信託服務和合格信託服務提供商的概念，其中包含確保信託服務高級別安全性的要求和義務。
合格的 eDelivery 服務必須根據指令提供：資料／數據完整性、來源認證、交付時間的認證，而其中機密性不被視為核心功能但通常作為更完整的解決方案。
eDelivery 服務定義的資料 / 數據稱之為「Message（消息）」，且包含經過認證的通知和電子郵件。而電子郵件是一種可以使用的傳輸方式，但是 eDelivery 並不僅限於電子郵件。
eDelivery 實例介紹
- 註冊過的電子郵件，能提供更多與處理電子郵件相關的證據
- 訪問和交換敏感的資訊
- 事件的電子化公證
交換協議中的安全性和可信任之第三方
至今所提出的交換協議（例如電子郵件服務）的操作通常使用 TTP ，其負責解決由於交換或詐欺而引起的衝突。
當前的公平交換協議，包括 TTP 之干預以及很難為網路中用戶提供真正可靠的 TTP ，且具有明確的框架（例如，TTP 生成的電子文件必須被法院接受才能解決事件上的爭議）。
TTP 也有可能在技術層面遇到問題（例如：通信容易遇到瓶頸、協議缺乏效率），並且他們的可靠性也容易遇到挑戰，如果他們有任何漏洞，交換協議中的安全性即會被打破。
區塊鏈的解決方案
隨著區塊鏈技術以及智能合約（Smart Contract）的出現，TTP 可以被這種新的技術所取代或補充，這為尋找解決方案提供了新的可能性。
智能合約能減少對 TTP 的需求，他是一種運行在區塊鏈上的程式，以預先訂立的規則來執行交易，這可以保障雙方之間的公平交換和相互信任，並且可防止互相欺騙且從而減少傳遞訊息中的延遲及服務佣金。
區塊鏈中的時間戳記（Timestamps）對於協議中的公平性是至關重要的！
第二章節：註冊 eDelivery 之理想屬性
下將會介紹關於 eDelivery 的主要功能列表
法律相關 Legal Features
- 交貨證明：發送方收到不可偽造的時間戳記，證明他已經傳遞訊息。
- 接收證明：雙方皆收到不可偽造的時間戳記。
- 誠信證明：雙方皆可以確保傳輸過程中沒有被竄改。
- 安全性：防止丟失、被盜或未經授權之更改。
安全相關 Security Features
- 發送人識別：消息接收方可以驗證發送方。
- 安全的時間戳記：此時間戳記提供交付日期和時間準確性。
- 保密：雙方皆可確定未經授權的人員無法訪問該訊息。
- 資料完整性：確保傳輸資料的完整性，即消息之內容。
- 控制路由錯誤：該控制有助於傳輸前檢查接受器之參數，並告知用戶傳輸前接收消息的能力。
- 互操作性：服務向發送方指示預期接收方可以儲利的格式消息，並將消息轉換為另種格式。
功能相關 Function Features
- 發送大文件：該服務必須允許傳輸大量消息和各種格式的消息。
- 快速處理：必須是即時的。
其他 Other Properties
- 降低風險：合格的電子註冊交付使得以下操作變得不可行（操縱數據、偽造發送和接收的時間戳記或未授權訪問）。
- 降低成本：降低失敗或不確定性的成本。
- 沒有傳輸延遲：傳輸必須幾乎是瞬間的。
- 沒有雙重支付：避免發送額外的簽名版本。
- 事故處理和責任：服務提供商仍要對客戶造成的損害承擔責任。
考慮了上述功能，以便列出 eDelivery 系統的安全屬性。
- 有效性：如果雙方行為正確，他們將收到預期的項目。
- 公平性：完成協議運行後，每一方將會收到預期的項目，或者任一方皆沒收到任何一方的有效訊息。
- 時效性：在協議運行期間，每一方皆可以單方面選擇終止協議而不會失去公平性。
- 不可否認性：如果物品從 A 發送到 B ，則 A 不能拒絕該物品的來源，B 不能拒絕接收該物品。
- 第三方可驗證性：如果第三方行為不好，導致一方喪失公平，受害者可以爭議中證明此事實。
- 保密性：只有資料的發送及接收方才知道認證消息的內容。
- 效率：有效的協議使用允許有效交換或最小成本的最少步驟數。
- 證據可轉移性：系統生成的證據可以轉移到外部，以證明交換的結果。
- 狀態存儲：如果不需要可以參與交換的 TTP 來維護狀態訊息。
上述解釋了不可否認的階段：證據生成、證據轉移、證據驗證、證據存儲和解決爭議。
第三章節：註冊電子服務當前發展
作者調查了公平交換問題，提出兩種使用智能合約進行公平交換的解決方案，該方案由區塊鏈功能支持並使用圖靈完備語言。
作者提出以區塊鏈技術和以太坊智能合約之不可否認協議，此用於解決 Token 和 數字資產間的交易，此協議要求相關各方存放抵押品，以激勵行為者的誠實行為。
作者也提出一個可重複使用的智能合約概念，它用於發送多個通知。
第四章節 – 貢獻
- （略）
第五章節：系統總覽
參與者
- 發送方
- 接收方
- 可信任的第三方
- 智能合約
所有參與者皆擁有 address 並且能夠相互溝通以及和智能合約溝通。 兩個提議的協議都遵循 3-Steps 交換。關於這個 3-Steps 協議的非機密和機密解決方案之間的主要區別在於，在機密解決方案中，各方可以直接交換消息（離線通信交換），而在非機密解決方案中，各方執行 3-Steps ，通過調用為此服務部署的智能合約的功能。
- 圖1 描述了非機密協議的參與者之間的鏈間交互
- 圖2 中描述了機密協議的離線交互。
第六章節：基於非機密區塊鏈的多方註冊電子交付系統
此方法非常適合需要儲存交付數據的應用程序，這些應用程序必須註冊並可公開訪問。
非機密註冊 eDeliveries 的多方協議提供了一個發送方（A）和多個接收方（B = {B1，B2 …，Bn}）的公平交付解決方案。
圖3 是發送方和接收方在非機密 eDelivery 中為所提出的鏈上通信方案交換的消息序列圖。 在圖3中，藍色箭頭表示上述步驟，並指定對區塊鏈地址的簽名請求。
此外，框內的紅色文本描述了必須由區塊鏈上部署的 eDelivery 執行的過程。
交付的發送方 A 和接收方集合 B 將遵循交換協議的步驟。 在以下對協議的完整描述中，協議的參與者發送的請求被指向區塊鏈上部署的 eDelivery 服務的地址。
交換協議的細節是（表1中的表示法）： 發送方 A 發送新的 eDelivery 請求。
- 該請求包括發送方的 Address，要傳遞的消息的 Hash（c，該 Hash 也用作 eDelivery 的識別），- 接收方的地址以及句號 term1 和 term2。
`
- term1 為接收方在發送方完成交付前，能接受交付的有效期限。
- term2 為允許接收方取消，未完成交付的期限。 `
- 取消的功能是為了保證有效性和公平性。
- B 中的每個接收方 Bi 必須在 term1 期間單獨接受傳遞的接收，發布表達其意願的消息。
簽署的交易將作為接收證明的不可否認性。
- 如果接收方在 term1 期間不接受，則假定拒絕。
- 在 term1 的截止日期之後，或者在所有接收方（B的成員）接受了接收之後，發送方A可以通過使用區塊鏈發布消息，完成與已接受的接收方B’（B’⊂B）的子集的傳遞。
- 因此，部署在區塊鏈上的 eDelivery 服務會檢查消息的完整性，並為 B’ 中的接收方發布原始證據的不可否認性。完成後，發送方將收到押金退款。
- 在這種情況下，我們在一般的 3-Steps 協議中添加了最後一步：在 term2 的截止日期之後， B’ 中的任何接收方都可以獲取消息，或者可以請求取消 eDelivery，以防消息未正確存入。
- 最後執行完交換協議之後，所有接收方都可以讀取消息 M，因為它存在區塊鏈中，但只有 B’ 的成員可以證明他們已被通知且有證據。
- 如果 term2 之後，發送方尚未發布消息，則每個接收方 Bi 可以取消 eDelivery 。
第七章節：基於機密區塊鏈的註冊 eDelivery 協議
第二項提案的設計考慮到了需要保密的交付。
也就是說，區塊鏈必須有助於保持交換的公平性，但是消息不能存儲在公開訪問的區塊中。 與非機密案例的主要區別在於，在機密案例中，協議允許進行離線交換，所以交換可以在沒有區塊鏈或 TTP 干預的情況下執行。
另一個重要特徵是該提案不需要截止日期，任何交換都可以隨時完成。無國籍 TTP 可用於解決雙方之間可能產生的爭議。我們描述了一種基於非區塊鏈的公平交換，我們將部分重用（即鏈下 3-Steps 交換），並在套用在本節中基於區塊鏈的新提案。
在新協議中，發送方 A 和收件方 B 直接交換消息和不可否認證據，使用圖4 中描述的 3-Steps 脫鏈通信。僅作為最後手段，以防他們無法獲得預期通過發送取消請求（圖5）或完成請求（圖6），可以調用來自另一方，智能合約或TTP的項目。
描述的協議相比，基於區塊鏈的解決方案中 TTP 的作用已大大降低。此外，發送方永遠不會聯繫 TTP。 在這個新提案中，TTP 將僅採用已部署的智能合約來回應 B 的請求。TTP 完全是無狀態的，因此它從不存儲有關任何交換狀態的信息。
圖中的藍色箭頭表示對區塊鏈地址的簽名請求，而黑色箭頭表示離線通信消息。
多重之正向交換子協議
該協議在某種意義上是正向的，發送方 A 有可能在沒有 TTP 干預的情況下完成接收方集合 B 的交換。
圖 4. 由機密 eDelivery 發送方和接收方交換的 3-Steps，已通過正向方法解決交換：該協議在某種意義上是正向的，即發送方 A 有可能在沒有 TTP 干預的情況下完成與接收方 B 的交換。
交換如下：發送方向接收方集合發送消息，包括加密消息，接收者的地址和原始證據的不可否認性的第一部分，kT、hA。
每個接收者決定他是否發送不可否認接收證明 hBi 的交換。 接收方將接收打開消息的密鑰和原始證據的不可否認部分 kA。
如果已成功完成這些步驟的執行，則發送方將持有來自所有接收方的不可否認接收（NRR）證據，並且每個接收方將持有該消息和不可否認原產地（NRO）證據。
每個接收者都有密鑰，因此他可以解密消息，然後集合B的每個接收者獲得用於解密消息的密鑰 kA，以及相應的 NRO 證據（hA）。以相同的方式，消息的發送方將從每個接收者獲得 NRR 證據（hBi）。
這樣，協議允許正向交換，也就是說，交換可以完全執行而無需 TTP和區塊鏈的干預。另一個重要特徵是該提案不需要截止日期，並且可以隨時完成，如果雙方之間發生爭議，可以執行以下子協議。
多方之取消子協議
取消子協議將由消息的發送方發起。
如果沒從消息的所有接收方接收 hBi ，則發送方執行智能合約的相應功能。 在圖 5 中，有一個圖形描述，表明發送方和區塊鏈為取消未完成的接收方取消機密 eDelivery 所採取的行動。
Hash H（c）用作 eDelivery 的識別碼。當發送方執行智能合約的取消功能時，她必須指出所有未發送 hBi 的用戶的身份（由集合 B’’ 表示）。就智能合約而言，它將負責檢查集合 B’’ 中的任何用戶是否已通過 TTP 完成交換。在這種情況下，它會將相應的 NRR 證據（針對特定的 Bi）發送給發送方。否則，未完成的接收方將被包括在已取消的用戶組中（B’’ — 已取消）。因此，在此階段結束時，發送方 A 將與所有接收方完成公平交換，或者令人滿意，因為她已經收到了 hBi，或者因為取消了。
多方完成子協議
將由任何接收方發起，在已發送相應的 hBi 但尚未接收到該元素以獲得密鑰 kA 的情況下。
最終確定將由 TTP 根據從收件方 Bi 收到的請求進行。在檢查從 Bi 接收的所有不同參數的正確性之後，TTP 執行智能合約的完成功能（TTP 將 Bi 的 NRR 證據（hBi）提交給智能合約）。
在圖6中，描述了收件方，TTP 和區塊鏈在異常情況下完成機密 eDelivery 所採取的操作。 TTP 基於區塊鏈中存儲的有關此 eDelivery 的信息。在此子協議中，智能合約檢查請求是否來自 TTP，然後驗證聲明的收件人是否已取消其郵件傳遞的用戶。在這種情況下，會發出適當的取消證據。否則，智能合約在區塊鏈中存儲收到的 hBi，並通過將 Bi 添加到 B’’ 來完成已完成此交換的用戶組 — 已完成。最後，TTP 將 kT 發送給 Bi，接收者能夠閱讀該消息並完成 NRO 證據。
第八章節 – 智能合約
本文採用了以太坊區塊鏈，因為它提供了比比特幣區塊鏈更豐富的功能，因為他們在完全分布式系統中支持使用圖靈完備語言的智能合約。 底下將以非機密 / 機密的協議來給大家展示一下相關的智能合約。
非機密多方註冊 eDelivery 協議的智能合約
底下將會展示各種功能的智能合約撰寫範例
機密多方註冊eDelivery協議的智能合約
底下將會展示各種功能的智能合約撰寫範例
結論
歐法規定了電子交易的電子識別和信託服務規則。然後技術提案必須達到合格的法律要求。合格電子註冊交付的特徵是法規中包含的信託服務之一，與公平交換協議提供的特徵類似：不可否認來源和接收數據的完整性。因此，可以為註冊的 eDelivery 設計公平交換協議。然而，這種服務通常嚴重依賴於可信第三方的使用，並且成本高且效率低，並且必須驗證 TTP 的行為。
在本文也採用了區塊鏈技術結合智能合約來將 TTP 減少甚至取消，並且透過機密與非機密之不同需求選擇需要採用何種協議，使得人員能夠透過智能合約來減少複雜的手續和流程並且將 TTP 的干預降到最低，實現服務的理想屬性，我們也得知在協議設計中結合基於區塊鏈的技術可以影響 TTP 的作用。
資料來源
?相關報導?
人物故事｜電子現金之父 David Chuam 談「重新創造 Ecash、Praxxis 抗量子加密貨幣」
從網路看區塊鏈的未來《二》a16z：1993年，在網路上賣東西是違法的
《BlockTempo動區動趨》LINE官方號開通囉～立即加入獲得第一手區塊鏈、加密貨幣新聞報導！
