王晟典，陳 娥?，朱 巖，林映春，劉國(guó)偉

1) 北京科技大學(xué)計(jì)算機(jī)與通信工程學(xué)院，北京 100083 2) 北京市經(jīng)濟(jì)和信息化局，北京 100744

軟件即服務(wù)（SaaS）作為一種云計(jì)算服務(wù)架構(gòu)，旨在幫助企業(yè)通過互聯(lián)網(wǎng)交付應(yīng)用程序，并交由第三方云供應(yīng)商進(jìn)行管理，已成為軟件服務(wù)領(lǐng)域當(dāng)前主流交易方法之一[1].與軟件外包開發(fā)、架構(gòu)即服務(wù)（IaaS）、平臺(tái)即服務(wù)（PaaS）一樣，SaaS 本質(zhì)上是一種將管理軟件和實(shí)施服務(wù)一體化外包的服務(wù)模式，也是伴隨著軟件行業(yè)發(fā)展興起的一種新型軟件應(yīng)用模式.它的商業(yè)成功很大程度上依賴于采用訂閱模式制備軟件許可證[2].與傳統(tǒng)的軟件永久許可不同，訂閱模式采用企業(yè)或消費(fèi)者與SaaS提供商簽署的一段時(shí)間（通常是每年或每月）的軟件訂閱合同（也稱訂閱協(xié)議），并在前者繳納訂閱費(fèi)后向其授予SaaS相應(yīng)的訪問權(quán)限.此外，訂閱模式采用不同繳費(fèi)價(jià)格獲得不同類型服務(wù)來(lái)滿足不同用戶的需求.這種方式增加了消費(fèi)者服務(wù)選擇靈活性、降低購(gòu)置成本和試錯(cuò)成本、增強(qiáng)了客戶關(guān)系、以及SaaS提供商定價(jià)靈活性.

盡管軟件訂閱模式具有眾多優(yōu)勢(shì)并代表著未來(lái)SaaS的必然選擇，但是目前大多數(shù)訂閱合同仍采用“提前付費(fèi)”方式.這種方式會(huì)讓SaaS提供商的現(xiàn)金流呈現(xiàn)出較好的狀態(tài)，但服務(wù)費(fèi)用與實(shí)際的服務(wù)數(shù)量與質(zhì)量無(wú)關(guān)，因此無(wú)法按照實(shí)際使用量計(jì)費(fèi).這與按勞計(jì)酬的服務(wù)收費(fèi)原則相違背，難以適應(yīng)現(xiàn)代服務(wù)業(yè)自動(dòng)化執(zhí)行與監(jiān)管的要求.更為合理的訂閱模式是按照訂閱合同和實(shí)際使用量讓消費(fèi)者“先服務(wù)后結(jié)算”或“先充值后扣費(fèi)”，這種付費(fèi)方式對(duì)于消費(fèi)者來(lái)說成本控制和服務(wù)定制更加靈活.

然而，實(shí)現(xiàn)SaaS“先服務(wù)后結(jié)算”方式遠(yuǎn)比提前付費(fèi)方式復(fù)雜.這種復(fù)雜性體現(xiàn)在兩個(gè)方面：首先，需要自動(dòng)化的金融支付能力，保證依照訂閱合同條款對(duì)租期、服務(wù)能力（如云虛擬機(jī)數(shù)目、計(jì)算性能、網(wǎng)絡(luò)帶寬）和服務(wù)質(zhì)量進(jìn)行自動(dòng)化支付，避免人工干預(yù)；其次，需要強(qiáng)有力的法律化支持，保證服務(wù)過程中當(dāng)事人履行訂閱合同條款中義務(wù)的行為得到法律上的認(rèn)可，服務(wù)過程的記錄或存證具有法律效力，避免取證困難和因合同糾紛消耗律師大量人工成本[3].

針對(duì)以上問題，本文提出一種服務(wù)即智能合約（Service as a smart contract, SaaSC）的新型軟件服務(wù)架構(gòu)，它是SaaS的一種商業(yè)化擴(kuò)展，即以智能合約（Smart contract）代碼和平臺(tái)為基礎(chǔ)，通過自動(dòng)執(zhí)行的交易合約形式交付和支付軟件服務(wù)，為軟件訂閱模式的實(shí)施提供更加有效的技術(shù)手段.其中，智能合約是個(gè)寬泛的計(jì)算機(jī)技術(shù)，它既包括部署在區(qū)塊鏈（Blockchain）上、在滿足預(yù)定條件時(shí)可自動(dòng)執(zhí)行并存證的計(jì)算機(jī)程序，也包括支持智能合約可執(zhí)行程序開發(fā)、生成、部署、運(yùn)行、驗(yàn)證的信息網(wǎng)絡(luò)系統(tǒng).交易合約則是法律上的概念，是指兩方或多方當(dāng)事人為完成某件事而共同遵循的約定，從而建立某種對(duì)當(dāng)事人具有約束力的權(quán)利義務(wù)關(guān)系，如約定未來(lái)某個(gè)時(shí)間以一定數(shù)量金額支付某種軟件服務(wù)的費(fèi)用.這種交易合約形式為軟件服務(wù)的“先服務(wù)后結(jié)算”方式提供金融化基礎(chǔ)[4]和法律化保障[5]，進(jìn)而智能合約系統(tǒng)為交易合約的自動(dòng)執(zhí)行提供技術(shù)保障.

智能法律合約（Smart legal contract, SLC）是一種具有法律約束力的智能合約，是含有合同構(gòu)成要素、涵蓋合同締約方依據(jù)要約和承諾達(dá)成履行約定的計(jì)算機(jī)程序[6].SLC為法律合同文本和智能合約代碼之間建立了轉(zhuǎn)化的橋梁，保證了開放網(wǎng)絡(luò)環(huán)境下合同的公平協(xié)商與交易合約的法律約束力，因此它已成為設(shè)計(jì)并開發(fā)具有法律效力智能合約的核心技術(shù).為實(shí)現(xiàn)智能合約代碼法律化，一種稱為 SPESC 的面向法律語(yǔ)言已被提出，它是一種類自然語(yǔ)言的語(yǔ)言規(guī)范[7]，旨在通過類自然語(yǔ)言、規(guī)范化的結(jié)構(gòu)與書寫、可自動(dòng)化向可執(zhí)行智能合約語(yǔ)言轉(zhuǎn)換的方式來(lái)解決不同領(lǐng)域?qū)＜覝贤?、法律效力以及部分邏輯安全問題.進(jìn)而本文將采用SPESC語(yǔ)言作為SLC的設(shè)計(jì)和開發(fā)工具.

為了開展SaaSC服務(wù)交易的實(shí)例化研究，本文將SLC與當(dāng)前服務(wù)計(jì)算領(lǐng)域流行的微服務(wù)（Microservice）框架[8]相結(jié)合.微服務(wù)是一種開發(fā)軟件的架構(gòu)和組織方法，將獨(dú)立服務(wù)通過明確定義的應(yīng)用程序界面（Application program interface,API）進(jìn)行組合，適用于云原生應(yīng)用程序（如SaaS）、無(wú)服務(wù)器計(jì)算或輕量級(jí)容器部署的應(yīng)用程序[9].微服務(wù)框架（如 Spring Cloud、Kubernetes）則為快速構(gòu)建微服務(wù)提供注冊(cè)、發(fā)布、發(fā)現(xiàn)及消費(fèi)等一體化的支持，如Spring Cloud框架采用Eureka作為注冊(cè)中心匯聚服務(wù)信息、統(tǒng)一管理和維護(hù)服務(wù)地址、快速發(fā)現(xiàn)與連接服務(wù)；采用Spring Boot打包和部署服務(wù)應(yīng)用，支持RESTful接口傳遞服務(wù)數(shù)據(jù).因此，微服務(wù)框架可為研究SaaS+SaaSC的“先服務(wù)后結(jié)算”軟件訂閱模式提供軟件服務(wù)上的平臺(tái)支撐.

