モナパちゃん大型アップデートの内容

暖かくなってきてしまったのでそろそろやっていかないといけない。 実装は段階的にやっていきます。いろいろ古くなってしまったのをまとめて一新する計画なので手間がかかります。

一括sendの導入

Monapartyでトークンの一括sendができるようになったので、モナパちゃんもこれまで１種類ずつ何回も送っていたのを１回で送れるようになります。これにはメリットがたくさんあります。

  • オンチェーンでもN連ガチャができます。
  • トークン配布や大量のwithdrawなどでsendが立て込んだとき、モナパちゃんはこれを小分けにして時間をかけて処理しています。一括sendでこの待ち時間がなくなります。
  • トークン配布や大量のwithdrawなどでsendが立て込んだとき、実はモナパちゃんはよくエラーを吐いています。大抵は再送しているはずですがあまり自信はないので、人知れずGOXしていたトークンもあると思う。たぶん一括sendでこれが安定します。
  • その他にも送信負荷を抑えるために意図的に不便にしていた部分が不便じゃなくなっていくかもしれない。

DB設計の改良

最初にモナパちゃんを作った後でAWSの料金体系が改善されたので、他のアプリと共有していたテーブルをモナパちゃん専用に設計し直します。

  • オンチェーンの残高がオフチェーン（DB）の残高に対して不足していないか、定期的にチェックできるようになります。上に書いた通りsendが立て込んだ時の処理に不安があったりするので、これで安心感が増します。
  • Monapartyサーバに都度問い合わせていたトークン情報の一部をDBに突っ込むことで、処理が高速化安定化します。

ポータル改善

  • ツイート不要でこっそりトークンをwithdrawできます。さらに上記一括sendとの合せ技により、よりたくさんのトークンを一発でwithdrawできます。withdrawの枚数が個別に指定できるようになります。
  • ガチャフォームがもっと便利になります。
  • フォームで配布ツイートを生成できるようになります。
  • 配布されてるトークンでまだもらってないやつとか、まだ持ってないやつとかがわかるようになります。

既知の問題の解消

  • mona1アドレス（Native Segwitアドレス）に対応します。
  • ガチャからちゃんと全部のカードが出てきます。

anipopina.hateblo.jp

その他の仕様変更

@usernameがcase sensitiveじゃなくなる

たぶん預入時やtip時の@usernameの大文字小文字が違っていても大丈夫になります。

再移転不可トークンの取扱不可

以下の理由で再移転不可トークンの取り扱いを完全にやめます。

  • 最初は再移転不可トークンがモナパちゃん上で矛盾なくやりとりできたらおもしろいかと思っていたけど、全然そんなことはなくて無駄に混乱するユーザが出ただけだった。
  • 最初から気がついてはいたけど、オフチェーンとはいえ再移転不可トークンが自由にtipできるのは「再移転不可」の意図には沿っていない。
  • Monapartyやモナパちゃんに機能が増えるたびに（上記の通り全く有効活用されていないにも関わらず）再移転不可トークンのためだけの特別な実装が出てきてめちゃくちゃ面倒くさい。

現バージョンでは再移転不可トークンは発行元のアドレスに対してのみwithdrawできるようになっているので、回収が必要な場合はアップデート前に回収しておいてください。

アップデート後、今ある再移転不可トークンは残高から消えます。そしてアップデート後にモナパちゃんのアドレスに対して送られた再移転不可トークンは漏れなく「モナパちゃん再移転不可GOX」することになります。

サブアセットのID指定の廃止

サブアセット（例: SPACEMONA.CAT）はID（例: A11616776313666346663）で指定することもできるようにしていましたが、以下の理由でこれは廃止します。

  • もともとはTOKENNAME.COMみたいなトークンがURL扱いされてしまって投げられないのでこの実装にしていたけど、いまは「TOKENNAME&COM」のように.の代わりに&を使えるようにしているのでID指定できなくちゃ困るということがない。
  • ID指定を切ることで処理とDB設計がシンプルになるので、性能と安定性と拡張性が増す。

