さて突然ですが、お知らせです。カオスの坩堝は2023年1月（この記事投稿の約1年後）をもって新規の記事作成やその他の動的な機能を全て停止します。動的な機能というのは、新規記事の作成・既存記事の編集・既存記事の削除・記事への新規コメントなどで、これらが全て2023年1月をもって無効化されます。一方で既に投稿された記事を閲覧することは以前と変わらず行うことができます。URLも特に変わりません。技術が分かる人向けに言うと、WordPressで作られているページがcurlでスクレイピングした静的Webページに置き換わります。

というわけで、カオスの坩堝の著者の皆様には、2022年12月（この記事投稿の約1年後）までに次のようなことをしていただけると幸いです。

• もし、手元にカオスの坩堝で公開したい記事がある場合には、2022年12月までにその記事を投稿してください。
• もし、カオスの坩堝で公開した記事を修正・取り下げ・削除したい場合は、2022年12月までにそれを行ってください。

2017年からの長らくのご愛顧、ありがとうございました。

B1

京大は入学するとビラロードとかいうクソみたいなところを歩かされるんですが、そこをビラ 1 枚で通り抜けるなどしていました。

プログラミングの記憶はほとんど無いけど、鼻くんとかを使ってプログラムを書いていた気がします。

もしかしてカオスの坩堝はこの学年で作ったんじゃないかと思ったらやっぱりそうでしたね。もうそんなになるのか。もともとは 2017 年の AdC をやるためのブログだったんですが、いまや総記事数が 300 近いサイトになりました。

あと第二外国語でロシア語をとっていました。キリル文字が面白かったので坩堝に記事を書いたりしていました。今でもキリル文字が出てくると頑張って読もうとするけど、ロシア語自体はほとんど忘れてしまいました。

有志で蟻本を読む輪読会をしたり、Linux 講習会をやったりしていました。AtCoder で ABC/ARC とかを解いていたのも多分このころですが、解けなかった問題の解答がコンテスト後に Twitter に流れてくるのが嫌でやめました。メンタルが競プロに向いてない。

GPA ポケモンのサイトを作ったのもこのころです。

2018 年の正月には、ddの出力先を間違えてディスクを吹き飛ばしたりしていました。fsckを振り回してなんとか復旧しました。

割と A+を取れた授業が多くて GPA 4.12 とかでイキってたら、何人か友達をなくしたりしました。みんなは気をつけてください。

あと鮟鱇丼という Mastodon を立てていたのですが、サーバー操作ミスで吹き飛ばしたりしていました。

B2

5 月にセキュリティ・ミニキャンプ in 兵庫に、8 月にセキュリティキャンプ全国大会に@VTb と一緒に参加しました。全国大会の顛末は坩堝にも投稿しました（応募用紙, 開発記）。低レイヤー的なことをやったのはこれが初めてだったのですが、めちゃめちゃに楽しい経験ができました。 aqcc を書いた後に物足りなくなってAQaml というセルフホスト OCaml コンパイラを書いたりもしました。あと Kernel/VM 関西 9 回目で aqcc について発表して、ベストオブ頭おかしいをもらいました。めちゃめちゃ嬉しかったです。

この話をアカデミアのよくしらないおじさんにしたら全否定されたので、アカデミアには絶対に行かないという強い意志を持ったりしました。このあたりの話はいずれまとめて短いエッセイにしたいなぁと思っています。

ちなみにこのおじさんはこの後もちょくちょく私を惑わせています。

ミニキャンプと同時期にわくわく鮟鱇ランドという Mastodon を立てて、身内で遊び始めました。これも若干メンバーを増やしつつ現在まで続いています。ちなみにこの名前は wotto さんが考えてくれたやつです。

初めは Twitter と相補的に使っていたのですが、最近はもうほとんど Mastodon でしか活動していません。Fediverse はいいぞ。みんなも連合しよう。 Mastodon を 1 年半くらいやったときに坩堝にも記事を書きました。ちなみに B3 で本格始動する未踏のチームから参加のお誘いが来たのもこの Mastodon の DM でした。

あとニューラルネットワークの研究を書くプロジェクトに参加して論文を書いて、査読が通らなかったりしていました。

割と A+を取れた授業が多くて GPA 4.12 とかでイキってたら、何人か友達をなくしたりしました。みんなは気をつけてください。

B3

2019 年の 3 月に@VTb と@nindanaoto にいきなり準同系暗号を用いたセキュアなプロセッサ開発に誘われて、急いで応募資料を書いて未踏事業に応募したところ通ったので、B3 の間はずっとそれをやっていました。その顛末は前に坩堝にも書きました（VSP の紹介・未踏体験記）。応募資料と、終わった後の成果報告書はGitHub 上で公開したので良かったら見てください。ちなみに VSP は Virtual Secure Platform の略なんですが、もともとは P は Processor で、後から「プロセッサ以外にも作るもの死ぬほどあるやんけ」といって Platform に変えたという経緯があります。

未踏期間中は、開発をしたいのに試験があったりして、ままならない思いをしていました。

それから、大学の演習で FPGA 上でプロセッサを作るというものがあったのですが、ハードウェアはつらかったのでソフトウェアの勝負に持ち込むべくコンパイラを書いて、当時流行っていた「1000 円でサイゼリヤで最大何 kcal の食事をできるか」という問題を自作プロセッサ上で解いたりしました。これもカオスの坩堝に書いたのですが、思いのほか好評で、初めてはてブにたくさんコメントがついたりしました。あとロボ太さんに言及されたり、ハードウェア実験の主担当の先生に言及されたりもしました。めちゃめちゃ嬉しかったです。

あと世界の真相を知ったりしました。

ちなみにハードウェア実験のソート速度を競うコンテストでは@VTb がぶっちぎりで優勝していました。シングルコアの性能としては歴代トップらしい。

