情報をありがとう。
クライアント専用ノードについて同じ結論に達し、それを実装してきた。もうすぐ完成だ……ブロックチェーンのダウンロード、ブロック/トランザクションの解析と検証が完了し、支払いトランザクションの作成もほぼ完了している。
v1は基本的にあなたの提案通りに行い、ブロックロケーターを構成するために必要なブロックのみを保存するという最適化の可能性がある（指数的な間引きで）。Androidはアプリ専用のローカルストレージを提供しているため、新しいブロックを受け入れるためにブロックチェーン全体を保存する必要はない……常に最長チェーンに追従できるだけの量があれば十分だ。
ところで、あなたのコードは読みやすく、非常に貴重な参考になった。ありがとう。
v2では、安全でロックダウンされたリレーノードを実行して、トランザクションがメモリプールに受け入れられたときに携帯電話にメッセージを送信することで、ブロックチェーンに統合される前のトランザクションを表示することを考えている。Androidはすべての携帯電話に安全で低消費電力のバックチャネルを提供している。デバイスがオフラインの場合、メッセージはサーバー側に保存され、着信メッセージを処理するためにアプリが自動的に起動される。
リレーノードがハッキングされていない限り、このシステムは低額取引をUIで即座に表示するのに十分な信頼性を提供するはずだ。ある程度の中央集権化/単一障害点を導入するが、リレーメカニズムが停止またはハッキングされても、被害は新しいブロックがダウンロードされるまでの10分間だけだ。
クライアント専用の再実装はEvalScriptを全く実装する必要がないか、せいぜい標準トランザクションテンプレートで使用される5つのオペコードだけを実装すれば十分です。」
確かに、クライアント専用の実装がEvalScriptを実装する意味はない。ブロックチェーン全体を保存しインデックス化しなければ、トランザクションが二重支払いされていないことを検証できないからだ。私のコードはスクリプトを解析し、標準的な構造であることに依存しているが、実際には実行しない。
経験に基づく推測で、計算するときりのいい数字になります。非常に普及した場合に低すぎず、そうでない場合に高すぎないものが欲しかったのです。
この計算過程を見てみたいものだ。ある意味、コインの数は任意だ。nanocoinの表現により、発行量は事実上無限と言えるほど膨大だからだ。
実際の使用量が制限に近づき、正常に動作していることを確認してから、より高い制限を段階的に導入できます。
何らかのより堅牢な自動アップデートメカニズム、またはこの段階的導入のスケジュールを実装する価値があるだろう。人々が「BitCoinに自分の時間と労力を費やす価値があるか」を評価する際に、スケールアップの確固たる計画が文書化されていることは良いことだからだ。
ハードウェアの物理的な能力については心配していないが、アプリが再実装され、自動アップデートしないノードの数が増えるにつれてのプロトコルの硬直化が気になる。クライアント専用の再実装はもちろん問題ないが、SMTPのような他のシステムは、拡張メカニズムが組み込まれているにもかかわらず、グローバルなアップグレードが不可能であることが証明されている……実装が多すぎ、インストールが多すぎるのだ。