尹稚淳,李航
(沈陽師范大學軟件學院,沈陽 110034)
相對于紙質(zhì)合同,電子合同的優(yōu)勢就是經(jīng)濟、快捷、安全和可隨時查閱。我國對電子合同的法律保護見于《民法通則》、《合同法》、《電子簽名法》等法律法規(guī)中,2004年8月28日通過的《電子簽名法》,它用法律條文確定了電子簽名的法律效力[1-2]。
2013年12月,中華人民共和國商務(wù)部頒布了《電子合同在線訂立流程規(guī)范》。作為行業(yè)標準,規(guī)范明確了電子合同適用范圍,保密和安全性要求,同時規(guī)定了合同簽署流程,查詢和保管規(guī)范;提到了合同簽訂雙方須在第三方平臺上簽署電子合同,才具備完備的法律效力[3-4]。
我國對電子合同平臺有諸多隱私、安全性要求,電子合同平臺是否會越界違法,取決于管理制度和其口碑背書,這也是中心化網(wǎng)絡(luò)的通病,用戶使用各種互聯(lián)網(wǎng)公司提供的社交生活便利的同時,就不得不將個人數(shù)據(jù)安全和隱私交付給互聯(lián)網(wǎng)公司來保障。然而,由于用戶數(shù)據(jù)被販賣事件層出不窮,依靠公司信譽背書來無論如何也只是便利性與安全性的妥協(xié)。區(qū)塊鏈的無需中心機構(gòu)做信任背書的特性特別適合電子合同的應(yīng)用環(huán)境。
超級賬本(Hyperledger)是在2015年成立的聯(lián)盟區(qū)塊鏈開源項目,目前有超過190家公司和組織。超級賬本項目努力解決各種不同商業(yè)場景下的區(qū)塊鏈落地問題。開源且透明的去中心化賬本設(shè)計,支持模塊化的共識算法和出塊算法,支持多種語言的開發(fā)測試環(huán)境,有助于更多的中小企業(yè)更容易,更小代價的進入?yún)^(qū)塊鏈時代,并可以根據(jù)自己的應(yīng)用場景和業(yè)務(wù)量優(yōu)化鏈上性能。
超級賬本Fabirc是超級賬本的第一個項目[5],區(qū)塊鏈的基礎(chǔ)核心平臺;采用分層模塊化開發(fā),支持插拔式共識機制以及成員管理,支持權(quán)限管理;支持Node.js,Python和Java的鏈碼開發(fā)[6]。目前Fabric1.0的每秒交易數(shù)在5000左右。
如圖1所示,超級賬本Fabric 1.0的邏輯架構(gòu)支持通過API、SDK和CLI的形式來訪問Fabric的服務(wù)。從底層的角度,F(xiàn)abic可以分為身份識別服務(wù)、策略管理服務(wù)、區(qū)塊鏈服務(wù)、鏈碼(智能合約)服務(wù)四個部分。
超級賬本Composer是一個兼具開放性擴展性的開發(fā)工具集和框架[7]。使用Composer,開發(fā)者可以將的精力集中在領(lǐng)域模型設(shè)計和業(yè)務(wù)邏輯開發(fā),在數(shù)周內(nèi)完成鏈碼應(yīng)用,并且部署到生產(chǎn)環(huán)境。Composer支持現(xiàn)有的超級賬本Fabric區(qū)塊鏈基礎(chǔ)架構(gòu)和運行環(huán)境。
圖1 超級賬本系統(tǒng)邏輯架構(gòu)
圖2 Composer鏈碼應(yīng)用結(jié)構(gòu)
Composer鏈碼應(yīng)用由四類文件組成,分為模型文件、腳本文件、訪問控制文件和查詢文件。模型文件中定義了應(yīng)用中的各種實體和具體的交易行為,例如區(qū)塊鏈二手車市場的汽車,保險合同,買賣雙方,買賣交易等。腳本文件中是交易行為的具體代碼實現(xiàn)。函數(shù)可以理解為不會寫入?yún)^(qū)塊鏈的交易,僅用作查詢返回數(shù)據(jù)。訪問規(guī)則則定義了那些參與者有權(quán)限訪問哪些資源,可以使用哪些交易。查詢文件中的查詢函數(shù)定義了一類不會寫入?yún)^(qū)塊鏈的交易。
Composer鏈碼應(yīng)用開發(fā)完成后,打包成.bna文件,使用鏈碼系統(tǒng)身份卡可以將鏈碼安裝到現(xiàn)有Fabric環(huán)境中,或在Web瀏覽器的仿真環(huán)境中運行??梢允褂萌N方式來訪問鏈碼應(yīng)用,第一種是通過命令行接口Composer-CLI的方式來訪問,第二種是通過RESTFul API的方式來訪問,這也是通常情況下Web應(yīng)用使用的方式,第三種是通過Web Playground后臺來訪問。這通常用在開發(fā)和測試鏈碼應(yīng)用階段。
整個電子合同系統(tǒng)架構(gòu)設(shè)計如下:
圖3 電子合同系統(tǒng)架構(gòu)
每個層的主要功能如下:
區(qū)塊鏈底層平臺:提供狀態(tài)數(shù)據(jù)庫維護、分布式賬本的維護、智能合約的生命周期管理等區(qū)塊鏈功能,實現(xiàn)數(shù)據(jù)的不可篡改和智能合約的業(yè)務(wù)邏輯,以及通過CA服務(wù)提供成員注冊和注銷等功能[8]。
智能合約:智能合約通過鏈碼來實現(xiàn),包括用戶信息管理,圖章管理,簽名管理以及合同管理等一系列鏈碼功能的實現(xiàn),以及暴露給上層應(yīng)用調(diào)用的交易接口。所有在系統(tǒng)的重要業(yè)務(wù)都在此實現(xiàn)。
業(yè)務(wù)層:業(yè)務(wù)層是應(yīng)用程序的后端服務(wù),為Web應(yīng)用提供RESTful的接口,處理前端的業(yè)務(wù)請求。后端服務(wù)的基本功能是封裝智能合約層的鏈碼接口,將鏈碼的圖章管理,簽名管理和合同管理gRPC服務(wù)接口轉(zhuǎn)換成RESTful接口。同時合同接入SDK再次封裝RESTful接口,方便應(yīng)用開發(fā)者快速使用電子合同系統(tǒng)。
應(yīng)用層:Web應(yīng)用可采用ASP.NET+HTML+CSS的前端架構(gòu)編寫具有MVC、模塊化應(yīng)用程序,提供用戶交互的界面操作,包括用戶操作的功能和業(yè)務(wù)操作的功能。
用戶可以通過兩種方式將合同存儲在區(qū)塊鏈上,第一種方式是通過Web應(yīng)用服務(wù)器將合同存儲在區(qū)塊鏈上,第二種方式是通過區(qū)塊鏈RESTFul API服務(wù)器為第三方租戶提供接入服務(wù),用戶通過第三方接入服務(wù)器將合同存儲在區(qū)塊鏈網(wǎng)絡(luò)上。
電子合同訂立主體可以為個人或組織,簡稱“主體”,這里也可以稱為“用戶”。“用戶”可以在電子合同平臺上補全“用戶”信息,添加合同模板,發(fā)布合同并邀請其他的“用戶”下載、閱覽和簽署合同,也可以鑒定合同是否是經(jīng)過當前區(qū)塊鏈承認的合同。
根據(jù)“用戶”在系統(tǒng)上的業(yè)務(wù)劃分,可以分為身份信息管理、圖章管理、簽名管理、合同模板管理和合同管理五個模塊。
合同系統(tǒng)領(lǐng)域模型ER圖,如圖4所示:
圖4 領(lǐng)域模型ER圖
身份信息管理包括身份信息建立和身份信息修改。
圖章管理包括圖章創(chuàng)建,圖章銷毀,圖章信息修改和圖章查詢。
簽名管理包括簽名創(chuàng)建,簽名銷毀,簽名信息修改和簽名查詢。
同模板管理包括合同模板創(chuàng)建,合同模板銷毀,合同模板信息修改和合同模板查詢。
合同管理包括合同創(chuàng)建,合同簽署,合同撤銷,合同查詢,合同驗簽功能。
圖5 合同狀態(tài)機
合同(Template)類代碼:asset Contract identified by Id{
o String Id //標識符
--> EndUser founder //發(fā)起者
o Signature[]signatures //用戶簽章記錄
o String Title //合同標題
o String Extension //合同擴展名
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 //簽署截止時間}
合同簽署部分鏈碼: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接口
筆者具體研究了電子合同的法律規(guī)范[1-4],以及目前成熟的電子合同簽訂系統(tǒng)的業(yè)務(wù)功能[3],區(qū)塊鏈常用場景下的應(yīng)用以及性能問題。綜合考慮各個方面因素,選擇超級賬本Fabric作為底層區(qū)塊鏈應(yīng)用架構(gòu),使用超級賬本Composer作為鏈碼應(yīng)用的開發(fā)平臺,最終將鏈上所有服務(wù)通過RESTFul API來與鏈下應(yīng)用做連接。這樣就完成了一個電子合同應(yīng)用場景下的業(yè)務(wù)閉環(huán)。
最近兩年來,區(qū)塊鏈的開發(fā)非常多,但真正落地實施的項目屈指可數(shù),但隨著應(yīng)用不斷地涌出和淘汰,區(qū)塊鏈開發(fā)也必然會變得明朗和規(guī)范化[9-10]。到那時,基于區(qū)塊鏈的電子合同就不應(yīng)該僅僅是紙質(zhì)合同的數(shù)字化代表了。數(shù)字合同的問題在于它只是一個法律證明。而合同本身不具有強制執(zhí)行力。資產(chǎn)在合同上的交割,都必須基于線下的現(xiàn)實世界中的合同雙方的協(xié)商或法院裁定,透過國家強制力來保證。電子合同的下一步發(fā)展趨勢,一定要做到可以理解用戶合同文本中的職責方,資產(chǎn)和轉(zhuǎn)移條件,并通過生成鏈碼的方式來強制執(zhí)行合同文本。這樣,整個合同的執(zhí)行流程就無需法院或國家的干預(yù)了。
參考文獻:
[1]全國人民代表大會.中華人民共和國合同法[L],1999-03-15.
[2]全國人民代表大會常務(wù)委員會.中華人民共和國電子簽名法[L],2015-04-24.
[3]云簽.國家電子合同標準制定[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.超級賬本白皮書[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è)計與應(yīng)用[M].北京:機械工業(yè)出版社,2017.
[9]張偲.區(qū)塊鏈技術(shù)原理、應(yīng)用及建議[J].軟件,2016(11).
[10]沈鑫,裴慶祺,劉雪峰.區(qū)塊鏈技術(shù)綜述[J].網(wǎng)絡(luò)與信息安全學報,2016(11).