仕組みの解説2026-10-28約 5分

Pactus Berlin：履歴を刈り込んだ後に残るアンカー

Pactus 1.17.0は、現在のコミットメントをアカウントに置くスロットを実装した。残るハッシュは、文書そのものや正確な実時刻、永続的な失効記録とは異なる。

過去の取引記録を片付けても、現在のコミットメントが一つ残る関係を描いたAI生成の概念図。実在するPactusの設備や、文書のオンチェーン保存を描いたものではない。

要点

Berlin 1.17.0は10月28日にリリースされた。実装はプロトコルv5を対象とし、本稿はメインネットでの有効化を独立に確認した報告ではない。
各アカウントには現在のハッシュを持つ任意のスロットが一つある。作成時は最低1 PACをロックし、既存スロットの更新は追加預託なしでも可能だが、取引手数料はかかる。
プルーニング後も現在のスロットは読める。ただしハッシュは、文書の真実性、正確な実時刻、削除済みアンカーの永続記録を保証しない。

出来事のタイムライン

2026-10-28Berlinソフトウェアをリリース

PactusがPIP-50の実装を含む1.17.0を発表。ソフトウェアの提供とネットワークのプロトコルv5への移行は別の事実だ。

リリースとプロトコルの切り替えは別の段階

2026年10月28日、PactusはBerlinと名付けたバージョン1.17.0をリリースした。ネイティブ状態アンカーは、オフチェーンのデータに対する現在のコミットメントをアカウントに残す場所を設ける。リリースと実装は公開されたが、PIP-50は機能の適用条件をプロトコルv5としている。本稿は公開された設計とリリース済みコードを解説するもので、メインネットのv5移行を独立に確認したものではない。^[1][2][3]

PIP-51では、提案者が把握した対応表明が委員会の総パワーの75%を超えると、ブロックバージョンを引き上げる。ノード数の75%ではない。PIP-50は重要な区別を加える。これは提案者の移行ルールであり、各ノードの手元の支持率に基づくブロック妥当性の条件ではない。その観測値はノードごとに異なり得る。ノードは有効で認証されたv5ブロックを受け入れ、必要な証明書の作成には委員会パワーの3分の2を超える部分がv5対応ソフトウェアを動かしている必要がある。リリースタグや支持率だけでは、移行完了の証拠にはならない。^[3][4]

過去の受領記録と、現在の表明

取引メモは、あるアカウントが過去にハッシュを記録したことを示せる。しかし、今もそのハッシュを支持しているかは別の問いだ。PIP-50は、アカウントの現在の状態に任意のアンカーを一つ置き、既存のアカウントのマークル木とグローバルな状態ルートでカバーする。古い取引本体をプルーニングしたノードでも、現存するスロットは読める。^[3]

スロットには長さを制限したハッシュ、任意の外部データの場所、種類のヒント、ロックした預託額、作成・更新フィールドが入る。文書そのもの、アプリのデータベース、検索インデックスを保存するものではない。例えばサービスのマニフェストを扱うアプリは、古い取引の存在を現在も有効な証拠とみなす代わりに、外部文書をアカウントの現在のコミットメントと照合できる。これはPIPが示す応用パターンであり、サービスが実運用されている証拠ではない。^[3]

預託はスロットを占有するためのもの

詳細ルールは、作成と更新の預託を一括して説明する発表文よりも具体的だ。新規作成では最低1 PACをロックする。既存スロットの更新では追加預託が0でもよく、従来のロックは維持される。ただし取引手数料はかかる。v1.17.0の実行コードは、アンカーがない場合にだけ最低預託額を検査する。削除時には、ロックした預託額から削除手数料を引いた分が戻る。現在の状態を占有するための返還可能なロックであり、利息や利回り、すべての操作が無料という約束ではない。^[3][5]

ブロック時刻は独立した時計ではない

作成時の高さと時刻は、そのスロットを作ったブロックから取得する。署名者が任意のタイムスタンプを入力することはできない。更新フィールドは現在のルートハッシュを設定したブロックを指す。同じハッシュを保ったまま、場所、種類のヒント、預託額だけを変えても、その日付は更新されない。PIP-50とリリースタグの実行コードはともにこの区別を維持する。^[3][5]

これにより、取引作成者がアンカーのペイロードに好きな日付を書き込むことは防げる。しかし、タイムスタンプが信頼できる外部時計になるわけではない。Unix時刻は提案者のブロックヘッダーから来ており、プロトコルが許容する時間範囲の制約に従う。PIP-50は順序の基準をブロック高としている。ハッシュに添えた日付はチェーン上の観測として読むべきで、現実世界の厳密な瞬間を独立に証明するものではない。^[3]

アンカーを削除すると日付も消える

プルーニングに耐えるという約束には範囲がある。現在の状態に残るスロットは、最初の取引がなくても読める。削除後のGetAnchorは有効なスロットがないと返し、タイムスタンプも消える。現在の状態だけでは、一度もアンカーを作らなかったアカウントと、作成後に削除したアカウントを区別できない。削除時刻も分からない。その証拠は削除取引にあり、プルーニング済みのノードはもう保持していない可能性がある。^[3]

これは失効記録にとって重要だ。スロットの削除は現在の表明を終わらせるが、その場所に日付付きの永続的な失効マーカーを残すものではない。PIPは、プルーニング後にも失効の根拠が必要な場合の別の応用を示す。スロットを残し、その現在のルートで失効レジストリにコミットする方法だ。レジストリの意味と裏付けデータは、引き続きアプリが担う。^[3]

ハッシュが一致しても残る問い

外部データを記録済みダイジェストと照合すれば、選択したハッシュ規約の下で完全性を確認できる。しかし、文書の記述が真実であること、アドレスが特定の人物に属すること、外部ファイルが今後も入手できることは証明しない。任意の場所情報も信頼できない入力であり、コンセンサスは取得も解釈もしない。一つのコミットメントで複数項目をオフチェーンのマークル木にまとめられるが、ファイルと包含証明はチェーンの外で受け渡す。^[3]

状態へのコミットメントと、画面上の回答も別だ。PIP-50のGetAnchorには状態ルートに対する証明が付かない。他人のRPCサーバーやエクスプローラーを問い合わせるクライアントは、そのサービスの回答を信頼しており、メソッドだけでその信頼が不要になるわけではない。Berlinの設計は、アカウントの現在の表明と過去の受領記録を分ける点に価値がある。正確に読むには、文書の完全性、身元、時刻、可用性、問い合わせ先をそれぞれ別の問いとして扱う必要がある。^[3]

次の疑問へ