尹稚淳，李航

（沈陽(yáng)師范大學(xué)軟件學(xué)院，沈陽(yáng) 110034）

1 相關(guān)法律法規(guī)和行業(yè)現(xiàn)狀

相對(duì)于紙質(zhì)合同，電子合同的優(yōu)勢(shì)就是經(jīng)濟(jì)、快捷、安全和可隨時(shí)查閱。我國(guó)對(duì)電子合同的法律保護(hù)見于《民法通則》、《合同法》、《電子簽名法》等法律法規(guī)中，2004年8月28日通過的《電子簽名法》,它用法律條文確定了電子簽名的法律效力[1-2]。

2013年12月，中華人民共和國(guó)商務(wù)部頒布了《電子合同在線訂立流程規(guī)范》。作為行業(yè)標(biāo)準(zhǔn)，規(guī)范明確了電子合同適用范圍，保密和安全性要求，同時(shí)規(guī)定了合同簽署流程，查詢和保管規(guī)范；提到了合同簽訂雙方須在第三方平臺(tái)上簽署電子合同，才具備完備的法律效力[3-4]。

我國(guó)對(duì)電子合同平臺(tái)有諸多隱私、安全性要求，電子合同平臺(tái)是否會(huì)越界違法，取決于管理制度和其口碑背書，這也是中心化網(wǎng)絡(luò)的通病，用戶使用各種互聯(lián)網(wǎng)公司提供的社交生活便利的同時(shí)，就不得不將個(gè)人數(shù)據(jù)安全和隱私交付給互聯(lián)網(wǎng)公司來(lái)保障。然而，由于用戶數(shù)據(jù)被販賣事件層出不窮，依靠公司信譽(yù)背書來(lái)無(wú)論如何也只是便利性與安全性的妥協(xié)。區(qū)塊鏈的無(wú)需中心機(jī)構(gòu)做信任背書的特性特別適合電子合同的應(yīng)用環(huán)境。

2 超級(jí)賬本技術(shù)介紹

超級(jí)賬本（Hyperledger）是在2015年成立的聯(lián)盟區(qū)塊鏈開源項(xiàng)目，目前有超過190家公司和組織。超級(jí)賬本項(xiàng)目努力解決各種不同商業(yè)場(chǎng)景下的區(qū)塊鏈落地問題。開源且透明的去中心化賬本設(shè)計(jì)，支持模塊化的共識(shí)算法和出塊算法，支持多種語(yǔ)言的開發(fā)測(cè)試環(huán)境，有助于更多的中小企業(yè)更容易，更小代價(jià)的進(jìn)入?yún)^(qū)塊鏈時(shí)代，并可以根據(jù)自己的應(yīng)用場(chǎng)景和業(yè)務(wù)量?jī)?yōu)化鏈上性能。

超級(jí)賬本Fabirc是超級(jí)賬本的第一個(gè)項(xiàng)目[5]，區(qū)塊鏈的基礎(chǔ)核心平臺(tái)；采用分層模塊化開發(fā)，支持插拔式共識(shí)機(jī)制以及成員管理，支持權(quán)限管理；支持Node.js，Python和Java的鏈碼開發(fā)[6]。目前Fabric1.0的每秒交易數(shù)在5000左右。

如圖1所示，超級(jí)賬本Fabric 1.0的邏輯架構(gòu)支持通過API、SDK和CLI的形式來(lái)訪問Fabric的服務(wù)。從底層的角度，F(xiàn)abic可以分為身份識(shí)別服務(wù)、策略管理服務(wù)、區(qū)塊鏈服務(wù)、鏈碼（智能合約）服務(wù)四個(gè)部分。

超級(jí)賬本Composer是一個(gè)兼具開放性擴(kuò)展性的開發(fā)工具集和框架[7]。使用Composer，開發(fā)者可以將的精力集中在領(lǐng)域模型設(shè)計(jì)和業(yè)務(wù)邏輯開發(fā)，在數(shù)周內(nèi)完成鏈碼應(yīng)用，并且部署到生產(chǎn)環(huán)境。Composer支持現(xiàn)有的超級(jí)賬本Fabric區(qū)塊鏈基礎(chǔ)架構(gòu)和運(yùn)行環(huán)境。

圖1 超級(jí)賬本系統(tǒng)邏輯架構(gòu)

圖2 Composer鏈碼應(yīng)用結(jié)構(gòu)

Composer鏈碼應(yīng)用由四類文件組成，分為模型文件、腳本文件、訪問控制文件和查詢文件。模型文件中定義了應(yīng)用中的各種實(shí)體和具體的交易行為，例如區(qū)塊鏈二手車市場(chǎng)的汽車，保險(xiǎn)合同，買賣雙方，買賣交易等。腳本文件中是交易行為的具體代碼實(shí)現(xiàn)。函數(shù)可以理解為不會(huì)寫入?yún)^(qū)塊鏈的交易，僅用作查詢返回?cái)?shù)據(jù)。訪問規(guī)則則定義了那些參與者有權(quán)限訪問哪些資源，可以使用哪些交易。查詢文件中的查詢函數(shù)定義了一類不會(huì)寫入?yún)^(qū)塊鏈的交易。

