chike0905の日記

何者かになりたい

議論をする、ということと、「用語の定義」の意味

雑記

本稿は慶應義塾大学 SFC 村井研 (RG) Advent Calendar 2022の1日目である。 技術系じゃなくてごめんなさい

ブロックチェーン/Web3等の議論をする際に、よく「定義がない/揺れている」ということが批判の的になる。 これは一定以上事実であり、自分も先日Internet Weekで登壇した時それに類するお話をさせていただいた。 一方で、「Web3はムーブメントであり、Decentralizedなシステム1を志向していることが示されていれば良いのだ」と言った風な言説も時折見かける。 自分は研究者であり、世の中に文章を通じて世間に自分の提案や、自分らの議論を問いかけることを生業にしている、と理解している。 そうした中で、なぜ改めて議論をするにあたって定義が重要なのか、をポエムとして記したい。

議論をするということ

議論をする、ということは、原則として「積み上げ」である。 過去の先人たちが積み上げてきた議論、論理を礎にして、新しいものを模索していく作業である。 我々研究者はそれを「論文」という形で議論を記録するし、先人たちの論文を「引用」することで、その先の自分らの議論を補強していく。

積み上げによらない議論は、ある意味で独りよがりである可能性が高く、全くの引用のない論文は比較的評価されにくい。 「自身の中ではこういうものであるからこうなんだ」と言った具合に論を展開したところで、そもそもの「こういうもの」の共通理解が得られなければ、その先の論理展開にも理解を得ることは難しいだろう。 だからこそ、論文執筆の際には1語1語に注意を払い、ある語に既存の定義が存在するならば極力引用することで読者が自分の意図と異なる解釈をしないように注意深く執筆を進めていく。

定義をするということ

では、いわゆるWeb3など最先端の議論の場合はどうだろうか。 それぞれのステイクホルダたちが様々な意見を述べつつも、定義は定まらないまま議論が進んでいる。 そのため、何かを言えば、それとは異なる意図で解釈され、自分の意とは少し的を外れた指摘を受けることも多々あるだろう。

こうした中で、言葉を定義する、ということは何を意味するだろうか。 慶應義塾大学名誉教授の田中茂範氏は「用語の定義と説明」という文章の中で以下のように述べている2。

「意思決定」や「共有信念」や「意味」のように、「それが何であるか」を記述することによってのみ、その指示対象（観念対象）を明らかにする場合がある。 連載『言語の役割を考える』第３回　用語の定義と説明 より

まさに、「Web3」は実在する何かではない「観念対象」であろう。 また、Web3は「ブロックチェーンを中核技術として扱ったさまざまなアプリケーションたちの総称」だと自分は理解している。 ブロックチェーンベースのアプリケーションがどのような効用を産み、有用性があるかは世界中で議論が進行中である。 したがって、「Web3で一体何ができるのか」を現在は模索している状況なのである。

田中氏は以下のようにも述べている。

事物名詞の場合、「がある」ということを前提に「である」を導くことができる、比較的、意味の共有感覚を確保しやすいということである。 (中略) 専門用語辞典が取り扱う多くの名詞の場合には、「がある」と「である」の相互作用が起こらず、「AはBである」という表現形式を使ってその語についての定義をしたり、説明をしたりしなければならない。それらは、共通の知覚体験から創発される概念ではないがため、その捉え方に個人差が生まれ、議論や論争、時には紛争の対象になり得る。ここに専門用語の記述の難しさがあるように思う。

つまり、Web3が意味することは依然十分に共通理解の得られる概念が形成されていない状況であるが故に、さまざまな人が定義を試みている状況とも言えよう。 こうした状況の中では、定義を作ろうと模索することは、その観念の意味すること、ひいては有用性を明らかにしようとする1つのアプローチなのである。 自分の先のブログエントリも、改めてブロックチェーンの定義をすることで、その概念の意味するところを明らかにしようと試みたものである。 定義それ自体を議論することそのものが、対象の意味するところを整理・理解し、有用な活用方法を模索する道筋なのであると考えている。

定義と説明

田中氏の文章の中ではこうも述べられている。

定義が「Aとは何であるか」を規定する行為であるのに対して、説明は「Aはどういうものか」を明らかにする行為である。すなわち、定義は概念の差異化のために必要な行為であり、「何であるか」を明かせば、その役割は終わる。一方、説明は、「何であるか」ではなく、「どういうものであるのか」を明らかにするものであり、それを通して、用語(＝概念)の意義が読者に了解される。

Web3が何であるか、を規定することで、これはWeb3ではない、というものが規定できるだろう。 一方で、Web3で何ができるのか、はさらにその意味合いを「説明」しなければならない。 ブロックチェーンベースのアプリケーションであるならば、ブロックチェーンベースのアプリケーションで「何が嬉しいのか」を説明しなければならないだろう。 つまり、新たな技術を定義/説明することで、その技術の有用性に関する共通理解を形成しようというのが、自分のスタンスである。 ここを疎かにすれば、どんなに素晴らしいシステム/アイディアであろうとも言語コミュニケーションは不可能であり、社会およびユーザたちの理解は得られず、この分野はいつか潰えることになるだろう。

概念形成のプロセス

田中氏は、概念形成に至る過程として「差異化・一般化・類型化」が存在するとも述べている。 定義を試みることで、差異を明確にすることが一定期待できるであろう。 その中で、さまざまなアプリケーション/事象に対して、その定義が適用できるか、すなわち一般化ができる差異であるか、が検討できるようになるだろう。 さらには、そうした中でアプリケーション等の類型化することで、その定義に当てはまる概念が、社会の共通理解として進んでいくであろうと期待する。

「Web3」という語に関する私見

ここで、「Web3」という語に関する現状の私見を述べておきたい。 「Web3」という語は、「Web」と「3」で構成される。 この時、Web、すなわちWorld Wide Webの一形態であることを示していると理解できる。 ただし、ブロックチェーンベースのアプリケーションは果たしてWebであろうか。

World Wide Webとは、「インターネットを通じて公開されたウェブページが相互に接続されたシステム(MDN Web Docs 用語集)」であると考えると、議論の余地があるだろう。 現にWorld Wide Webの提唱者であるTim Berners-Lee卿は以下のように述べている。

It’s a real shame in fact that the actual Web3 name was taken by Ethereum folks for the stuff that they’re doing with blockchain. In fact, Web3 is not the web at all. (元記事)

加えて、仮にWebという語を使うとして、「3」が末尾につくことで、これは「Web1.0」「Web2.0」につづくWebの進化であることを意味しようとしていると理解する。 Web1.0からWeb2.0は、情報発信の流れが1方向から双方向になった、ということでシーケンシャルな進化であると理解できる。 しかし、それ以降のWebの進化は多岐にわたるはずであり、Web3と称しているものだけが既存のWebの正統進化系であるとは現状理解することは難しい。 そのため、私見としてはいずれの進化もシーケンシャルな番号による語を充てるのは不適切でないか、と考えている。

