ブロックチェーンに基づくWeb APIのSLA契約の自動化方法とそのプラットフォームの提案と評価

全文

(1)Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report. ブロックチェーンに基づく Web API の SLA 契約の自動化方法とそのプラットフォームの提案と評価中島啓貴† 青山幹雄† 概要：Web API を利用しサービスプロバイダとコンシューマが連携，エンドユーザにサービスを提供するシステムが増加している．しかし，連携の前提となる SLA 契約や，システムに対するサービスの追加は，プロバイダのインタフェースに依存するため，コンシューマが人手で行わなければならい．一方で，Fintech の分野では，ブロックチェーンと呼ばれる分散型台帳技術の無停止性や耐改ざん性の契約や送金への応用が行われているが，Web API の SLA 契約を実現する方法は現在確立されていない．本稿では，RDF に基づく Web API と SLA 仕様の記述を定義し，共通 SLA 契約プラットフォームに基づく SLA 契約の方法を提案，また，ブロックチェーンに基づく共通 SLA 契約プラットフォームを定義した．さらに，契約プラットフォームのプロトタイプを実装し，例題に適用することで，その実現可能性を示した．これらにより，セキュアな共通 SLA 契約プラットフォームを介して，サービスをオンデマンドに契約しサービスを提供するシステムが実現可能となった．. An Automation Method of SLA Contract of Web APIs and Its Platform Based on Blockchain Concept HIROKI NAKASHIMA† MIKIO AOYAMA† 1. 背景. 3. 関連研究. Web API を利用しサービスプロバイダとコンシューマ. 3.1 Web Service Level Agreement (WSLA)[1]. が連携しエンドユーザにサービスを提供するシステムが増. XML 形式で SLA 契約におけるサービスプロバイダと. 加している．しかし，連携の前提となる SLA 契約とシス. コンシューマのそれぞれの責務を定義する言語である．. テムに対するサービスの追加は，プロバイダが提供する. SOAP over HTTP を前提としている．サービスの構文表現. SLA 契約の仕様記が異なる形式であること，さらに，SLA. には，WSDL (Web Services Description Language)[2] を利用. 契約プラットフォームのインタフェースもそれぞれ異なる. し，WSLA は，WSDL の意味拡張を行う．. こと，これらにより自動化は困難である（図 1）．人手に依. 3.2 Web API の仕様記述. 存した SLA 契約とサービスの追加はサービス連携のボト. API Blueprint[3], RAML[4], OpenAPI[5] などの Web API. ルネックとなっている．また，プロバイダに依存した SLA. の仕様記述方法が提案されている．それぞれの言語に，開. 契約プラットフォームは，その信頼が担保されていない．. 発，利用支援ツールが提供されている．これらの仕様に基づき記述された文書は厳密ない未定義が成されていないため HTML ドキュメントの生成ツールやエディタにより，意味の補完が行われ仕様記述として利用されている． 3.3 シェイプを用いた RDF 文書検証[6] RDF に対する制約定義として，シェイプが提案されてい. 図 1 既存の SLA 契約方法のアクタの関係. 2. 研究課題. る．また，RDF のクエリ言語 SPARQL (SPARQL Protocol and RDF Query Language)[7] を応用し，シェイプによって定義された制約に対して，RDF グラフの充足性を検証する. Web API 活用の障害は，以下を 2 つの問題に起因する．. 方法を定義している．この検証方法は，検証の結果および，. 本稿ではこれらを研究課題とする．. 違反箇所の詳細を出力する機構を備えている．. (1). SLA と API の仕様記述の未確立. 3.4 SHACL (Shapes Constraint Language)[8]. (2). サービスプロバイダごとに異なる SLA 契約プラッ. SHACL は，シェイプの定義言語の 1 つである．SHACL. トフォームと契約インタフェース. により定義される制約は，SPARQL クエリを用いて RDF 文書の制約充足の検証が可能である．さらに，SHACL の. † 南山大学 Nanzan University. ⓒ 2017 Information Processing Society of Japan. 仕様は，検証結果の出力形式の定義も含む．. 1.

