大道至簡、やっぱり KISS が正しかった？

Keep It Simple, Stupid

上の一文は Linux カーネル設計の中核となる原則ですが、いま流行りのフレームワークや設計に囲まれていると、つい忘れがちです。最近、特によく関わっている DHT やブロックチェーンのプロジェクトで、いろいろな過剰設計の問題にぶつかっています。ブロックチェーンという fancy な新技術は、本当に焦点をぼかしやすい。少し前に自分もこの罠にはまったので、戒めとして新しいサイトの最初の記事に書き残しておきます。

# DHT の基盤の罠

最近 DHT のプロジェクトをやっていて、これにさんざん苦しめられたので、順を追って話させてください。

多くのブロックチェーンプロジェクトは、設計段階でそこそこ完全な DHT、つまり分散ストレージを用意します。テーブル全体が複数のユーザーで構成されていて、みんなそこを出発点に、自分たちのコンセンサスアルゴリズムを選び、ノード間のやり取りを設計しはじめます。そして、そこにこそ罠がある。なぜか？

罠というのは、みんなの設計でフォーマットが統一されていないこと。あるいは P2P のノードをどこから調達するのか、という問題だったり、基盤に書き込むデータのフォーマットがすごく新しいのにすぐ見捨てられるものだったり（特殊な protobuf とか。例として挙げただけで、狙い撃ちしているわけではないです XD）。こうした罠は、プロジェクトを立ち上げた直後にあっさり踏んでしまいがちです。

少し前に Smaller is Better ↗ という記事を読みました。あれもこれも欲しくなってしまった設計の状態を説明していて、その中の一文を引用すると「nginx チームが postgres をリリースすることなんて誰も望んでいない」。だから彼らは DHT の転送層の設計に集中して、信頼できる同期の構築に専念した。複雑な機能を盛りすぎると、かえって互換性を持たせたり組み込んだりするのが難しくなるからです。巨大な怪物も、シンプルな設計の積み重ねでできているんですよね。

これで思い出したのが、少し前に見た GitHub による Linus のインタビュー動画です。その中で Linus は、Git は CVS を置き換えるために作った解決用の Script にすぎないと言っていて、コア機能もその数週間で書き上げたそうです。何年も使ってきた統計でも、彼が主に使っているのは git blame や git log といったいくつかのコア機能だけ。sha1 の設計を使って、patch のマージに時間がかかりすぎる問題を解決するのが主目的で、コア機能全体がその問題の解決を軸に設計され、それからバージョン管理の基本機能を作り上げた。さらにその性質を生かしてローカルの git ツリーまで実現している。分散型の世界がいちばん見習うべきツールは、まさにこれだと思います。

Git の設計思想を知って、まさに目からウロコでした。これこそ、いま多くの設計者が解決すべき問題です。問題を解決できるツールの設計にだけ集中すればいい。そのツールは Script でもまったく構わない。十分に役に立つなら、すぐにみんなが使う便利な車輪になります。

# ブロックチェーンのプロジェクトはみんな車輪を再発明していて、互換性に取り組む人はいない

いまネット上では、多くの人がイーサリアム財団を叩いています。個人的には、ユーザー目線だとたしかに「イーサリアムは無能だ」と感じる方向に流れているのかなと思います。最近のアップグレード、Blob の EIP-4844 や Gas の EIP-1559 は、全体としてユーザー体験に大きな影響を与えていないと個人的には思っていて、むしろ EVM エコシステム全体の体験をより分断させてしまいました。

この話を広げる前に、そもそもイーサリアム財団はなぜこうなのかを考えてみます。個人的には、彼らが EVM コア全体の開発に重きを置いているからだと思います。なにしろブロックチェーンのヒエラルキーでは、基盤をやっている人は鼻で人を見下しながら話せる立場ですから（冗談です、コア開発者のほとんどはすごくいい人です）。その結果、アプリケーション層はイーサリアムが出たばかりの頃と比べて大して進歩していない、とみんな感じるようになった。これはけっこう悲しいことで、6〜7 年前にオンチェーンでみんなが使っていたのは UniswapV2、そしていまも同じモデルを使っている。違うのは、Swap の前につく食べ物の名前くらいです。

