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

従来のストリーミングデータパイプラインは、オンチェーン の監視機能への対応が困難です。

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

3つのチェーンで月額4,000ドル。運営を継続するためにequipe を4に設定する

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

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

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

Defimon社は、自社で管理していたパイプラインをQuicknode （Streams ）に切り替えました。移行はnear-instantで行われました。既存の検知ロジックはそのまま引き継がれ、equipe は一から再構築することなく稼働を開始しました。

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

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

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

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