(2) Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report 3.5 ブロックチェーン[9][10][11] ブロックチェーンはビットコイン[12]の基盤技術であり， P2P ネットワーク，分散データベース，ハッシュチェーン. 図 2 提案 SLA 契約方法のアクタの関係. を応用した分散型台帳技術である．その無停止性や耐改ざん性より契約の実行や送金への応用が期待されている．しかし，SLA 契約を実現するための方法は確立されていない．. 5. RDF に基づく Web API の SAL 仕様記述. 3.6 スマートコントラクト [13]. SLA 契約に必要な SLA 仕様記述と Web API の仕様記. 契約を電子化し，ブロックチェーンに記録，実行する仕. 述をまとめて Web API の SLA 仕様記述とし，これに基づ. 組みである．スマートコントラクトはプログラムとして記. く文書を SLA 文書と定義する．. 述され，条件に応じて自律的に執行される．. 5.1 仕様記述の内容. スマートコントラクトは，規定した動作を確実に行うた. 仕様記述の内容は WSLA を参照し定義した．WSLA で. め，従来では，信用できる第 3 者期間に依存しなければな. は，WSDL を用いて Web API の構文的な定義を行い，SLA. らなかった契約の自動化を実現する．. に関する意味拡張を行っている．. 3.7 Ethereum[14]. 現在提供されている Web API の約 9 割は REST に. ブロックチェーンを応用した分散型アプリケーションプ. 基づく API である[15]，しかし WSDL は，SOAP over. ラットフォームである．EVM (Ethereum Virtual Machine) と. HTTP を前提としており，REST API の表現は未定義であ. 呼ばれる仮想マシン上で，コントラクトと呼ばれるスマー. る．そのため，Web API の仕様記述は，REST API の表現. トコントラクトを実行する．コントラクトに対する操作は，. 形式として一般的に用いられている API Blueprint に基づ. 呼び出し元のアカウント情報とともにブロックチェーンに. き定義した．. 記録される．アカウントは，公開鍵暗号による署名で保証. API Blueprint は，内部表現として JSON（および JSON. される．コントラクトでは，仮想通貨 Ether のユーザ間の. Schema の一部）の記述に MSON (Markdown Syntax for. 送金を扱うことも可能である．. Object Notation) 形式を用いている．提案仕様記述も JSON. 4. アプローチ. （および JSON Schema の一部）の表現仕様を定義する． Web API の SLA 仕様記述は，以下の 3 つの仕様記述か. 本提案方法が実現する SLA 契約とは，SLA 仕様記述に. ら構成される．文書の関係間の関係を図 3 に示す．. 基づく合意形成と契約内容の履行と定義する．. (1). SLAMS: SLA の仕様記述. 4.1 RDF 形式の仕様記述とシェイプの定義. (2). APIMS: Web API の仕様記述. RDF 形式を用いた SLA および Web API の仕様記述の. (3). TSON: JSON（および JSON Schema の一部）の記述. 方法を提案する． RDF は拡張可能であり，既存の SLA および Web API 同等の表現が可能である．RDF グラフは，シェイプを用いることで検証可能であり，SLA 契約において文書の充足性を保証可能である．. 図 3 仕様記述の関係. 4.2 ブロックチェーンに基づく SLA 契約. 5.2 SLAMS (SLA Metadata Specification). スマートコントラクトを応用しブロックチェーン上で，. RDF 形式で SLA の仕様記述を行う仕様として，. SLA 契約を行う方法を提案する．. SLAMS を提案する．. 既存の SLA 契約方法では，サービスプロバイダに依存. 5.2.1 SLA 仕様記述に求められる表現. した契約プラットフォームを介した契約が行われている．. SLA 契約を実現するために SLA の仕様記述には，以下. 一方，提案方法の共通 SLA 契約プラットフォームは当事. の表現が求められる．. 者に依存することなく P2P 環境で動作し，ブロックチェ. (1). サービス水準と保証の定義. ーンの耐改ざん性と無停止性より，セキュアな契約プラッ. (2). 契約の当事者の情報. トフォームを実現できる．また，複数のプロバイダが共通. (3). 拡張対象の Web API に対する参照. SLA 契約プラットフォームを介して様々な Web API を提. 5.2.2 SLAMS のデータモデル. 供することで，コンシューマは共通インタフェースを用い. WSLA を応用し定義した SLAMS のデータモデルを図. てそれらを利用可能となる．. 4 に示す．SLA の仕様記述は，slams:SLAMS(a) リソース. 提案する SLA 契約方法において，契約インタフェース. をルートリソースとする RDF グラフで表現する．. のメッセージをして，RDF を用いた仕様記述を用いることで，SLA 契約の自動化が可能となる(図 2)．. ⓒ 2017 Information Processing Society of Japan. (a) slams: は APIMS の名前空間を表す．. 2.