このように語として既存の語を援用する場合は、既存の語文脈に沿った形で理解されるため、話者の意図と聴衆の意図にずれがしばしば生じるだろう。 この辺りも、「Web3」と名づけてしまったが故に、余計な批判を生んでいる点であるとも理解できる。 自身はブロックチェーンのアプリケーションの有用性を追い求め研究活動をする身として、こうした誤解/ずれを生みやすい語が充てられていること自体が、議論/発展の道を阻害していると考えている。

終わりに

概念形成が依然進まず、多岐にわたる議論がされる今だからこそ、今後の未来に生きる技術への進化を遂げるための議論をする必要がある。 そのためには、概念形成をするための定義および説明を試みることは、議論を積み上げるためのコミュニケーションの中で欠かすことのできない挑戦であると自分は考えている。

  1. ここでいう「システム」は情報システムだけでなく「社会システム」も含むだろう。↩
  2. 余談であるが、学部生時代に講義を受講したことがあるのを思い出した。こうした分野の講義を受けられたSFCの多彩な環境には洗脳されている感謝しかない。↩

ブロックチェーンでそんなことはできない

ブロックチェーン 雑記

概要

本稿は、突然ムシャクシャした筆者が自分の考えるブロックチェーンの定義と、世間で言われているブロックチェーンの特性および応用例を批判するものである。 本稿は筆者の見解であり、所属組織の公式見解ではない。

ブロックチェーンの定義

そもそもブロックチェーンとはなんなのか。狭義には、「ブロック」の「チェーン」であることから、以下の定義をしたい。

データが、当該データ直前のデータの暗号学的ハッシュ値を持つリスト型のデータ構造

ここでは、そのデータの中に何を保持するかは一切考慮しない。 データがハッシュ値で連鎖することによって、リスト中の任意のデータのみを書き換えると、ハッシュチェーンの整合性が失われ、書き換えが行われたことを検知可能なデータ構造であると定義する。

しかし、世間で「ブロックチェーン」に興味を持つ諸氏はこの定義だけではいささか狭すぎると感じるだろう。 そこで、狭義のブロックチェーンを保持するノードに関する情報を加え、定義を拡張する。

上記データ構造を持つデータをP2Pネットワーク上で各ノード上に形成するシステム

上記定義の穴、すなわち最も議論されなければならない点は「各ノード上に形成する」点である。 とりわけ「形成する」の点が最も重要であると筆者は考える。 どのように形成するか、つまり、どのように新規のデータを追記するか、追記時に行わなければならないことは何かといったことに関してはこの定義は踏み込んでいない。

そこで、以下のように定義を拡張する。

P2Pネットワーク上で新規データを全ノードに共有し、受信したノードが各自で検証および追記を行うことで、上記データ構造を持つデータを各ノード上に形成するシステム

この定義の肝は「各自で」という点である。 各自で検証し、他のノードに依存するプロセスは本定義のブロックチェーンの動作の中には含まれない。 従って、他のノードに何かを問い合わせる必要もなく、信頼する第三者などは存在しない。

したがって、上記定義から導かれるブロックチェーンの特性は以下のようなものである。

  • 過去のデータの書き換えを検知することが可能
  • 新規データの書き込みにおいて第三者を信頼する必要がない

「コンセンサス」は入らないのか？

ここでは筆者は「コンセンサス」という言葉を持ち出したくない。 というのも、ブロックチェーンにおけるPoWを用いたコンセンサス(と呼ばれるもの)はコンセンサスなのかということに大いに疑問が残るからである。 PoWをベースにしたコンセンサス(と呼ばれるもの)を考えてみよう。 主なプロセスは以下のようなものである。

  1. 新規ブロックがネットワーク上で作成される
  2. 当該新規ブロックがブロードキャストされる
  3. 当該新規ブロックを受信したノードは、当該新規ブロックに含まれるデータの正当性を検証する
  4. 当該新規ブロックを自分の持つブロックチェーンへと追記する
  5. 4の実行時、当該ブロックが参照するブロック（親ブロック）を参照するブロック（兄弟ブロック）が既にリスト中に存在する際（Forkの発生）、PoWの合計難易度が最大のものを正規のリストと見なす

さて、この時コンセンサスは取られているだろうか。 英単語としてコンセンサス(consensus)、の定義はロングマンによれば以下の通りである。

an opinion that everyone in a group agrees with or accepts
引用元： ロングマン現代英英辞典 https://www.ldoceonline.com/jp/dictionary/consensus

訳すとすれば「グループのメンバー全員が賛同あるいは、受け入れる意見」といった具合であろうか。 ここで先ほどのPoWベースのコンセンサス(と呼ばれるもの)のプロセスをみてみよう。 プロセスの中に「グループのメンバー（P2Pネットワーク上のノード）」が「同様の意見（特定のブロックを含むリスト）」に賛同したことを確認しているだろうか。 そんなプロセスは存在しないのである。 従って、あるノードは自分が採用したブロックを、ネットワーク上の他のノードも採用したかどうかに関しては、一切注意を払っていない。

したがって、筆者はこれをコンセンサスとは呼ばない。 分散システムで語られるPBFTなどの分散コンセンサスアルゴリズムでは、一定のメッセージの交換によって、他のノードでどの値が採用されたかに関する情報を交換する。 そのため、コンセンサスに至ると、他のノードが同じ値を採用していることが保証されるのだ。 ブロックチェーン、とりわけ世間で語られるPoW形式の物に関して言えば、コンセンサスは提供されていない。

世間で語られる「ブロックチェーン」のノードが行っているのは「新規ブロックを受信したら検証し、リストに追記する」ということだけである。 これは、各自のノード上でただリストを形成するだけの行為であり、先述の定義によってカバーされるものである1。

仮想通貨とかスマートコントラクトとかは？

ブロックチェーン、とは狭義には単なるデータ構造であり、それ以上の意味はない。 従って、それを構成するデータには任意のデータを含めることができると考えられる。 例えば通貨の発行、送金を示すデータを含めることもでき、それによってデータを書き換え検知可能な形で記録もできるだろう。 しかし、それはデータ構造の上に構築されるアプリケーションの話であり、ブロックチェーンそれ自体の機能ではない。

ブロックチェーン、というデータ構造を採用することによって書き換えが検知可能な形で記録することで、実装が可能なシステムは多様にあるだろう。 しかし、それらはその特性を利用して、その上に実装をしているだけであり、ブロックチェーンそれ自体の機能ではない。 例えばDBを使って様々なシステムを構築可能であり、SNSのシステムなどを構築可能であるが、SNSはDBの機能ではない。

Bitcoinはそのブロックチェーンに仮想通貨の発行、送金を示すデータを記録するアプリケーションであるし、Ethereumはその上にプログラムとその実行を記録するアプリケーションである。 とりわけEthereumを用いることで、任意のアプリケーションを構築可能であるが、それはEthereumの機能であり、ブロックチェーン自体の機能ではない。

改ざん困難とかは？

これは筆者の定義で逃げている点である。 というのも定義の中では「検証」がなんのプロセスを指すのか定義されていない。 従って、その検証の点に、PoWなどを取り入れることで、少なくとも他のノードに受け入れられる（と期待される）ブロックを作成するには十二分な計算コストがかかる仕組みを実装できる。 この「検証」をどう定義・実装するかによって、多様な特性を持ったブロックチェーンの実装が行える、という点が本定義は優れていると筆者は考えている。