それから応用情報技術者試験を受けて受かったりしていました。普段は自分の好きなことしか知識を得ないので、こういう資格の勉強をすると普段なら絶対に知り得ないような内容（PMBOK とか）を知ることができました。

ISUCON 9 に出て、ボーダーで予選を通過して本戦を欠席したりしていました。これも坩堝に書きました。

VSP以外で作ったものとしては、mattnさんのlongcatコマンドが流行っていたので、それに便乗して「流れてくる音楽で伸びたり縮んだりするlongcat」を作ったりしていましたが、全然ウケませんでした。技術的にはSixelを知れて面白い経験でした。

あと A+を取れた授業が多くて GPA 4.11 とかでイキってたら、何人か友達をなくしたりしました。みんなは気をつけてください。

B4

実は 2020 年のまとめ記事を坩堝に投稿したので、新しく書くことはあんまりありません。

4 月に行われるはずの研究室配属がコロナで 1 ヶ月ずれ込んだりしていたので、その間にカラオケ Web アプリ Damjiroを書いたりしました。

GPA ポケモンがトレンドに載って、4 万 hit を叩き出していました。

USENIX Security っていう学会に VSP の論文が通ったので、ツイートしていいねを稼いだりしていました。

論文は理論的な側面が強くて、@nindanoto にめっちゃ負担をかけたので感謝です。

VSP まわりでいうと、@nindanaoto がセキュリティ・キャンプ 2020 で講師をしていたので、それをサポートするチューターをやったりしていました。その過程で都合 3 回目となる TFHE ライブラリを書いたりしました（aqTFHE3）。@nindanaoto の講義スライドに合わせて書かれていて、世界で一番分かりやすいTFHEライブラリだと自負しています。

ISUCON 10 に出て、学生枠で予選を通過して本戦で fail したりしていました。これは梅さんが坩堝に書いてくれました（予選・本戦）。このときに aquery という Go 用の SQL スロークエリアナライザを開発したり、fgprof という既存のプロファイラのバグを取ったりしていました。

B4 の後半は F*というプログラム検証用プログラミング言語を使って、ブロックチェーン用のストレージライブラリに証明をつけていました。この F*というのが曲者で、だいぶ泣いていました。

泣いた内容をまとめて技術ブログの記事にしたりしました。これは未だにちまちま更新しています。

F#という言語を触って代読 Discord ボットを作ったりしていました。これも技術ブログの方に書きました。 F#は OCaml を.NET 用に Microsoft が改造した言語で、関数型っぽい形で.NET が触れます。個人的にはオフサイドルールが OCaml の文法とこれほどマッチするとは思いもよらなくて面白かったです。 .NET 側の事情に引っ張られて若干型推論が弱いのと、フォーマッタ（fantomas）の完成度が低いのが玉にキズです。

そのあとずっとやってみたかった Erlang/OTP と Elixir を触っていました。Erlang/OTP でalqo というアルゴを遊べる Web アプリを作ったり、 Discord の代読ボットを Elixir で書き直したりしていました。 Erlang と Elixir はかなり良い言語で、アクターモデルがよくハマる Web まわりではとても楽しくプログラミングすることができました。文法としては実は Elixir よりも Erlang のほうが好みなのですが、Elixir のほうが人気があるのでライブラリが充実していて、 Elixir でプログラミングするほうが楽そうな事情が悲しいところです。あと Dialyzer という型をつけるためのツールがあるのですが、あんまり強くないのも若干残念です。

さて今年度はコロナ禍で、大学に行ったのは年度中 5 日程度しかありませんでした。ほとんどすべてのものがリモートになったわけですが、これが意外と快適で、コロナが終わってもこのままであってほしいなぁと思うくらいでした。特に、ひどいときで 1 週間に 1 回なっていた偏頭痛が、今年度に入ってからピタッと止まったのは、リモートになったおかげで睡眠時間がちゃんと確保できたからだろうなぁと本気で思っています。

あと A+を取れた授業が多くて GPA 4.11 とかでイキってたら、何人か友達をなくしたりしました。さて今の私の友達は何人でしょう。

ちなみに、B1 のときに予言したように、彼女は 4 年間できませんでした。

感想とか

書き忘れていることもたくさんありそうですが、大きなところは大体書いたかなと思います。 4 年間あっという間だった気がするのですが、こうして並べてみると意外と色々おもしろいことができたなぁという感じです。今後もこういう生活を続けて行きたいのですが、世知辛い世の中で就活なるものをしないと餓死してしまうようなので、そうも言ってられないかなと思っています。

というわけであんまり締まらないですが終わりです。ツイートを貼りまくって終わってしまいましたが、ここまで読んで頂きありがとうございました。

1 月

未踏で VSP の開発をしていた。KVSP の基幹部分である準同型暗号ゲートの評価エンジン Iyokan を 1 月 13 日あたりから書き始める。当時並行で、ユーザーインタフェースの kvsp コマンドも作っていた。いまの KVSP のベースは、おおよそこのあたりで形作られていく。 @nindanaoto が TFHEpp を書いたのも正月三が日だったはず。

締切が近づくにつれ VSP チームに険悪なムードが漂い始めるが、全員で Factorio マルチプレイを n 時間やり、ギリギリのところで均衡を保っていた。

あと大学の試験勉強とかしてた気がする。覚えてない。

2 月

引き続き VSP を開発した。未踏の発表会が 2 月中旬にあって、この直前にバグが見つかって直したりした。発表会が終わった後も未踏の作業期間が続いていて、Iyokan とか kvsp の改善をやっていた。カーネル/VM 探検隊@関西 10 回目で発表したのもこのころ。

2 月末から 3 月頭にかけて大学で試験があったはず。このあとコロナ禍に突入していくため、試験日を最後に大学に来なくなる。