(3) Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report slams:SLAMS リソースは，APIMS のリソース，サービス. 階層構造をもっている． apims:Content リソースは，. プロバイダのリソース，及びサービス水準のリソース Web. tson:TSON(c) リソースへリンクする．. API の仕様記述へリンクする．サービス水準のリソースは，. 5.4 TSON (Triple Syntax for Object Notation). 達成を監視するモニタリソース (slams:SupportingParty) へ. RDF 形式で JSON（および JSON Schema の一部）の記. のリンクと水準の達成を判断するために用いる達成判断式. 述を行う仕様として，TSON を提案する．. を表現するリソースへのリンクをもつ．. 5.4.1 TSON に求められる表現 TSON は，Web リソースとして再利用さることで，API 間の連携が実現するので，以下の 2 つの特性が求められる． (1). MSON との互換性. (2). RDF 標準リソースの積極的な利用. 5.4.2 TSON の構造 TSON のデータモデルを図 6 に示す．TSON は，MSON 及び，Standard ECMA-404[16] を応用し定義した TSON の仕様は，tson:TSON リソースをルートリソースとする RDF グラフで表現する． JavaScript Object を表現する，ルートリソース，tson:Object, tson:Pair リソース意外は，すべて RDF の標準語彙を用いて表現する．図 4 SLAMS のデータモデル 5.3 APIMS (API Metadata Specification) RDF 形式で Web API の仕様記述を行う仕様として， APIMS を提案する． 5.3.1 Web API の仕様記述に求められる表現能力 Web API の仕様記述には，既存の Web API 仕様記述と同等の表現能力が求められる． 5.3.2 APIMS の構造 APIMS のデータモデルを図 5 に示す．APIMS は，API 図 6 TSON のデータモデル. Blueprint を応用し定義した. 5.5 Web API の SLA 仕様記述に対するシェイプの定義 3 つの仕様記述それぞれの RDF グラフに対し，SHACL を用いてシェイプを定義した．シェイプを用いることで， SLA 文書に対し，RDF 文書検証が適用可能となった．図 7 に本提案で定義したシェイプの 1 つ SLAMS のシェイプの一部を示す． @prefix slams: <http://slams.example.org/> . @prefix sh: <http://www.w3.org/ns/shacl#> . @prefix xsd: <http://www.example.org/> . ...(中略) slams:Shape a sh:Shape ; sh:targetClass slams:SLAMS ; ...(中略). 図 5 APIMS のデータモデル APIMS の仕様は，apims:APIMS(b ) リソースをルートリソースとする RDF グラフで表現する． APIMS で定義されるリソースは，API Blueprint が定義する項目と対応した. (b) apims: は APIMS の名前空間を表す．. ⓒ 2017 Information Processing Society of Japan. sh:property [ sh:predicate slams:activateDate ; sh:minCount 1 ; sh:maxCount 1 ; sh:datatype xsd:dateTime ; ] ; ...(省略). 図 7 SLASMS シェイプグラフ（抜粋） (c) tson: は TSON の名前空間を表す．. 3.