ブロックチェーンの優位性と活用可能性

上記定義よるブロックチェーンは、書き換えの検知と第三者への依存を排除していると述べた。 この2つが同時に存在することがブロックチェーンの最も有意義な点であると筆者は考える。 とりわけ第三者への依存の排除は、多くのブロックチェーンの文脈で語られるのは周知だろう。 既存のシステムの多くは運用主体などを信頼する必要がある。 あるシステム提供主体が必ずしも信頼できない状況下で、当事者相互に自らが検証したデータに基づいて何かを実施できることは、多くの可能性を秘めていると考えられる。

ここから考えられるブロックチェーンの活用としては、データの存在証明、の1点であると筆者は考える。 あるデータがP2Pネットワーク上で作成、ブロードキャストされ、全ノードが各自でそのデータを持つとすれば、当該データは全ノードに複製される。 従って、（ネットワーク上に十分なノード数が存在すれば）当該データは消失不可能性を担保可能である。 また、逆に当該データが存在しないことを作成者が主張したとしても、参加ノードは各自が持つブロックチェーンのデータ中から当該データが存在したことを主張可能である（否認不可能性の担保）。

ただし、ここではコンセンサス（に類する何か）が実装上に存在し、各ノードが持つ仕組みに一定の均一性がなければ期待できないことは記しておく。 例えば、当該データの存在を主張したとしても、それがその主張する者のノード上にしか存在しなければ、その主張する者が恣意的にデータを作成した可能性がある。

存在証明の利用

存在証明を応用することで、あるデータが存在し、それに伴う何かしらの操作、またその操作記録それ自体のデータが存在することにより「あるデータに基づいた操作が存在したこと」が確認できる。 それらの実装がBitcoinやEthereumであると整理可能であろう。

BitcoinやEthereumにおいては、デジタル署名を書き込むデータの中に含むことによって、データ発行者の否認不可能性を担保している点も、興味深い点である。 存在しただけでなく、それが発行者の秘密鍵によるデジタル署名を含むことによって、当該鍵ペアを持つ者が間違いなくそのデータを発行したことが保証される。 鍵ペアと現実世界のエンティティの結び付けの方法などは課題が残るものの、ブロックチェーンのデータ存在証明の機能を最大限活用していると言えるだろう。

ブロックチェーンでそんなことはできない

さて、本稿の主眼であるブロックチェーンの機能および応用に対しての批判を加えていくことにする。

トークン系： ブロックチェーンを用いたデジタル地域通貨で地域活性

このような主張をする多くのケースでは「地域通貨を発行し地域経済を活性化する」という主張だろう。 先述したようにブロックチェーンそれ自体の機能としては仮想通貨は存在しない。 ただし、デジタル地域通貨の実装にあたり、取引の当時者同士で取引の存在を証明することが「必要」とされ、ブロックチェーンベースの仮想通貨を実装するに至る。 しかし、「地域通貨」の実装にそれらは本当に「第三者に依存しない形で」実装する必要があるのだろうか？

筆者の考えでは、それらはこれらの施作実行者、多くの場合は地域商店街や自治体がクライアントサーバモデルでの通常のWebシステムで実装したとしても、同様の効果が期待できるのではないかと考える。 大概のケースでの目的は、ブロックチェーンであるかどうかではなく、地域通貨というものを発行することでその地域経済を活性化することにある。 とすれば、まずは地域通貨システムを純粋に実装し、地域通貨が活性化に寄与するかどうかを検証する必要があるだろう。

確かに地域通貨を入手する人は観光客など、その地域の人にとって「信頼がおけない」人で、不正に二重支払いを行う可能性がある。 しかし、地域通貨を発行し、その支払いを受けるというシステムの上で、その発行主体が存在する。 その発行主体が正しく発行されたデジタル地域通貨トークンに対してデジタル署名を付与するなどの仕組みで担保可能である。 それを当事者全員にデータを配布し、各自で検証するモデルにするべきかどうかは、疑問が残ると言わざるを得ない。

類型として、「hogeトークンを発行し、hoge経済圏を」というものは大概同じ疑問を呈することになる。 仮想通貨を全世界レベルで、信頼できない人同士で交換しようとするので参加者個人レベルでの検証作業が必要になるのである。 一定の参加者の中で流通する通貨を作りたいだけであれば、通常のWebシステムで実装可能である。

権利系: ブロックチェーンを用いた著作物の利用許諾管理

利用許諾管理、すなわち許諾を受けない人が利用した際は正しく利用料を徴収する必要がある。 しかし、ブロックチェーンでは、データの存在を証明しかできない。 つまり許諾を受けているかどうかの確認までしかできないのである。 従って、このシステムを実現するためには、全世界でのあらゆる著作物利用者を追跡し、それらが全て許諾を受けているかどうかを確認する必要がある。 ブロックチェーンはデータ構造であり、それをノード上で保存するシステムであるため、ブロックチェーンの外側で起こっていることは積極的に検知することは「ブロックチェーンの機能としては」存在しない。

本システムを実現するためには、まず著作物の権利保有者が、利用許諾の許可は全てブロックチェーン上で行う、というような運用をすることが必須である。 別チャンネルでの許諾した場合、それとブロックチェーン上に存在しない許諾の判別することはほとんど不可能である。 その上で、全世界の著作物利用クローラーが必要である。 これは不正利用を積極的に検知するためである。最後に、利用料の徴収の仕組みの実現である。 これが筆者は最も困難であると考える。 なぜなら不正利用者は許諾を受けないで利用をしたとして、その保有資産を強制的に徴収するような仕組みがなければ積極的にその利用料を支払わないと想定できるからである。 実装するとすれば、許諾は全てブロックチェーン上に記録されている前提の元、許諾を受けているリストに不正利用者が存在しないことを根拠に訴訟を起こすなどしかないだろう。

しかし、ここでさらに厄介な問題として、許諾者の識別子の問題がある。 許諾を受けている者の識別子リストがブロックチェーン上に存在するとして、その識別子がブロックチェーン外部の利用者本人に対して許諾をしているかどうかを検証する必要がある。 すなわち、その識別子をどう認証するか、という問題が発生する。 これはブロックチェーン単体では到底解決できず、識別子の設計、利用者がどのようなデータを提示しながら利用をするべきか、などのスキームを整理する必要があるだろう。

また、そうした識別子の認証、不正利用の紛争調停を信頼する第三者に依存するのであれば、ブロックチェーンを使う意味がどれだけ存在するかは疑問と言わざるを得ない。

プライバシー系

一部のブロックチェーンの応用では、「プライバシーを守る」という言説がある。 しかし、ブロックチェーン上に書き込まれるデータは、全参加者に書き込まれたデータは共有される。 従って、単にブロックチェーンを使ったのみでは、プライバシーの問題は解決できるどころか、全てオープンな形にしなければならない。

一方、載せるデータを一定の暗号化を行えば良いとも考えられる。 しかし、暗号化し、一定の参加者しか復号できないとすれば、全参加者がその新規データの正当性の検証は行えない。 ここで準同型暗号やゼロ知識証明などの暗号技術を活用することもさらに考えられるが、これはまだ研究開発段階と言わざるを得ないだろう。