3 月

東京に VSP の紹介発表をしに行ったりしていた。多分これが最後の東京旅行。次に行けるのはいつになるのか。

2 月末から 3 月頭にかけて未踏の成果報告書を書いたりした。全文をGitHub で公開した。未踏期間は 3 月中旬で終わった。

3 月末に VSP チームで温泉旅行の予定だったが、大阪で外出自粛令的なやつが出たので中止。結局今まで行けていない。

3 月 29 日にカオスの坩堝で2020 年春季投稿大会をやった。

4 月

大学が、4 月の講義計画を 3 月末になって白紙に戻したため、めちゃめちゃに暇になった。暇に任せて採点機能付きカラオケ Web アプリ Damjiroを作ったりしていた。

なんだかんだあって研究室配属が第一希望に決まったりした。

5 月

研究室での活動がリモートで始まった。研究会やら輪読やらは全部 Zoom 経由になった。昨年と比べて、朝早く起きる必要がないのでめちゃめちゃに楽になった。昨年までは偏頭痛に悩まされていて、ひどいときには一週間に一回死んでいたが、今年はよく眠れたおかげか、ついに一度もならなかった。

院試で必要な TOEIC がコロナ禍で中止になったりした。最終的には、今年の院試では TOEIC の結果が不要になった。

4 月終わりから 5 月にかけて、VSP を論文にまとめるため動き始めた。動き始めたといってもメインで書いていたのは@nindanaoto で、私は追加で実験をやったり、@nindanaoto の無茶振り機能追加要求に対応したり、 @VTb をせっついて新しいプロセッサを書かせたり、それを KVSP に取り込んでもう一度実験をしたりしていた。未踏期間が終わるとコードを書いてもお金が出ないんだなぁということを認識したりした。

6 月〜7 月

論文を書き上げて USENIX Security に提出した。書くべき英語が全然分からなくて、先生にめちゃめちゃにお世話になるなどしていた。

あとは院試勉強というのをしていた。始めの方は気楽にやっていたが途中から余裕がなくなってきて大変だった。とくにコードを書く時間がなくなってきた。実際 GitHub の contributions のところを見ると、6 月から 7 月にかけてぽっかり空いている。 OS の勉強をすると OS を書きたくなってくるのでつらかった。

8 月

院試を受けるために大学に 2 日行った。実に半年ぶりの大学だった。寒かった京都は暑くなっていた。ちなみにネタバレすると、院試後に次に大学に行くのは 12 月末に一度だけなので、今年度は結局 3 日しか大学に行っていない。

研究室で、OCaml でなにか書かないといけないというタスクがあったので、定理検証器 Qlown を書いた。依存型ベースの、Coq の弱いバージョンみたいなものができた。一応n + m = m + n程度は証明できる。もともと Qiita の記事を参考に書き始めたのだが、雰囲気で拡張したら簡約が良くわからなくなってそのまま放置することになった。

9 月

ISUCON10 に出て、予選を学生枠で突破し、本選で fail（失格）した。どちらもチームリーダーの梅さんが坩堝で記事を書いてくれた（予選、本選）。今年は本当に何もできなくて、メンバーの他二人に終始助けられた。Web は難しい。

VSP 論文の rebuttal が 9 月頭くらいにあって、なんやかんやあって minor revision になって、諸々を修正して accept された。

あと卒業研究が本格的に始まって、F*というプログラム検証用の関数型プログラミング言語をつつきはじめた。

10 月

コロナの流行が若干落ち着いていたので、VSP チームでモツ鍋を食べに行った。その折に@nindanaoto から誕生日プレゼントで Let’s Split というキーボードを貰ったが、ファームウェアの焼付がまずいか何かで片手だけキーの位置が反転していた。直し方がよく分からず、そのまま倉庫に眠っている。

セキュリティキャンプに L トラックチューターとして参加した。講師は@nindanaoto で、チューターは私と@VTb で、TFHE を教えるという内容だった。今年のセキュリティキャンプはリモートな上に 10 月から 12 月まであるという長期戦で、本当にこれで大丈夫かと思っていたが、最終的には結構うまくいったんじゃないかと思う。

11 月〜12 月

F*に苦しめられていた。なかなか思い通りの証明が書けずに苦労している様子がわくわく鮟鱇ランドの#fstarハッシュタグで確認できる。最近ようやく理解してきた。

まとめ

良いお年を。

あんた誰

GPAポケモン算出Webアプリの開発者。 Twitter: @ushitora_anqou

GPAポケモンってなに

2017年ごろ（あるいはそれ以前）から京大ツイッタラーの一部界隈で流行っていた、自分のGPA（Grade Point Average）を100倍した番号を持つポケモンの画像をツイートする遊びで、もともとWebアプリは関係ない。

ちなみにGPAポケモンという遊び自体は京大以外でも見られるものだが、その形態は様々で一貫していないようだ。

GPAポケモン算出Webアプリってなに

京大の成績表を貼り付けるとGPA及びGPAポケモンを自動的に計算してくれるWebアプリで、私が2018年に開発した。当然京大に関して非公式である。算出したGPAポケモンをTwitterにツイートできるようになっていて、ツイートにはデフォルトで「#GPAポケモン」のハッシュタグが付与される。

内部の処理は全てクライアントサイドで完結するようになっている（アクセスカウンタを除く）ため、貼り付けた成績情報が第三者に渡ることはない。ソースコードはMITライセンスのもとで GitHub上で公開されている。

なお余談だが、開発者（私）に開発意欲が既に無いため、Issueを立てても改善される見込みが無いことがよく知られている【要出典】。プルリクを送ってもらえれば取り込むかも。

Twitterトレンド

