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

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

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

3つのチェーン店に対し月額4,000ドル、運営には4人のチームが必要

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

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

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

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

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

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

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

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