Ripple、NEM、Symbolの着金の監視（モニター）に徹底的にこだわってみました。
その時に使ったコードや分かったことをまとめてみましたので、お役に立てれば幸いです。

着金トリガーサービス(着金時にプログラムを起動)
https://triggersv.com/

動作環境

利用したサーバー（VPS）環境は下記の通りです。

CentOS 8: Rocky Linux などに切り替えて使用すると、2029年まで使えます。; CentOS おすすめの移行先とは？ https://ops.jig-saw.com/tech-cate/recommendation_of_centos_predict_trend_in_japan
node.js: バージョンによりメモリーの使用量がかなり異なります。v14.18.1 あたりがいいようです。; リリース： https://nodejs.org/ja/about/releases/
pm2: node.jsのプログラムの管理にpm2 v5.1.2 を使いました。apiも使えてなかなか便利です。; pm2：https://pm2.keymetrics.io/docs/usage/quick-start/

Rippleの監視

ripple-lib(v1.10.0)を使うと簡単に着金の監視ができます。
※最新の高度な機能を使うときは、ripple-libの新バージョンxrpl.jsを使うよう勧められていますが、着金の監視だけならripple-libでも大丈夫なようです。

ripple-libのインストール：
npm install -g ripple-lib@1.10.0

ripple_monitor.js

const RippleAPI = require('ripple-lib').RippleAPI;
const api = new RippleAPI({server: 'ws://(ノードのIP:ポート)/'});
api.connect().then( () => {
  api.connection.on('transaction', ev => {
    //宛先(Destination又はAccount)で絞り込む
  });
  api.request('subscribe',{accounts:['r**～***']
  }).then(response => {
    //
  }).catch(error => {
    console.log('Subscribe Error : '+error);
  });
}).catch(error => {
  console.log('Connect Error : '+error);
});

accountsをaccounts_proposedにすると、未検証トランザクションと検証済みトランザクションの両方を監視できます。
ただし、Rippleの場合、未検証トランザクションは必ず出現する訳ではありません。

一方、検証済みトランザクションで、"tesSUCCESS"の場合、確定となります。
送金に特化したRippleでは約4秒で確定することになります。

トランザクションのタイプがPaymentの場合、送金額はdelivered_amountで調べるように勧められています。

参考：

Migration Guide
https://xrpl.org/xrpljs2-migration-guide.html

RippleAPI Reference
https://github.com/XRPLF/xrpl.js/blob/1.x/docs/index.md

Listening to streams
https://github.com/XRPLF/xrpl.js/blob/1.x/docs/index.md#listening-to-streams

subscribe
https://xrpl.org/subscribe.html

WebSocketを使用した着信ペイメントの監視
https://xrpl.org/ja/monitor-incoming-payments-with-websocket.html

着金トリガーサービス(着金時にプログラムを起動)
https://triggersv.com/

NEMの監視

NEM Walletでも使われているstompjs(v2.3.3)を使った監視用コードです。

ripple-libのインストール：
npm install -g stompjs@2.3.3

nem_monitor.js

const client = stomp.overWS("ws://(ノードのIP):7778/w/messages/websocket");
client.debug = undefined;

var Monitor =function(frame){
  client.send("/w/api/account/subscribe",{},"{'account':'N**～***'}");//(最初のsubscribeのみ)
  client.subscribe('/transactions/N**～***',function(data) {
    //宛先(recipient)で絞り込む
  });
}
var connectErr =function(error){
  console.log(error);
}
var sendPing = function(){
  client.send('0x9');
} 

client.connect({}, Monitor, connectErr);

setInterval(sendPing, 270000);//5分以内に1度pingを送信

同一アカウントの最初のsubscribeの時のみ、sendする必要がある点に注意が必要です。

さらに、5分で接続が切れるので、5分以内に1回pingを送信する必要があります。

transactionsをunconfirmedにすると、未承認トランザクションを監視できます。
NEMの場合、未承認トランザクションはノードの状態により監視できない場合があります。また、未承認トランザクションはネットワークの状態によっても発生しないことがあります。

参考：
MONITORING THE BLOCKCHAIN
https://rb2nem.github.io/nem-dev-guide/07-monitoring-blockchain/

nem-lightwallet
https://github.com/QuantumMechanics/nem-lightwallet/tree/master/lightwallet