Webアプリを公開した当初はそれほど流行らなかったが徐々に普及し、 2020年2月17日に初めてTwitterトレンドに「GPAポケモン」が載った。また2020年8月25日にも再度Twitterトレンドに浮上した。なお2月のときにはおよそ2万アクセス、 8月のときにはおよそ4万6千アクセスを記録した。

まとめ

みんなが自分のサービス使ってくれるの嬉しすぎてハッシュタグがついたツイートにいいねしまくっていますが気にしないでください。

この記事を読むにあたって：私は弁護士ではありません。これは法的アドバイスではありません。私は法律に関する特別な知識を何ら持ち合わせていません。私はZen言語を批判するつもりも全くありません。私は、単に自分が読んだことのある文献に齟齬を発見したために、その疑問をまとめようとしてこの記事を書いています。

connectFree社が開発しているZenという言語がある。 C言語の代替を目指している言語で、安全な組み込み用のコードが書きやすいという特長を持つ。

以前から、この言語のライセンスが気になっていた。というのも、2019年10月1日の記事には次のようにある：

個人やOSS開発においては、OSSライセンスを利用することができます。 ライセンスはAGPLv3であり、このライセンスのZenコンパイラを利用してコンパイルしたプログラムのソースコードにも、AGPLv3のライセンスが適用されます。（強調ママ）

また、2020年8月20日に公開された記事にも次のようにある：

Q. Zen 言語用のソースコードを公開したり、第三者に渡したりすることはできますか。

はい、Zen 言語用のソースコードであれば CF-RSL の範囲で公開や受渡しが可能です。（中略）ご自身で作成されたソースコード に CF-RSL と衝突しない任意のライセンス (GPLのような、リンクしたもの含めてソースコードの再配布条項があるライセンスは 「CF-RSLと衝突しない任意のライセンス」に含まれません) を設定した上で公開することは可能です。 また、CF-RSL に同意した他の Zen 言語利用者が、 そのソースコードを自分でコンパイルし自分の環境で実行することも可能です。

コンパイルする前のプログラムのソースコードに制限を掛けることは果たして可能なのだろうか。ソースコードそれ自体はそのコードを書いたプログラマの著作物である。どのように扱おうとプログラマの勝手だ、という考え方もできる。

実際、GNUのGPLを解説するページには次のようにある：