針對(duì)目前SaaS架構(gòu)難以依據(jù)現(xiàn)有法律合同規(guī)范當(dāng)事人權(quán)利義務(wù)關(guān)系的問題，本文提出的SaaSC系統(tǒng)架構(gòu)將面向法律合同的智能法律合約技術(shù)引入到服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)消費(fèi)三階段中，為軟件服務(wù)過程的法律化提供了一種有效解決方案，并為該SaaSC架構(gòu)設(shè)計(jì)如下機(jī)制：首先，設(shè)計(jì)了一種服務(wù)注冊(cè)與發(fā)布過程中的服務(wù)接口合約化方案，通過分析服務(wù)注冊(cè)過程的6種交互動(dòng)作、4種微服務(wù)狀態(tài)及3階段狀態(tài)轉(zhuǎn)移流程，建立了遵循OpenAPI標(biāo)準(zhǔn)的服務(wù)通用接口到SLC語(yǔ)言中合約條款描述的映射關(guān)系，實(shí)現(xiàn)了一種基于智能法律合約“注冊(cè)條款”的服務(wù)注冊(cè)交互行為的規(guī)范化方法，以法律上“要約-承諾”方式為消費(fèi)方合法獲取軟件服務(wù)權(quán)益奠定了基礎(chǔ)；其次，提出了一種服務(wù)發(fā)現(xiàn)與消費(fèi)過程中消費(fèi)需求與計(jì)費(fèi)合約化機(jī)制，以服務(wù)發(fā)現(xiàn)中的三級(jí)緩存機(jī)制和服務(wù)匹配方法為基礎(chǔ)，設(shè)計(jì)了對(duì)服務(wù)發(fā)現(xiàn)請(qǐng)求和響應(yīng)進(jìn)行約定的智能法律合約“發(fā)現(xiàn)條款”與“定制化條款”，并在服務(wù)消費(fèi)中借助智能合約自動(dòng)執(zhí)行并檢查條款，實(shí)現(xiàn)細(xì)化到服務(wù)接口調(diào)用級(jí)別的精準(zhǔn)計(jì)費(fèi)模式，進(jìn)而確保服務(wù)交易行為存證到區(qū)塊鏈系統(tǒng)，從法律上為“先服務(wù)后結(jié)算”模式提供了保障.

1 系統(tǒng)框架

本文的目標(biāo)是探索“由軟件到服務(wù)、再由服務(wù)到合約”的新型軟件服務(wù)交易，即通過一種SaaS+SaaSC的軟件架構(gòu)實(shí)現(xiàn)“先服務(wù)后結(jié)算”的軟件訂閱模式，在技術(shù)上推動(dòng)軟件服務(wù)交易的法律化和金融化.架構(gòu)核心是以服務(wù)質(zhì)量和數(shù)量為基礎(chǔ)，以按勞分配、公平公正的交易原則，建立“先服務(wù)后結(jié)算”的軟件訂閱模式，依法保護(hù)軟件服務(wù)消費(fèi)者合法權(quán)益.

1.1 系統(tǒng)架構(gòu)

根據(jù)系統(tǒng)目標(biāo)，本文設(shè)計(jì)了一種面向軟件服務(wù)交易的SaaS+SaaSC架構(gòu).如圖1所示，該架構(gòu)在現(xiàn)有SaaS微服務(wù)框架基礎(chǔ)上，借助區(qū)塊鏈智能法律合約在法律化和自動(dòng)化交易方面的獨(dú)特優(yōu)勢(shì)，將軟件訂閱合同映射為智能法律合約，解決引言中基于智能合約的服務(wù)注冊(cè)與發(fā)布及發(fā)現(xiàn)與消費(fèi)中的關(guān)鍵挑戰(zhàn)，將智能法律合約應(yīng)用于服務(wù)計(jì)算環(huán)境.圖1中SaaS+SaaSC架構(gòu)的四個(gè)實(shí)體描述如下：

圖1 SaaS+SaaSC 架構(gòu)示意圖Fig.1 Architecture of SaaS+SaaSC system

(1) 服務(wù)消費(fèi)方（Consumer）：指為實(shí)現(xiàn)自身需求以有償方式使用在線軟件服務(wù)的一方，簡(jiǎn)稱甲方；

(2) 服務(wù)提供方（Provider）：指為滿足消費(fèi)方需求，通過平臺(tái)提供在線軟件服務(wù)的一方，簡(jiǎn)稱乙方；

(3) 服務(wù)交易平臺(tái)（Platform）：支持服務(wù)提供方和消費(fèi)方進(jìn)行合約化服務(wù)交易的在線共享區(qū)域，簡(jiǎn)稱丙方.

(4) 區(qū)塊鏈平臺(tái)（Blockchain）：指采用密碼手段保障、只可追加、鏈?zhǔn)浇Y(jié)構(gòu)組織的分布式賬本系統(tǒng)[10]，目的是實(shí)現(xiàn)去中心化服務(wù)交易的完整性、不可否認(rèn)性、可追溯性[11]等安全目標(biāo).

在圖1所示SaaS+SaaSC架構(gòu)中，服務(wù)提供方與服務(wù)消費(fèi)方通過合約平臺(tái)簽訂由智能法律合約編寫的“軟件訂閱合同”，進(jìn)而產(chǎn)生服務(wù)消費(fèi)活動(dòng).消費(fèi)活動(dòng)的發(fā)起方載體表現(xiàn)多樣，可以通過Web應(yīng)用、智能手機(jī)終端、第三方客戶端等多種方式訪問平臺(tái)提供的統(tǒng)一網(wǎng)關(guān)接口（Gateway）.網(wǎng)關(guān)從注冊(cè)中心（Service’s registry）獲取服務(wù)與地址對(duì)應(yīng)信息，將服務(wù)請(qǐng)求路由轉(zhuǎn)發(fā)到對(duì)應(yīng)微服務(wù)接口.在此過程中，合約引擎（Contract engine）作為區(qū)塊鏈交互的執(zhí)行模塊，負(fù)責(zé)執(zhí)行已簽訂“軟件訂閱合同”中相應(yīng)條款，將合約代碼和中間狀態(tài)以區(qū)塊鏈交易的格式讀取或存入?yún)^(qū)塊鏈.

1.2 系統(tǒng)實(shí)體關(guān)系與流程

在上述系統(tǒng)架構(gòu)中本文將主要研究基于智能合約的服務(wù)注冊(cè)、發(fā)現(xiàn)與消費(fèi)三個(gè)階段.為了清晰地展示這三個(gè)階段，圖2表示了主要實(shí)體間的交互關(guān)系，并將上述三大階段按流程先后關(guān)系分為注冊(cè)與發(fā)布（Registration and publication）、發(fā)現(xiàn)（Discovery）、推薦（Recommendation）、請(qǐng)求（Request）、綁定（Binding）、消費(fèi)（Consumption）、結(jié)算（Transation）等步驟：

圖2 SaaSC 系統(tǒng)主要實(shí)體間關(guān)系Fig.2 Relationships among essential entities in SaaSC system

(1) 服務(wù)注冊(cè)與發(fā)布.

