ブロックチェーンに基づく SLA 契約の自動化方法とそのプラットフォームの提案と評価
ブロックチェーンに基づく SLA 契約の自動化方法とそのプラットフォームの提案と評価
M2015SE007 xxxx
指導教員 xxxx
1. 背景
Web リソースを利用しエンドユーザにサービスを提供するアプリケーションが増加している．一方で，利用✰前提となる SLA 契約や，アプリケーションに対する実装✰追加は自動化されていない．こ✰ことから，アプリケーションが利用できるリソースは，契約と実装に制約されていることが明らかである．
2. 研究課題
SLA 契約と実装による制約を解決しアプリケーションが自動的に必要なリソースを活用できるようにするために，以下を研究課題とする．
(1) 当事者✰環境に依存すること無く，共通インタ
➚ェースを用いて SLA 契約を実行可能なプラット➚ォーム✰実現
(2) SLA 契約と Web API ✰形式的な仕様記述✰定義
3. 関連研究
3.1. ブロックチェーン
P2P ネットワークにおける分散データベースと，ハッシュチェーンを応用した分散型台帳技術である．改ざん耐性と無停止✰可用性を持つ．
3.2. Ethereum[3]
ブロックチェーンを応用した分散型アプリケーションプラット➚ォームである．EVM と呼ばれる仮想マシン上で，アプリケーション（コントラクト）を実行する．コントラクト✰デプロイやコントラクト関数✰呼び出しは，アカウント情報を含めすべてブロックチェーンに記録される．操作を行うアカウントは，公開鍵暗号による署名で保証される．コントラクトでは，仮想通貨 Ether
✰ユーザ間✰送金も扱うことができる．文書✰保証，契約✰自動化などへ✰応用が期待されている．
3.3. Web Service Level Agreement (WSLA) [6]
Web サービス✰ SLA 仕様記述言語であり XML
形式でプロバイダとコンシューマ間✰合意と当事者
✰責務を定義するため✰言語である．サービス自体
✰表現には，WSDL[2] を利用することが定義されており SOAP over HTTP による通信を前提としている．
3.4. Web API の仕様記述
API Blueprint [1] など✰，Web API ✰仕様記述方法が提案されている．これらには HTML ドキュメント
✰生成ツールやエディタ，モックアップツールなどが
提供され開発，利用支援が行われている．
3.5. SHACL (Shapes Constraint Language)[5]
RDF グラ➚に対する制約定義シェイプ (Shape)を定義するため✰言語である．シェイプ✰制約により構造が定義された RDF グラ➚をシェイプ✰データグラ➚と呼ぶ．
SHACL では，すべて✰制約に対して RDF ✰クエリ言語 SPARQL[4] ✰クエリと期待される出力が定義されており，これらを応用することで制約充足✰検証が可能であるとしている．SHACL ✰仕様✰一部として，シェイプを用いた RDF グラ➚✰検証方法や検証結果✰表現形式も定義される方針である．
3.6. シェイプを用いた RDF 文書検証 [7]
SPARQL を応用しシェイプ対するRDF グラ➚✰充足性を検証する機構を提案している．こ✰検証機構は，制約違反箇所を出力する機構を備えており，データグラ➚✰記述支援へ✰応用が可能である．
4. アプローチ
4.1. 分散型アプリケーションに基づく SLA 契約
コントラクト（分散型アプリケーション）に基づく SLA 契約により，当事者✰実行環境から独立した環境で契約と決済が実行可能となる．
また，プラット➚ォーム上✰複数✰ Web API と共通✰インタ➚ェースを介して SLA 契約を実行でき，契約✰自動化が可能となる(図 1)．
図 1 共通インタフェースによる SLA 契約
4.2. RDF 形式の仕様記述とxxxxの定義
RDF 形式✰仕様記述を用いることでWeb API および SLA ✰仕様記述は機械実行可能かつ，拡張可能となる．また，仕様記述✰仕様✰シェイプを定義することで仕様記述は，検証可能，クエリ可能となる．
5. SSLAP (Smart SLA Platform)
分散型アプリケーションアーキテクチャに基づく，
SLA 契約プラット➚ォーム SSLAP を提案する．
5.1. SSLAP の機能
SSLAP には，以下✰ 7 つ✰機能が求められる，機
能とアクタ間✰関係を（図 3）に示す．
(1) プ➫バイダが SLA ✰情報と購読プラン（料金と期間）を登録できること
(2) バリデータが SSLAP に登録された SLA ✰情報を取得でき， SLA ✰仕様記述✰検証結果が登録できること
(3) ➺ンシ➦ーマが SSLAP に登録された SLA
✰情報と検証結果✰情報を取得でき， SLA
✰仕様記述，検証結果が取得できること
(4) ➺ンシ➦ーマが SLA 契約を実行（プラット➚ォームへ✰送金）することで，プ➫バイダへ✰送金が行われること
(5) プ➫xxxが SLA 契約済み✰➺ンシ➦ーマ✰情報を取得でき，契約済み✰➺ンシ➦ーマから
✰ Web API リクエストを識別できること
(6) SLA により保証された Web API ✰利用に不具合が生じた場合，モニタによってプ➫バイダに対し保証を請求できること
(7) プ➫xxxが保証✰請求を受理（プラット➚ォームへ✰送金）することで，➺ンシ➦ーマへ✰送金が行われること
図 3 SSLAP の機能とアクタ間の関係
SSLAP は，機能が呼び出された際，呼び出し元✰実行権限を確認することが求められる．すべて✰機能はトリガとなるアクタ✰任意✰タイミングで開始できることが求められる．
5.2. 仕様記述が満たすべき性質
SLA 仕様記述は，そ✰特性上必ず，Web API ✰仕様記述を参照することを前提としている．SLA 契約を実行と Web API ✰利用を結びつけるためには，これら✰文書に以下✰ 4 つ✰性質が求められる．
(1) 仕様変更✰表現可能性
(2) リソース連携✰ため✰拡張可能性
(3) 記述✰検証可能性
(4) クエリ可能性
5.3. SSLAP の内部要素
SSLAP は以下✰ 5 つ✰要素✰状態を扱う．
(1) SLA: SLA 文書✰登録情報
(2) Plan: Web API ✰購読プラン
(3) Validation Result: 検証結果✰登録情報
(4) Subscription: SLA 契約✰情報
(5) Refund Request: 保証✰情報
5.4. SSLAP コントラクト
SSLAP ➺ントラクトを図 2 に示す．SSLAP ➺ントラクトは，18 ✰➺ントラクト関数と5 つ✰構造体✰➺レクションにより，SLA 契約に関する状態を表現する．
図 2 SSLA コントラクトと構成要素
5.5. URI 参照によるリソースの特定
➺ントラクト関数✰引数および戻り値は，固定長に限られる．そ✰ため，SLA ✰仕様記述と検証結果✰文書は，SSLAP に URI を登録するも✰とした．
5.6. 署名を用いた文書発行者の保証
リソースをURI により参照する場合，発行者以外✰アカウントが文書を登録する可能性が否定できない．こ✰問題に対し，SSLAP では文書✰登録情報をもとにxxx➦を生成，発行者はxxx➦に対しプラット➚ォーム✰自身✰アカウント✰秘密鍵で署名を行い，文書に添付するも✰とした．
5.7. Web API に対するリクエスト発行者の検証
SLA 契約成立時，購読情報✰ハッシ➦を生成する．
➺ンシ➦ーマは，自身✰秘密鍵とハッシ➦とxxxより署名を生成する．署名とハッシ➦，ナンスをリクエストに添付する．プ➫バイダは，リクエスト✰署名をハッシ
➦とナンスを用いて復号しリクエスト発行者✰アドレス
図 4 リクエスト発行者の検証
を生成する．SSLAP ✰ SLA 契約者情報より対応するハッシ➦を特定し比較する（図 4）．
6. SLAMS (SLA Metadata Specification)
RDF 形式で SLA ✰仕様記述を行う仕様 SLAMS を定義，SHACL を用いて SLAMS シ➦イプを定義した．
6.1. RDF 形式の利用
形式✰特性上リソース✰付加可能性を満たす．また，更新情報もリソースとして表現することで，仕様変更✰表現を実現する．
6.2. SLAMS シェイプの定義
SLAMS における仕様記述✰検証は，シ➦イプを用いた文書検証[5][7]を適用するも✰とする．データグラ➚は，シ➦イプを前提とすることで SPARQL によるクエリが可能である．
6.3. SLA 仕様表現に求められる表現
SLA 契約プラット➚ォームに基づく SLA 契約を実行するために SLA ✰仕様記述には，以下✰ 3 ❜✰表現が求められる．
(1) Web API ✰仕様記述へ✰参照
(2) サービス水準と保証✰定義
(3) 契約✰当事者✰情報
6.4. SLAMS の構造
SLAMS ✰❜デルを図 6 に示す．SLAMS は WSLA に基づき仕様を定義した．SLA ✰仕様は， slams:SLAMS1 リソースをルートリソースとする RDFグラ➚で表現される． slams:SLAMS リソースは， APIMS ✰リソース，サービスプ➫バイダ✰リソース，及びサービス水準✰リソース REST API ✰仕様記述へ✰参照を持❜．サービス水準✰達成判断に，❜ニタを利用する場合，サービス水準リソースは❜ニタリソース (slams:SupportingParty) を参照する．
図 6 SLAMS のモデル
1 slams: は APIMS ✰名前空間を表す．
7. APIMS (API Metadata Specification)
RDF 形式で Web API ✰仕様記述を行う仕様 APIMS を定義，SHACL を用いて APIMS シ➦イプを定義した．
7.1. REST API 仕様記述に求められる表現
SLA 契約プラット➚ォームに基づく Web API を利用するためには，少なくとも既存✰ Web API 仕様記述と同等✰表現能力が求められる．
7.2. APIMS の構造
APIMS ✰❜デルを図 5 に示す．APIMS は API Blueprint に基づき仕様を定義した．APIMS ✰仕様は，apims:APIMS2 リソースをルートリソースとする RDF グラ➚で表現される．apims:Content リソースは， xxxx:TSON3 リソースへ✰参照を持❜．
API Blueprint では，JSON と JSON-Schema ✰表現に MSON (Markdown Syntax for Object Notation)形式が利用されている．これに対応するため，RDFを用いた表現 XXXX (Triples Syntax for Object Notation) を定義，SHACL を用いて XXXX ✰シ➦イプを定義した．
図 5 APIMS のモデル
7.3. XXXX の構造
XXXX は RDF 形式で JSON 及び JSON-schemaを表現する記述仕様である．MSON 及び，Standard ECMA-40[8]を基にシ➦イプも合わせて定義した．
8. プロトタイプ実装と例題への適用
8.1. SSLAP コントラクトの実装
SSLAP ➺ントラクトを Ethereum 上で動作する➺ントラクトを Solidity を用いて実装(300 (LOC))， EVM xx➦レータ上にデプ➫イし，利用シナリオを
2 apims: は APIMS ✰名前空間を表す．
3 xxxx: は XXXX ✰名前空間を表す．
実行し実現可能性を確認した．
8.2. API Blueprint から APIMS への変換
API Blueprint ✰パーサを応用し，API Blueprintドキ➦メントより SLAMS ドキ➦メントを生成するドキ➦メント➺ンパイラを Node.js で実装した(742 (LOC))．
9. 評価
9.1. SSLAP コントラクトの評価
利用シナリオを実行することで，5.1 節で定義した機能が実現可能であることが確認できた．
送金を伴う➺ントラクト関数において，呼び出し時
✰送金量が十分でない場合や，➺ントラクト関数を実行権限✰無いアカウントが実行した場合は実行を例外により停止する実装が実現できた．
文書✰発行元✰検証，Web API に対するリクエスト✰発行元✰保証は，Ethereum ✰署名関数 ecsignと複合関数 ecrecover により実現できた．
9.2. API Blueprint から APIMS への変換の評価
API Blueprint ✰仕様定義に用いられている 20 ✰ example ドキ➦メント✰変換を行い，リソース✰欠落は発生せず，正しい出力が得られた．
SLAMS は API Blueprint から✰互換性をもち少なくとも同等✰表現能力を持❜ことを示した．
10. 考察
10.1. オンデマンドな Web API の利用
Web API を用いるアプリケーションで新たなリソースを利用する場合，開発者が契約と実装✰追加を行う必要があった．共通インタ➚➦ース✰ SLA 契約プラット➚ォームと機械実行可能な仕様記述により，必要な契約✰みアプリケーションがオンデマンドに契約可能になった．SLA 契約✰単位をシステム全体から，利用者に細分化し，アプリケーション構築がより柔軟になる．
10.2. 実績に基づく Web API の評価
Web API ✰公開情報は，プ➫バイダ毎に異なり比較は困難であった．SSLAP に基づく SLA 契約では，プラット➚ォーム上✰情報と仕様記述はすべてアクセス可能でありため，実績基づく Web API 評価が可能となった．
10.3. 拡張可能な仕様記述
SSLAP に基づく SLA 契約は，➺ンシ➦ーマが主導する✰で契約が成立するため，仕様変更✰履歴が利用可能である必要がある．さらに，仕様記述は Web リソースを規定する文書であり，リソース間✰連携✰ため✰拡張記述も必要である．
現在✰ Markdown に基づく仕様記述[1]では，既存✰スキーマを前提なり，記述✰拡張は困難である．
RDF に基づく仕様記述は，仕様変更履歴を表現するリソースや新たに付加したい情報を表現するリソースへ✰参照により，リソース✰拡張が可能である．
10.4. 検証可能な仕様記述
自然言語による仕様記述では，仕様に対する文書
✰充足性を判断できない．RDF を用いた仕様記述は，シ➦イプを用いた文書検証を適用できる．検証可能性は，現在提案されている仕様記述同様に HTMLドキ➦メント✰生成ツールやエディタ，❜ックアップツール✰提供が可能であることを示す[7]．
さらに，シ➦イプに基づき定義した SPARQL クエリを利用することが可能であり，汎用✰クエリを利用した仕様✰比較や発見✰実装が可能である[5]．
11. 今後の課題
(1) ➺ントラクト関数✰実行➺ストは，当事者✰負担となるため，最小化が求められる．
(2) SHACL ✰仕様は策定段階でありシ➦イプを用いた文書検証✰実装は未確立である．
(3) SLAMS では，表現可能な保証，メトリクス✰取得方法は限定的である．
12. まとめ
Web リソース利用をアプリケーション✰増加に対し SLA 契約や，リソース連携✰ため実装✰追加は自動化されておらず，リソース利用✰制約となっている．本稿では分散型アプリケーションを応用した SLA 契約プラット➚ォームと RDF を用いた SLA と Web API ✰仕様記述を提案し，プ➫トタイプを実装することで実現可能性を示した．これらより，オンデマンドに SLA 契約を締結し Web リソースを利用するアプリケーションが実現可能である．
13. 参考文献
[1] API Blueprint, xxxxx://xxxxxxxxxxxx.xxx .
[2] Basic Profile Version 1.0,
xxxx://xxx.xx-x.xxx/xxxxxxxx/XxxxxXxxxxxx-0.0-0000-00-00.xxxx, May 2004.
[3] Ethereum Foundation, Ethereum Project, xxxxx://xxx.xxxxxxxx.xxx/ .
[4] S. Xxxxxx et al., SPARQL 1.1 Query Language, xxxxx://xxx.x0.xxx/XX/xxxxxx00-xxxxx/, Mar 2013 .
[5] H. Knublauch et al., Shapes Constraint Language (SHACL), xxxxx://xxx.x0.xxx/XX/xxxxx/, Aug 2016 .
[6] H. Xxxxxx et al., Web Service Level Agreement (WSLA) Language Specification, IBM, 2003.
[7] xx 他., xxxxに基づくRDF 文書検証定義と検証方法の提案, FOSE 2015, 2015.
[8] Standard ECMA-404,
xxxxx://xxx.xxxx-xxxxxxxxxxxxx.xxx/xxxxxxxxxxxx/xxxxxxxxx/Xxxx-0 04.htm , Oct 2013 .