人々がわたしのプログラムを利用して得た出力結果にGPLを適用する方法はないでしょうか? たとえば、わたしのプログラムがハードウェアの設計に使われているとして、その設計図も自由でなければならないと要求することはできるでしょうか? (#GPLOutput)

一般的に言って、それは法的に不可能です。著作権法は人々があなたのプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。ユーザがあなたのプログラムを使ってその人自身のデータを入力ないし変換した場合、出力結果の著作権はその人に属すのであって、あなたにではありません。もっと一般的に言えば、あるプログラムが入力を他の形式に変換する場合、出力結果の著作権の状態は、生成の元となった入力のそれを継承するのです。

これを見る限り、Zen言語のライセンスは「法的に不可能」であるように見える、というのが私の疑問である。

ちょっと手間がかかってもいい人は、YouTubeのカラオケ風動画を持ってきて、Damjiroの画面の下半分でMIDIファイルと組み合わせると、カラオケ風動画を見ながら歌えます。MIDIファイルを直接再生するよりもこっちのほうが音が（大抵）いいです。詳しいやりかたはGitHubのREADMEに書いてあります。

実装はJavaScriptでReactやらReduxやらMaterial UIやらを使っています。遊んでると不満点がたくさん出てくると思うので、そういうときは修正のコードを書いてGitHubからPull Requestを送ってもらえると助かります。コメントは日本語でも英語でもいいです。家で暇しててコードが書きたいという奇特な人はTODOリストを見てもらえると良いかもしれません。

以上です。お相手は、一日中PCの前に座っている生活に慣れてしまっていて、それほど生活スタイルが変わっていない鮟鱇でした。

登場人物

• @nimdanaoto
  • プロジェクトのリーダーで、言い出しっぺ。主に暗号理論や準同型暗号ライブラリの開発を担当。
• @VTb
  • プロジェクトのメンバーで、言い出しっぺに最初に乗っかったやつ。主にプロセッサの実装と準同型暗号論理ゲート評価エンジンの実装を担当。
• @ushitora_anqou
  • 筆者

はじまり

2月某日に @VTb からこんなDMが届きました。

@VTb「未踏で2人共同で出そうとしてるですけど、鮟鱇さんも興味ありませんか？テーマとしては準同型暗号上で動くセキュアなプロセッサエミュレーションです。」
@ushitora_anqou「とっても興味がありますが、それは私が噛んでも大丈夫なものですか？」
@VTb「今回のセキュアプロセッサを開発するに当たり、コンパイラや類するツールチェインの開発をする可能性があるので助けていただけると嬉しいです。あと、単純に強い人手がほしいのと、なんか楽しそうだからです」

「『なんか楽しそう』かぁ〜〜！　そっかぁ〜〜！」と嬉しく思った記憶があります。能力をあてにされるよりも性格をあてにされるほうが嬉しいですよね。

このDMのあとオフラインで打ち合わせをしてその中身を把握し、正式にプロジェクトに参加することになりました。ちなみにこの時点で未踏の申込締切まで1週間程度しか無かったので急ピッチで申し込み書類などを書き上げて提出しました。その際の資料はここで公開しています。

無事に書類審査が通った後に二次審査（PMの前でプロジェクトについて話す）を受け、なんとか採択されることになりました。ここは特に面白いことが無かったので割愛。

LLVMバックエンドを書く

今回のプロジェクトの前半では、私はひたすらLLVMバックエンドを書いていました。LLVMバックエンドというのは、まぁ大雑把に言ってしまえばLLVM coreのコード生成を司っている部分で、抽象構文木（AST）からアセンブリを吐き出す部分を担当しています。このプロジェクトでは命令サイズを小さくする必要が有ったために、独自のISAを計3個も作成しました。この各ISA上でC言語を動かすために、LLVMを利用してCコンパイラを3回作成したわけです。

これがなかなかやっかいで、まずろくに資料がありません。LLVMのサイトを見れば “Writing an LLVM Backend” というドンピシャな文章があるように見えるんですが、これを読んでもバックエンドは書けません。というのも、チュートリアルのような書き方をされてはいないため、LLVM coreを何も知らない状況では読み解くのが難しく、全体として「分かっている人」を対象にしているような印象を受けました。他の資料としては、有名な「きつねさんでもわかるLLVM」にもLLVMバックエンドに関する記述がありますが、こちらも若干情報が古く、またLLVMバックエンドとしては限定された機能しか実装されていません。

最終的に一番参考にしたのはRISC-V用のLLVMバックエンド（とそれに関する資料）でした。RISC-Vバックエンド開発は（おそらく他のバックエンド開発を支援するという目的から）その開発資料を多く公開しています。例えばRISC-Vバックエンドを追加するイテレーティブなコードの編集をパッチの形式で公開しているほか、初めの方のパッチについてはドキュメントまで整備されています。

というわけで基本的な開発はRISC-Vバックエンドのパッチをひとつひとつ自分たちのISAに移植していく作業となりました。単純にコピペして名前を置換するだけですめば楽で良かったのですが、RISC-Vとは異なる部分も多かったため、そうもいかず大変でした。例えば条件分岐の際に直前の命令の演算結果を見て分岐するような命令（CMP＋Jcc）を実装する際には、否応なくx86バックエンドを参考する必要があるわけですが、その規模の大きさと読みにくさに大変苦戦しました。

ただまぁ、いま振り返って見れば、かなり順調に進んだなぁという印象です。結局最後まで「コンパイラのせいで○○ができなかった」ということはありませんでした。

Iyokanの開発

1月くらいからは準同型暗号ゲートを実際に実行して結果を得るためのエンジンを書いていました。もともとは @VTb がIyokan-L2という名前で書いていたものを実装のアイデアだけはそのままにフルスクラッチし、より機能を追加したバージョンを作成しました。これを使うことで論理回路を、その論理ゲートを対応する準同型暗号のゲートに置き換えて実行することができ、それはつまり「暗号化された入力を暗号化されたまま実行して暗号化された結果を得る」というVSPの根幹のアイデアを可能にしています。

Iyokanが内部で実行している準同型暗号のゲートは、実際には外部のライブラリに処理を移譲しています。具体的には、CPUのみを用いて実行するときはTFHEpp、GPUも使用できる場合はcuFHEというライブラリを使用します。この二つのライブラリを透過的に、つまりIyokanのユーザーからは同じ操作感で使用できるように気を配りました。cuFHEにはなくTFHEppのみにある機能なども現時点では存在するため、cuFHEで処理したほうが速い場所はcuFHEで処理し、そうでない箇所は適宜cuFHE用のデータをTFHEpp用に変換した上でTFHEppに流し込む、といった機構も実装しました。

ところで現状のIyokanを、例えば手元にあるGPUのNVIDIA GTX 1660Tiなどで動作させると、テストに落ちます。面白いことに、NVIDIA V100という数値演算用のGPUで動作させるとテストは正常に終了します。もちろんIyokanの実装が何かしら間違っているということも大いに考えられるのですが、一方で数値演算用のGPUでないと計算誤りが発生するのではないかとも考えられます。このような特徴は、計算誤りにロバストな深層学習などではそれほど大きな問題になりませんが、暗号の演算では致命的です。普段このようなことが問題になる場所に出くわしたことが無かったため、この経験は新鮮でした。

小規模チーム開発

今回のプロジェクトで面白かったのは、メンバー各々がほか二人の作業内容を肩代わりできないことでした。例えば私はコンパイラ担当だったわけですが、他の二人はコンパイラの中身について詳細を知りません。同様に私は @VTb が作ったプロセッサの中身についてほとんど知らず、また @nimdanaoto が担当した暗号理論について私と @VTb はほとんど知りません。各々が自分の担当部分の仕事を完璧にこなし、各々の部分の結合に用いるインタフェース（ISAやライブラリAPIや論理回路のポート名）だけを統一していました。良く言えば疎結合で無駄がなく、悪く言えばバス係数がほぼ1で、誰かが倒れると後がありませんでした。

また開発方針が食い違うことも多く、Slackはよく殺伐としていました。議論で埒が明かないときにコードを叩きつける、という展開も何度かありました。お互いがお互いを尊敬しつつも、おかしいと思うことはズバズバ言うというスタンスで、最終的に成果が出たから良いものの、出ていなければ途中で空中分解してもおかしくない危うさがありました。ただこの雰囲気のおかげで良いものが作れたという自負も多少あります。

雑感

あんまりおもしろくない体験記になってしまいました。未踏期間、山あり谷ありだった気もするのですが、喉元すぎればなんとやらであんまり覚えていません。こんなことならaqccのときみたいに日記をつけておくんだったなぁと反省しています。ちなみに技術ログはつけてあるので、そのうち「自作ISAのためのLLVMバックエンドを書く薄い本」を出せればいいなぁと思ってリポジトリだけ作ってあります。

8ヶ月間かけて、自分は実装の人間なんだなぁというのを再認識した気がしています。手を動かすのがすきと言ってもいいかもしれません。理論を組み立てるよりも、それをどうコードに起こすかを考えるほうが好きみたいです。まぁ理論・実装ときれいに分けられるわけではないので結局両方をやる必要があるわけですが、そういう意味で今回のプロジェクトは @nimdanaoto に理論部分を全て投げられたので非常に楽でした。

あと未踏コミュニティについて多少Twitterなどで議論があるみたいですが、任意のコミュニティは閉鎖的になりがちというか、独自の文化を持つものなんじゃないかなぁと第三者的に考えています。真面目に考えていないのでこれ以上書きません。

最後に、VSPを担当していただいた首藤PMと、諸々のサポートをしていただいた未踏事務局の方々には大変お世話になりました。成果報告会のときには身内の謝辞を入れられなかったので、この場を借りて感謝申し上げます。ありがとうございました。

さて2020年春季投稿大会を下記の日程で実施します。著者の方々におかれましては、ぜひ参加して頂けると幸いです。

• 3月29日（日）00:00〜23:59
• フリートピック

なお以前にも書きましたように、新規著者は随時募集中です。参加したい方は、鮟鱇にカレーでもおごって面識をつくってから、Twitterなどでご連絡ください。

投稿大会ってなんだ

著者陣が記事を投稿して楽しむ大会。ちょっとしたお祭りです。普段はあんまり投稿しない人も含め、できれば全著者による記事投稿が見られたら良いなぁと思っています。もちろん私も何か書きます。

質問などありましたらコメント欄にどうぞ。

「クラウド」という言葉が市民権を獲得して久しくなりました。 一口に「クラウド」と言っても様々ですが、その多くは「他者に処理を移譲する仕組み」と 簡潔にまとめられます。例えば、GPUを使う機械学習のプログラムを書いたが手元にはGPUが無い。 そこでGPUが搭載されたクラウド上のマシンを 借りて代わりに実行してもらう、といったケースが分かりやすいでしょう。

（画像は全てクリックで拡大します）

このとき、処理を実行するにあたって必要なプログラムとデータは、 もちろんクラウドに送信する必要があります。しかし、もしこのプログラムやデータを秘匿したいと すればどうでしょうか。そうやすやすとクラウド上に置くことはできません。 「クラウド」というふわっとした言葉ですが、 その実体は地球上のどこかに設置されたコンピュータです。そのマシンの在り処を知っている クラウドの管理者であれば、そのマシンに直接接続して情報を抜き出すことが可能です。 あるいは、そのマシンを構成している機器自体に脆弱性があり、外部の人間がデータを盗聴することを 許してしまうかもしれません。 このように、自分の管理下にないマシンでは「ハードウェアが脆弱であることによる情報の漏洩」が 起こりえます。ハードウェアを信用している限り、この問題は常につきまといます。

この問題を解決するためには「ハードウェアを信用せずにプログラムを実行する」必要があります。 これはつまり「プログラムが実行される際にハードウェア中を流れる電気信号を 読み取ったとしても、実行されている内容が分かることはない」ということです。 このような動作を可能にする一つの手段は、ハードウェア中を流れる信号をすべて暗号化して しまうことです。しかしプログラム自体も電気信号ですから、これはすなわち 「プログラムを暗号化したまま実行し、暗号化された結果を取得する」ということを意味します。 しかし、「プログラムを暗号化したまま実行する」などということは可能なのでしょうか。

これを可能にするのが「準同型暗号」と呼ばれる特殊な暗号です。 準同型暗号を使用すると次の図のような演算が可能になります。すなわち、暗号化した値を〈足し算〉した上で復号化すると、 暗号化する前の値を直接足し算した結果と一致します。同様に〈掛け算〉も行うことができます。

ここで、暗号化した値同士の演算を〈足し算〉・〈掛け算〉と山括弧付きで表記しました。 実は、この〈足し算〉・〈掛け算〉の処理は暗号化していない数値の加算・乗算とは全く異なる操作で、 処理には大変時間がかかります。このことは後ほど詳述します。

さてこの準同型暗号がどのようにプログラムの実行と関係するのでしょうか。 すぐに思いつくことは「プログラム中の演算を準同型暗号の演算に変換すれば、 暗号化したままプログラムを実行できる」というものです。 すなわちプログラム中での数値の足し算を準同型暗号の〈足し算〉に、 掛け算を〈掛け算〉に変換すれば、準同型暗号上でそのままプログラムを実行できるように思えます。 しかしこの手法には重大な欠点があります。現在発見されている準同型暗号で行うことができる演算にはいくらか制限があり、特に「場合分け」をそのまま処理できるような準同型暗号はまだ見つかっていません。というのも場合分けは通常「値が1のときは足し算、2のときは掛け算……」といったふうに値に依存して何を行うか決める必要がありますが、暗号上でこれを行うことはとりもなおさず値を復号化することにつながってしまうからです。

この問題を解決するためには、準同型暗号についてもう少し知る必要があります。ここまで「準同型暗号」という言葉を使いまるで1つの暗号かのように扱ってきましたが、実は準同型暗号には様々な種類があり、扱うことができる演算も各々異なります。その中に論理演算を扱うことができる準同型暗号があります。論理演算というのはいわゆる電気回路を構成する演算でXORやANDといった種類があります。すなわち先程の〈足し算〉や〈掛け算〉のように〈XOR〉や〈AND〉を計算できる暗号というわけです。

さて、通常プログラム（をコンパイルして得た機械語）はプロセッサ（CPU）という大きな論理回路の上で実行されます。 大きい、とはいっても論理回路ですから、論理演算によって構成されることに変わりはありません。 そこでプロセッサ自体を準同型暗号上に構築し、その上でプログラムを実行することで「プログラムを暗号化したまま実行する」ことが可能になります。

上記の構成を概念的に表すと上図のようになります。まずこのシステム自体は通常のCPU上で動作しています（下から1段目）。そのCPU上で〈XOR〉や〈AND〉といった準同型暗号の計算を行います（2段目）。その計算によって、プロセッサの論理回路が準同型暗号上で構築されます（3段目）。このプロセッサは暗号化したプログラムを受け取り、その内容を暗号化したまま実行します（4段目）。

完璧に思える準同型暗号ですが、一つ大きな欠点があります。 それはとてつもなく処理が遅いということです。現在知られている最速の実装でも、 1つの論理演算を評価するのに約0.13ミリ秒（＝13万ナノ秒）かかります。 電気回路で使用する論理ゲートの出力は通常数ナノ秒で行われますから、 およそ10万倍遅いというわけです。

技術的な制約による速度低下も考慮し、 我々は目標とするプロセッサの動作周波数を60Hzとしました。60MHzでも60KHzでもありません。 今私がこの記事を書いているPCにはIntel Core i7-8700が搭載されており 動作周波数は4.6GHzとのことなので、およそ10億倍の差があることになります。 黎明期のコンピュータで1940年ごろに開発された ABC（アタナソフ&ベリー・コンピュータ） の基本動作周波数が60Hzとのことなので、いい勝負かもしれません。

しかし準同型暗号上で動くプロセッサの開発は他にほとんど例がなく、 まさに黎明期と言っていい状態です。我々のプロジェクトではこのアイデアの概念証明（PoC）を行うことを 主目的とし、速度に関しては今後の暗号学の発展に期待したいと考えています。

デモと成果報告会について

2019年度未踏事業における上記のような我々の取り組みは既にある程度成功しており、実際に動作するデモを GitHub上で公開しています（Linux環境等必須）。その利便性や速度の点において課題は山積していますが、残りの未踏期間（及びその後の活動）にて解決できればと考えています。

未踏事業における最終的な成果は、2020年2月に実施される「2019年度（第26回）未踏IT人材発掘・育成事業成果報告会」にて発表予定です。例年YouTubeでのライブ配信が行われるため、ぜひご視聴ください。

参考文献

• TFHE
• Cingulata
• brainfreeze

ISUCON9に参加したので、大会前と大会中と大会後に何やったかを書く。

開催前

@_nemohemと@fplwdが ISUCON9のメンバーを募集していたので「入れて入れて〜」と言って入れてもらう。まともなWebサービスの運営はほぼ経験が無いが、「知識を得ることが目的」とのことだったので、気軽に参加した。

気軽に参加したあと、本戦の開催日にはすでに予定があるので参加できないことがわかり、土下座するなどした。大変申し訳ありませんでした。

Golangを選択するということが予め決まったので“A Tour of Go”を流し読みするなどする。それから、前から気になっていた「みんなのGo言語」の第二版が出ていたので買ってベンチマークのところを読み、そこに書いてあった Profiling Go Programsを読んでpprofを知った。

あと開催の少し前に集まって練習する予定が、偏頭痛でドタキャンして土下座するなどした。その節は大変申し訳ありませんでした。二人のご厚意で、本番2日前にも集まることが出来たので顔合わせをしつつGolangの過去問を解いたりした。その時の感じから、@fplwdがインフラ、 @_nemohemと筆者がGolangアプリという担当に決定した。

開始直前

行きの電車の中で、複数台構成のためのNginxの設定を調べる。 upstream と proxy_pass を使ってよしなにすればいいらしい。ふーん。とりあえず知識だけ仕入れて現場に入る。

10:00 開始

開始。@_nemohemに鯖を立ててもらっている間にマニュアルを読む。ちんたら読みつつ /initialize のレスポンスに謎の Campaign キーが生えていることだけを把握する。このあたりで鯖が立ったので「負荷は自分で決めるらしいよー」「まじー？」という会話をしつつSSHする。 ls に色がついていなかったためキレつつ alias を設定するなどしていた。

今回は初めに動いている言語がGolangだったので、そのままベンチを回す。 2千数百点付いた気がする。過去のISUCONではGolang版は0点スタートというのも珍しくなかったので、わりと取り組みやすいのかなぁなどと考えながらとりあえずコードをgitに載せGitHubのプライベートレポジトリにつっこむ。ついでにpprofも仕込んでプロファイルをとる。 getNewCategoryItems が遅いっぽいのでコードを眺めるとN+1になっているっぽい。解消するためにSQLをゴニョゴニョし始める。

11:00 getNewCategoryItems のN+1を解消

とりあえずitemとuserとcategoryを INNER JOIN すればええやろとばかりにSQLを書き始めるが、 sqlx を知らなかったため、解読とコーディングに時間がかかった。ついでにcategoryは親カテゴリー名を取得するために再帰的なコードが書かれており、 SQLに落とせない。最終的にsqlxをsqlっぽく使う初心者丸出しコードで itemとuserのinner joinだけを書き上げ、投入してベンチを走らせるがSQLが間違っている。ぐだぐだのまま12時台へ。

12:00 N+1の解決と500エラー

結局1時間以上使ってなんとか動かしたが、謎の500エラーが /buy と /sell に出て思ったよりもスコアが伸びない。負荷が足りないのかと Campaign を 1 にセットするがやっぱり伸びない。ついでにToo many connectionsのエラーが出たので@fplwdに対応してもらうなどした。

あとから聞いた話によると、DBのロックのかけかたがまずくデッドロックが起こっていたらしい（？）。結局これには最後まで気づかなかった。

何度かベンチを走らせても伸びないので、諦めてご飯を食べに行く。店に入るほどの余裕はなかったのでローソンで冷やし中華を買って食べた。麺がゴムっぽかったが、お腹も減っていたのでまあまあ美味しかった。タレで味がついていれば大抵の物は食えるんだなぁ。みつを。

13:00 カテゴリをメモリに乗せる

getNewCategoryItems のN+1を解決するためにはcategoryをよしなにしなければいけない。メンバーがcategoryテーブルに変更が加わらない（初期データの呼出しのみ）ことを見つけてくれたので、DBを叩いてcategoryテーブルの中身をダンプし、「categoryのidを与えると必要な情報を出してくれる関数のGolangコード」を出力するスクリプトをRubyで書く。これを使ってようやくN+1を解決した。長かった……。

14:00 遅いbcryptと6000点

このあたりでbcryptがアホ遅いことに気づく。以前Railsのチュートリアルをやったときに「動作時間で情報がもれないように、ハッシュ化されたパスワードの比較はどんな場合でも一定時間で終わるようになっている（≒わざと遅くなっている）」と読んだことを思い出し、これを通常の等号比較で行えないか検討する。しかし「ユーザにしてほしくないことは行いにくくする」というライブラリ作成の原則が bcryptに一貫されていて、脆弱性を仕込むことはできないようになっていた。仕方がないので「この部分は仕方がないんじゃなーい？」などと言いつつ諦める。

ちなみにレギュレーション上は「平分のままDBに保存しないこと」のみが規定されていたため、例えばbcryptのcostを下げるなどすれば対応可能だったようだ。残念。

さてpprofを見ると getUseSimpleID が重いらしいので SELECT 時に取ってくるカラムの数を減らす。またcategoryを全部取ってくる SELECT が遅いらしいので、またまたDBをダンプして関数に変換したりなどした。ベンチをとると、このあたりで6000点を越えた。

わくわくしつつnginxのキャッシュやらgz圧縮などを設定すると 3000点に落ちたり5000点に浮上したりと安定しない。仕方がないのでキャッシュとgz圧縮はなくして、複数台構成にシフトすることで点数を稼ぐことにした。

15:00 複数台でバグる

ベンチがアクセスしてくるサーバ（フロントエンド）で静的ファイルを配信し、 Golangが動く必要がある場合はバックエンド1台目に投げ、さらにDBを動かす必要があればバックエンド2台目に投げる構成に決定する。さっそくNginxを設定するが、そもそもNginxで複数台構成を（練習を含め）経験した人間がチームに一人もいないことに気づく。Golang側のボトルネックがほとんど解消していると感じていたこともあり、朝に upstream を知った筆者が設定することになる。

フロントエンドとバックエンド1台目はわりとすぐに動いてくれたが、バックエンド2台目の設定で詰まる。バックエンド2台目で動いているリバースプロキシ用の NginxとMySQL間の通信がうまくいかない。3人で頭を突き合わせてあーでもないこーでもないと言っているうちに1時間経過する。

16:00 複数台で動く

MySQLはunix domain socketで接続を待ち受けるらしい。知らなかったよね。これに気づいてからは早かった。ベンチを回すと6000点か7000点くらい出た気がする。やったぜ。

top を見るとバックエンド1台目がCPUを使い切ってることが分かったので、フロントエンドにも処理を肩代わりしてもらうことにする。これは upstream に 127.0.0.1 を追加するだけではだめで、フロントエンドとバックエンド1台目のどちらかにアップロードされる画像ファイルに、これらの両方からアクセスできるようにする必要がある。 ISUCON7のfujiwara組が同様の問題を upload/01/ と upload/02/ に画像を振り分けた上で Nginxでスイッチすることで解消していたのでこれを真似る。fujiwara組の nginx.conf は公開されていなかったのだけど、Google検索し続けたらどうにかなった。

「残り30分でも動かなかったら単一構成に戻す」などと言っていたのが杞憂に終わってよかった。

17:00 ラストスパート

残り時間が1時間を切ったのでランキングが見えなくなった。このあたりでベンチを回して9000点台が出た。うれし〜〜。

初めの方に有効化してバグったキャッシュとかgz圧縮とかを復活させる？という話をしていたが、下手にいじって壊すのが怖い。結局ここで最適化は打ち止めにして、ログの出力やプロファイルのコードを消してベンチを回し続けることにした。なぜかベンチが二回に一回failするのでドキドキしながらベンチを回していた。ついでに再起動試験をし忘れていたことに気づいたので慌ててやった。

最終的に17:45に9670点が出て、ここで打ち切りにした。 17:50あたりからポータルサイトが不安定になっていたので、「ここで止めて正解やったなぁ」などと話しながら、夕飯の場所を決めた。

終了後

無事終了。公式が立てた感想戦のDiscordを眺めながら「デッドロックとか起こってたんかへー」「非同期APIはさっさと返してええんやなへー」「bcryptはやっぱり手を入れるべきやったんかへー」などと喋っていた。ついでにボーダー予想もしつつ「ボーダーは1万2千点くらいかなぁ」「いやもうちょっと高くて1万5千点くらいじゃないー？」などと喋っていた。

適当なところで切り上げてモダン焼きを食べに行った。美味しかった。

食べている途中で結果が発表された。残念ながら予選敗退だったが、ボーダーが意外と低くて 1万点くらいだったので「非同期APIに気づいてればなー」「デッドロックに気づいてればなー」「bcryptに手を入れてればなー」などとほざいていた。

今

ISUCON9 オンライン予選 全てのチームのスコア（参考値）が発表され、予選をボーダーで通過したチームのすぐ下に点差210点で自分のチームが付けていたことを知り泣いています。

感想、あるいは来年への備忘録

始まる前に思っていたよりもいいところにつけた（全参加者の上位5.1%）ので個人的には満足した。Webアプリについて実戦経験が無くても、意外と付け焼き刃でできることはいろいろあるのだなぁと実感した。

Golang側の改善がほとんどpprof一本槍だったので、もう少しいろいろなツールを利用すればデッドロックに気づけたのかなぁと思ったり思わなかったり。あとNginxの知識とかDBの知識とか、諸々のWeb周りの知識が欠けているというのも実感としてあるので、どうにかしていきたいですね（ふんわりとした問題意識）。

大変楽しかったので、できれば来年も出たいなぁと思いつつ。

お疲れ様でした。