本階段是指服務(wù)將自身模塊信息向交易平臺(tái)宣稱、平臺(tái)再根據(jù)約定推廣服務(wù)的過程.服務(wù)提供方使用SLC范本對(duì)服務(wù)注冊(cè)與發(fā)布過程進(jìn)行合同意義上的封裝，被稱為服務(wù)的合約化封裝.在此過程中服務(wù)提供方提交接口注冊(cè)信息的同時(shí)將服務(wù)接口承諾寫入SLC范本，繼而采用“服務(wù)注冊(cè)條款（SRT）”對(duì)服務(wù)接口宣稱進(jìn)行約定與檢查（見圖2階段 1）.

(2) 服務(wù)發(fā)現(xiàn)與綁定.

消費(fèi)方通過平臺(tái)獲取可用服務(wù)列表進(jìn)而使用服務(wù)的過程稱為服務(wù)發(fā)現(xiàn)與綁定.首先，平臺(tái)作為聯(lián)系服務(wù)提供方與消費(fèi)方的橋梁，依據(jù)已注冊(cè)SLC范本中“服務(wù)發(fā)現(xiàn)條款（SDT）”接受發(fā)現(xiàn)請(qǐng)求，并提供對(duì)應(yīng)的服務(wù)列表（見圖2階段2.A）.其次，服務(wù)推薦是將多家服務(wù)整合，根據(jù)評(píng)價(jià)指標(biāo)給出評(píng)估結(jié)果排名，由于服務(wù)推薦使用現(xiàn)有推薦算法[12]，故在本文中不作為重點(diǎn)內(nèi)容（見圖2階段2.B）.然后，服務(wù)提供方和消費(fèi)方根據(jù)定制化條款約定服務(wù)內(nèi)容，消費(fèi)方請(qǐng)求所選擇服務(wù)授權(quán)軟件許可（見圖2階段3.A）.提供方根據(jù)定制化條款授權(quán)具體的服務(wù)資源綁定到條款指定的接口描述，雙方通過合約訂立確立最終合約形式并生成可執(zhí)行智能合約程序部署到區(qū)塊鏈平臺(tái)（見圖2階段3.B）.

(3) 服務(wù)消費(fèi)與結(jié)算.

本階段是“先服務(wù)后結(jié)算”軟件訂閱模式的執(zhí)行過程.根據(jù)條款規(guī)定的定價(jià)規(guī)則，服務(wù)提供方先期交付SaaS訂閱使用權(quán)，消費(fèi)方通過合約中規(guī)定的條款按需調(diào)用SaaS軟件服務(wù)（圖2階段4.A）.智能合約程序根據(jù)服務(wù)消費(fèi)賬單進(jìn)行結(jié)算，將資金轉(zhuǎn)賬到服務(wù)提供方賬戶（圖2階段4.B）.

1.3 軟件訂閱合同中的條款

上述階段中，合約引擎提供智能合約部署與執(zhí)行等功能.智能法律合約作為設(shè)計(jì)開發(fā)工具，約定平臺(tái)與服務(wù)提供方、消費(fèi)方之間采用三種條款規(guī)范兩兩之間交互行為與結(jié)果：

(1) 服務(wù)注冊(cè)條款SRT：是指合約中用于以資產(chǎn)（Asset）形式描述服務(wù)接口（Interface）并將資產(chǎn)提交給平臺(tái)（通過Commit子條款）、以及平臺(tái)將其中的服務(wù)接口發(fā)布到服務(wù)列表中（通過Register子條款）的相應(yīng)條款，其中，Commit和Register為合約模板中約定的兩個(gè)子條款.

(2) 服務(wù)發(fā)現(xiàn)條款SDT：是指合約中用于消費(fèi)方向服務(wù)交易平臺(tái)提交發(fā)現(xiàn)請(qǐng)求（通過Request子條款）及平臺(tái)向消費(fèi)方提供服務(wù)列表.依據(jù)條款中關(guān)于服務(wù)功能或質(zhì)量的限制條件，服務(wù)發(fā)現(xiàn)請(qǐng)求中可附帶檢索信息以幫助平臺(tái)縮小檢索范圍.

(3) 服務(wù)定制化條款（SCT）：服務(wù)提供方和消費(fèi)方依據(jù)協(xié)商一致的原則自行定義各方權(quán)利義務(wù)和服務(wù)計(jì)費(fèi)標(biāo)準(zhǔn).合同條款協(xié)商完畢的標(biāo)志是合約訂立.合約訂立即“要約?承諾”的過程，與服務(wù)請(qǐng)求綁定過程相對(duì)應(yīng).

2 服務(wù)注冊(cè)與發(fā)布

本節(jié)將使用智能法律合約語(yǔ)言SPESC進(jìn)行服務(wù)注冊(cè)與發(fā)布的合約化封裝.服務(wù)提供方提交接口注冊(cè)信息同時(shí)將服務(wù)接口承諾寫入智能法律合約，繼而采用合約中資產(chǎn)表示對(duì)服務(wù)接口宣稱進(jìn)行約定與檢查.SPESC語(yǔ)法模型的構(gòu)成要素包括合約名稱、當(dāng)事人描述、標(biāo)的、合約條款、附加信息、合約訂立等.同時(shí)，智能法律合約編寫過程中涉及權(quán)利和義務(wù)、資產(chǎn)操作、表達(dá)式、時(shí)間表示等語(yǔ)法規(guī)范（見文獻(xiàn)[7]）.后文將采用該語(yǔ)法模型對(duì)服務(wù)進(jìn)行合約化描述.

2.1 合約當(dāng)事人聲明

首先，SPESC智能法律合約中需要記錄提供服務(wù)的負(fù)責(zé)人信息，服務(wù)實(shí)體作為合約當(dāng)事人，對(duì)應(yīng)智能法律合約的合約參與方（Party）.在SPESC語(yǔ)言描述的智能法律合約中，合約當(dāng)事人的屬性采用鍵?值對(duì)描述，其中，屬性鍵由合約范本指定，屬性值可以留空或者預(yù)先填充.

本文中合約范本（或稱合同范本）采用合約模板化思想[13]進(jìn)行設(shè)計(jì).該思想最早來(lái)源于李嘉圖合約（Ricardian contract）[14]，旨在通過可讀性語(yǔ)言以類似合同文本的形式描述合同中每個(gè)條款的意思表示，并將其與當(dāng)事人的意志選擇分離開，前者被轉(zhuǎn)化為合約模板，后者生成數(shù)據(jù)域.在合約模板代碼被上傳到區(qū)塊鏈系統(tǒng)后，區(qū)塊鏈提供的去中心化計(jì)算能力支持分布式環(huán)境下多方當(dāng)事人對(duì)數(shù)據(jù)域進(jìn)行填充與交換協(xié)商.因此，合約模板與數(shù)據(jù)域相分離的設(shè)計(jì)方式融合區(qū)塊鏈去中心化計(jì)算能力，支持了多方當(dāng)事人對(duì)合約進(jìn)行并發(fā)操作.

