整理してみた。英語だが。
これが『ベスト』プラクティスかどうかはちょっと判断が難しいが
少なくともある程度考慮が必要な部分を測る土台にはなる。
BaseContractとか、BaseCommonって言うのは構成上ここにチェックや
基本属性の設定・取得の処理を入れておけばいいよ、と言う実装上のパターンを示すもので
トークン構成の本質ではないので一旦外すと、おおまかな構成は以下の表のようになる。
- TokenFilter ： フィルターコントラクト
- アプリケーションから直接呼び出される窓口となるコントラクト
- 必要に応じて複数のフィルターコントラクトが実装される
- ほぼ全て処理を他のコントラクトコード（コイン操作等）に委譲している
- 例えばトークンセールの初期キャンペーンで20%OFFとか20%トークン増量とかやる場合は、専用のFilterを用意してその処理差分だけを実装するイメージ
- Filter単位でそうした差分を実装し、Filter単位でコントラクトを破棄（廃止）できる
- AuthenticateService ： 認証コントラクト
- コントラクトを利用するユーザアカウント（アドレス）の把握と管理を行う
- ユーザアカウント（アドレス）単位での権限設定と権限の取得も行う
- ContractNameService ： アドレス解決コントラクト
- 各コントラクトの名前とアドレスの対応管理と解決を行う
- 各コントラクトコードは例え不備が発覚しても更新できず、新規アドレスで再登録になる
- 故に各サービス名で現時点の呼び出し先アドレスを取得するために必須となる
- トークン本体コントラクトと並んで（あるいはそれ以上に）一度デプロイしたら二度と変更してはならないコントラクトなので、確実なものを初回でアップする必要がある（難しい処理のないシンプルなコントラクトコード実装）
- TokenERC20 ： トークン本体コントラクト
- トークン本体『コントラクトコード』とは言うが、実態はトークンそのもの
- 実装上はいくつかの「手堅い・枯れた・プリミティブな」トークン操作処理が記載されるが、それ以上の操作の付加的な処理はトークン操作コントラクト側で分離実装される
- トークンそのものなので、一度でもトークンの配布や取引が行われたら、永続的にそのまま利用され、再登録されてはならない（再登録は過去の取引履歴や残高のリセットを意味する）コントラクトである
- ただ、履歴を放棄するか手間をかけてトランザクションの内容を転記すれば、新規のトークン本体コントラクトに内容をコピーすることは可能
- TokenOperator ： トークン操作コントラクト
- トークン操作を行うコントラクトコード、トークンの実体データは保持しない
- フィルターコントラクトと１：１の関係になり、増量や割引の処理実装が反映されるケースもある
- 操作にバグがあったり、改善・追加を施したい場合はトークン操作コントラクトのみを再デプロイするので（新規アドレスに対する名前解決の登録は必要だが）、トークン本体の取引履歴や状態に影響を与えないで済む
実装時に気にするべき基本的な考慮・制限は以下のとおり。
まだまだ、全然足りないかもしれないので、気づき次第追記していく。
| 役割 | 内容 |
|---|---|
| サーキットブレイカー | 問題が発生したとき、可及的速やかに全ての操作を停止させるための仕組み |
| 管理者（オーナー）チェック | 管理者でなければアカウントの管理や、サーキットブレイカーの発動を行えないようにする仕組み |
| 管理アカウントチェック | コントラクトを操作できる登録ユーザ（アカウント）自体を管理し、実行制限を施しておく仕組み |
| アカウント権限チェック | 必要に応じて各コントラクトに権限を設け、それをアカウント管理と連動させて機能させる仕組み |
| アドレス種別チェック | ユーザ登録時や送金時にそのアドレスがコントラクトコードではないか、などを管理する仕組み（制限を入れるかどうかは要件次第となるが） |
| 有効期間チェック | キャンペーンフィルターなどの有効期間をしっかりと定めて、期間外にアクセスさせない仕組み。時間を扱うのが難しければキャンペーンの流量制限等でも。 |