(4) Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report 5.6 シェイプに基づく SLA 文書の検証図 8 に SLAMS のグラフの例の抜粋を示す．この RDF グラフに対して，SLAMS シェイプを適用し検証を行う．シェイプにおいて slams:activateDate の値は xsd:dateTime 型のリソースであるとの制約が定義されている．しかし，検証対象の RDF グラフの slams:activateDate の値は， xsd:dateTime 型のリソースである．以上より制約違反が発生していることが判定される． @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix ex: <http://example.org/> . @prefix slams: <http://slams.example.org/> . @prefix slams-sslap: <http://slams.example.org/sslap/> .. ex:slams a slams:SLAMS ; slams:activateDate "2017-01-01T00:00:00Z"^^xsd:string ; slams:serviceProvider ex:org0 ; slams:apims ex:apims ; slams:serviceLevel ex:sl0 .. ex:org0 a slams:ServiceProvider ; slams:name "Weather Company inc." ; ...(省略). 図 8 SLAMS の RDF グラフの例（抜粋）. 6. ブロックチェーンに基づく SLA 契約方法 6.1 共通 SLA 契約プラットフォームを用いた契約方法共通 SLA 契約プラットフォームを用いた契約方法を提案する．コンシューマは，プロバイダごとに異なるインタフェースに合わせたメッセージを作成する必要がなくなり，共通 SLA 契約プラットフォームに登録されている Web API を共通のインタフェースに基づくメッセージを介して利用可能になる． 6.1.1 アクタ提案方法のアクタ間の関係とやり取りされるメッセージを図 10 に示す．. 図 10 アクタとアクタ間のメッセージ提案方法では，Web API を介してサービスを利用するコンシューマ，サービスの提供を行うプロバイダ，Web API. @prefix sh: <http://www.w3.org/ns/shacl#> . @prefix ex: <http://example.org/> . @prefix slams: <http://slams.example.org/> .. トフォームをアクタとして定義した．これらのアクタによ. [. り SLA 契約を実現することが可能である．しかし，これ. a sh:ValidationReport ; sh:conforms false ; sh:result [ a sh:ValidationResult ; sh:resultSeverity sh:Violation ; sh:focusNode ex:slams ; sh:resultPath slams:activateDate ; sh:value "2017-01-01T00:00:00Z"^^xsd:string ; sh:resultMessage "slams:activateDate expects a literal of datatype xsd:dataTime." ; sh:sourceConstraintComponent sh:DatatypeConstraintComponent ; sh:sourceShape slams:Shape . ] , ...(省略). 図 9 SLAMS の RDF グラフの検証結果（抜粋）. の情報の管理と SLA 契約の管理を行う SLA 契約プラッ. らの 3 アクタのみの SLA 契約を実行するために以下の 2 つの問題を解決する必要がある． (1). SLA 文書として不適切な文書をもとに契約が成立してしまう問題. (2). 契約後サービスプロバイダがサービス水準を満たさず，かつ，保証をしない問題. これらの問題に対応するため，本提案方法では，SLA 契約に用いられる文書の検証を行うバリデータと，サービスプロバイダがサービス水準を満たすサービスを提供していることを確認するモニタの 2 つのアクタを導入した． 6.1.2 SLA 文書バリデータの役割. 検証結果 RDF グラフの抜粋を図 9 に示す．このグラフ. バリデータは，SLA 契約プラットフォームに登録された. は，制約違反箇所を特定するために以下の情報をもつ．. Web API の情報を取得，SLA 文書を取得し検証を行う．ま. sh:focusNode: 違反発生主語. た検証結果を SLA 契約プラットフォームに登録する．. (2). sh:resultPath: 違反発生プロパティ. コンシューマは，SLA 契約プラットフォームより，Web. (3). sh:value: 違反発生目的語. API の情報と SLA 文書の検証結果を取得し，不適切な. (4). sh:resourceConstraintComponent: 違反制約のコンポー. SLA 文書に基づく契約を回避することが可能となる．. ネント. 6.1.3 サービスパフォーマンスモニタの役割. sh:sourceShape: 違反シェイプ. モニタは，SLA 文書に定義された Web API の情報をも. (1). (5). 制約違反が発生しなかった場合，これら違反情報は，. とにサービスレベルに基づきサービス提供が行われている. 生成されない．SLA 文書は，3 つのシェイプに対して，制. ことを監視する．サービス提供違反が発生すると，SLA 契. 約違反を持たないが検証されることで，SLA 文書として妥. 約プラットフォームに保証の要求する．. 当であることが保証される．. コンシューマは，SLA 契約プラットフォームより，プロ. ⓒ 2017 Information Processing Society of Japan. 4.