如圖3(a)所示，合約范本為每個(gè)當(dāng)事人設(shè)置賬戶和身份證明兩個(gè)屬性.由于服務(wù)提供方提供合約范本，故已在其中添加了屬性值；其余當(dāng)事人在合同協(xié)商過程中動(dòng)態(tài)填入屬性值.當(dāng)事人還可以擁有其他屬性，如可操作的動(dòng)作等，在后文中將通過合約條款的方式進(jìn)行聲明.微服務(wù)應(yīng)用（Service app）、當(dāng)事人與智能合約的統(tǒng)一建模語(yǔ)言（UML）之間關(guān)聯(lián)關(guān)系如圖3(b)所示.其中，實(shí)體類（InstanceInfo）表示運(yùn)行微服務(wù)的實(shí)例信息，微服務(wù)與其實(shí)例信息為組合關(guān)系；Party表示合約當(dāng)事人，繼承自區(qū)塊鏈賬戶實(shí)體類（Blockchain account）；智能合約的具體類（Smart contract）繼承自合約范本抽象類（Contract pattern）.微服務(wù)與智能合約、當(dāng)事人與智能合約均為多對(duì)多關(guān)系.當(dāng)事人可作為提供方負(fù)責(zé)（零或）多個(gè)微服務(wù)，一個(gè)微服務(wù)至少需將一個(gè)當(dāng)事人作為提供方，故兩者間為一到多關(guān)系.此外，合約當(dāng)事人在區(qū)塊鏈上依然采用匿名機(jī)制（視為匿名礦工賬戶[13]），而由云平臺(tái)負(fù)責(zé)對(duì)匿名區(qū)塊鏈賬戶進(jìn)行身份識(shí)別，確認(rèn)其對(duì)應(yīng)的真實(shí)身份，因此，智能合約發(fā)起區(qū)塊鏈交易中記錄該匿名帳戶地址即可.

圖3 合約當(dāng)事人描述與關(guān)系結(jié)構(gòu).(a)SPESC合約當(dāng)事人描述; (b)微服務(wù)、當(dāng)事人與智能合約的UML模型Fig.3 Contract party ’s description and relation model: (a) example of parties’ description in a SPESC contract; (b) UML relation model among microservices, parties and contracts

2.2 服務(wù)接口合約化

亨德里克森在《會(huì)計(jì)理論》中認(rèn)為，用于購(gòu)買服務(wù)的支出形成無(wú)形資產(chǎn)[15].基于將SPESC合約中的軟件服務(wù)承諾看作無(wú)形資產(chǎn)的前提假設(shè)，SPESC 語(yǔ)法定義的服務(wù)接口類型（Type service）繼承于合約資產(chǎn)關(guān)鍵字（Asset），見圖4右部?jī)蓚€(gè)結(jié)構(gòu)體的描述.這種定義方式的好處是將無(wú)形的服務(wù)與有形的資產(chǎn)進(jìn)行統(tǒng)一封裝，并且符合軟件工程的開閉模式設(shè)計(jì)原則.

圖4中完整描述了樣例中“服務(wù)注冊(cè)接口”和“提供方服務(wù)接口”的合約化聲明.服務(wù)接口（圖4左部）采用Java語(yǔ)言編寫，由SPESC定義的接口聲明（圖4右部）則由文檔生成工具提取并轉(zhuǎn)化為必要屬性，轉(zhuǎn)化關(guān)系如圖中箭頭所示.接口聲明中的必要屬性包括：提供服務(wù)實(shí)例的地址與服務(wù)名（Instances）、服務(wù)所接收的路徑（Paths）及路徑下接口所需參數(shù)（Parameters）、動(dòng)作類型（Methods）及返回狀態(tài)碼（Responses）等.服務(wù)接口的聲明格式參照OpenAPI 3.0版本標(biāo)準(zhǔn)[16]實(shí)施.依據(jù)對(duì)服務(wù)接口的實(shí)際要求，合約當(dāng)事人可協(xié)商添加原本服務(wù)接口描述中所沒有的權(quán)屬（Rights）和必要的計(jì)費(fèi)字段（Price）等.基于上述合約化聲明，提供方將添加接口描述后的合約范本與服務(wù)注冊(cè)信息一并發(fā)送給注冊(cè)中心，進(jìn)而推廣給服務(wù)消費(fèi)方.

圖4 服務(wù)接口與智能法律合約中服務(wù)聲明對(duì)應(yīng)圖Fig.4 Mapping from service interfaces to service declarations in Smart Legal Contract

2.3 服務(wù)注冊(cè)合約條款

在合同層面上，服務(wù)提供方（甲方）的注冊(cè)過程應(yīng)視為向服務(wù)交易平臺(tái)（丙方）發(fā)起委托請(qǐng)求的過程，丙方的發(fā)布過程應(yīng)視為接受甲方委托請(qǐng)求的過程.甲方與丙方之間這種服務(wù)注冊(cè)發(fā)布過程的權(quán)利與義務(wù)關(guān)系使用如圖5所的示條款進(jìn)行規(guī)定.條款no1分為2個(gè)子條款，分別由甲方和丙方予以實(shí)施.子條款no1_1規(guī)定服務(wù)注冊(cè)請(qǐng)求由甲方提交，其中所含的服務(wù)注冊(cè)信息應(yīng)包括：服務(wù)域名地址與端口、服務(wù)接口路徑、生成時(shí)間戳、狀態(tài)檢查接口信息、以及被添加在自定義信息（metadata）中的合約范本.子條款no1_2規(guī)定丙方實(shí)施注冊(cè)動(dòng)作的義務(wù)，包括：

圖5 服務(wù)注冊(cè)條款Fig.5 Term of service registration

(1) when語(yǔ)句：指示前置條件，用于檢查甲方服務(wù)信息是否已經(jīng)提交.

(2) while語(yǔ)句：指示伴隨動(dòng)作，用于為丙方添加服務(wù)的使用權(quán)，以保證平臺(tái)對(duì)服務(wù)功能進(jìn)行測(cè)試和提供消費(fèi)方試用的權(quán)利.

(3) where語(yǔ)句：指示后置條件，用于檢查注冊(cè)后的服務(wù)狀態(tài).

在when語(yǔ)句中，防止重復(fù)注冊(cè)的原理是鍵-值表中的每個(gè)鍵只對(duì)應(yīng)一條服務(wù)實(shí)例信息，不允許重復(fù).服務(wù)提供方提交服務(wù)的操作過程中如果產(chǎn)生失敗，合約引擎會(huì)回滾操作，以保證下次條款前置條件檢查依舊會(huì)判定動(dòng)作未執(zhí)行.在where語(yǔ)句中，由丙方調(diào)用狀態(tài)檢查（healthCheck）函數(shù)訪問甲方提供的地址，如果注冊(cè)成功則返回成功狀態(tài)碼（即前述定義 code: 204）.

若服務(wù)通過條款no1的全部檢查過程，則丙方將發(fā)布服務(wù)，完成服務(wù)注冊(cè)與發(fā)布階段.服務(wù)注冊(cè)過程隱含的權(quán)利義務(wù)關(guān)系是服務(wù)提供方將服務(wù)授權(quán)給服務(wù)平臺(tái)，平臺(tái)接收委托則有義務(wù)為其推廣銷售.服務(wù)提供方與注冊(cè)中心的交互與狀態(tài)轉(zhuǎn)移過程的技術(shù)點(diǎn)在下一節(jié)表述.

2.4 服務(wù)注冊(cè)交互與狀態(tài)轉(zhuǎn)移

服務(wù)注冊(cè)中心的任務(wù)是通過交互動(dòng)作維護(hù)服務(wù)提供方微服務(wù)的注冊(cè)信息，交互動(dòng)作按發(fā)起方的不同可分為微服務(wù)主動(dòng)發(fā)起和注冊(cè)中心自行發(fā)起兩大類.微服務(wù)能主動(dòng)發(fā)起的動(dòng)作有四種，分別是注冊(cè)（Register）、心跳連接（Renew）、狀態(tài)更新（StatusUpdate）、取消（Cancel），四種交互動(dòng)作以HTTP報(bào)文格式封裝.

注冊(cè)中心能自行發(fā)起的動(dòng)作有兩種，分別是心跳續(xù)約超時(shí)（Expire）和定期清理（Evict）.在原有的Eureka模塊中，注冊(cè)中心還記錄微服務(wù)的四種狀態(tài)，包括服務(wù)啟動(dòng)（Starting）、服務(wù)上線（Up）、異常掉線（Out-of-service）、服務(wù)下線（Down）.如圖6(a)所示，結(jié)合上述6種交互動(dòng)作和4種微服務(wù)狀態(tài)，對(duì)服務(wù)狀態(tài)轉(zhuǎn)移流程描述如下：