そしてコア開発者と関わる多くのプロジェクトは、互換性を気にせず自前のブロックチェーンを作りたがります。その結果、イーサリアムがかえってそうしたプロジェクトのための互換レイヤーを作らされる形になり、いまや名前を挙げられる DeFi プロジェクトより L2 のほうが多い、という状況になっています。

P2P のプロジェクトでもブロックチェーンのプロジェクトでも、目にするのはどんどん難しくなるアルゴリズムを次から次へと作って、イーサリアムへのブリッジを架けて ETH の流動性を吸い上げるものばかりです。半分冗談で言うと、いまイーサリアム最大のアプリケーションは、イーサリアムとそっくりな大量のブロックチェーンです。新しく出てくる DHT システムも、多くは 10 年前にみんなが歩んだ道をそのままたどっています。ICO の前に、話題性のあるブロックチェーンを急いで一本作る。いまはブロックチェーン自体がもう Fancy ではないかもしれないので、何か特殊な手法を発明して、「速い」「イーサリアム互換」と言わないといけないのかもしれません。

いろいろ書きましたが、僕はいまでもイーサリアムが大好きです。この記事は、いまのエコシステムで感じている小さな問題について書いているだけです。多くの人の設計思想は「顧客の問題を見つけて解決する」なのに、往々にして他の人がすでに落ちた穴にもう一度はまりに行ってしまう。そのせいで、似たような DHT やブロックチェーンのプロダクトが多くなりすぎました。特に、ワンクリックでチェーンを立てられた時期があって、そのせいで多くの問題がシンプルなものからとても複雑なものになり、いまに至っています。

# 複雑なものを削ってシンプルにする

では、良い設計とは何なのか。いまはみんな Git を見て「なんてすごいんだ」と感嘆しますし、Nginx や Postgre も美しく設計されたプロダクトです。それらが何をしたかに注目すると、同種の他のプロダクトと比べて、安定していてシンプルで使いやすいツールを提供した、ということです。

いま僕は DHT システムの沼にはまっていて、自分の特殊な仕様の問題を解決するための p2p システムを設計したい気持ちにどっぷり浸かっています。でも実は、ブロックチェーンはすでにとても優れた DHT の一種です。Sui や EVM のような既存のブロックチェーンに ZK を組み合わせるほうが、自前でノードを立てるモデルを一から設計するより良いんじゃないか。ユーザーの立場で言えば、絶対にそうだと思います。web3 に何より事欠かないのは複雑なプログラムで、多くのイベントではお金を払ってまで使い方を教えてくれるくらいですから。ユーザーの視点に立てば、自前のノードを立てないことは、自分の手間を省くだけでなく、ユーザーの手間も省くことになります。

まだ答えが出ていないのは、Git のようにシンプルで破壊的なイノベーションを起こす設計です。それでも、シンプルなコアはとても重要な理念だと思います。ユーザーが向き合うのが複雑なツールなら、利用者層もどんどん複雑で奇妙になっていくはずです。これを戒めとして、巨大な怪物を生み出さないようにしたいと思います。

個人的な感想をちょっと吐き出してみました。というのも、年初に DHT システムを一式作って、P2P がどこでも簡単に run できるように WASM まで持ち込んだんです。でも、複雑な type 検証、メッセージ処理、同期の問題に追い詰められて似たようなプロダクトを探したら、シンプルな webRTC で自分の作業の 9 割が片付いて、しかもかなりエレガントに処理できることがわかりました。これはかなり気まずくて、数か月の努力が水の泡になったようなものです。これも自分の成長の一環ですね！