Rippleでシニアソフトウェアエンジニアとして活躍するMayukhaさんによる、ソースコードがrippledにマージされるまでの道のり解説ツイートスレッドを訳しました。
読みやすさのためにいくつかのツイートはひとつの段落にまとめてあります。
小見出しはほっち製です。
Many of you have been asking lately about how XRPL source code (rippled) changes (amendments, fixes, new features, etc.) are written and tested, so here’s a thread.
— Mayukha Vadari (@msvadari) March 4, 2024
How Code Gets Into Rippled: 🧵
最近、XRPLのソースコード（rippled）の変更（アメンドメント、改善、新機能など）がどのように書かれ、テストされるのかについて多くの方から質問をいただいています。そこで、こちらのスレッドで説明します。 コードがRippledに取り込まれるまで: 🧵
1. はじめに
まず、rippledはきわめて高度なプログラミング言語であるC++で書かれています。 XRPLエコシステム内でC++とrippledの知識を持ち、コードの変更を提案・レビューできる人は多くなく、また、そのうちの何人かはRippleで働いています。ですが、その数は日々増えています！
2. C++エンジニアでなくても大丈夫！
たとえあなたがC++エンジニアでなくても、アメンドメントの書き方を学ぶ方法があります。
例えば、私は「プラグイン」というプロジェクトに取り組んでおり、これにより開発者はPythonなどの言語で、実験的なアメンドメントをもっと気軽な環境で書くことができます。
3. コードの前に仕様を書こう
XRPLに新しい機能アメンドメントを追加する場合、コードを書く前にXLS(XRPL標準規格)の仕様を公開する必要があります。XLS仕様の詳細についてはこちらをご覧ください。
つぶやき
この仕様策定の段階で、提案者はXRPLエコシステムの開発者たちからいろんなフィードバックを受け、さらに仕様を磨きます。
4. コードを書いたらレビューを受けよう
次にレビューがあります。
XRPLにバグを生じさせたくないので、たとえ簡単なプルリクエスト（PR）でも数時間のレビューが必要です。AMMのような複雑な機能のPRレビューは、安全にマージできると判断されるまでに数ヶ月かかります。
rippledのPRのレビュー手順自体は至ってシンプルです。内容が複雑でも関係ありません。レビューは、rippledの経験が十分にある人なら誰でもできます。各PRには2人のレビュー担当者が割り当てられますが、他の人もコメントすることができます。
5. 変更箇所によって複雑度は天と地の差
rippledの複雑な部分、例えばコンセンサスの変更は別次元の難しさです。なぜなら分散型システムは変数が多く、それら全てをモデル化・モック化するのは非常に難しいからです。
6. テストしよう
より複雑なPRには追加のテストプロセスがあります。Ripple社内では優れたQAエンジニアがこれを担当しており、時にはAMMのような複雑な機能を評価するために何百ものテストを書きます。エンドツーエンドテストやパフォーマンステストなど、さまざまなテストが行われます。
7. テストが完了したらマージ準備完了
PRがすべてのテストを通過したら、マージできます。
これにより、次のrippledのリリースに含まれることになります。新しいコードを早く試したい人のために、ベータ版が定期的に公開されています。
8. テストネットでリリース候補の動作テスト
rippledの新しいリリースを行う時（おおよそ四半期ごと）には、リリース候補（RC）が公開されます。このRCはテストネットで2週間動作し、他のテストネットワークでも多数のテストが行われます。
この2週間の間に何か問題が発生した場合（例えばバグが見つかった場合）、そのバグの修正が最優先となります。修正が完了すると、ふたたび2週間のカウントダウンが始まります。このため、テストネットで問題が発見された後にrippled2.0のリリースが遅れました。
9. みんな大好きアメンドメント投票
アメンドメントの最終段階は、もちろん投票プロセスです。
バリデータは投票を用いてアメンドメントの有効化を決定します。アメンドメントを理解し、それがネットワークにとって安全だと確信したときに、デフォルトの「反対」票を「賛成」に変更する必要があります。
10. Mayukhaさんの思い
私は、みんながアメンドメントに慎重なのはとても良いことだと思っています。私たちは皆、XRPLが常に高性能で、エラーがなく、安定していることを望んでいます。うっかりバグを導入すると大きな影響があるため、慎重に進める必要があるのです。
読んでくださってありがとうございました！
11. 追記
次のフローチャートは、このプロセスの主要な部分を表しています。
出典：xrpl.org
あとがき
非開発者目線ではどうしても「あの新機能の話が出てから随分経った気がするな〜まだ来ないのかな〜」なんて思っちゃいがちですが、舞台裏では多くの開発関係者が何層にもなったデリバリープロセスをこなしてくれているのですね。ありがとう、開発者の皆様✨
