標準だが安全でないトランザクションとは?

このトランザクションはわかりやすい状況で発生します。それは、コールドウォレットから忽然と全残高が消える現象を生み出している原因が、この「標準だが安全でないトランザクション」です。ちなみに「全残高が消える」、ここが重要で、そこが全原因を作り出しています。よりにもよって「全残高が消える」が原因を作り出しているとは(^^;、でした。

そして、その技術的な理由を書くには非常に複雑で何ページにも渡るような内容になる上、その詳細を書くのは良くない可能性もある(まだ「未解決」です)ため、ここでは割愛し、概要だけに留めます。

トランザクションが発生した場合、その特徴は次の4つのタイプに分類されます。

1, 標準かつ安全なトランザクション
2, 非標準だが安全なトランザクション
3, 標準だが安全でないトランザクション
4, 非標準かつ安全でないトランザクション

メモリプールに追加する前のトランザクションチェックはハードコーディングされています。この過程で、標準か非標準かを区別するために、タイプ2とタイプ4が除外されます。

ところで、タイプ1は通常のトランザクションで、問題がありません。では、残るのはタイプ3ですね?

このタイプ3は動的な性質を持つため、ハードコーディングで除外することができません。そのため、AIの推論が活用されます。

ところが、トランザクションがメモリプールに入ってしまうと、標準的だが安全でないトランザクションをキャンセルするのは難しいことに気付きました。全ノードでAI監視を行えば、そのようなトランザクションを取り除けると考えていましたが、この考えは甘いという結論に至ります。

理由として、トランザクションをキャンセルする操作がAIによって行われたのか、それともそうでないのかを区別できず、正当なトランザクションが恣意的にキャンセルされてしまい、スパムに発展する恐れがあるからです。

したがって、やはりメモリプールに入る前の異常検知にAIの推論を実装するのが有効だということが明確になりました。つまり、メモリプールに入る前にAIの推論などの技術を使ってそのような『標準的だが安全ではないトランザクション』を無効化するというアイデアです。

ところが、その方法も意味がありません。なぜなら、ハッカーが組み立てた「標準だが安全でないトランザクション」を、狙われたノードのメモリプールに放出する必要がないためです。

そこで、その狙われたノードにはAIの推論による監視が実装されていたとします。「標準だが安全でないトランザクション」をそのノードに放出した場合は、確かにその監視がそのようなトランザクションを弾くことでメモリプールに放出されることはなく、その結果、ブロックに取り込まれることがないため、取引は成立しません。

しかし、ブロックチェーンは分散性です。各ノードはそれぞれ独立し、利用者はどのノードを利用してもブロックに取り込めるトランザクションを放出することができます。つまり、AIの推論による監視が実装されたノードにそのようなトランザクションを放出する必要性がなく、ハッカーはメモリプールへの受け入れ設定がゆるいノードに、そのようなトランザクションを放出すれば良いことになります。

ちなみに、トランザクション受け入れの厳格さは「ブロックへの取り込み」よりも「メモリプールへの受け入れ」の方が上です。つまり、メモリプールに入り、そこにマイナーが存在すれば、ブロックに取り込まれるのは「ほぼ間違いない状況」となります。そして、ブロックチェーンの性質上、ブロックに取り込まれると、その取引は不正であっても成立となります。

それで、不審なトランザクションを検知したとしても残高が失われる状態になるのです。その検知した段階で、そのようなトランザクションは別のノードから伝播することで、すでに他のメモリプールに存在する状態となっており、アラートが出た段階では「ブロックに取り込まれているのが観察できる」はずで、取引は成立しており、すでに手遅れとなります。

さらに、この現象はコールドウォレットの概念すら簡単に突破します。なぜなら、ウォレット自体は管理しているscriptPubKeyを束ねて残高を計算しているだけの存在なので、ウォレット自体はトランザクションや取引に関与していません。

よって、トランザクションを組み立てられれば、それをどのノードに放出するのかは自由に選べる状況となっており、ウォレットの概念とは独立しております。

このような感じで、どの方法も最後の一手が足りない状態で振り出しに戻されます。このような未解決に対しては、毎日アイデアを出し続けて検証を重ねていくしかありません。