圖6 微服務(wù)注冊(cè)狀態(tài)轉(zhuǎn)移示意圖.(a)原有 Eureka 注冊(cè)中心狀態(tài)轉(zhuǎn)移; (b)合約化注冊(cè)狀態(tài)轉(zhuǎn)移Fig.6 State transfer in microservice registration: (a) state transfer in original Eureka center; (b) state transfer in contract based registration

(1) 當(dāng)注冊(cè)中心收到微服務(wù)第一次注冊(cè)請(qǐng)求時(shí)，將狀態(tài)置為服務(wù)啟動(dòng).如果通過審核成功，則將服務(wù)信息加入到服務(wù)列表中，狀態(tài)更新為服務(wù)上線狀態(tài).

(2) 上線狀態(tài)的微服務(wù)到達(dá)下一狀態(tài)有3種可能，分別為維持上線狀態(tài)、進(jìn)入異常掉線狀態(tài)和進(jìn)入服務(wù)下線狀態(tài).為了維持上線狀態(tài)，微服務(wù)需要定期向平臺(tái)發(fā)送心跳連接以證實(shí)自身狀態(tài)，未及時(shí)發(fā)送心跳連接的微服務(wù)將觸發(fā)平臺(tái)執(zhí)行續(xù)約超時(shí)動(dòng)作，被標(biāo)記為異常掉線狀態(tài).微服務(wù)也可以主動(dòng)結(jié)束生命周期，通過發(fā)送取消動(dòng)作請(qǐng)求進(jìn)入下線狀態(tài).

(3) 平臺(tái)按清理周期（默認(rèn)參數(shù)Eviction-intervaltimer設(shè)置為 60 s）定期清理心跳超時(shí)的服務(wù).清理周期設(shè)置一個(gè)較大的值以防止出現(xiàn)因注冊(cè)中心網(wǎng)絡(luò)中斷而導(dǎo)致微服務(wù)誤下線的情況，這屬于注冊(cè)中心的自我保護(hù)機(jī)制.被清理后的微服務(wù)進(jìn)入下線狀態(tài)，被動(dòng)結(jié)束服務(wù)生命周期.

圖6 (b)描述了合約化后的服務(wù)狀態(tài)轉(zhuǎn)移關(guān)系.結(jié)合服務(wù)部分與合約部分的狀態(tài)轉(zhuǎn)移關(guān)系，流程描述如下：

(1) 當(dāng)收到微服務(wù)首次注冊(cè)請(qǐng)求時(shí)，注冊(cè)中心將該微服務(wù)狀態(tài)置為服務(wù)啟動(dòng)；此后，狀態(tài)服務(wù)商需要選擇或提供含有服務(wù)定制條款的合約范本，完成服務(wù)注冊(cè)條款約定的交互行為后才可上線.

(2) 消費(fèi)方依據(jù)服務(wù)發(fā)現(xiàn)條款選擇服務(wù)并進(jìn)入合約簽署過程，在雙方確認(rèn)完成合約訂立后，合約部署到區(qū)塊鏈系統(tǒng).

(3) 依據(jù)雙方協(xié)商的定制化服務(wù)條款與定價(jià)標(biāo)準(zhǔn)，消費(fèi)者賬戶向合約賬戶充值生成合約實(shí)例后，該微服務(wù)進(jìn)入合約化服務(wù)狀態(tài)，實(shí)施使用時(shí)計(jì)費(fèi).

(4) 在合約化服務(wù)狀態(tài)下，服務(wù)違約行為（心跳超時(shí)、條款執(zhí)行失敗、違約條款條件成立等）將觸發(fā)合約引擎的異常處理功能.

相比圖6 (a)原狀態(tài)機(jī)模型，服務(wù)啟動(dòng)過程需要提供相應(yīng)的服務(wù)注冊(cè)合約條款信息，服務(wù)心跳超時(shí)會(huì)觸發(fā)異常處理而不是直接進(jìn)入服務(wù)異常狀態(tài).合約簽署確認(rèn)成功生成合約實(shí)例后，將進(jìn)入合約化服務(wù)狀態(tài).上述合約實(shí)例是對(duì)SPESC合約條款邏輯的具體實(shí)現(xiàn)，合約條款執(zhí)行過程包括檢查前置條件、執(zhí)行伴隨動(dòng)作和檢查后置條件.根據(jù)合約交易的原子性（All or nothing）原則，只有當(dāng)前置條件、動(dòng)作執(zhí)行和后置條件都滿足后，合約狀態(tài)才會(huì)產(chǎn)生更新.

3 服務(wù)發(fā)現(xiàn)與綁定

SaaSC架構(gòu)下合約當(dāng)事人依據(jù)智能法律合約的判定結(jié)果提供服務(wù)和支付服務(wù)費(fèi).服務(wù)提供方依據(jù)合約條款的規(guī)定提供服務(wù)，服務(wù)消費(fèi)方則依據(jù)合約條款獲取服務(wù)進(jìn)而消費(fèi)服務(wù)，并觸發(fā)智能合約完成轉(zhuǎn)賬功能.消費(fèi)方可根據(jù)實(shí)際需求檢索服務(wù)承諾，通過平臺(tái)簽署智能法律合約以獲取所需的軟件服務(wù).

3.1 服務(wù)發(fā)現(xiàn)合約條款

如圖7所示，服務(wù)發(fā)現(xiàn)條款規(guī)定服務(wù)消費(fèi)方（乙方）可調(diào)用平臺(tái)（丙方）的服務(wù)發(fā)現(xiàn)接口，丙方有義務(wù)返回匹配的服務(wù)列表.其技術(shù)原理是服務(wù)注冊(cè)中心提供服務(wù)發(fā)現(xiàn)接口調(diào)用地址（圖4左側(cè)GetInstances接口），消費(fèi)方通過服務(wù)發(fā)現(xiàn)客戶端發(fā)送HTTP GET請(qǐng)求，此過程觸發(fā)合約引擎記錄子條款 no2_1 中請(qǐng)求（Request）動(dòng)作.服務(wù)發(fā)現(xiàn)（Discover）過程可以指定服務(wù)ID進(jìn)行精準(zhǔn)匹配，或者根據(jù)檢索信息進(jìn)行模糊匹配，包括：

圖7 服務(wù)發(fā)現(xiàn)條款Fig.7 Term of service discovery

(1) 服務(wù)功能匹配.

服務(wù)功能匹配的種類包括：定購(gòu)服務(wù)數(shù)量、時(shí)間長(zhǎng)短、特定服務(wù)特征等，即請(qǐng)求中攜帶用戶檢索與上述種類相關(guān)的關(guān)鍵字，丙方根據(jù)關(guān)鍵字信息返回匹配后的相關(guān)列表.若服務(wù)提供方擁有多個(gè)地區(qū)的運(yùn)營(yíng)服務(wù)器，服務(wù)發(fā)現(xiàn)客戶端可根據(jù)服務(wù)器所屬地區(qū)提供對(duì)應(yīng)服務(wù)實(shí)例的匹配結(jié)果.

(2) 服務(wù)質(zhì)量匹配.

匹配的服務(wù)將按照質(zhì)量由高到低的順序依次顯示.服務(wù)質(zhì)量評(píng)價(jià)指標(biāo)根據(jù)平臺(tái)統(tǒng)計(jì)數(shù)據(jù)收集，包括：該服務(wù)以往使用人數(shù)、是否產(chǎn)生違約、用戶評(píng)分等.

