Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
0
Help us understand the problem. What are the problem?

posted at

updated at

Ripple、NEM、Symbolの着金を監視(モニター)する方法をまとめてみました。

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

動作環境

利用したサーバー(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);
});

accountsaccounts_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を送信する必要があります。

transactionsunconfirmedにすると、未承認トランザクションを監視できます。
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 の管理

Rippleの場合、公開されているrippled serverはテスト用となりますから、本番では自前で準備する必要が有ります。

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

  [node_db]
  type=RocksDB

参考:
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で着金を監視(モニター)する方法を書いてみました。
継続的で確実な監視を実現するためには他にも必要なことがありますが、気が付いたときに書き足したいと思います。
参考になれれば幸いです。

関連リンク

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
0
Help us understand the problem. What are the problem?