時々、ある会社がいちばん問題を起こしやすいのは、責任を負う人がいないからではなく、全員が少しずつ責任を負っているからだと気づくことがあります。製品チームは「開発が確認済み」と思い、開発は「運用がすでに承認している」と考え、運用は「法務が反対するはずはない」と見ています。最後に事が起きたとき、誰もが関わっていたのに、結局どの段階で問題が起きたのか誰も説明できません。

その後、@NewtonProtocol というごく小さなデザインを見て、私はずっとあまり意識してこなかった Authorization Receipt のことをふと思い出しました。これは「実行が完了した後に生成される、単なる証明書」なのだと思っていて、ログやレシートと似たように、主に保管のためのものだと思っていました。けれど読み進めるほどに、それが現れる場所が妙だと感じるようになりました。

それはプロセスの最後に置かれているのではなく、Authorization、Policy、Operator と一緒に配置されていて、実行全体の一部になっています。私はその部分を何度も読み返して、最初の理解がずれていたことに気づきました。これまでの多くのシステムは結果を保存していました。取引が成功した、資産が出庫された、状態が更新された――それらはすべて記録として残ります。でも本当に問題が起きたとき、人々はなお「誰が承認したのか？」「どのルールに基づくのか？」「途中で何かの手順が飛ばされていないか？」と追及しがちです。そうした情報は、多くの場合ログだけを手がかりに少しずつつなぎ合わせるしかありません。

Newton がずっと解こうとしているのは、おそらくこの問題です。Authorization Receipt は、実行が完了したことを記録するだけではありません。これは、ある認可、その認可に対応する Policy、実行した Operator、そして最終的に生じた結果までを、一本の完全なチェーンとして結びつけています。今後誰かが今回の実行を疑ったとしても、システムは特定のノードを改めて信じる必要はなく、運用側に確認する必要もありません。この記録に沿って再検証するだけで、各ステップがなぜ成立しているのか、その根拠をすべて見つけられます。

ここまで読んで、私は突然気づきました。Receipt は Newton の中では、単なるレシートではなく、実行の責任の連鎖のようなものなのだと。

だから今、改めて Authorization Receipt を見ると、そこに残っているのは「記録」ではないと感じます。
そこに残っているのは、認可から判断、そして完了までのあらゆる根拠です。長期的に信じられるのは、おそらく特定のノードでも、ある特定のプラットフォームでもなく、誰でも再検証できるそのプロセスそのものなのです。#newt $NEWT