STOMP Over WebSocket
http://jmesnil.net/stomp-websocket/doc/

着金トリガーサービス(着金時にプログラムを起動)
https://triggersv.com/

Symbolの監視

WebSocket(v1.0.34)を使った監視用コードは下記のようになります。

symbol_monitor.js

const WebSocket = require('ws');
const ws = new WebSocket('ws://(ノードのIP):3000/ws');

ws.on('error', (err) => {
  console.log(err);
});

ws.on('open', () => {
  console.log('Connection opened');
});

ws.on('message', (msg) => {
  const response = JSON.parse(msg);
  if('uid' in response){
    console.log('uid:', response);
    body = '{"uid":"'+res.uid+'","subscribe": "confirmedAdded/{N**～***}"';
    ws.send(body);
  }else{
    //宛先(recipient)で絞り込む
    console.log(response);
  }
});

confirmedAddedチャンネルをunconfirmedAddedチャンネルにすることで、未承認トランザクションを監視できます。

Symbolの場合、ノードのminFeeMultiplierの設定により、未承認トランザクションのトリガーの発生が異なります。minFeeMultiplier=25の場合、手数料が最遅0.0044XYM以上の時に未承認トランザクションのトリガーが発生します。

また、これはNEMの場合も同じですが、ブロックチェンであるがゆえに、フォークが発生してトリガーが2回発生することもあります。これは異なるブロックに2回含まれるためです。

トランザクションを宛先で絞り込む場合、アドレスを16進表示に変換する必要があります。

また、トランザクションタイプがAggregateComplete/Bonded (16705/16961)の場合、内部にトランザクションが複数含まれています。

さらに、Symbolの場合、タイムスタンプは、ブロックのheightのタイムスタンとなります。

参考：
新しいブロックの監視
https://docs.symbolplatform.com/ja/guides/blockchain/listening-new-blocks.html

チャンネル
https://docs.symbolplatform.com/ja/api.html#channels

着金トリガーサービス(着金時にプログラムを起動)
https://triggersv.com/

ノードの管理

ノードの管理は継続的で確実な監視には不可欠です。

Rippled server の管理

公開サーバーがrippled serverに加えて、xrplcluster.comが加えられました。自分でrippledサーバーを運営しない場合はこれらを利用できるようです。
wss://xrplcluster.com/
wss://s1.ripple.com/
wss://s2.ripple.com/

2021年後半以降、type=RocksDBでは同期が難しくなり、通常はNuDBを使用するように勧められています。それでも、かなり、高性能なサーバーが要求されています。個人での運営は難しくなっています。
https://xrpl.org/ja/capacity-planning.html

着金の監視では、古い履歴を使いません。それで、ledger_history の設定は下記で良いと思います。
　　[ledger_history]
　　1000

参考：
rippledサーバの利用
https://xrpl.org/ja/manage-the-rippled-server.html

NEMノードの管理

NEMの場合、スーパーノードでも未承認トランザクションのトリガーが発生しない時があります。その場合、ノードをrestartすると再び未承認トランザクションのトリガーが発生するようになります。

なお、NEMのノードを構築する際、着金を監視するためだけならservantは不要です。

javaのメモリーの割り当ては、大体下記のようにすると良いと思います。
　　8GBのVPS : java -Xms5G -Xmx5G
　　16GBのVPS : java -Xms12G -Xmx12G

参考：
NEM スーパーノードの構築
https://mizunashi-rin.hatenablog.jp/entry/2017/02/12/114147

Symbolノード(Dual)の管理

Dual(peer&api)ノードを構築します。apiノードでは未承認トランザクションのトリガーが発生しません。

NEMノードと比べて、Symbolノードは安定しているようです。それでも、ノードのメンテナンスの時を特定できないので、やはり、自分で管理することが必要になりますが、ハーベストでも利用できます。

minFeeMultiplier は、目的によりますが、下記あたりが良いかもしれません。
　　minFeeMultiplier: 25

参考：
Symbol ノードの立ち上げ
https://docs.symbolplatform.com/ja/guides/network/running-a-symbol-node.html

まとめ

大雑把に、Ripple、NEM、Symbolで着金を監視（モニター）する方法を書いてみました。
継続的で確実な監視を実現するためには他にも必要なことがありますが、気が付いたときに書き足したいと思います。
参考になれれば幸いです。

関連リンク