Composer鏈碼應(yīng)用開發(fā)完成后，打包成.bna文件，使用鏈碼系統(tǒng)身份卡可以將鏈碼安裝到現(xiàn)有Fabric環(huán)境中，或在Web瀏覽器的仿真環(huán)境中運(yùn)行。可以使用三種方式來(lái)訪問鏈碼應(yīng)用，第一種是通過命令行接口Composer-CLI的方式來(lái)訪問，第二種是通過RESTFul API的方式來(lái)訪問，這也是通常情況下Web應(yīng)用使用的方式，第三種是通過Web Playground后臺(tái)來(lái)訪問。這通常用在開發(fā)和測(cè)試鏈碼應(yīng)用階段。

3 電子合同方案架構(gòu)設(shè)計(jì)

整個(gè)電子合同系統(tǒng)架構(gòu)設(shè)計(jì)如下：

圖3 電子合同系統(tǒng)架構(gòu)

每個(gè)層的主要功能如下：

區(qū)塊鏈底層平臺(tái)：提供狀態(tài)數(shù)據(jù)庫(kù)維護(hù)、分布式賬本的維護(hù)、智能合約的生命周期管理等區(qū)塊鏈功能，實(shí)現(xiàn)數(shù)據(jù)的不可篡改和智能合約的業(yè)務(wù)邏輯，以及通過CA服務(wù)提供成員注冊(cè)和注銷等功能[8]。

智能合約：智能合約通過鏈碼來(lái)實(shí)現(xiàn)，包括用戶信息管理，圖章管理，簽名管理以及合同管理等一系列鏈碼功能的實(shí)現(xiàn)，以及暴露給上層應(yīng)用調(diào)用的交易接口。所有在系統(tǒng)的重要業(yè)務(wù)都在此實(shí)現(xiàn)。

業(yè)務(wù)層：業(yè)務(wù)層是應(yīng)用程序的后端服務(wù)，為Web應(yīng)用提供RESTful的接口，處理前端的業(yè)務(wù)請(qǐng)求。后端服務(wù)的基本功能是封裝智能合約層的鏈碼接口，將鏈碼的圖章管理，簽名管理和合同管理gRPC服務(wù)接口轉(zhuǎn)換成RESTful接口。同時(shí)合同接入SDK再次封裝RESTful接口，方便應(yīng)用開發(fā)者快速使用電子合同系統(tǒng)。

應(yīng)用層：Web應(yīng)用可采用ASP.NET+HTML+CSS的前端架構(gòu)編寫具有MVC、模塊化應(yīng)用程序，提供用戶交互的界面操作，包括用戶操作的功能和業(yè)務(wù)操作的功能。

用戶可以通過兩種方式將合同存儲(chǔ)在區(qū)塊鏈上，第一種方式是通過Web應(yīng)用服務(wù)器將合同存儲(chǔ)在區(qū)塊鏈上，第二種方式是通過區(qū)塊鏈RESTFul API服務(wù)器為第三方租戶提供接入服務(wù)，用戶通過第三方接入服務(wù)器將合同存儲(chǔ)在區(qū)塊鏈網(wǎng)絡(luò)上。

4 電子合同方案設(shè)計(jì)和實(shí)現(xiàn)

電子合同訂立主體可以為個(gè)人或組織，簡(jiǎn)稱“主體”，這里也可以稱為“用戶”。“用戶”可以在電子合同平臺(tái)上補(bǔ)全“用戶”信息，添加合同模板，發(fā)布合同并邀請(qǐng)其他的“用戶”下載、閱覽和簽署合同，也可以鑒定合同是否是經(jīng)過當(dāng)前區(qū)塊鏈承認(rèn)的合同。

根據(jù)“用戶”在系統(tǒng)上的業(yè)務(wù)劃分，可以分為身份信息管理、圖章管理、簽名管理、合同模板管理和合同管理五個(gè)模塊。

合同系統(tǒng)領(lǐng)域模型ER圖，如圖4所示：

圖4 領(lǐng)域模型ER圖

身份信息管理包括身份信息建立和身份信息修改。

圖章管理包括圖章創(chuàng)建，圖章銷毀，圖章信息修改和圖章查詢。

簽名管理包括簽名創(chuàng)建，簽名銷毀，簽名信息修改和簽名查詢。

同模板管理包括合同模板創(chuàng)建，合同模板銷毀，合同模板信息修改和合同模板查詢。

合同管理包括合同創(chuàng)建，合同簽署，合同撤銷，合同查詢，合同驗(yàn)簽功能。

圖5 合同狀態(tài)機(jī)