批判のまとめ

一貫して、以下の点で応用を整理することで批判できてしまうプロジェクトがほとんどであろう。

  • 「信頼する第三者を排除しなければならないのは、システムのどの部分においてなのか」という議論の欠如
  • ブロックチェーン外で起こる事象への積極的検知が必要なシステムへの適用
  • ブロックチェーンの根本的な優位点の活用の議論の欠如

また、その他にもブロックチェーンを利用した際のシステム全体のアーキテクチャ的に信頼点が存在する作りになっていることもある。 例えば、ブロックチェーン上に何か書き込むそのクライアントを、あるWebサービスを通じて行うような場合がある。 そのWebサービスを介してしか行えないのであれば、そのWebサービスのバックエンドとして利用しているのみであり、DBを使う場合とどれだけ差異があるかは疑問を呈さざるを得ない。 さらに、近年のEthereumのGas代の高騰から、書き込みを最小限に抑えてWebサービス側でデータを持ち、一定の操作を要求された場合のみブロックチェーンに書き込むような実装も散見される。 この場合、書き込まれるまではブロックチェーンの特性は一切利用できないため、Webサービスは信頼点となってしまう。

現状、そうしたGas代などの要素をブロックチェーンの特性をうまく利用しながら削減する手法は研究開発段階である。 そうしたパーツが揃わなければ、安定して人々の資産を預かるようなサービスを実装することは困難であろう。 本稿では、それぞれの不足する要素に深く言及はしない。 しかし、ブロックチェーンの本来の特性を生かしてシステムを構築し、世の中のインフラとして運用するためにはまだまだ未成熟な技術である。

終わりに

本稿では、ブロックチェーンの応用と呼ばれるものに対して、批判を加えた。 なぜこのような本来のブロックチェーンの機能から乖離した応用や有用性が叫ばれるのだろうか。 これは、前節で述べたように、ブロックチェーンの技術それ自体が未だ研究開発段階であり、それを活用するモデルも議論の最中であるからである。 ブロックチェーン技術の未解決問題が出版されてから既に4年の月日が経った。 しかし、述べられている問題の多くは依然解決していない。

根本解決しないまま応用を実装する場合、暫定対処をすることになるだろう。 それの1つが、Gas代の削減で述べた書き込み回数を抑えるような手法であり、その手法によって本来の特性が損なわれていることを述べた。 システムを構成するということは、その要件から必要な技術選定し、それが安定運用されることまでを見据えて実装をしなければ長期的に活用可能にはならない。

とりわけ、近年のWeb3等の議論で、そうした現状の技術、その特性に即した議論からは乖離した議論が散見される。 正しくその技術特性を見極め、適切な適用と、実装、そして運用を見据えた議論が増えることを切に願う。

  1. PoSなど、「コンセンサス」を提供しようとする試みはある。それらも、データ構造に対して新規データを「どう検証・追記するか」の部分の工夫であると考えられるため、実装として「コンセンサス」を組み込むことも可能、という形で本定義の中で整理できる。↩

did:webをGitHub Pagesで使う

本項はdid methodのdid:webをGitHub Pagesでホストし，didを使った署名検証を行うメモである． didはさまざまなメソッドの実装があるが，中でもdid:webは，特定のURLでアクセスできる箇所にDID Documentを配置することで利用できる． 特定のURLでアクセス可能な静的なサイトをホストする方法として，GitHub Pagesがある． そこで，本稿では特定のリポジトリのGithub PagesでDID Documentを提供し，DIDをインスタントに利用する方法を記す．

例によってdid:webの仕様は確定しておらず，2022年4月現在のものであることに留意していただきたい．

did:web仕様の理解

did:webの識別子は，did:webをmethodの識別子として，その後にdomain-nameが続く． 例えば，did:web:domain-nameのDIDがあった時，https://domain-name/.well-known/did.jsonでアクセスできるようにDID Documentを配置することで，resolverが解決可能になる． また，特定のドメイン配下の特定ユーザを表現するためには，domain-name:usernameなどと表現すると，https://domain-name/username/did.jsonがDID Documentの配置箇所になる． ドメイン配下のパスが入った場合.well-knownを実際のアクセスするパスに含まないので注意が必要である．

GitHub Pagesでのdid:webのホスト

GitHub Pagesは，特定のリポジトリの特定の箇所を，https://{GitHubUserName}.github.io/{RepositoryName}で静的にホストできる． 本稿では，この機能を使ってdid.jsonをアクセス可能にし，did:webを利用する． この時did:webはdid:web:{GitHubUserName}.github.io:{RepositoryName}となる．

筆者はhttps://{GitHubUserName}.github.ioで，自身のWebサイトchike.xyzをホストしているため，Github Pagesを利用するとhttps://chike.xyz/{RepositoryName}でホストされる． did:webの仕様と照らし合わせると，この場合のdid:webはdid:web:chike.xyz:{RepositoryName}となる．

GitHub Pagesでは，GitHub Pagesとしてホストする箇所は，gh-pagesブランチか，mainブランチのdocs以下を選択できる． そこで，Node.jsを用いてsecp256k1の鍵ペア及びDID Documentを生成し，それをmainブランチのdocs以下に配置するスクリプトを実装した．

github.com

詳細はリポジトリのREADMEに記載したが，本リポジトリをForkしてclone，src/config.json内にホストされるドメイン及びリポジトリ名を設定することで，鍵を1つ持つDID Documentをdocsディレクトリ内に生成できる． 生成したDID DocumentをGitHub上にpushし，GitHub上でGitHub Pagesとして，mainブランチのdocsをホストするよう設定することで，DID Documentを公開できる．

一応本リポジトリ内で生成した秘密鍵を用いてJWTを作成し，jwtのissuerとしてdidを利用して検証可能であるライブラリのdid-jwtを用いて検証可能なデモのスクリプトも設置している．

やってみての感想

GitHub Pagesは静的なサイトをホストするには非常に簡単で，使い勝手も悪くない． しかし，did:webをホストする，ということを考えるといくつかの懸念があると感じた． did:webの仕様上でも述べられているが，did:webはドメインの解決に強く依存しておりその解決が正常に行われるか，ということがdid:webを利用できる前提条件となる．

また，実質的に独自ドメインでGitHub Pagesを用いた時は，DNSレコードとしてGitHubが指定する特定のA/AAAAレコードを設定することが求められる． 従って，ユーザがアクセス時にはVirtual Hostに相当するものでどのドメインが解決されアクセスしたかをGitHubが振り分けていると推測される． 本稿で述べた方式を用いてdid:webを利用すると，DNSが正しく解決されるかに加え，GitHubが正しくアクセスの振り分けを行うか，ということも懸念事項となる． DNS解決の真正性に関してはDNSSECの利用などが考えられるが，GitHub内部のプロセス依存の問題は外部からの検証が困難である．

一方，インスタントにdidを利用してみる，という点では，did:webとGitHub Pagesの組み合わせは非常に簡単であり1，利用しやすいため，暫定の実験目的などでは有効な1手段ではあると感じた．

  1. 実際Universal ResolverのExampleで用意されているdid:webはGithub Pagesでホストされているようである．↩

