私は、より良いインフラとは、開発者により多くのコントロールを与えることだと思っていました……
最近、その逆が時には当てはまるのではと考えるようになりました。
設定可能な権限、カスタムのセキュリティチェック、アプリケーション固有の認可ルールなど、あらゆるものが、開発チームが正しく判断しなければならない別の意思決定を増やします。
その多くはユーザーには見えません。
しかし、そここそがセキュリティが成功するか失敗するかの要所です。
Newton Mainnet Betaについて読んでいたとき、ひとつの考えが特に印象に残りました。
このプロトコルは、プログラマブルな認可を導入するだけではありません。各チームにそれぞれ独自のセキュリティモデルを考えさせるのではなく、異なるアプリケーション間で認可がどのように表現され、検証されるべきかを標準化しようとしています。
それは、別の新機能以上に重要かもしれません。
すべてのプロトコルが認可を別々のやり方で構築してしまうと、あらゆる連携は、異なる前提、異なる失敗パターン、そして異なる運用上のリスクを理解しなければなりません。
共通の認可フレームワークは、ソフトウェアを自動的に安全にするわけではありません。
できることは、開発者がゼロから行わなければならない独自のセキュリティ判断の数を減らすことです。
それは興味深い形のスケーラビリティです。
取引をスケールすることではありません。
優れたセキュリティ実践をスケールすることです。
もちろん、標準化にはトレードオフがあります。
似た認可パターンに依存するアプリが多すぎると、弱点もよりシステム全体に波及しやすくなるかもしれません。多様性はときにレジリエンスをもたらします。
だからこそ、Newton Mainnet Betaは、どれだけ多くのアプリが連携するかだけで判断すべきではないと思います。
私はむしろ、それが柔軟性を損なうことなく、開発者が避けられるセキュリティ上のミスを減らすのに役立つかどうかに関心があります。
私が残した問いはこれです:
Web3がより複雑になっていく中で、勝つのは「最も多くの選択肢を提供する」インフラでしょうか。それとも、「ビルダーが正しく行う必要のある重要な判断の数を減らす」インフラでしょうか?
$NEWT #Newt @NewtonProtocol
$TLM $MAGMA #Binance #TradingCommunity #TrendingTopic
最近、その逆が時には当てはまるのではと考えるようになりました。
設定可能な権限、カスタムのセキュリティチェック、アプリケーション固有の認可ルールなど、あらゆるものが、開発チームが正しく判断しなければならない別の意思決定を増やします。
その多くはユーザーには見えません。
しかし、そここそがセキュリティが成功するか失敗するかの要所です。
Newton Mainnet Betaについて読んでいたとき、ひとつの考えが特に印象に残りました。
このプロトコルは、プログラマブルな認可を導入するだけではありません。各チームにそれぞれ独自のセキュリティモデルを考えさせるのではなく、異なるアプリケーション間で認可がどのように表現され、検証されるべきかを標準化しようとしています。
それは、別の新機能以上に重要かもしれません。
すべてのプロトコルが認可を別々のやり方で構築してしまうと、あらゆる連携は、異なる前提、異なる失敗パターン、そして異なる運用上のリスクを理解しなければなりません。
共通の認可フレームワークは、ソフトウェアを自動的に安全にするわけではありません。
できることは、開発者がゼロから行わなければならない独自のセキュリティ判断の数を減らすことです。
それは興味深い形のスケーラビリティです。
取引をスケールすることではありません。
優れたセキュリティ実践をスケールすることです。
もちろん、標準化にはトレードオフがあります。
似た認可パターンに依存するアプリが多すぎると、弱点もよりシステム全体に波及しやすくなるかもしれません。多様性はときにレジリエンスをもたらします。
だからこそ、Newton Mainnet Betaは、どれだけ多くのアプリが連携するかだけで判断すべきではないと思います。
私はむしろ、それが柔軟性を損なうことなく、開発者が避けられるセキュリティ上のミスを減らすのに役立つかどうかに関心があります。
私が残した問いはこれです:
Web3がより複雑になっていく中で、勝つのは「最も多くの選択肢を提供する」インフラでしょうか。それとも、「ビルダーが正しく行う必要のある重要な判断の数を減らす」インフラでしょうか?
$NEWT #Newt @NewtonProtocol
$TLM $MAGMA #Binance #TradingCommunity #TrendingTopic