ビットコインの仕組み：たった9ページで世界を変えた論文
2008年、謎の人物サトシ・ナカモトが、たった9ページの論文を発表した。
タイトルは「Bitcoin: A Peer-to-Peer Electronic Cash System」。
この論文が、世界の金融システムを揺るがすことになる。
サトシナカモト：ビットコインが残した意志と量子コンピュータの衝撃
「デジタルのお金」が不可能だった理由
現金には、ひとつだけ絶対的な強みがある。
コピーできないということ。
1万円札を誰かに渡したら、自分の手元からは消える。当たり前だ。でも、デジタルデータは違う。音楽も動画も、クリックひとつで無限にコピーできる。
じゃあ「デジタルのお金」はどうなる？
AさんとBさん、両方に同じ1万円を送れてしまう。これが「二重支払い問題」。デジタル通貨の最大の壁だった。
従来の解決策は単純——銀行に任せる。銀行が「Aさんの残高を減らして、Bさんに足す」と記録すればいい。でも、それって結局「銀行を信用しろ」という話だ。
サトシは、銀行なしでこの問題を解いた。
コインの正体：「署名のリレー」
ビットコインには、実は「コイン」という実体がない。
あるのは「誰が誰に送った」という署名の連鎖だけ。
Aの署名 → Bの署名 → Cの署名 → ...
AがBに送るとき、Aは「Bに送る」と書いて自分の秘密鍵で署名する。Bはその署名を検証できる。Bが次にCに送るときも同じ。
つまりビットコインとは、「この権利は私のものだ」という署名が連なったもの。コインを「持っている」のではなく、「次に署名する権利を持っている」。
誰が正しい記録を持っているのか？
署名のリレーだけでは、まだ問題がある。
Aが「Bに送った」と署名した直後に、「Cに送った」とも署名したらどうなる？どちらが本物？
銀行なら「先に届いた方」と判定できる。でもビットコインには銀行がいない。世界中のコンピュータが、バラバラに記録を持っている。
全員が「同じ順序」で合意する仕組みが必要だった。
サトシの答えは「ブロックチェーン」。取引をブロックにまとめ、チェーンのように繋げる。
ブロック1 → ブロック2 → ブロック3 → ...
各ブロックには、前のブロックの「指紋」（ハッシュ）が刻まれている。過去を改ざんするには、それ以降のすべてのブロックを作り直す必要がある。
でも、誰がブロックを作るのか？
「計算した者が記録する」というルール
ここからが、サトシの天才的な発想。
ブロックを作る権利を、計算競争で決める。
具体的には、ブロックのハッシュ値が特定の条件を満たすまで、ひたすら計算を繰り返す。条件は「ハッシュの先頭にゼロが並ぶこと」。
ブロックデータ + ナンス値 → ハッシュ関数 → 0000000abc123...
↑
先頭のゼロが条件を満たすまで
何兆回も計算を繰り返す
この計算には膨大な電力と時間がかかる。だから「計算した」こと自体が「労働の証明」になる。これがProof of Work（PoW）。
最初に条件を満たしたノードが、ブロックを作る権利を得る。そして全員がそのブロックを採用する。
悪意ある改ざんをするには、正規のチェーンより速く計算し続けなければならない。ネットワーク全体の過半数を超える計算力がない限り、事実上不可能。
なぜ「正直」がいちばん得なのか
でも、そもそもなぜ人々は正直に計算するのか？
報酬があるからだ。
ブロックを最初に作ったノードには、新規発行されるビットコインが与えられる。最初は1ブロックあたり50BTC。約4年ごとに半分になり、最終的には2100万BTCで打ち止め。
さらに、ブロックに含まれる取引の手数料ももらえる。
計算してみよう。もし悪意ある攻撃者が、ネットワークの過半数の計算力を手に入れたとする。その力で何をする？
- 選択肢A：過去の取引を改ざんして、自分に有利にする
- 選択肢B：正直にマイニングして、報酬をもらい続ける
Aを選ぶと、ビットコインの信頼が崩壊し、価値がゼロになる。
Bを選べば、莫大な計算力で大量のビットコインを正当に獲得できる。
どちらが得か？答えは明らかだ。
システムは「正直が最も儲かる」ように設計されている。
全取引を保存しなくていい理由
ビットコインのブロックチェーンは、2024年時点で約600GB以上ある。全部保存するのは大変だ。
でも実は、すべてを保存する必要はない。
マークルツリーという構造を使えば、ブロックヘッダ（約80バイト）だけで、任意の取引の存在を証明できる。
ルートハッシュ（ブロックヘッダに含まれる）
/ \
Hash01 Hash23
/ \ / \
Hash0 Hash1 Hash2 Hash3
| | | |
取引0 取引1 取引2 取引3
自分の取引が本当にブロックに含まれているか確認したい？ルートまでの経路（数個のハッシュ）があれば十分。だからスマートフォンでもビットコインを使える。
プライバシーの逆転
銀行は、取引記録を秘密にすることでプライバシーを守る。
ビットコインは逆だ。すべての取引が公開されている。
じゃあプライバシーはどこにある？
「誰が」の部分が匿名なのだ。
取引は公開。でも、その公開鍵が誰のものかは分からない。新しい取引ごとに新しいアドレスを使えば、追跡はさらに困難になる。
従来の銀行: 本人 ←→ 取引（非公開）←→ 銀行が管理 ビットコイン: 匿名の公開鍵 ←→ 取引（公開）←→ 誰でも検証可能
「6承認」の数学的根拠
「ビットコインの送金は6承認待て」という話を聞いたことがあるかもしれない。なぜ6なのか？
論文には、攻撃者が正規チェーンに追いつく確率の計算が載っている。
| 承認ブロック数 | 攻撃者の計算力30%の場合 |
|---|---|
| 1 | 45% |
| 5 | 10% |
| 6 | 2.4% |
| 10 | 0.14% |
6承認で、攻撃成功率は約2%まで下がる。これが「6承認」の根拠。
たった9ページで何を成し遂げたのか
ビットコイン論文の本質を5行でまとめる：
- 電子署名で「誰が誰に送ったか」を証明
- ブロックチェーンで取引の順序を全員で共有
- Proof of Workで改ざんを計算的に不可能に
- 経済的インセンティブで正直な行動が最も得になる設計
- P2Pネットワークで銀行という中央管理者を不要に
銀行への「信頼」ではなく、数学と経済合理性で動く通貨システム。
これが、サトシ・ナカモトがたった9ページで設計したものだ。
関連リンク
VSCode に java.configuration.runtimes を自動設定する拡張機能
VS Code 拡張機能 Java Extension Pack Auto Config の Java 21 対応版をリリースしました。この拡張機能には java.configuration.runtimes 自動設定を含む以下のような機能があり、JAVA_HOME などの設定が不要です。インストーラやパッケージャでインストールした JDK のバージョンアップなどでパスが変わった場合も、VS Code 起動時に settings.json が自動更新されます。
- Microsoft、Red Hat、VMware などの Java 拡張機能が付属
- 複数の JDK を自動設定、エラー修復、更新
- Maven や Gradle を自動設定、エラー修復、更新
- Java 開発用の自動デフォルト設定
- VS Code ターミナルで各バージョンの Java 実行可能
ReentrantLock を try-with-resources で安全に使う
Java 21で導入された仮想スレッドで、プラットフォームスレッドに影響を与えずに仮想スレッドに対してsynchronizedと同じ効果を得るために、ReentrantLockクラスの使用方法について投稿しました。通常のReentrantLockの使用方法は柔軟性がありますが、lock()とtryの間に処理を書くことができ、またfinallyにunlock()を書かないと不具合が発生する可能性があります。そのため、ReentrantLockを安全に使うための3つの方法を紹介しています。
- ReentrantLockをtry-with-resourcesで使用する方法
AutoCloseable対応の共通クラスを作成し、try-with-resourcesで使用します。これにより、自動的にアンロックされます。 - ReentrantLockをラムダで使用する方法
ラムダを扱える共通クラスを作成して、ラムダで使用します。これにより、アンロックがラムダ内で行われます。 - Lombokの@Lockedを使用する方法
Lombokのバージョン1.18.32で導入された@Lockedアノテーションを使用すると、ReentrantLockを簡潔に利用できます。
Spring Bootにおける仮想スレッドの対応や副作用についても記載しています。特に、Spring Bootでは3.2から仮想スレッドが利用可能であり、設定によってデーモンスレッドやアプリケーションの終了条件が変わります。また、Tomcatはバージョン11からリクエストの仮想スレッドをサポートします。
React、Vue、Svelte、Solid のレンダリング性能
様々な指標で多くの JavaScript フレームワークが計測されている GitHub js-framework-benchmark による処理時間 + レンダリング時間の公式総合結果。最も速い Vanilla JS (素の JavaScript) を 1 とした数値です。Vue は高性能とされているコンパイラ型の Svelte や Solid と比較しても意外？に速いようです。この結果からは性能に関しては React に対して Solid は圧倒的ですが、Vue に対して Svelte の優位性が薄い感じです。
表示速度は UX や SEO (Google 検索順位) に大きく影響します。現在の Google クローラーは CSR (クライアント側で JavaScript を実行してレンダリング) でコンテンツを評価できるため、Next や Nuxt などの拡張フレームワークによる SSR (アクセス時にサーバー側でレンダリング) や SSG (事前に静的サイト生成) でなくてもコンテンツ自体はほとんどの場合は認識されますが、方式に関わらず、処理 + レンダリング速度は重要です。Vercel、Cloudflare、AWS などの CDN で JS を実行するサービス CDN Edge も有用です。
拡張フレームワークの機能
| ベース | 拡張 | ファイルシステムルーティング | SSR | SSG |
|---|---|---|---|---|
| React | Next | ○ | ○ | ○ |
| Vue | Nuxt | ○ | ○ | ○ |
| Svelte | SvelteKit | ○ | ○ | ○ |
| Solid | SolidStart | ○ | ○ | ○ |
Eclipse と STS の違いは？
STS3 のときは、Eclipse に STS3 プラグインをインストールしたときと、ほぼ同じだったのですが、STS4 になり WTP が削除されたため、現在は STS と Eclipse + STS プラグインは結構異なります。ベースの Eclipse に Wild Web Developer が追加されましたがサーバー機能が無いため、WTP の代わりにはなりません。また、一般の開発者はあまり使わない重量級のプラグイン PDE (Eclipse プラグイン開発機能) が STS4 でも残っています。Tomcat 組み込みの Spring Boot jar しか使わない場合でも、画面を使用する場合、現在の STS は HTML 作成ウィザードなどがありません。