IONをBitcoin Testnet上で動かす

本稿はDIDの一実装であるIONをBitcoin Testnet上で動かしたメモである。 ION/Sidetree/IPFS共に実装がそれぞれまだ変更が激しく、本稿の記述は2022.01.11時点の内容である。

構築環境

  • Debian 10
  • Bitcoin Core v22.0
  • ION v1.0.3
    • node v14.18.2
    • ipfs v0.9.1
    • MongoDB v4.4.11

構築手順

1. Bitcoinのインストール/テストネットのセットアップ

  • Bitcoinのインストール
  • bitcoin.conf の作成
    • ~/.bitcoin/bitcoin.conf に以下を作成

    • rpcpassword には任意の値を設定する

      testnet=1
server=1
rpcuser=admin
rpcpassword={任意の値}
txindex=1
  • Bitcoinをtestnetで起動
    • ブロックの同期がスタートする
      • 数時間で完了
      • 本稿執筆現在で30GB程度
      bitcoind -testnet

    • 同期の終了を確認するには以下のコマンドで blocks と headers の値を確認する

      bitcoin-cli -testnet getblockchaininfo
  • ION用の鍵の生成

    • walletの生成

      bitcoin-cli -testnet createwallet default

    • アドレスの生成

      bitcoin-cli -testnet getnewaddress

    • 鍵の確認

      bitcoin-cli -testnet dumpprivkey <getnewaddressで生成したaddress>

2. IONのインストール

  • 依存関係
    • IPFS
      • https://docs.ipfs.io/install/command-line/#official-distributions
      • NOTE: go-ipfsの最新版(v0.11.0)ではIONから書き込みが正常に行えなかったため、ION v1.0.3リリース当時の最新版 go-ipfs v0.9.1をインストールする

      • インストール

        wget https://ipfs.io/ipns/dist.ipfs.io/go-ipfs/v0.9.1/go-ipfs_v0.9.1_linux-amd64.tar.gz

        tar -xvzf go-ipfs_v0.9.1_linux-amd64.tar.gz

        cd go-ipfs
sudo bash install.sh
        • インストールの確認
        ipfs --version

      • IPFSの初期化

        ipfs init

      • 起動

        ipfs daemon
    • MongoDB
    • node
      • nodenvでインストール
  • ION本体

    • リポジトリのクローンとv1.0.3へのチェックアウト

      git clone https://github.com/decentralized-identity/ion
git checkout refs/tags/v1.0.3

    • ionの設定ファイルの記述

      • テンプレートはjson ディレクトリにあるので、任意のフォルダに移動する
      • ここでは~/.ion 中に配置する
      • testnet-bitcoin-config.json
        • bitcoinDataDirectory: testnetなので/home/username/.bitcoin/testnet3
        • bitcoinWalletOrImportString: 先ほど生成した秘密鍵
        • bitcoinRpcUsername: ~/.bitcoin/bitcoin.confに設定した値
        • bitcoinRpcPassword: ~/.bitcoin/bitcoin.confに設定した値
      {
  "bitcoinDataDirectory": "[FILL THIS IN!]",
  "bitcoinFeeSpendingCutoffPeriodInBlocks": 1,
  "bitcoinFeeSpendingCutoff": 0.001,
  "bitcoinPeerUri": "http://localhost:18332",
  "bitcoinRpcUsername": "",
  "bitcoinRpcPassword": "",
  "bitcoinWalletOrImportString": "[FILL THIS IN!]",
  "databaseName": "ion-testnet-bitcoin",
  "genesisBlockNumber": 1900000,
  "logRequestError": true,
  "mongoDbConnectionString": "mongodb://localhost:27017/",
  "port": 3002,
  "sidetreeTransactionFeeMarkupPercentage": 1,
  "sidetreeTransactionPrefix": "ion:",
  "transactionPollPeriodInSeconds": 60,
  "valueTimeLockUpdateEnabled": false,
  "valueTimeLockAmountInBitcoins": 0,
  "valueTimeLockPollPeriodInSeconds": 600,
  "valueTimeLockTransactionFeesAmountInBitcoins": 0.0001
}

    • IONのビルド

      npm i
npm run build

    • 設定ファイルを読み込むための環境変数の設定

      export ION_BITCOIN_CONFIG_FILE_PATH=~/.ion/testnet-bitcoin-config.json
export ION_BITCOIN_VERSIONING_CONFIG_FILE_PATH=~/.ion/testnet-bitcoin-versioning.json
    • IONのBitcoin Serviceの起動
      • Blockchainを全てチェックするため、時間がかかる
      npm run bitcoin
    • IONのCore Serviceの起動
      • Bitcoin Serviceで発見されたDIDとIPFS上の情報を照合するので、こちらも時間がかかる
      npm run core

3. 確認

  • curlでresolve可能なことを確認する
    • ここでresolveできるDIDはIONのドキュメント上でバージョンごとに異なるようなので注意

    • Core Serviceの起動してからしばらくしないとresolveできるようにならない

      curl http://localhost:3000/identifiers/did:ion:test:EiClWZ1MnE8PHjH6y4e4nCKgtKnI1DK1foZiP61I86b6pw

4. DIDの作成とresolve

IONのコマンドラインツールを使って新規にDIDを作成する。

参考

奨学金獲得戦線

筆者は学部生時代から足掛け9年間（学部4年 + 修士2年 + 博士3年）奨学金をさまざまな工夫を凝らしながら獲得し、学費を工面してきた。本年度で学生生活が終わるにあたり、本稿では、奨学金を獲得するためのTipsおよび考え方を示す。

Note: 本稿は筆者の主観であり、本稿に沿って奨学金を獲得できることを保証するものでもない。また、制度、システムに関しては筆者が在籍した機関、および2021年度までの情報なため、最新情報でもない。

要点

  • 奨学金応募は研究活動・論文執筆においても有用な能力を養えるので、積極的にやるべき
  • 新年度になってからではなく3月から情報収集・書類準備は始める
  • わからないことがあれば窓口にしっかり聞きましょう

奨学金の分類

現代においては多くの学生が大学院進学に当たって学費面の心配をする。そこで、奨学金を受給し、それによって工面を行うことを考えるだろう。主に奨学金は

  • 給付：返還の義務がないもの
  • 貸与：返還の義務があるもの（事実上の借り入れ）

の2種類がある。慶応では、三田会などの寄付を受けて運用されている学内奨学金、学生支援機構など学外の団体による奨学金の2つにさらに分類される。

奨学金ガイダンスなどで重々告知されているように、貸与の奨学金は「返還の義務がある」ということを念頭に入れなければならない。従って、多くの人は給付型の奨学金の獲得を狙うだろう。一方、大学院であれば、学生支援機構奨学金は優秀な業績を収めた学生への返還免除の制度がある。そうしたものを狙って、学生支援機構奨学金を活用するのは一つの戦略であろう。

また、さまざまな観点で奨学金は分類することができるが、筆者が奨学金を探すときに意識をしていた項目は以下のようなものである。

金額・期間