(5) Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report バイダのサービス提供違反の情報と保証の実行履歴を取得. 6.2.3 署名を用いた文書発行者の保証. し，サービスを適切に提供していないプロバイダとの契約. SLA 文書を URI により参照する場合，発行者以外が文. を回避することが可能となる．. 書を登録する可能性を排除できない．この問題に対し，以. 6.1.4 共通 SLA 契約プラットフォームの機能. 下の方法で，文書の発行者の保証を行う．コンシューマが. 共通 SLA 契約プラットフォームを利用した SLA 契約. プロバイダの SLA 文書を検証する場合の検証する場合に. を実現するために，プラットフォームに求められる機能は，. 必要な情報の関係を図 11 に示す．. 以下の 7 つである．. プロバイダは，機能 (1) を実行した際に，SLA 文書のハ. (1). Web API の情報の登録する機能. ッシュを取得する．SSLAP は，登録を行ったアカウントの. (2). SLA 文書の検証結果の登録機能. 情報と生成したハッシュをブロックチェーン上に記録する．. (3). Web API の情報，SLA 文書の検証結果，サービス提. サービスプロバイダは，そのハッシュと自身の秘密鍵を用. 供の保証の実行情報の取得機能. いて署名を作成し文書に添付し公開する．. (4). コンシューマよりプロバイダに対する送金機能. コンシューマは機能 (3) により，SSLAP よりプロバイ. (5). SLA 契約済みのコンシューマの情報を取得する機能. ダのアドレスと，SLA 文書のハッシュ，SLA 文書の URI. (6). サービス提供の違反情報の登録機能. を取得する．URI に基づき SLA 文書を取得し，署名と. (7). サービス提供の違反に対する保証の送金機能. SLA 文書のハッシュよりプロバイダの公開鍵を生成する．. 6.2 SSLAP (Smart SLAP Platform). 次に公開鍵の情報をもとにアドレスを生成し，SSLAP よ. 共通 SLA 契約プラットフォームとして，スマートコン. り取得した SLA 文書のハッシュとプロバイダのアドレス. トラクトを応用した SLA 契約プラットフォーム SSLAP. と比較し文書の発行者が正しいことを確認する．. を提案する．. 6.2.4 Web API に対するリクエスト発行者の検証. 6.2.1 URI 参照によるリソースの特定. プロバイダは，サービス提供にあたり，コンシューマを. SSLAP に文書を登録する機能 (1), (2) では文書の URI. 一意に特定する必要がある．この問題に対し，以下の方法. を受け付けるものとした．これにより，機能 (3) では，共. で，リクエストの送信者を検証する．. 通 SLA プラットフォームより得た SLA 文書の URI に. プロバイダがコンシューマのリクエストを検証する場合. よって，SLA 文書が取得できる．. に必要な情報の関係を図 12 に示す．. SLA 文書全体計算量が大きい. コンシューマは，機能 (4) を実行し，契約成立後に. ブロックチェーンの特性上スマートコントラクトの実行. SSLAP が生成する SLA 契約のハッシュを得る．SSLAP. 速度はクライアントコンピュータに比べ低速であり，扱え. は，このハッシュと契約を行ったアカウントの情報をブロ. るデータサイズも最低限である．そこで，Web 上で文書を. ックチェーン上に記録する．コンシューマは，このハッシ. 一意に特定するために必要な最小限の情報 URI により文. ュと自身の秘密鍵とナンスを用いて署名を作成し Web. 書を特定するものとした．. API のリクエストに添付する．. 6.2.2 内部通貨を用いた決済に基づく契約の締結. プロバイダは，機能 (5) を実行し，コンシューマのアド. 共通 SLA プラットフォームの機能 (4), (7) を実現する. レスとそれに対応するハッシュを取得，Web API のリクエ. ためには決済機能が必要である．これらの機能はスマート. ストより生成されたコンシューマのアカウントのアドレス. コントラクトの特性を応用し内部通貨の送金事実に基づき. と照合しリクエストの送信者が改ざんされていないことを. 実行するものとした．内部通貨の送金は，コントラクト中. 検証する．. で実行可能であり，送金の自動化が可能である．また，送金事実を契約の締結として扱うことができる．. 図 11 文書の検証. ⓒ 2017 Information Processing Society of Japan. 図 12 リクエスト発行者の検証. 5.