合約引擎通過子條款no2_2監(jiān)聽注冊(cè)中心的服務(wù)發(fā)現(xiàn)動(dòng)作.該子條款由客戶端HTTP GET請(qǐng)求觸發(fā)，伴隨動(dòng)作將合約中記錄的服務(wù)使用權(quán)授權(quán)給消費(fèi)方.在動(dòng)作執(zhí)行結(jié)果產(chǎn)生返回值時(shí)檢查是否返回成功狀態(tài)碼（即前述code: 204），以保證客戶端請(qǐng)求結(jié)果被成功響應(yīng).

服務(wù)發(fā)現(xiàn)階段結(jié)束并進(jìn)入下一階段的標(biāo)志是消費(fèi)方為選定的服務(wù)預(yù)付款.預(yù)付款作為消費(fèi)方履行服務(wù)約定的保證金交由平臺(tái)暫存.完成預(yù)付款的過程需要服務(wù)參與方對(duì)合約條款聲明達(dá)成一致，此階段稱為合約訂立階段.合約訂立是服務(wù)參與方對(duì)服務(wù)合約中的意思表示進(jìn)行“要約?承諾”的過程；在技術(shù)上，此階段需采用密碼學(xué)手段保障合約訂立合規(guī)性，如使用身份認(rèn)證技術(shù)驗(yàn)證參與方的身份使其不可偽造；采用數(shù)字簽名保證當(dāng)事人對(duì)簽訂服務(wù)合約行為不可抵賴；借助區(qū)塊鏈存證以保證簽署確認(rèn)后的服務(wù)合約不可篡改.

3.2 服務(wù)發(fā)現(xiàn)緩存機(jī)制

服務(wù)發(fā)現(xiàn)是指服務(wù)消費(fèi)方通過向平臺(tái)發(fā)送檢索請(qǐng)求獲取所需服務(wù)的過程.平臺(tái)負(fù)責(zé)維護(hù)已注冊(cè)服務(wù)列表，該列表的數(shù)據(jù)結(jié)構(gòu)為鍵-值對(duì)映射表.微服務(wù)架構(gòu)的消費(fèi)方無(wú)需事先知曉服務(wù)IP地址，而是交由服務(wù)發(fā)現(xiàn)客戶端（圖8中Eureka client）作為代理定期與注冊(cè)中心同步緩存服務(wù)列表，通過檢索服務(wù)緩存獲取服務(wù)注冊(cè)信息與實(shí)際IP地址等匹配信息.服務(wù)發(fā)現(xiàn)客戶端緩存的服務(wù)列表需要與注冊(cè)中心的服務(wù)列表保持最終一致，客戶端緩存服務(wù)列表的獲取包括以下兩種模式：

圖8 三級(jí)緩存同步機(jī)制示意圖Fig.8 Three levels of cache mechanism for replication

(1) 全量更新服務(wù)列表：客戶端請(qǐng)求全部應(yīng)用的服務(wù)注冊(cè)信息.如果注冊(cè)中心的當(dāng)前緩存中沒有該信息，則向上一級(jí)注冊(cè)表請(qǐng)求得到服務(wù)注冊(cè)信息，并且在當(dāng)前一級(jí)添加緩存.當(dāng)同步過程檢查出列表中各個(gè)狀態(tài)對(duì)應(yīng)的服務(wù)數(shù)量不一致時(shí)，也會(huì)觸發(fā)全量更新.

(2) 增量更新服務(wù)列表：在客戶端已有緩存的前提下，通過定期比較得到本地緩存與注冊(cè)中心緩存的差異獲取某個(gè)應(yīng)用的服務(wù)信息.緩存定期更新的過程由后臺(tái)線程的駐留任務(wù)執(zhí)行（默認(rèn)周期值為⑥）.

如圖8所示，注冊(cè)中心提供三級(jí)緩存機(jī)制用于同步服務(wù)列表，分別為可讀可寫表（registry）、讀寫緩存表（readWriteCacheMap）、只讀緩存表（read-OnlyCacheMap），通過參數(shù)設(shè)置定期同步.可讀可寫表儲(chǔ)存即時(shí)的全部服務(wù)列表數(shù)據(jù)；讀寫緩存表保存最近被讀取或?qū)懭氲姆?wù)列表（默認(rèn)保存時(shí)間為①），服務(wù)發(fā)現(xiàn)客戶端每讀或?qū)懸粭l數(shù)據(jù)，可讀可寫表將這條數(shù)據(jù)即時(shí)寫入讀寫緩存中；只讀緩存表非即時(shí)更新，而是按配置周期從可讀可寫緩存表中更新（默認(rèn)周期值為②）.針對(duì)服務(wù)發(fā)現(xiàn)場(chǎng)景對(duì)于及時(shí)性和吞吐量的不同需求，客戶端可選擇從讀寫緩存（默認(rèn)配置③）或只讀緩存（配置④）同步數(shù)據(jù).

3.3 服務(wù)接口的請(qǐng)求綁定

請(qǐng)求綁定過程將協(xié)商完成的服務(wù)合約綁定到具體的傳輸協(xié)議上，與合約訂立的“要約?承諾”過程相對(duì)應(yīng).由消費(fèi)方發(fā)送服務(wù)授權(quán)請(qǐng)求，授權(quán)結(jié)果由服務(wù)提供方發(fā)布到區(qū)塊鏈上進(jìn)行存證.服務(wù)提供方和消費(fèi)方通過區(qū)塊鏈完成請(qǐng)求綁定后，在條款規(guī)定的服務(wù)要求內(nèi)，服務(wù)提供方有義務(wù)提供按需服務(wù)，消費(fèi)方有權(quán)利向服務(wù)提供方發(fā)起服務(wù)請(qǐng)求.

通常情況下，一次請(qǐng)求綁定過程由消費(fèi)方發(fā)起，由提供方實(shí)現(xiàn)響應(yīng).目前的消息傳輸方式有RESTful、遠(yuǎn)程過程調(diào)用（RPC）、消息中間件三種.RPC傳輸數(shù)據(jù)格式通常為二進(jìn)制格式，需要自定義協(xié)議格式；消息中間件雖然對(duì)異步傳輸支持較好，但需要單獨(dú)部署服務(wù)端口，復(fù)雜度較高；而RESTful請(qǐng)求可采用封裝了JSON格式的HTTP報(bào)文，可讀性與可分析性更強(qiáng).綜合考慮，本文將采取RESTful接口傳輸HTTP數(shù)據(jù)報(bào)文.

如圖9所示，智能法律合約中的服務(wù)接口聲明在請(qǐng)求綁定的過程中采用HTTP報(bào)文封裝形式.將接口聲明中url字段與path字段映射為報(bào)文訪問路徑，將method字段映射為HTTP方法，將parameters字段映射為報(bào)文中的訪問參數(shù)，將responses字段映射為接收HTTP報(bào)文的返回值等.最終實(shí)現(xiàn)將服務(wù)消費(fèi)過程綁定到基于HTTP的請(qǐng)求響應(yīng)行為中.

圖9 服務(wù)接口聲明請(qǐng)求綁定至 HTTP 報(bào)文示意圖Fig.9 Mapping from service interface to HTTP package

4 服務(wù)消費(fèi)與結(jié)算

4.1 服務(wù)消費(fèi)定制合約條款