depositコマンドとbalanceコマンドの廃止

他のチップボットとの互換性に配慮して実装していましたが、モナパちゃんに関してはほとんど意味がないので廃止します。もはや他のチップボットがTiproidしかいないし。

ガチャ仕様の調整

ノーマルガチャの値段を0.02MONAにして、代わりにノーマルでもN連ができるようにします。プレミアムガチャは0.1MONA据え置き。N連ガチャはこれまで10連までだったのを、とりあえず20連まで可能にしてみようと思います。

また、サービスの充実によってモナカード以外でもトークンにいろいろと属性が付けられるようになってきたので、整数枚で扱うトークンであればモナカード以外も出てくるようにします。

追加：200XMPで1回プレミアムガチャが回せるようにします。単価が異なるだけで仕様はGACHAトークンと同じ。

さらに追加：1日1回引けるデイリー無料ガチャを実装します。

燃料の補給先

ほしいMONAリスト運営のほしいMONAリスト ２枚目 https://monalist.komikikaku.com/list/C7rFTwN9LzSgFrRB3XJioK4xw3NVdB6wTM

既知の問題／非直感的な仕様

モナパレット

  • 基本的にChrome以外のブラウザはあんまりサポートしませんが、以下の環境では実際に表示の不具合が報告されています。
    • Pixel6 / Android v12のMpurse（WebView）
  • 発行枚数がめちゃくちゃ多くてJavaScriptの有効桁数をはみ出すトークンは数量の扱いで誤差が出る場合があります。例えば 10000000000000001 と入力したものがいつの間にか 10000000000000000 になってしまったり、999999999.99999999 であるはずの値が 1000000000 と表示されたりします。実用上そう困ることがないわりにちゃんとするのはけっこう面倒なので、ちゃんとする予定は今のところありません。
  • UTXOマネジメントの都合により「くばる」機能でMONAを配ろうとしたときに、MONAの残高が足りているのに足りていない旨のエラーがでる場合があります。これはいったんMONA全額を自アドレスに送り直すと、UTXOが１つにまとまって解消します。
  • 過去にTXを発行したことのないMpurseアドレスやmona1アドレスからデータ量の多いMonaparty TX（バイト数の多いbroadcastなど。Pay to Multisigという古い形式のoutputをもつTX）を発行しようとするとエラーになります。なにかしら別のTXを発行して世の中にアドレスの公開鍵を知らしめることで解消します。
  • Trezorでデータ量の多いMonaparty TXを発行しようとするとエラーになります。データ量を減らすかTrezor以外のアドレスを使ってください。Trezor+Trezor ConnectではPay to Multisigのoutputを含むTXへの署名をサポートしていないようなのですが、もし解決方法をご存知の方は情報をお寄せください。

GoriFi

  • Monaparty DEXの注文は内部的には板とは異なる形で管理されているので、価格の実数がXMPの最小単位（1e-8）よりも下の桁に及ぶ場合がある。価格の1e-8未満の部分がある場合は、askは切上げ、bidは切下げられて表示されるので正確な値ではなくなるが、思っていたよりも有利な条件で約定する場合があるというだけなのでそんなに気にしなくていい。
  • GoriFiは手軽さ重点なのでTX手数料の確認とかもすっとばしていますが固定長のMonapartyTXしか発行しないので全部0.001MONA未満だと思いますたぶん。

オダイロイド

いまのところ思い出せるものはない。

モナパちゃん

いくつかあった問題は2021年春の大型アップデートでぜんぶ解消しました。

Tiproid

問題というわけじゃないけどバックエンドはelectrumからblockbookに換えたい。

ほしいMONAリスト

いまのところ思い出せるものはない。最初に作ってからほとんど手を入れてないのでもっといい感じにアップデートしたいという気持ちが少しある。