金額は大小さまざまなものがある。また、給付の形式も、月額が定まっており毎月給付されるもの、年額が定まっており一回給付されるもの（数回に分割されるケースもある）、などさまざまである。期間に関しても、申請したその年度のみのものから、最短修業年限まで継続して受給できるものなどがある。筆者は応募先を検討する際は、基本的には応募年度の年額を計算し、比較検討を行っていた。

募集対象

多くの奨学金は「優秀な、経済面での支援が必要な学生」など、支援の必要性がある学生に給付する旨を公表している。一方で、「優秀な学生」のみを掲げている奨学金も存在し、その場合は純粋に申請書などに記載する内容で審査がされるものであると考えられる。

また、募集対象の学生の専門分野を限っているケースも存在する。例えば「理系」、「〜の分野で研究を行なっているもの」などである。この場合、多くの場合は多くの場合学部・研究科で分野の判断がされる。申請書に書かれる研究概要で判断する場合もある。

慶応SFC固有の問題だが、筆者は情報系の研究に従事しているので、大雑把には「理系」である。しかし、先述のように「学部・研究科」で分野の判断がされる場合、実際の研究内容に関係なく、筆者の出身である「総合政策学部」は「文系」の学部であると判断されてしまうケースも多い。また、「政策・メディア研究科」もまれに「理系」と判断されないケースも存在し、この辺りは学際学部固有の苦しみが存在する。

財団の情報

奨学金の財団は、多くの場合篤志家の方々/企業によって設立され、奨学金の運用を行なっている。そのため、その企業の業界分野に寄与する研究を行なっている学生を募集するケースも多い。また、最終的に審査を行うのは財団であること鑑みると、応募書類へ自身の活動を書く際にその業界を意識して伝わる例示などを考えるのに重要なヒントとなる。

奨学生の義務

奨学金の受給が決まると、研究などの学生生活の活動報告書、あるいは財団の方々、他の奨学生との懇親会への出席が義務付けられるケースがある。これらは受給を受けると「義務」なので、必ず満たせるように意識しなければならない。

選考フローとスケジュール

本項では、主に慶応SFCにおいて、給付型の奨学金を受給することを主眼として話を進める。SFCでは、多くの奨学金が以下のフローとなる。

  1. SFC内: 書類選考
    • ここでは事前に提出した書類に基づいた審査が行われる
  2. SFC内: 面接選考
    • SFC内の任意の専任教員と面接を行う
  3. SFC内: SFCからの推薦者決定
  4. 慶応全体: 他キャンパスからの推薦者を含めて、慶応全体としての推薦者決定
    • 学内奨学金の場合はここで内定する場合もある
  5. 奨学財団: 財団固有の選考
    • 書類のみであったり、面接が課せられたりするケースもある

それぞれの奨学金によって募集時期は異なるが、多くは3月下旬〜4月に募集の学内締め切りが集中する。奨学金によっては、公的な所得などの証明書、家族の正確な情報が必要になるケースが存在する。　また、応募にあたり自身の研究のサマリーなどの文章を求められるケースもある。その場合、応募の準備には相応の時間がかかる。

ここで注意しなければならないのは、当該年度の奨学金募集は3月締め切りのものも存在することである。そのため、「新年度始まるのでそろそろ奨学金の申請を」と思って学内の案内ページを見ると、既にいくつもの奨学金が締め切られている、数日後に締め切りが迫っている、という状況になりかねない。特に、新年度で入学する際はそれらの情報リソースをいち早く、と思って4月2日に窓口に相談に行っても、5日締め切りのものが存在するなどのケースもある。3日間で全ての書類を準備するのは、体感として困難と言わざるを得ない。

結論として、3月に入ったら奨学金のページをチェックし、自分が応募可能な奨学金を探し、リスト化、必要書類の準備を進めなければならない。また、新規に募集が始まったとしても多くの場合は学生にメールなどで通知されることはない。そのため、毎日奨学金のページをチェックし、リストを更新する作業を行うべきである。

応募に関する筆者の考え方

筆者は、博士課程まで毎年3月ごろになると奨学金の応募書類の作成作業を始めていた。この作成作業には、それ相応の時間がかかり、実際研究活動の手を緩めなければならないケースもある。一方で、奨学金の申請のためには、多くの場合「自身の研究のサマリー・貢献」「将来像」などについて記述しなければならない。また、これは論文と異なり、異分野の人が読んでも理解できる書類に仕上げなければならない。そのためには、自分の行なっている議論を再整理し、その貢献をシャープに平易な言葉で語るようにしなければならない。自身の活動の意義を平易に語り、それに出資してくれる気になるような文章を書く、その能力は研究・社会の中においても非常に重要な能力である。自分はまだ社会に出てないから知らないけど。

従って、筆者は例年新年度を迎えるにあたって、改めて自身の研究の貢献を考え直す機会と捉え、研究活動の一環としてこれらの作業は行っていた。貢献や方向性の整理を意識的に行わず、迷走ししてしまうことが研究活動ではしばしば発生する。少なくとも奨学金の申請という手続きの中で、これらを年に1回強制的に行うだけでも非常に意味のあることであると考える。

Tips

奨学金応募および選考にあたりいくつかのTipsを残す。

準備の手順

以下の手順を遅くとも3月中旬には始める。

  • 応募可能な奨学金のリスト作成
    • 5月ぐらいまでは毎日チェックを行い更新をする
  • 必要書類のリストアップ
    • 家族の所得証明を勤務先に依頼するケースもあるので締め切りに十分注意する
  • 自身の書類記述部分の文章作成
    • 主に書くこと（募集要項・必要書類から項目を整理しておく）
      • 研究・活動していること
        • その貢献
      • 将来像
        • 現在の活動と将来像はどう繋がるか
    • これらの文章は1度書いた後に、数日おくなりして見直すタイミングがあると良い
      • 文書を推敲する能力を養うトレーニングと捉えて行う

学内選考におけるノウハウ

書類の書きっぷり

  • 「わかりやすい文章」を意識する
    • 初学者にも読めるようにする
      • 「誰が読むのか」を意識する
        • 多くの場合は「教授」である
        • 専門分野が異なっても、いい加減な専門用語で煙に巻くような文章は評価されないと思っていいだろう
      • 専門用語は必要最低限にとどめ、必要な場合は適宜説明を加える
    • パラグラフライティングを意識する

面接官を知る

  • 文章の書きっぷり同様、面接官に対してわかりやすく説明する
    • SFCの中であれば、教員プロフィールなどを眺めておき、顔と専門分野を大まかに把握しておく
      • 面接官は事前に通知されないので、部屋に入った時に、顔から専門分野がわかるとベスト
        • 近年はzoomで面接が実施されるため、その場で手元で表示名を検索することも可能だろうが、その良し悪しはある
      • その人にわかるような例、喋り方、専門用語の使い方を心がける

ありそうな疑問

Q1: 両親の所得が多くて奨学金なんて受けられそうにない

所得制限なく、「優秀な学生」を対象に奨学金も存在する。絶対数は少ないが、チャレンジする価値はあると筆者は思う。 大学院生で、両親と別居、バイトで生計を立てている状況であれば、独立した生計として申請することができるので、一度窓口に相談しよう。

Q2: 学生結婚すると学費が少なくなるって聞いたけど？