在服務(wù)請(qǐng)求綁定過程中，消費(fèi)方發(fā)起的合約簽訂請(qǐng)求可以看作服務(wù)要約[17].請(qǐng)求授權(quán)的過程可以是多次協(xié)商獲得的結(jié)果，提供方和消費(fèi)方可以協(xié)商合約自定義條款中的具體服務(wù)參數(shù)，如服務(wù)期限、服務(wù)費(fèi)用、付款時(shí)間、服務(wù)強(qiáng)度等.通信協(xié)商的過程可借助區(qū)塊鏈實(shí)現(xiàn)存證.

雙方對(duì)智能法律合約中的自定義條款協(xié)商達(dá)成一致，示例條款如圖10所示，根據(jù)子條款no3_1，消費(fèi)方在發(fā)送服務(wù)消費(fèi)的同時(shí)向合約存入押金作為預(yù)付款.根據(jù)子條款no3_2，服務(wù)提供方在提供服務(wù)后從由合約轉(zhuǎn)賬取出預(yù)付款，實(shí)現(xiàn)“先服務(wù)后計(jì)費(fèi)”.若服務(wù)調(diào)用結(jié)束返回成功狀態(tài)碼（即code:200）則調(diào)用付款接口，立即轉(zhuǎn)賬到服務(wù)提供方地址.智能合約將保證儲(chǔ)存在合約中的余額非負(fù).以上條款實(shí)現(xiàn)了以“先服務(wù)后計(jì)費(fèi)”方式對(duì)服務(wù)接口進(jìn)行按次、按量精準(zhǔn)計(jì)費(fèi).

圖10 服務(wù)消費(fèi)定制化條款Fig.10 Term of service customized consumption

服務(wù)結(jié)束依賴于服務(wù)消費(fèi)請(qǐng)求接收到HTTP狀態(tài)碼code: 404，產(chǎn)生的原因分為兩種情況：

(1) 服務(wù)過程結(jié)束：服務(wù)提供方依據(jù)消費(fèi)定制條款中約定的條件提供一定次數(shù)或者一段時(shí)間的服務(wù).每次或每段時(shí)間的服務(wù)履行記錄由合約引擎以日志形式存證到區(qū)塊鏈系統(tǒng).當(dāng)合約引擎執(zhí)行條款條件不滿足時(shí)（如超出服務(wù)次數(shù)或時(shí)間限制）將判斷為服務(wù)過程結(jié)束，此時(shí)服務(wù)請(qǐng)求將不會(huì)響應(yīng)，而是返回404狀態(tài)碼.

(2) 合約終止：合約有效期（如使用次數(shù)和期限等）結(jié)束將導(dǎo)致合約終止.此外，在服務(wù)期限內(nèi)消費(fèi)方退訂服務(wù)也將導(dǎo)致合約終止，此過程需設(shè)置合約退訂子條款，即當(dāng)滿足退訂子條款的前置條件（如使用的最低次數(shù)或時(shí)間、合約賬戶中的剩余資金返還的比例計(jì)算方式等）時(shí)，平臺(tái)將執(zhí)行終止服務(wù)合約.終止的合約將無(wú)法進(jìn)行實(shí)例化，網(wǎng)關(guān)從注冊(cè)中心獲取對(duì)應(yīng)下線合約狀態(tài)并攔截關(guān)聯(lián)的服務(wù)消費(fèi)請(qǐng)求，并返回404狀態(tài)碼.

4.2 智能合約的交易格式

軟件服務(wù)的履行作為觸發(fā)事件，發(fā)送給合約引擎執(zhí)行智能合約中的服務(wù)條款，從而引發(fā)區(qū)塊鏈中合約狀態(tài)的改變.合約狀態(tài)改變將以區(qū)塊鏈交易方式予以記錄、通信與存證，可用于合約交易結(jié)算的過程.

表1所示的區(qū)塊鏈交易存儲(chǔ)結(jié)構(gòu)中合約相關(guān)的字段主要包括 Contract input和 Contract output兩部分，其中，Contract input部分記錄一次操作收到的輸入?yún)?shù)；Contract output部分記錄操作對(duì)結(jié)果的狀態(tài)更新.將Input和Output存儲(chǔ)在一個(gè)交易中以保證操作原子性.假設(shè)本次交易表示為Ti，前一次合約協(xié)商或執(zhí)行的交易表示為Ti?1，則Ti的last-Txid字段為前一次合約動(dòng)作產(chǎn)生的交易號(hào)，即與交易Ti?1的txid相等.此外，partySig動(dòng)作執(zhí)行方簽名與partyPubList中的公鑰匹配，以對(duì)操作的當(dāng)事人身份進(jìn)行驗(yàn)證.

表1 合約交易存儲(chǔ)結(jié)構(gòu)Table 1 Structure of the transaction storage in contract

5 基 于 智 能 合 約 的 服 務(wù) 案 例 設(shè) 計(jì) 與 實(shí) 驗(yàn)評(píng)估

本文平臺(tái)系統(tǒng)選取現(xiàn)代服務(wù)業(yè)中應(yīng)用廣泛的天氣預(yù)報(bào)服務(wù)場(chǎng)景作為應(yīng)用進(jìn)行案例與流程設(shè)計(jì).之后介紹實(shí)驗(yàn)環(huán)境與方案，并給出系統(tǒng)運(yùn)行過程和執(zhí)行效率的實(shí)驗(yàn)結(jié)果.

5.1 案例合約與流程設(shè)計(jì)

案例中使用SPESC語(yǔ)言描述的智能法律合約實(shí)現(xiàn)合同意思表示，如圖11所示.服務(wù)提供方、消費(fèi)方與平臺(tái)在服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、服務(wù)消費(fèi)三階段的權(quán)利與義務(wù)，經(jīng)三方共同參與協(xié)商、完善并達(dá)成一致.智能法律合約案例中將服務(wù)表達(dá)為一種資產(chǎn)類型，服務(wù)提供方擁有服務(wù)收益權(quán)，服務(wù)消費(fèi)方擁有服務(wù)使用權(quán).在合約中使用三個(gè)條款進(jìn)行描述三方準(zhǔn)許或必須的動(dòng)作等.條款1至3分別規(guī)定了服務(wù)提供方與服務(wù)平臺(tái)、服務(wù)消費(fèi)方與服務(wù)平臺(tái)、提供方與消費(fèi)方之間的服務(wù)注冊(cè)、發(fā)布、發(fā)現(xiàn)、消費(fèi)交互過程.

圖11 SPESC 智能法律合約天氣預(yù)報(bào)服務(wù)案例Fig.11 Complete example of SPESC Smart Legal Contract for weather forecast service

以天氣預(yù)報(bào)服務(wù)流程為例，本案例中的服務(wù)提供方和服務(wù)消費(fèi)方在流程開始時(shí)已擁有平臺(tái)的賬戶.服務(wù)提供方通過其賬戶發(fā)起服務(wù)注冊(cè)，注冊(cè)請(qǐng)求中附帶合同范本.消費(fèi)方在簽署合同之前，享有服務(wù)的需求選擇和試用權(quán).消費(fèi)方可在試用滿意后選擇服務(wù)，進(jìn)入對(duì)應(yīng)合約簽署確認(rèn).當(dāng)合同所有參與方都簽署完畢后，最終合同書生成，發(fā)布到區(qū)塊鏈上存證，保證可隨時(shí)查取.