Token Vault

いまのところ思い出せるものはない。荒削りだからもっとオシャレで実用的にしたい。

宇宙モナコイン

いまのところ思い出せるものはない。混沌モナコイン編に突入しました。

Monapartyのdividendの仕様

dividendの仕様変わったのでここに書いてあることは一部通用しなくなりました

詳細がドキュメントから読み取れない部分／わかりづらい部分があるので検証結果とかメモ

  • asset（株券にあたるほう）は自分がオーナーじゃないとダメ
  • dividend_asset（配当のほう）は自分がオーナーじゃなくても大丈夫
  • quantity_per_unit はassetやdividend_assetがdivisibleかどうかとは関係なくとにかく 1e8 のときにamount換算で1対1になる
  • create_dividendでdividend_asset にMONAをセットすると普通のマルチアウトプットTX（Monaparty TXじゃないやつ）を返してくれる
    • Monaparty TXと違って宛先が多くなるにつれてTX Feeが増えていくので注意
  • 個別の配当の量はdividend_assetの最小単位（dividendがtrueなら1e-8、dividendがfalseなら1）で切り捨て
    • 切り捨て後に配当を受け取ることのできるアドレスが１つもない場合にはcreate_dividendの時点でエラーになる
    • amount x quantity_per_unit x 1e-8 >= 1 を満たすアドレスが存在していれば分割できないdividend_assetでも小数のquantity_per_unitを設定できる
  • dividendの宛先の数に比例して消費されるXMPの量はcreate_dividendの結果だけではわからないので事前計算するなら別途get_holdersなどを使う必要がある
    • 切り捨てにより配当0となるアドレスがあっても消費されるXMPの量は変わらない
    • 前のバージョンではいちどassetを持ったことのあるアドレスは現在の残高が0でもXMP手数料の計算に含まれてしまっていた。最新版では含まれない。
  • assetがDEXに出品するなどでescrowになっている場合は出品元のアドレスに配当が行く
    • ただし配布数の切り捨てはescrow毎に計算される。つまり分割できないdividend_assetをquantity_per_unit=0.5で配る場合、assetを2枚保有しているがそのうち1枚をescrowしているアドレスに届く配当は0になる。
    • XMP手数料は宛先アドレス数のみに依っていてescrowで増えたりはしない

軽くしか確認していないので間違いあるかも。 create_XXXできてもブロードキャストにしくじるみたいな例も稀にあるのでそういうのを発見したら追記します。

Lambda@Edgeのハマりポイント

どのパスでも常に同じHTMLを返しているためOGPが変えられないというSPAの弊害をLambda@Edgeで解消しようとして、各種ドキュメントを隅々まで読んで慎重にやれば大丈夫なんだけど、随所にハマりポイントがあって捗らなかったので個人的に危うかったところをメモ。

  • Edgeに撒く関数はバージニア北部に作らないといけない。
  • 関数のロールの信頼関係にedgelambda.amazonaws.comを追加しないといけない。
  • オリジンレスポンス、ビューアーレスポンスでbodyを書き換えることはできないので、OGP書き換えるならリクエスト側で傍受した上でS3からhtmlファイルを取ってきて書き換えて返すとかしないといけない。
  • Lambda@Edgeでは環境変数が使えないので、CloudFrontのOrigin Custom Headersで代用する。そのへんも含めて、OGP書き換えはオリジンリクエストでやるべき。
  • Edgeに撒かれるのは特定のバージョンの関数なので、更新したらデプロイし直さないと反映されない。このとき新規でデプロイすると勝手にDefault(*)のBehaviorに追加されてしまうので注意。「この関数で既存のCloudFrontトリガーを使用」を選べば設定済みのものだけが新しいバージョンで置き換えられる。
  • Lambda@Edgeのログは通常のLambdaのログとは別でリージョン毎に残る。
  • 関数を更新した場合もCloudFrontのinvalidationを忘れずに。