(6) Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report 6.2.5 SSLAP のモデル SSLAP コントラクトのモデルを図 13 に示す．. 7. プロトタイプ実装と評価 7.1 SSLAP コントラクト SSLAP を Ethereum 上のコントラクト定義言語 Solidity を用いて実行可能なコントラクトとして実装した (300 (LOC))． 7.1.1 例題への適用作成したコントラクトを JavaScript 上で実行する EVM エミュレータ上にデプロイした．この環境で，共通 SLA 契約プラットフォームに基づく契約方法の定義に用いた 6 つの利用シナリオを実行し，提案方法の実現可能性を確認した（図 14）．実行シナリオのうち，SLA 契約の実行シナリオの一部と， SLA 契約実行と Web API のリクエストの検証のプロセスを抜粋し示す．. 図 13 SSLA コントラクトと構成要素共通 SLA 契約プラットフォームの機能を満たすために， SSLAP は以下の 5 つの要素を扱う． (1) SLA: SLA 文書の登録情報 (2) Plan: Web API の購読プラン (3) Validation Result: 検証結果の登録情報図 14 Ethereum を用いた SSLAP コントラクト. (4) Subscription: SLA 契約の情報 (5) Refund Request: 払い戻しの情報 SLA 文書の登録情報，Web API の購読プラン，払い戻し. SLA 0 の Plan 0 の fee を 1,000,000,000 weid と設定した．コントラクト関数の呼び出しには，以下の値を持つアカウ. の情報の open プロパティは，それぞれが有効か否かを表. ントを利用した．. 現するプロパティである．SLA 文書の登録情報と Web API. (1). の購読プランの open プロパティは，対応するコントラクト関数（setSlaOpen 関数など）の呼び出しにより値を更新. (2). する．払い戻しの情報は，プロバイダが払い戻しを実行し，コンシューマへの払い戻しが成立した時点で値を更新する． SLA 契約の情報の有効期限は契約が有効になる時刻（activate プロパティの値）と無効になる時刻（finished プロパティの値）で定義される．この値は，契約が成立した時刻と Web API の購読プランで定義された期間（span プロパティの値）により決定する．すべてのコントラクトの関数は，実行可能なユーザが限定されており，コントラクト関数が呼び出されると呼び出し元を検証し，実行する．. (3). 秘密鍵: "0x1be3fd99e9819aca25bec9383602e49fe6dfa9d6e75b 1d116555663a7138539f" 公開鍵: "0x31800bf1ebed99f11977d81f6ba71cdcc0670664c7eb e7a03ea33de0982e15e0ebfad233d83e4a154c63157fdbb 2f991f0a0e39ff3f444f626eef762869a5e8a" アドレス: "0xb2c5a2fe26458387822481bc718a4f92f6e91ad4". SLA 0 の Plan 0 の SLA 契約の実行を図 15 に示す． > subscribe(0,0) with 1000000000 wei Result: "0x6a696d59deaf6ad98489800e74be94b5 faab00f26ef2765e8dc835a98e65bc9f000（略） Transaction cost: 130964 gas. Execution cost: 109436 gas. Decoded: bytes32 hash: 0x6a696d59deaf6ad98489800e7 4be94b5faab00f26ef2765e8dc835a98e65bc9f uint256 id: 0. subscribePlan 関数と acceptRefund 関数は送金を伴うコ. 図 15 SLA 0 の Plan 0 の購読リクエストと結果. ントラクト関数であり，呼び出されると必要量の送金が伴. ナンスの 0 と，SLA ハッシュを組み合わせ，署名の対. っていることを検証し，実行する．. 処となるメッセージは次のようになった． "0x6a696d59deaf6ad98489800e74be94b5faab00f26ef276 5e8dc835a98e65bc9f,0" d wei は Ethereum の内部通貨 ether の最小単位. ⓒ 2017 Information Processing Society of Japan. 6.

