大道至簡：エンジニアリングにおける 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 に代わるスクリプトとして設計しただけで、コア機能は数週間で書き上げられました。長年の統計によると、彼は git blame や git log といったコア機能のほとんどしか使用していません。主に sha1 の設計を利用して、パッチマージの長年の問題を解決しました。コア機能はすべてこの問題の解決設計を中心に展開され、次にバージョン管理の基本的な機能をすべて設計しました。さらには、その先天的な特性を利用してローカルの Git ツリーを実現しました。彼は、現在分散型で最も称賛されるべきツールだと思います。

Git の設計思想を読んだとき、それはまさに目から鱗でした。これが、現在の多くの設計者が解決すべき問題です。実際には、問題を解決できるツールを設計することに集中すれば良いのです。そのツールがスクリプトであっても問題ありません。それが十分に有用であれば、すぐに有用な車輪となるでしょう。

# ブロックチェーンプロジェクトは皆、車輪を造っていて、プロジェクトの互換性を気にしない

現在、インターネット上ではイーサリアム財団を非難する声が多く聞かれます。個人的には、この風潮は確かにユーザーから見ればイーサリアムが無能だと感じるかもしれません。なぜなら、最近のアップグレードである Blob の EIP-4844 や Gas の EIP-1559 は、全体としてユーザー体験に大きな影響を与えなかったどころか、EVM エコシステム全体の体験をさらに分断させてしまったからです。

この問題に入る前に、イーサリアム財団はなぜこのようなことをしているのか考えてみましょう。個人的には、彼らは EVM コア全体の開発に重点を置いているからだと思います。ブロックチェーンの鄙視連鎖においては、基盤を開発する者は鼻で人を相手に話すことができます（冗談ですが、ほとんどのコア開発者は非常に素晴らしいです）。そのため、アプリケーション層はイーサリアムが最初に登場した頃と比べてあまり進歩していないという現状に陥ってしまい、これは非常に悲しいことです。6〜7年前、我々がチェーン上で使っていたのは UniswapV2 であり、今も同じモデルを使っています。ただ、前のものが異なる食べ物や、何かの Swap であるというだけかもしれません。

そして、コア開発者に触れる機会の多いプロジェクトの多くは、独自のブロックチェーンを構築したがっており、互換性を重視していません。これらの結果、イーサリアムはむしろこれらのプロジェクトの互換性開発を助けることになり、現在 L2 でより注目される DeFi プロジェクトが多く存在する状況になっています。

P2P プロジェクトもブロックチェーンプロジェクトも、私が目にするのは、ますます複雑なアルゴリズムを構築し、クロスチェーンブリッジを設置してイーサリアムから流動性を吸い取ろうとしていることです。そして、口先だけで、イーサリアムの最大の応用は、それと全く同じように見えるブロックチェーンの山であり、新しく登場する DHT システムも、ほとんどが10年前に皆が歩んだ道をたどっています。ICO の前に、話題性のあるブロックチェーンを急いで作り、今はブロックチェーンは fancy ではないかもしれませんが、特殊な方法を発明し、自分たちは速い、イーサリアムと互換性があると言っています。

上にたくさん書きましたが、私はイーサリアムが大好きです。しかし、この記事は、現在エコシステムにある小さな問題について述べています。多くの人の設計思想は、顧客の問題を見つけてそれを解決することですが、しばしば他人が踏んだ轍を再び踏もうとします。これにより、現在、同質の DHT やブロックチェーン製品が過剰に多くなってしまっています。特に、一時期の「ワンクリックでチェーン発行」の時代は、多くの問題を現在、単純なものから非常に複雑なものに変えてしまいました。

# 複雑さからシンプルさへ

では、良い設計とは何でしょうか？ 現在、皆 Git を見て驚嘆しています。なぜこんなに素晴らしいのか。Nginx や Postgre もいくつかの美しい設計の製品です。もし、彼らが何をしたかに注視するなら、それは他の同質の製品と比較して、安定して使いやすいツールを提供することです。

現在、私は DHT システムに参入し、自分自身の特殊な仕様の問題を解決するために P2P システムを設計したいという衝動に駆られています。しかし、実際にはブロックチェーンは素晴らしい DHT の一種です。Sui や EVM のような既存のブロックチェーンに ZK を追加すれば、自分でノードモデルを再設計するよりも良いのではないでしょうか？ ユーザーの視点から見れば、間違いなく良いでしょう。なぜなら、Web3 には複雑なプログラムが不足しているわけではなく、多くのイベントでは参加するためにお金を払って教えてもらう必要があります。そのため、ユーザーの視点から見れば、自分でノードを構築しないことは、自分の手間を省くだけでなく、ユーザーの手間も省くことになります。

まだ解決策を思いついていないのは、Git のようにシンプルで破壊的な革新的な設計ですが、シンプルなコアは非常に重要な理念だと思います。なぜなら、ユーザーに複雑なツールを提示した場合、受講者もますます複雑で奇妙になるだろうからです。これを戒めとし、巨大な獣を造り出さないことを願っています。

個人的な感想を述べると、年初に DHT システム一式を構築し、WASM をすべて導入して P2P をどこでも簡単に実行できるようにしました。しかし、複雑な型検証、メッセージ処理、同期の問題により、類似製品を探すことになりました。すると、シンプルな WebRTC で自分の仕事の9割を完了でき、しかも非常にエレガントに処理できることがわかりました。これは私にとって非常に気まずいことで、数ヶ月の努力が泡と消えたようなものです。これも自己成長の一環でしょう！