6 party Consumer (a) b ServiceApp 1 account: certificate ID: party Provider! account:0xluWDvekrPw......A16pfAnBLY9U certificate1D:915780435....650792541 party Platform account: certificate ID: 图3合约当事人描述与关系结构：(a)SPESC合约当事人描述：(b)微服务、当事人与智能合约的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 组合关系：Party表示合约当事人，继承自区块链账户实体类(Blockchain Account):智能合约的具体类(Smart Contract)继承自合约范本抽象类(Contract Pattern)。微服务与智能合约、当事人与智能合约均为多对多关系。 当事人可作为提供方负责（零或）多个微服务，一个微服务至少需将一个当事人作为提供方，故两者间为一 到多关系。此外，合约当事人在区块链上依然采用匿名机制（视为匿名矿工账户而由云平台负责对匿名 区块链账户进行身份识别，确认其对应的真实身份，因此，智能合约发起区块链交易中记录该匿名帐户地址 即可。 3.2服务接口合约化 亨德里克森在《会计理论》中认为，用于购买服务的支出形成无服资产)。基于将SPE$C合约中的软件 服务承诺看作无形资产的前提假设，SPESC语法定义的服务接可类型(type Service)继承于合约资产关键字 (asset),见图4右部两个结构体的描述。这种定义方式的好处是将无形的服务与有形的资产进行统一封装， 并且符合软件工程的开闭模式设计原则。 asset Eureka:type Service public void register(final InstanceInfo info,final boolean isRepltcatton) instances[ this.handleRegistration(info,this.resolveInstanceLeaseDuration(info),isReplication) furl:http:eureka-service.com” super.register(info,isReplication); description:"Eureka server 1" paths[ path:"/register",label:"Register", 稿件 parameters:[Instancelnfo],method:"POST" path:“/getlnstances'”,abet“Discover” parameters[serviceName,serviceLevell method:"GET”h responses fcode:204,description:"sucoess" public List<InstanceInfo>getIn ances(strin erviceName,int serviceLevel){ {code:404,decription:“failed"】 Applications applications getApplications(serviceName,serviceLevel); rights[ return applications.getApp at ions(）.stream(）Stream<Applicatio fownership:Platform! map(Application:getInstances)Stream<Listcinstancelnfos> .flatMap(List::strea) } ,collect(Collectors.toList(; asset ForecastWeather:type Service{ instances[ {url:“http:weather-.serivce.com”, description:"Weather forecast server 1" paths[ ath“/forecast'”,method:“GETi parameters:[time,location.abet“Forecast'”}l, response习平 @GetMapping(7forecast") eede:200,description:"served"), public Map<String,Object>queryWeather(String location,String time) (code:404,description:"Not Found")]. return weatherForecastService.getcityWeather(location,time); rights fonwnership:Provider, usufrust:Provider] price:Money 图4服务接口与智能法律合约中服务声明对应图 Fig.4 Mapping from service interfaces to service declarations in smart legal contract6 组合关系；Party 表示合约当事人，继承自区块链账户实体类（BlockchainAccount）；智能合约的具体类（Smart Contract）继承自合约范本抽象类（Contract Pattern）。微服务与智能合约、当事人与智能合约均为多对多关系。 当事人可作为提供方负责（零或）多个微服务，一个微服务至少需将一个当事人作为提供方，故两者间为一 到多关系。此外，合约当事人在区块链上依然采用匿名机制（视为匿名矿工账户[14]），而由云平台负责对匿名 区块链账户进行身份识别，确认其对应的真实身份，因此，智能合约发起区块链交易中记录该匿名帐户地址 即可。 3.2 服务接口合约化 亨德里克森在《会计理论》中认为，用于购买服务的支出形成无形资产[17]。基于将 SPESC 合约中的软件 服务承诺看作无形资产的前提假设，SPESC 语法定义的服务接口类型（type Service）继承于合约资产关键字 （asset），见图 4 右部两个结构体的描述。这种定义方式的好处是将无形的服务与有形的资产进行统一封装， 并且符合软件工程的开闭模式设计原则。 Party ServiceApp SmartContract ContractPattern 0..* 1..* BlockchainAccount 1..* 1..* InstanceInfo 1..* 1..* party Consumer{ account: ______________________________ certificate ID: ______________________ } party Provider{ account: 0x1uWDvekrPw……A16pfAnBLY9U certificate ID: 915780435……65079254 } party Platform{ account: ____________________________ certificate ID: _____________________ } 图 4 服务接口与智能法律合约中服务声明对应图 Fig.4 Mapping from service interfaces to service declarations in smart legal contract asset ForecastWeather : type Service { instances[ {url: http://weather-serivce.com description: Weather forecast server 1” }], paths[ {path: forecast method: GET , parameters: [time, location],label: Forecast }], responses[ {code:200, description:"served"}, {code: 404, description:"Not Found"}], rights[ {onwnership: Provider}, {usufrust: Provider}] price : Money } asset Eureka : type Service{ instances[ {url: http://eureka-service.com description: Eureka server 1”}], paths[ {path: register label: Register parameters:[InstanceInfo], method: POST {path: getInstances label: Discover parameters[serviceName, serviceLevel], method: GET responses[ {code: 204, description: success {code: 404, decription: failed rights[ {ownership: Platform}] } (a) (b) 图 3 合约当事人描述与关系结构: (a)SPESC 合约当事人描述; (b)微服务、当事人与智能合约的 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 录用稿件，非最终出版稿