Defimon：ストリームを活用したリアルタイムDeFiセキュリティ

従来のストリーミングデータパイプラインは、オンチェーン監視への適応が難しい

Defimonは、数百万件のウォレットアドレスやコントラクトのやり取りをリアルタイムで追跡しています。当初の構成では、AWS上で動作するApache Flink SQLパイプラインがこの監視リストをメモリ内に保持していました。しかし、監視対象範囲が拡大するにつれ、メモリ不足エラーが発生するようになり、代替案の検討が必要となりました。システムは、監視が必要な範囲の拡大に対応できなくなっていたのです。

3つのチェーン店に対し月額4,000ドル、運営を維持するために4人のチームを配置する

AWSでは、わずか3つのネットワークを運用するだけで、インフラコストが月額約4,000ドルかかり、3～4人のエンジニアが必要でした。その業務内容は、RPCデータの手動抽出、SQLスキーマの管理、パイプラインの障害のデバッグなどでした。チームの専門知識は検知ロジックにあったにもかかわらず、そのノウハウをインフラの運用管理に費やしていたのです。

アラートの品質を低下させたブロックの遅延

手動によるRPCポーリングでは、1ブロックあたり約2秒の遅延が発生していました。検知のタイミングによってプロトコルチームに警告が間に合うかどうかが決まる製品にとって、これは構造的な問題でした。

Defimon社は、自社で管理していたパイプラインをQuicknode Streamsに切り替えました。移行はほぼ瞬時に行われました。既存の検知ロジックはそのまま引き継がれ、チームはゼロから再構築することなく、すぐに運用を開始することができました。

メモリの問題、発生源で解決

Streamsの上流フィルタリング機能と、キーバリューストアのリストとのネイティブ連携により、Defimonは、データがパイプラインに到達する前に、アドレス、コントラクト、またはイベントタイプごとに、どのデータをシステムに取り込むかを正確に定義できるようになりました。ウォッチリストは、もはやRAM上に存在し、膨れ上がってクラッシュを引き起こすような状態ではなくなりました。監視対象のアドレスの追加や削除は、エンジニアリング作業ではなく、単なる設定変更で済むようになりました。

1つのパイプライン。8つのチェーン。

イーサリアム、BNBスマートチェーン、Arbitrum、Base、Polygon、Avalanche、Optimism、HyperEVMはすべて、単一のStreams統合を通じて稼働しています。新しいチェーンを追加しても、もはや新たなインフラの構築は必要ありません。設定ファイルを更新するだけで済むのです。チームは、断片化したAWS環境全体で3つのチェーンを管理していた状態から、1人の担当者が8つのチェーンを管理する体制へと移行しました。