これは嘘。正確には、所得を計算する際に結婚していると、配偶者の収入をある程度控除する仕組みがある。加えて独立生計である場合、自身の所得では2人で暮らすのには不十分である、という旨を記述してあげればある程度は奨学金受給の必要性が明確になり、受給できる可能性が上がるかもしれない、というのが実態である。

Q3: 書類がめんどくさい

うるさい こう書くと老害っぽいが、数年前までは全ての書類が手書きだった。今はWebフォームに入力で済むので、wordなどで十分に推敲するのは楽だ。お金のためと思って頑張ろう。

Q4: hogehogeって書類って何ですか？

窓口に聞きましょう。みなさんすごく丁寧に対応していただけます。

終わりに

本稿で述べたのは応募に関しての話であり、審査される対象はそれまでの実績や、記述内容である。そのためには、やはり研究・活動に精を出し、業績をあげた方が結果として奨学金は通りやすくなるだろう。そのための活動に集中するためには、奨学金を受ける必要がある、これはにわとりとたまごみたいな話だ。

一方、頑張ればその分のリターンはある話だし、本稿で述べたように特に文章執筆および人にその内容を伝えるということは非常に重要な能力であるとともに、有意義なトレーニングの機会である。

自分は家庭の事情もあり、給付・貸与含めて9年間で受けた奨学金の額は相当なものだ。特に大学院に入ってから純粋に自費で学費は払っていない。これは家族、指導教員、そして学事学生生活奨学金担当の方々による多大なサポートを受けて実現できたことである。ここで改めてその感謝を示しておきたい。

本稿が学費を憂う学生の何かしらのヒントになることを祈る。

OpenStack調査メモ

本稿は慶應義塾大学 SFC 村井研 (RG) Advent Calendar 2021の2日目である。

本稿は実験環境のクラウド環境のOpenStackへの移行を検討するために調査を行なったメモである。

OpenStackとは

主要なものは以下

