コンポーザビリティはビットコインのスケーリングの鍵

DEVCON1: ブロックチェーンのシングルセル設計モデル - Lucius Greg Meredith

(合計 19 分、以下のリンクではタイトルの引用を最後まで再生します):

https://youtu.be/uzahKc_ukfM?t=1041

ちなみに、この深い哲学的、数学的な美しさは、いつも私にインスピレーションを与え、次のようなフォーラムに自分の意見やアドバイスを投稿する動機を与えてくれます。

1. • Ethereum EVM イエローペーパーは過度に複雑で恣意的です (ここで「yellow」を検索してください https://np.reddit.com/r/ethereum/comments/4pl804/solidity_is_an_implementation_language_and_the/d4malcl)

2. • C/C++ プログラマーはプログラミングパラダイムにとらわれているため、大規模で実証済みのビットコインの拡張を理解するためのビジョンと知恵がありません。 (https://np.reddit.com/r/btc/comments/4q95ri/the_day_when_the_bitcoin_community_realizes_that/)

3. • 自分で計算してみましょう (ydtm)

________________________________________

ビットコインが前進するための最善の方法は、皆が協力して一種の「スーパー/メタシェリングポイント」を作ることだと私は思います。

…つまり、誰もが自動的に同意するほど「明らかに最良」なハードフォークです。
…また、次のようにも説明できます: 十分な柔軟性と「組み込み」オンチェーン ガバナンスを備えたハード フォークにより、将来のほとんどのハード フォークの必要性を最小限に抑える、または排除します。
…というか、私たちが約束されていたビットコインは、数学と市場によって支配されており、グレッグ・マクスウェルが現在支配しているビットコインではありません。
ハードフォークが「誰もが自動的に同意するほど明らかに最適」であるためには、どのような特性が必要ですか?

（1）「明らかに最善」のハードフォークは、もちろん、過去のビットコイン投資の判断における賢明さを維持し、誰もがブロックチェーン上で直接ビットコインの取引を継続できるようにする必要があります。

1. • つまり、フォーク前からのビットコインのグローバル台帳上の全員の既存の取引/残高を維持する必要があります。

2. • このようなアップグレードは「スピンオフ」として広く知られています (https://bitcointalk.org /index.php?topic=563972.0) - 人々はすでにビットコインのこのようなスピンオフに取り組んでいます (https://duckduckgo.com /?q=site%3Abitco.in%2Fforum+spinoff&ia=web)。つまり、すべての人の既存のアカウント残高を台帳に保持し、人々がより速く、より安価に取引できるようにすることです。

（２）「明らかに最適な」ハードフォークは、将来のビットコインガバナンスの決定においてすべての人の知恵を解放し、今後は誰もがブロックチェーン上で直接ビットコインガバナンスを実装できるようになるはずです。

1. • つまり、ビットコインの合意形成メカニズムを最大限に活用して、次にどのブロックを追加するかについて合意に達するだけでなく、次にどのソフトウェアをインストールするかについても合意に達する必要があります（たとえば、どのルールを使用するか、有効なブロックをどのように決定するかなど）。もちろん、すべての人の富を増やすために、主要な市場ベースのメタシステムルールを維持します。

2. • これは「自己修正型」暗号台帳と呼ばれます。

要件（1）は実装が非常に簡単です（つまり、スピンオフを直接使用します）。
要件（2）はより困難ですが、「自己修正型暗号台帳」に取り組んでいる非常に優秀な人々がいます。

https://tezos.com/white_paper.pdf

________________________________________
EB136-アーサー・ブライトマン: Tezos - 自己修正型暗号化台帳

https://www.youtube.com/watch?v=3mgaDpuMSc0

この独立系開発者のアプローチは、理論と実践のちょうど良いバランスをとっています (彼は、高レベルのロジックと証明可能な正しさを低レベルの C++ のような効率性と制御性に組み合わせた言語である Ocaml を使用しています。つまり、Ocaml プログラムは Coq 定理証明器から抽出でき、C++ の約 3 分の 1 の速度で実行される効率的な実行可能ファイルを作成できます。速度が桁違い (10 倍) で測定される環境では、これは悪いことではありません。また、低レベルの CPU 集中型データ処理には、Ocaml から C への優れた (単一セルの!) 外国語関数インターフェイスがあります)。

つまり、ある程度は分散型開発が行われているということですが、ビットコインユーザーにとっては次のような理由で良くありません。

本当に先見性のあるリーダー的開発者は Core/Blockstream では働いていません。彼らのほとんどはビットコインに取り組んでさえいません。

本当に賢い開発者は、当然ながら /u/nullc のような意固地な暴君のために働くことはできません。彼らは礼儀正しすぎるため、彼と交流することさえ考えられません。彼らは本能的にそのような人々を避けます。なぜなら、次のことをすぐに理解するからです。

Greg Maxwell は、グローバルに分散されたネットワーク上で大規模かつ正しく証明可能なスケーリングがどのようなものになるか想像もできない、単なる退屈な C++ プログラマーです。

グレッグ・マクスウェルが「ビットコインはスケールしない」と言ったとき、彼は実際は「ビットコインをスケールする方法が分からない」と言っているのだということを覚えておいてください。

他のプログラマーは、ビットコインを大規模かつ安全に、そして自然に拡張するための、エレガントでコンパクト、自然で、証明可能な正しい方法を開発することができます。一方、Core/Blockstream の愚かな開発者ができることは、ハックの上にハックを重ねることだけであるようです。いわゆる Lightning Network です。

これが、Core/Blockstream がコンピュータ業界における「悪いほど良い」という哲学の典型となった理由です。彼らは、ビジネスオーナーを助けることを期待して、ユーザーを傷つけるゴミを投稿します。 (https://np.reddit.com/r/btc/search?q=axa&restrict_sr=on)

私たちが今考慮すべきことは、ビットコインに献身する意欲のある、野心的で先見の明のある才能ある開発者をもっと歓迎し、奨励することです。

しかし、ビットコインが革新を恐れ、信頼できない平凡な開発者のグループによって管理され、「C++ スパゲッティコードの束」で定義されている限り、これらはすべて不可能となるでしょう。
________________________________________

だから私は、/u/nullc のような人物を基本的に「小さな池の大きな魚」、つまり悪者だと考えています。

暗号、ネットワーク、ゲーム理論の知識を持つ C++ プログラマーとして、彼は、結局のところシリアルプログラミングパラダイムにとらわれている彼のようなプログラマー (Core/Blockstream プログラマーはほとんどすべてこれに似ています) に指示を与えることができます。また、中国のマイナーや、これらのフォーラムの一部の人々に指示を与えることもできます。

同時に、イーサリアムに集まっているプログラマーたち（EVMイエローペーパーを書いたギャビン・ウッドやDAOを書いたslock.itの連中のことではなく、この記事の冒頭のビデオに出てくるルシウス・メレディスや、以下のアーサー・ブライトマンのような人たちのことを言っている）を見れば、ブロックストリーム/コアの近視眼的な人たちよりも数学や証明可能な安全性を持つ分散プログラムに精通した才能ある開発者がたくさんいることがわかるだろう。

先見の明のある開発者は、暗号通貨の将来は、恣意的で混乱を招く設計上の「決定」で満たされた黄色い紙によって決まるものではないことを知っています。 （むしろ、それは数学の美しさから自然に生じるはずです。）

そして彼らは、Core/Blockstream のようなチームが安全でないスパゲッティ コードを使用して Bitcoin の main.cpp を全面的に変更することを許可された場合、暗号通貨の将来がどうなるかを知っています。 （それどころか、それは証明可能に真実であるはずです。）

そして彼らは、長期にわたる成功したガバナンスは、フォーラム、IRC、メーリング リストの人々からは生まれないことを知っています。それは、ユーザー (市場) がブロックチェーン上で直接投票して合意に達することを可能にする適応型ルールからのみ生まれます。合意とは、次に追加するブロックについての合意と、適用する新しいルールについての合意です。

大規模に拡張できる暗号通貨は、4〜5 行のコード (機能的、真の単一セル) のみに基づいています (この記事の冒頭で引用したビデオを参照してください)。これらのコードは、自然と宇宙のフラクタルの美しさと壮大さを反映し、半ページの長さの別のコード セットによって正しいことが証明され、自己開始および自己修正が可能であるため、進化と改善を継続できます。

ここでの非常に興味深い社会学的/心理学的観点は、Core/Blockstream 開発者の権威主義的、人間中心主義的な考え方です。Luke-Jr のような病的な人間は、前述の内在性を信じることも理解することもできません。結局のところ、彼は実際にこれほど素晴らしいものを経験したことがないのです。

つまり、一方では次のようなことが言えます。

1. • Core/Blockstreamの管理下では、そのスパゲッティコードがBitcoinのmain.cppに書き込まれています（彼らは「ソフトフォーク」アップグレードを主張しているので、状況は悪化するだけです）

2. • /u/nullc のような悪党は皆を殴り倒して「ビットコインはスケールしない！」と言います。

3. • /u/theymos のような権威主義者は、「ビットコインユーザーは自由な決定を下すことができない」と信じています。

4. • Core/Blockstream に関連するその他の悲観的な追従者 — 自然と数学が自らの存在を自ら開始し、自らの進化の軌跡を自ら修正し、大規模に、形而上学的に、安全に拡張する様子を理解できない暗い世界観に囚われた人々。

そして、確かに、こうした性格上の欠陥は C++ プログラマーの間では非常に一般的です。

この考え方は、実装計画は書けるが詳細は書けない、マシンに近すぎるためポインタの追跡やメモリ容量の割り当てと再割り当てに気を取られ、マシンがクラッシュするのではないかと常に心配する、そしてプログラムがほとんどの場合に正しいかもしれないと「テスト」することしかできず、すべての場合に正しいことを証明することができない、低レベルの命令型言語につながります。これが、Blockstream/Core 開発者の真の姿です。

一方、別の場所では、ビデオに登場した人たちがいます。彼らはまだ地に足のついた賢い数学者とプログラマーで、フラクタルの美しさと自然と宇宙のスケールを伝えることができ、特に子供を木の葉に例えるという彼の言及、宣言的、機能的、自己証明可能な言語を使用した「ブロックチェーンの単一セル設計モデル」の例、「スケーラブルな PoS プロトコルの自動構築された正しい実装を記述できる、一貫性のある分散型スケーラブルな仮想マシン」の話などです。自己証明されているだけでなく、自己起動および自己修正可能で、つまり、私たちが約束されたビットコイン、つまり、マクスウェル氏のような人間ではなく数学によって管理されるビットコインを意味します。

覚えておいてください: 「自己修正」 = 将来的にハードフォークの必要がほとんどなくなり、フォーラムで他の人と議論して人生を無駄にすることがなくなります。

Bitcoin クライアントを開いて、希望するルールに投票します。 Bitcoin Unlimited (https://np.reddit.com/r/btc+bitcoin /search?q=bitcoin+unlimited&restrict_sr=on&sort=relevance&t=all) は、この方向への第一歩です。

Core/Blockstream の開発者は、自らを窮地に追い込んだ敗者であり、そこから抜け出すための数学的想像力が欠けていることは明らかです。

Core/Blockstream の開発者たちは、1MB から 2MB または 4MB に移行するべきかどうかについて何年も論争と激しい批判が続いてきた後、単純なルール投票 (Bitcoin Unlimited など) を直接シグナリングできる控えめな追加パラメータがいかに大きな前進となるかさえ理解できないほど迷っています。また、彼らはあまりにも無知であるため、超薄型ブロック (彼らはコンパクト ブロックと改名しました) が優れたスケーリング技術であることを認めることさえできません。

ビットコインが勝利するためには、Blockstream/Core の悲観的で凡庸なプログラマーと、彼らの数学とスケーラビリティに対する表面的な理解から脱却し、「スケーラビリティの鍵はコンポーザビリティ」 (Core/Blockstream によって書かれたスパゲッティコードや Lightning Network のようなハックではなく) を理解し、自然にスケーラブルで、自ら正しいことが証明され、自己開始 (https://www.youtube.com/watch?v=uzahKc_ukfM) し、自己修正 (https://www.youtube.com/watch?v=3mgaDpuMSc0) する分散システムの設計についてより深い理解を持つ、オープンマインドで先見性のあるプログラマーを歓迎する必要があります。