根據(jù)文獻(xiàn)[18]中的方法，本案例采用代碼翻譯器將SPESC合同轉(zhuǎn)化為可執(zhí)行智能合約，由消費(fèi)方預(yù)付定金以激活合約實(shí)例化運(yùn)行.合約引擎通過執(zhí)行合約接口調(diào)用函數(shù)記錄提供服務(wù)和消費(fèi)服務(wù)的過程.服務(wù)過程將由區(qū)塊鏈系統(tǒng)記錄并通過智能合約執(zhí)行發(fā)起區(qū)塊鏈交易實(shí)現(xiàn)自動(dòng)計(jì)費(fèi).若合約賬戶中余額用盡，則平臺(tái)將通過網(wǎng)關(guān)攔截服務(wù)接口調(diào)用，直到消費(fèi)方用戶繼續(xù)充值續(xù)費(fèi)后再恢復(fù)通過.若消費(fèi)方用戶不再希望續(xù)訂天氣預(yù)報(bào)服務(wù)，則平臺(tái)將終止合約，由智能合約執(zhí)行退訂條款完成退款結(jié)算，結(jié)束合約化服務(wù)流程.

5.2 實(shí)驗(yàn)方案

依據(jù)前述的方法和案例，采用ANTLR和Java ASM框架實(shí)現(xiàn)SPESC語(yǔ)言在JVM運(yùn)行的字節(jié)碼編譯器；基于 Spring Cloud Eureka 實(shí)現(xiàn)服務(wù)交易平臺(tái)；使用Spring Boot微服務(wù)應(yīng)用框架編寫天氣預(yù)報(bào)服務(wù)，提供RESTful API調(diào)用接口；基于多鏈區(qū)塊鏈系統(tǒng)實(shí)現(xiàn)合約交易通信與存證.實(shí)驗(yàn)環(huán)境包含 3 臺(tái)機(jī)器，其中 1 臺(tái)為本地主機(jī)（Arch Linux, 8核 Intel CPU@1.60 GHz, 內(nèi)存 8 G），用于編譯 SEPSC智能法律合約和發(fā)起消費(fèi)方調(diào)用；另2臺(tái)為阿里云服務(wù)器（Ubuntu 16.04, 雙核 Intel CPU@2.50 GHz,內(nèi)存1 G），分別部署帶有合約引擎依賴的Eureka平臺(tái)與天氣預(yù)報(bào)服務(wù).

表2給出了一輪完整的基于智能法律合約的服務(wù)注冊(cè)、發(fā)現(xiàn)、消費(fèi)流程的模擬執(zhí)行結(jié)果.表2中每一行記錄了參與方的動(dòng)作任務(wù)請(qǐng)求、觸發(fā)的合約條款序列以及引發(fā)的響應(yīng)動(dòng)作.表2各列中，參與方動(dòng)作請(qǐng)求列自上而下順序記錄了參與方的動(dòng)作請(qǐng)求調(diào)用列表.智能合約參與方發(fā)起的動(dòng)作請(qǐng)求按照合約規(guī)定觸發(fā)條款條件檢查后才能執(zhí)行，通過執(zhí)行合約伴隨生成區(qū)塊鏈轉(zhuǎn)賬交易進(jìn)行鏈上資產(chǎn)轉(zhuǎn)移操作.基于鏈上合約模板與數(shù)據(jù)域分離的設(shè)計(jì)原則，對(duì)于多用戶和單用戶操作的性能影響沒有顯著不同.

表2 參與方動(dòng)作任務(wù)請(qǐng)求列表Table 2 Request list of parties’ action task

5.3 實(shí)驗(yàn)驗(yàn)證

本輪實(shí)驗(yàn)分析驗(yàn)證了SPESC語(yǔ)言編譯器執(zhí)行效率與合約程序在微服務(wù)系統(tǒng)中的運(yùn)行耗時(shí).

本地主機(jī)運(yùn)行編譯器對(duì)圖11案例進(jìn)行編譯，輸入合約文本通過ANTRL編寫的規(guī)則解析生成語(yǔ)法樹（AST），編譯實(shí)驗(yàn)結(jié)果如表3所示，統(tǒng)計(jì)輸入合約文本字符數(shù)為994，行數(shù)為118；編譯過程中的AST含有標(biāo)記數(shù)為187個(gè)；再通過Java ASM框架編寫的字節(jié)碼生成模塊生成.class可執(zhí)行文件，重復(fù)執(zhí)行10次的平均用時(shí)為570 ms，編譯輸出的可執(zhí)行合約文件字節(jié)大小為2754 B.上述實(shí)驗(yàn)結(jié)果表明，合約編譯速度快且所生成的合約占用空間小.

表3 智能法律合約編譯實(shí)驗(yàn)Table 3 Compiling experiment of the Smart Legal Contract

可執(zhí)行智能合約文件被打包為jar文件，通過微服務(wù)客戶端發(fā)送事件請(qǐng)求模擬合約調(diào)用過程.按照表2順序依次發(fā)送動(dòng)作請(qǐng)求對(duì)接口測(cè)試，其中，每個(gè)接口分別進(jìn)行20次調(diào)用測(cè)試并統(tǒng)計(jì)用時(shí).結(jié)果如圖12(a)、(b)、(c)所示，圖中橫軸表示測(cè)試序號(hào)，縱軸表示測(cè)試用時(shí).條形圖中的加深部分表示加入條款檢查之前的接口調(diào)用用時(shí)，三個(gè)接口調(diào)用平均用時(shí)分別為 3.80、11.40、9.60 ms，數(shù)值記錄在表4中第3列，并計(jì)算95%置信區(qū)間填入第4 列.圖12(a)、(b)、(c)斜線條紋部分分別表示添加執(zhí)行條款no1、no2、no3后所增加的用時(shí)，斜線條紋與深色加和結(jié)果表示執(zhí)行條款檢查后的平均接口測(cè)試用時(shí)，分別為 5.35、13.00、11.20 ms，將結(jié)果記錄到表4第5列，同時(shí)計(jì)算95%置信區(qū)間結(jié)果記錄在第6列.

圖12 接口用時(shí)測(cè)試圖.(a)條款 1 測(cè)試; (b)條款 2 測(cè)試; (c)條款 3 測(cè)試; (d)接口用時(shí)比較Fig.12 Tests of interface time cost: (a)test of term 1; (b)test of term 2; (c)test of term 3; (d)comparison of interface time cost

表4 接口調(diào)用測(cè)試表Table 4 Tests of interface time cost

為了更清晰地評(píng)估上述實(shí)驗(yàn)結(jié)果，圖12(d)對(duì)數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析，圖中黑點(diǎn)表示接口平均用時(shí)，紅色線段表示置信區(qū)間，經(jīng)過比較執(zhí)行條款檢查前后的接口用時(shí)結(jié)果，計(jì)算出條款檢查的運(yùn)行時(shí)間對(duì)原有服務(wù)增加的比例分別為40%、14%和17%.相比于引入合約條款之前的情況，服務(wù)過程的時(shí)間消耗差距為常數(shù)級(jí)別，且隨著原本服務(wù)耗時(shí)增加，合約條款檢查對(duì)時(shí)間效率影響有減小的趨勢(shì).這說明在微服務(wù)系統(tǒng)中引入SPESC合約不會(huì)引起時(shí)間消耗產(chǎn)生數(shù)量級(jí)上的負(fù)擔(dān).

6 總結(jié)

本文提出了SaaSC架構(gòu)，旨在優(yōu)化SaaS預(yù)先付費(fèi)的服務(wù)交易模型，形成SaaS+SaaSC的新型軟件服務(wù)交易模式.該模式將服務(wù)訂閱使用行為與智能法律合約中條款履行情況相綁定，可滿足各方當(dāng)事人生成服務(wù)合同用于履行服務(wù)的需求，更加方便自動(dòng)化交易與監(jiān)督監(jiān)管.本文實(shí)驗(yàn)以案例方式對(duì)基于智能法律合約的軟件服務(wù)交易模式進(jìn)行驗(yàn)證，結(jié)果表明上述模式為軟件服務(wù)的金融化和法律化提供一種新的可行技術(shù)路線.