合同（Template）類代碼：asset Contract identified by Id{

o String Id //標(biāo)識(shí)符

--＞ EndUser founder //發(fā)起者

o Signature[]signatures //用戶簽章記錄

o String Title //合同標(biāo)題

o String Extension //合同擴(kuò)展名

o String Content optional //合同正文（Base64）

o String ContentHash optional //合同正文哈希值

o String FinalDocument optional //最終合同文檔（Base64）

o String FinalDocumentHash optional//最終合同文檔哈希值

o Template template optional //合同模板

o String templateData optional //合同內(nèi)容Json

o ContractStatus status //合同簽署狀態(tài)

o DateTime SignDeadline optional //簽署截止時(shí)間}

合同簽署部分鏈碼：function SignContract（param）{

…//setting environment

if（param.status=='WaitSigning'||

…//check status

if（signature.user.getIdentifier（）==currentParticipant.getI-dentifier（））{

if（signature.status!='WaitSigning'）{

throw new Error（'Already signed'）;

}

signature.status=param.status;

if（"undefined"!=typeof param.sealImage）signature.sealImage=factory.newRelationship（A_NS,'SealImage',param.sealImage.getIdentifier（））;

signature.sealImagePos=param.sealImagePos;

if（"undefined"!=typeof param.signTextImage）signature.signTextImage=factory.newRelationship（A_NS,'SignTextI-mage',param.signTextImage.getIdentifier（））;

signature.signTextImagePos=param.signTextImage-Pos;

signature.SignTime=new Date（）;

if（signature.status=='Signed'）{

signedCount++;}}

if（param.status=='Reject'）{

param.contract.status='Rejected';}

else if（signedCount==total）{

param.contract.status='Effective';}

else{

param.contract.status='PartSigned';}

…//write to chain

}

鏈碼開發(fā)完成后，透過Composer REST Server將鏈碼接口暴露成REST API的方式。如圖6所示。

圖6 合同簽署RESTFul API接口

5 結(jié)語(yǔ)

筆者具體研究了電子合同的法律規(guī)范[1-4]，以及目前成熟的電子合同簽訂系統(tǒng)的業(yè)務(wù)功能[3]，區(qū)塊鏈常用場(chǎng)景下的應(yīng)用以及性能問題。綜合考慮各個(gè)方面因素，選擇超級(jí)賬本Fabric作為底層區(qū)塊鏈應(yīng)用架構(gòu)，使用超級(jí)賬本Composer作為鏈碼應(yīng)用的開發(fā)平臺(tái)，最終將鏈上所有服務(wù)通過RESTFul API來(lái)與鏈下應(yīng)用做連接。這樣就完成了一個(gè)電子合同應(yīng)用場(chǎng)景下的業(yè)務(wù)閉環(huán)。

最近兩年來(lái)，區(qū)塊鏈的開發(fā)非常多，但真正落地實(shí)施的項(xiàng)目屈指可數(shù)，但隨著應(yīng)用不斷地涌出和淘汰，區(qū)塊鏈開發(fā)也必然會(huì)變得明朗和規(guī)范化[9-10]。到那時(shí)，基于區(qū)塊鏈的電子合同就不應(yīng)該僅僅是紙質(zhì)合同的數(shù)字化代表了。數(shù)字合同的問題在于它只是一個(gè)法律證明。而合同本身不具有強(qiáng)制執(zhí)行力。資產(chǎn)在合同上的交割，都必須基于線下的現(xiàn)實(shí)世界中的合同雙方的協(xié)商或法院裁定，透過國(guó)家強(qiáng)制力來(lái)保證。電子合同的下一步發(fā)展趨勢(shì)，一定要做到可以理解用戶合同文本中的職責(zé)方，資產(chǎn)和轉(zhuǎn)移條件，并通過生成鏈碼的方式來(lái)強(qiáng)制執(zhí)行合同文本。這樣，整個(gè)合同的執(zhí)行流程就無(wú)需法院或國(guó)家的干預(yù)了。

參考文獻(xiàn)：

[1]全國(guó)人民代表大會(huì).中華人民共和國(guó)合同法[L]，1999-03-15.

[2]全國(guó)人民代表大會(huì)常務(wù)委員會(huì).中華人民共和國(guó)電子簽名法[L]，2015-04-24.

[3]云簽.國(guó)家電子合同標(biāo)準(zhǔn)制定[EB/OL].https：//www.yunsign.com/yunsign4.0.1/api/contractDraft.do,2018-02-19.

[4]SB/T 11009-2013,電子合同在線訂立流程規(guī)范[S].

[5]Hyperledger WG.超級(jí)賬本白皮書[EB/OL].http：//www.8btc.com/hyperledger-whitepaper,2018-03-01.

[6]Hyperledger WG.Hyperledger Fabric-Hyperledger[EB/OL].https：//www.hyperledger.org/projects/fabric,2018-03-03.

[7]Hyperledger WG.Hyperledger Composer-Hyperledger[EB/OL].https：//www.hyperledger.org/projects/composer,2018-03-03.

[8]楊保華，陳昌.區(qū)塊鏈原理、設(shè)計(jì)與應(yīng)用[M].北京：機(jī)械工業(yè)出版社，2017.

[9]張偲.區(qū)塊鏈技術(shù)原理、應(yīng)用及建議[J].軟件，2016（11）.

[10]沈鑫,裴慶祺,劉雪峰.區(qū)塊鏈技術(shù)綜述[J].網(wǎng)絡(luò)與信息安全學(xué)報(bào)，2016（11）.