コンピュート (Nova）

ネットワーキング (Neutron)

ブロックストレージ (Cinder)

アイデンティティサービス (Keystone)

イメージサービス (Glance)

オブジェクトストレージ (Swift)

ダッシュボード (Horizon)

OpenStackのリリースサイクル

OpenStackを試す

OpenStackはそれぞれのコンポネントを組み合わせることで、クラウド環境を構築できる。また、コンポネントがそれ別の物理サーバ上において、スケールさせるということもできる。一方でサクッと試したい場合は必要なコンポネントが全て入った（All-in-One）な環境を作る、ということもできる。

Openstackのアーキテクチャを設計し、個々にデプロイしていくこともできるが、構成ツールがいくつかある。主要なものは以下に掲載。少し古いので、それぞれ調査する必要あり。 https://noaboutsnote.hatenablog.com/entry/openstack_installer

microstackを使った動作検証

microstackを使うと容易にall-in-oneの環境構築ができる

Microstackのデプロイ

  1. ESXIの仮想化をOpenstackから利用可能にする

  2. microstackインストールのためのsnapのインストール sudo apt install snapd

    • 再ログインしないと /snap/bin にパスが通らないので注意

  3. microstackのインストール

     sudo snap install microstack --devmode --beta

    • インストールの確認は以下

        snap list microstack
      • 2021.11.22時点でussuriが入ったので、少し古いか

  4. microstackの起動

      sudo microstack init --auto --control
    • 検証環境では、sudo時のPATHに/snap/binが引き継がれないためvisodoでsecure_pathに追加
    • このコマンド実行は数十分かかる
  5. Horizonへのログイン
    • https://ホストマシンでHorizonのログイン画面にアクセス可能
      • TLSエラーが出るがchoromeでは「thisisunsafe」と打つとアクセスできる
    • ユーザ名はadmin
    • パスワードを以下のコマンドで取得
     sudo snap get microstack config.credentials.keystone-password

VMの起動

debianのVMをデプロイしてみる。ImageからVMの起動がHorizonからだと失敗するので、以下はCLIからのみ検証 追記: MicroStackではCinderが未対応らしい、Volumeを作らなければHorizonからでもできた

  1. Imageの準備 
     wget https://cloud.debian.org/images/cloud/OpenStack/current-10/debian-10-openstack-amd64.qcow2
    • Imageの作成
     sudo microstack.openstack image create --disk-format qcow2 --container-format bare --public --file ./debian-10-openstack-amd64.qcow2 debian10
    • Imageの確認
     microstack.openstack image list
  2. ssh用鍵の登録
    • 鍵の作成
     ssh-keygen -t ed25519
    • 鍵の登録
     microstack.openstack keypair create --public-key ~/.ssh/id_ed25519.pub newkey
  3. VMの起動
    • 今回はdebian10testという名前のVMを作成
     microstack.openstack server create \
 --flavor m1.small \
 --nic net-id=test \
 --image debian10 \
 --key-name newkey \
 debian10test
    • nic net-idでデフォルトの内部ネットワークであるtestを指定
    • 起動を確認
      • statusがActiveになれば起動済み
        microstack.openstack server list
  4. ネットワークの設定
    • デフォルトではexternalという名前のネットワークがVMからホスト、外向けのネットワークとして構成されている
    • 外部（VM<->ホスト）のネットワーク設定
      • IPの払い出し
        microstack.openstack floating ip create external
      • 払い出されたIPの確認
        microstack.openstack floating ip list
      • 払い出されたIPをVMに設定
        • 確認時のFloating IP Addressを設定
        openstack server add floating ip debian10test FLOATING_IP_ADDRESS
    • HVのマシンからSSH
      • 必要に応じて登録したssh鍵を指定
      • debianのクラウドイメージではデフォルトユーザはdebian
     ssh debian@FLOATING_IP_ADDRESS
    • インターネット疎通性を確保
      • externalのDNSサーバを設定
        microstack.openstack subnet set --dns-nameserver 8.8.8.8 external-subnet
      • HVマシン上でNAT設定
        sudo iptables -t nat -A POSTROUTING -s 10.20.20.1/24 ! -d 10.20.20.1/24 -j MASQUERADE
  sudo sysctl net.ipv4.ip_forward=1
      • sshし、VMの中から疎通性確認

複数HV（Computing Node）での操作

Computing Nodeを追加する。

手順
  1. 上記手順の「3. microstackのインストール」までは同様の手順
  2. 既存のControl Node上でjoinするための情報を得る
    • この手順はComputing Nodeごとに必要
     sudo microstack add-compute

  3. 新規Compute Node上で上記で出力された文字列をCONNECTION_STRINGとして以下のコマンドを実行

     sudo microstack init --auto --compute --join CONNECTION_STRING

  4. 既存のControl Node上でhypervisorとして追加されたことを確認

     microstack.openstack hypervisor list
  5. VMの起動
    • 2021.11.23 Note: Horizonからインスタンスを起動するホストの指定方法が不明のため、CLIから起動確認
      • 今回はdebian10test02として起動
        • --availability-zoneのHYPERVISORに先述の4で確認した新規hypervisorを指定
        microstack.openstack server create \
  --availability-zone nova:HYPERVISOR \
  --flavor m1.small \
  --nic net-id=test \
  --image debian10 \
  --key-name newkey \
  debian10test02
      • Note: VMは起動したようだが、keyが設定されておらずdebianだとデフォルトパスワードが存在しないためsshが不可能な状態だった
        • crriosならデフォルトパスワードでログイン可能なことを確認
          • 未解決

ToDo

  • 複数HV（Computing Node）での操作
    • Horizonからのインスタンスデプロイ
      • (解決済み) どのようにnovaクラスタ内でallocateされるか?
        • novaのshcedulerによってallocateされる
      • (解決済み) 自動でallocateされるような風だが、HVのリソースを使い切った上でインスタンスデプロイしても別HVへallocateされない
        • 実際に使い切ったかどうかではなく、schedulerによる判断による
    • インスタンスのマイグレーションが動かない
      • 実行されている風だが、実態に変化なし
    • Key Pairのインスタンスへのインポート
      • Control Node以外のHVを指定して作成したインスタンスにpubkeyが設置されない
        • 2021.11.24 NOTE:
          • cloud-init中のプロセスで、metadataの取得ができていないことが判明
            • 169.254.169.254へアクセスしようとするがだめ
  • Cinderなしで実用できるか or Cinderだけ別で立てるか？

解決済み

  • (解決済み) HorizonからのVM作成
    • ImageからInstance作成時に以下のエラーが発生する
      Build of instance 13731f21-5c7e-4d14-a715-26c7b82953b1 aborted: Invalid input received: Invalid image identifier or unable to access requested image. (HTTP 400) (Request-ID: req-20c4229b-e3bc-4941-ae15-c0102985e8b2)
    • どうやらCinderでVolumeを作るのに失敗している様子
      • Volumeなしで作ると成功する

        MicroStack quickly installs OpenStack on a single machine. Supported services are currently Glance, Horizon, Keystone, Neutron (with OVN), and Nova.

      • https://microstack.run/docs
      • Cinder対応しとらんやんけ！！！！
  • （解決済み） VPNを作ってInstanceへアクセス

感想

構成ツールとかが出てきているので、ひと頃噂で聞いてたよりは構築は容易にできそう。しかし、クラスタ化して安定運用するためには様々なことを理解せねばならず、使い勝手は必ずしもよくない印象。というか、マイクロサービス化されていて疎結合になってるのに構築するの難しいからall-in-oneの密結合になったパッケージ使っちゃうのどうなのよ、と言う気分もある。最近はProxmoxというのも話題だそうなので、試してみる予定。

Appendix

VPN越しでOpenstack上のインスタンスへのアクセス

VyOS上でStatic Routeを指定し、VPNでpush-routeする。

  • 想定環境
    • vpnのIF: vtun0
    • VyOS（ルータ）のStatic IP: 10.8.0.1/24
    • Openstack Control NodeのStatic IP: 10.4.150.1
    • OpenstackのExternal Subnet: 10.20.20.0/24

手順

  1. VyOS Static Routeの指定

     set protocols static route 10.20.20.0/24 next-hop 10.4.150.1

  2. VyOS VPNへpush-route

     set interfaces openvpn vtun0 server push-route 10.20.20.0/24

  3. Openstack Control Node 上でのiptablesの設定

     sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 10.20.20.0/24 -j MASQUERADE
  4. インスタンスへsshして確認する

マンションISPにブチ切れた話

先日引越しをした。新居は最近よくある「壁にあるLANにつなぐだけでインターネットが使えます！」というマンションISPの入っている物件だ。結果として、壁につないだだけでは使い物にならず、ブチ切れてCiscoのルータを買って導入した顛末を記しておく。

引越し当日: 回線の確認

引っ越して荷物を概ね開け、ではネット環境を確認してみるか、と思いパソコンを壁に繋げてみると、ちゃんとDHCPでアドレスが降ってきた。スピードテストしてみると、だいたい6~70Mbpsぐらいは安定して出ている。 もともとマンションISPに期待してなかったので、 まぁそんなもんかと思いつつWiFiを飛ばすためのルータをAPとして設置して、その日は寝た。結果としてそれが悪さをしてしまった。

引越し2日目午前: アドレスが降ってこない

新居はそこそこの広さがあるので、APを寝室&書斎用に増やそうと思いながらWiFiにスマホをつないでみた。すると何かおかしい、DHCPでアドレスが降ってこない。リース要求を出そうが、昨晩Macbookに降ってきたアドレスを名乗ってもダメ。何かがおかしい。ということでサポートに電話すると、WiFiを飛ばしたい場合はAPモードではなくルータモードで設置しろとのこと、マニュアルに書いてあることと違うやん。

どういうことか詳しく話を聞いてみると、共用部にある建物全体のDHCPサーバから各家にはアドレス3つしか払い出しをしないというポリシーであることがわかった。そのため、3つ以上の払い出しを受けると、それ以上のデバイスを接続することができなくなってしまうとのことだった。今時家の中のデバイスが3台しかインターネットに繋がらないなんてことないだろ。とりあえず、APにしていたルータでNATさせることで接続できた。つなぐだけで簡単インターネットちゃうんか。

引越し2日目午後: スピードが遅い

さて、無事設置はできたので、スピードテストをしてみる。やっぱり6~70Mbpsぐらい。いや、やっぱりベストエフォート1Gbps名乗っておいてそのスピードはおかしいだろう。壁に設置されているLANの穴の横にも「5e」と書いてあるのでカテゴリ5eで配線されていることが伺える。ところが、Macbookを壁にさして直にリンクを確認してみると、100BaseTXでリンクが上がっている。

100BaseTX？！1Gちゃうんか？！

もしやと思い納戸に設置されている上流から各部屋に分岐するスイッチを眺めてみると、犯人はこいつだった。100Mしか対応されていないスイッチが設置されていた。 ここでこの家の設計者にぶちぎれながら、上流の線を引っこ抜き、Macbookに直に刺してみると1000BaseTでリンクが上がった。 なんてこった、上流から家までは1Gできているのに各部屋までは100Mで分岐させている。 しかしそのスイッチから各部屋はカテゴリ5eで配線している。設計者は何を考えているんだ？これで「壁にさして簡単インターネット！ベストエフォート1G！」は半ば詐欺に近いのでは？

結末

ということで、むしゃくしゃしたのでCiscoのルータ(C891FJ)を購入した。頭のおかしい設計者が設置した既設のスイッチを置き換え、各部屋への配線部分もC891FJから出すことで、各部屋で1000BaseTでリンクが上がるようになった。NAT&DHCPもさせて一括管理できてめでたしめでたし、とりあえずブログにまとめるか、というのが今です。グローバルアクセスもないし、自宅サーバも今のところないのでCiscoのルータを買ったのは完全にオーバースペックだが、自宅にそういうのを置いてみたかったという欲も満たせたので結果としてよかったのかもしれない(?)

おそらくマンションISP/不動産屋さんの連携が取れていないことが原因で設計時に導入する機材選定がうまくいかなかったのだろう。とはいえ、ベストエフォート1Gと言っといてこの構成はあまりにもひどい。今回の引越しで、マンションISPの物件入居時にはよく構成を確認することを肝に命じた。引越し、もしくは家を建てるとき(?)は皆さんよく考えましょう。