(7) Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report メッセージに対して秘密鍵を適用し，署名は次のようになった． "0x3099eb8b5ff4a74fb9e3968ff64abd75f197d57fa526 d359517db0d2296d8b451b9e15cb908028e4b2be99363e4 c4f7bfda77e0f42b668d041c21c834e7beac21c" 署名をメッセージで復号し，公開鍵は次のようになった． "0x31800bf1ebed99f11977d81f6ba71cdcc0670664c7ebe7 a03ea33de0982e15e0ebfad233d83e4a154c63157fdbb2f9 91f0a0e39ff3f444f626eef762869a5e8a" 公開鍵をもとにアドレスを生成すると次のようになった． "0xb2c5a2fe26458387822481bc718a4f92f6e91ad4" 以上から，SSLAP から取得した SLA ハッシュとアドレ. 送金を伴うコントラクト関数の呼び出し時に送金量が不十分な場合，例外処理を起動して関数の実行を停止する．図 18 に示す subscribe 関数は，payable 修飾子が付加されており，関数の呼び出し対して任意の送金量を Ethereum の内部通貨 ether として付加することが可能である．購読プランに定義された料金より多くの ether が関数呼び出しに付加されている場合，sla.publisher.send(plan.fee) が true となり，プランの購読が実行される．送金量が不足した場合，例外処理を起動して関数の実行を停止する． SLA 文書の発行元の保証，Web API に対するリクエスト. ス組み合わせと比較検証が実現した．. の発行元の保証は，Ethereum の署名関数 ecsign と複合関. 7.1.2 評価. 数 ecrecover により実現できた．. 利用シナリオの実行により，共通 SLA 契約プラットフ. 7.2 APIMS ジェネレータ. ォームに必要な機能が実現可能であることが確認できた．. APIMS ジェネレータは API Bluerpint で記述された. コントラクト関数の実行権限の無いアカウントによる呼. Web API の仕様から APIMS 文書を生成する．プロバイダ. び出しや，存在しない対象に対する操作を修飾子関数. が APIMS 文書を作成するために用いる．. (modifier) を用いて検出し，例外処理を起動して関数の実. API Blueprint のパーサを応用し，API Blueprint ドキュメ. 行を停止することが実現できた．図 16 に示す関数は SLA. ントより SLAMS ドキュメントを生成するドキュメントコ. 文書の登録情報がブロックチェーン上に登録されているこ. ンパイラを Node.js で実装した(742 (LOC))．. と，SLA 文書の登録者と関数の呼び出しが同一アカウント. 7.2.1 例題への適用. であることを検証したのち実行される．. API Blueprint の Web 上で examples として示されてい. Function setSlaOpen(uint _id) slaExsist(_id) onlyOwner(_id) { slas[_id].open = true; }. 図 16 setSlaOpen 関数図 17 に実行権限を確認する関数を示す．msg は組み込. 図 19 APIMS 変換器. み関数であり，msg.sender で呼び出したアカウントのアドレスを取得できる．SLA 文書の登録者と関数の呼び出しが異なる場合，例外処理を起動して関数の実行を停止する． Modifier onlyOwner(uint _id) { if (slas[_id].publisher != msg.sender) throw; _; }. 図 17 SLA の登録者の検証 function subscribe(uint _slaId, uint _planId) payable slaExsist(_slaId) planExsist(_slaId, _planId) returns (bytes32 hash, uint id) { SLA sla = slas[_slaId]; Plan plan = sla.plans[_planId]; if (sla.publisher.send(plan.fee) == false) throw; id = plan.subscriptions.length++; hash = sha256(_slaId, _planId, now); Subscription subscription = plan.subscriptions[id]; subscription.hash = hash; subscription.publisher = msg.sender; uint t = now; subscription.activate = t; subscription.finished = t + sla.plans[_planId].span; }. var getResourceGroupNode = function(writer, resourceGroup) { // resourceGroup Data var triples =[ { predicate: 'rdf:type', object: 'apims:ResourceGroup' } ]; var name = resourceGroup.name; if(name != "") { triples.push({ predicate: 'apims:name', object: '"' + name + '"' }); } ...(中略) var resources = resourceGroup.resources; resources.forEach( function(resource, index, resources) { triples.push({ predicate: "apims:resource", object: getResourceNode( writer, resource ) } ); }); return writer.blank(triples); };. 図 20 ResourceGroup リソースを生成する関数. 図 18 subscribe 関数 ⓒ 2017 Information Processing Society of Japan. 7.

(8) Vol.2017-SE-195 No.9 2017/3/12. 情報処理学会研究報告 IPSJ SIG Technical Report る 20 の仕様書例[17]（合計 2300 行）を APIMS 文書（合. 証実行記録に基づきプロバイダを評価可能になる．. 計 3200 行）に変換し，リソースの欠落が無く変換できる. 8.5 Web API のオンデマンドな利用可能性. ことを確認した（図 19）．. コンシューマが新たな Web API を利用する場合，開発. 7.2.2 評価. 者が契約と実装の追加を行う必要があった．共通インタフ. API Blueprint の仕様書例の出現項目数と対応する. ェースに基づく SLA 契約プラットフォームと機械実行可. APIMS のリソース数を比較し，一致していることを確認. 能な仕様記述により，必要な Web API の契約をオンデマ. した．これは SLAMS は API Blueprint からの互換性をも. ンドに締結し利用することが可能なる．. ち，同等の表現能力を持つことを示す． ResourceGroup リソースを生成する関数を図 20 に示す．. 9. 今後の課題. この関数は，API Blueprint の ResourceGroup 項目と対応し. (1). コントラクト関数の実行コストの最小化. た ResourceGroup リソースを生成する．. (2). SHACL の仕様に基づく文書検証の実装の未確立. (3). 保証，メトリクスの取得方法表現の拡張. 8. 考察 8.1 Web API 仕様記述の拡張性. 10. まとめ. 共通 SLA 契約プラットフォームに基づく契約は，コン. Web リソース利用をシステムの増加に対し SLA 契約や，. シューマ主導である．そのため，プロバイダによる SLA 文. リソース連携のためサービスの追加は自動化されておらず，. 書の仕様変更は追跡可能である必要がある．さらに，サー. リソース活用の制約となっている．. ビス連携の自動化にあたり，仕様記述には，サービス間の. 本稿では RDF を用いた SLA と Web API の仕様記述. 連携のための拡張記述も必要である．. とブロックチェーンを応用した共通 SLA 契約プラット. 現在の Markdown [3]や，JSON 形式[4][5] に基づく仕様. フォームを提案し，プロトタイプを実装することで実現可. 記述では既存のスキーマを前提とし，記述の拡張は困難で. 能性を示した．これらより，オンデマンドにセキュアな契. ある．本稿で提案した RDF に基づく仕様記述は，仕様変. 約プラットフォームを介して SLA 契約を締結しエンドユ. 更履歴リソースや任意の付加情報を表現するリソースを定. ーザにサービスを提供するシステムが構築可能となる．. 義し，リンクすることで記述を任意に拡張できる． 8.2 Web API 仕様記述の検証可能性自然言語による仕様記述は文書の充足性を判断できないため，合意形成後に解釈の差異が発生するおそれがある． RDF を用いた仕様記述はシェイプを用いた RDF 文書検証を適用可能であり，その記述内容は一意に解釈可能であるため，SLA 契約において，共通の解釈を前提とした合意形成が可能である．さらに，シェイプに基づき定義した SPARQL クエリを利用した Web API のマイニングが可能である[6] [8]． 8.3 セキュアな SLA 契約プラットフォーム現在の SLA 契約では，コンシューマとプロバイダ間で行われる決済は，契約プラットフォーム外の決済サービスの情報であり，決済情報のセキュリティを保証できない．決済者とサービスの利用者の関連付けは，プロバイダに依存していた．これに対して，提案方法はブロックチェーンの耐改ざん性，無停止性に基づく内部通貨の送金という事実を SLA の合意と見なせるので，コンシューマやプロバイダに依存しない合意形成を実現している． 8.4 実績に基づくプロバイダの評価可能性 Web API に関する公開情報はプロバイダ毎に異なり，その信頼性は保証できないおそれがある．これに対して， SSLAP に基づく SLA 契約では，共通 SLA 契約プラットフォーム上で管理されている情報にすべてのアクタがアクセス可能であり，契約実績数や SLA 文書の検証結果，保. ⓒ 2017 Information Processing Society of Japan. 参考文献 [1] H. Ludwig, et al., Web Service Level Agreement (WSLA) Language Specification, IBM, 2003. [2] K. Ballinger, et al., Basic Profile Version 1.0, http://www.ws-i.org/profiles/BasicProfile-1.0-2004-04-16.html, 2004. [3] API Blueprint, https://apiblueprint.org, (参照 2017-02-02). [4] RAML, http://raml.org, (参照 2017-02-02). [5] OpenAPI Specification, http://swagger.io/specification/, (参照 2017-02-02). [6] 中島啓貴, 他, シェイプに基づく RDF 文書検証定義と検証方法の提案, FOSE 2015 論文集, Nov. 2015, pp. 133-138. [7] S. Harris, et al., SPARQL 1.1 Query Language, https://www.w3.org/TR/sparql11-query/, Mar 2013. [8] H. Knublauch, et al., Shapes Constraint Language (SHACL), https://www.w3.org/TR/shacl/, Aug 2016. [9] K. Christides, et al., Blockchains and Smart Contracts for the Internet of Things, IEEE Access, Vol. 4, 2016, pp. 2292-2303. [10] A. Hari, et al., The Internet Blockchain: A Distributed, TamperResistant Transaction Framework for the Internet, ACM HotNets 2016, Nov. 2016, pp. 204-210. [11] M. Atzori, et al., Blockchain-based Architectures for the Internet of Things: A Survey, University College of London, May 2016, 8 pages. [12] S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, https://bitcoin.org/bitcoin.pdf, (参照 2017-02-02). [13] 赤羽喜治, 他 (編著), ブロックチェーン仕組みと理論. リックテレコム, 2016. [14] Ethereum Foundation, Ethereum Project, https://www.ethereum.org, (参照 2017-02-02). [15] ProgrammableWeb, https://www.programmableweb.com/, (参照 2017-02-02). [16] ECMA, Standard ECMA-404 The JSON Data Interchange Format, https://www.ecma-international.org/publications/standards/Ecma-404. htm, (参照 2017-02-02). [17] apiaryio, apiaryio/api-blueprint/examples/, https://github.com/apiaryio/api-blueprint/tree/master/examples, (参照 2017-02-02).. 8.

(9)