電話番号を変更したとき、銀行からセキュリティ質問による本人確認を求められました。自分は正しく答えたのに、結局拒否されました。理由は、システムが照合していたのが10年前に入力されたデータで、そのとき私は1文字だけ誤って入力してしまっていて、しかもそれを思い出せなかったからです。内容は合っているのに、形式が違う。そしてシステムは、その2種類の誤りを区別できないのです。
DeFiにもまったく同じ種類の混同があります。ウォレットアドレスの大文字・小文字の違い、丸めた数値と小数の桁の違いなどは、実質的には条件に合致していても、文字列の完全一致をそのまま見てしまうせいで「一致しない」と判断され得ます。意味を理解するのではなく、絶対的な文字列照合をしてしまうからです。
@NewtonProtocol 意味ベースで条件を理解できるポリシーエンジンを作れれば、この手の理不尽な拒否をかなり減らせます。
自己反論:ただ、「意味を理解して“柔軟に対応する”仕組み」を作れば作るほど、複雑なデータ正規化の層がさらに必要になります。そして各層が増えるたびに、新たなエラーが生まれる可能性も増えます。正規化しすぎると、本当は異なる2つの値を同じものだと見なしてしまい、逆に危険なリスクが発生します。つまり、「間違いなのに正しいと思って受け入れる」ことにつながり得るのです。
@NewtonProtocol の難しさは、システムをもっと賢くすることではありません。難しいのは、その“柔軟さの適切な限界”を見つけること——形式の違いによる無害な差異は拒否しない程度にしつつ、本当に重要な差異まで曖昧にしてしまわないことです。
$NEWT だから、意味理解の技術を採用したかどうかだけで評価するのではなく、その限界をどこに見いだせたかで評価されるべきです。
#newt $LAB $SAROS
DeFiにもまったく同じ種類の混同があります。ウォレットアドレスの大文字・小文字の違い、丸めた数値と小数の桁の違いなどは、実質的には条件に合致していても、文字列の完全一致をそのまま見てしまうせいで「一致しない」と判断され得ます。意味を理解するのではなく、絶対的な文字列照合をしてしまうからです。
@NewtonProtocol 意味ベースで条件を理解できるポリシーエンジンを作れれば、この手の理不尽な拒否をかなり減らせます。
自己反論:ただ、「意味を理解して“柔軟に対応する”仕組み」を作れば作るほど、複雑なデータ正規化の層がさらに必要になります。そして各層が増えるたびに、新たなエラーが生まれる可能性も増えます。正規化しすぎると、本当は異なる2つの値を同じものだと見なしてしまい、逆に危険なリスクが発生します。つまり、「間違いなのに正しいと思って受け入れる」ことにつながり得るのです。
@NewtonProtocol の難しさは、システムをもっと賢くすることではありません。難しいのは、その“柔軟さの適切な限界”を見つけること——形式の違いによる無害な差異は拒否しない程度にしつつ、本当に重要な差異まで曖昧にしてしまわないことです。
$NEWT だから、意味理解の技術を採用したかどうかだけで評価するのではなく、その限界をどこに見いだせたかで評価されるべきです。
#newt $LAB $SAROS
