技術仕様
Last updated
Last updated
アーキテクチャの範囲は、コアブロックチェーンソフトウェア、ブロックチェーンインデクサー、JavaScript SDKで、様々なクライアント向けのコンポーネントがコアブロックチェーンとブロックチェーンインデクサーとのインターフェースを提供します。
ANATHAブロックチェーンのコアブロックチェーン部分は、独自のANATHA SDKを開発するために、テンダーミント（Tendermint）プロトコルを用いてセキュリティを確保し、Cosmosエコシステムを活用して構築されます。テンダーミント・コアはコンセンサスエンジンの実行とP2P接続層の管理を行います。そのため、Tendermintは実行されているトランザクションについては何の情報も得られません。トランザクションの有効性チェックやトランザクションの実行は、モジュールと呼ばれる別の機能ベースの状態マシンでANATHAネットワーク層で行われます。
このモジュールには、ANATHAアドレスを1つ以上の間が読めるブロックチェーンアドレス（DeHRA）とそれらのメタデータにリンクするすべてのロジックが含まれるほか、多通貨ウォレットやその他の暗号アドレスが含まれる場合があります。また、各ユーザーは複数のDeHRAを持つことができ、これらはそれぞれネイティブのANATHAアドレスとなっています。各ANATHAアドレスは、複数の暗号通貨のアドレスのマッピングを保持しており、暗号通貨と同じ暗号通貨内のアドレスの順番でグループ化されています。
ユーザーは、複数の暗号通貨から複数のアドレスを追加する機能を持っています。ANATHAプラットフォーム内の既知の暗号通貨の最初に登録されたアドレスは、登録料が減額されます。それ以降の登録アドレスは、登録料が増額されます。この手数料の仕組みは、ネットワークに負荷をかける悪意のある取引を減らすために設定されています。
ANATHAネットワークでは、ユーザーがバイナリデータを扱う際、Bech32アドレスフォーマットを使用します。Bech32エンコーディングは、データの堅牢な整合性チェックを提供し、人間が読める部分（HRP）は、UI開発者が有益なエラーメッセージを提供するのに役立つコンテキストヒントを提供します。ANATHAネットワークでは、キーとアドレスは、アカウント、バリデーターなど、ネットワーク内のさまざまな役割を参照する場合があります。
本章では、製品ドキュメントで定義されたANATHAのビジネスロジックを実行するために必要なモジュールについて説明します。また、既存のオープンソースのモジュールを再利用し、ゼロから構築する取り組みについても触れます。
以下の部分からなるモジュール定義フレームワークの中で、すべてのモジュールを提示します：
摘要 - ハイレベルなモジュールの目的を定義します
コンセプト - 仕様全体で使用される専門的な概念と定義を記述します
状態 - どのデータがどのようなデータ構造で保存されているかを表示します
メッセージ - モジュールの状態マシンが処理できるトランザクション
開始ブロック - 任意の開始ブロック操作を指定します
終了ブロック - 終了ブロック操作を指定します
Hooks - このモジュールが呼び出す／モジュールから呼び出すことができるフックを記述します
キーパー（Keeper） - モジュール関数の論理的な分割。キーパーメソッドはハンドラ関数からのみ呼び出されます
イベント - インデックス作成のために発行されます。イベントには、モジュールから発行されているタイプとキーおよび値が含まれます
パラメータ - 各モジュールの設定ポイント
このリストは拘束力がなく、すべての部分はオプション化されています。
authモジュールはアプリケーションの基本的なトランザクションとアカウントのタイプを指定する責任があります。ここでは、すべての基本的なトランザクションの有効性チェック（署名、nonces、補助フィールド）が実行され、アカウントキーパーが公開されます。
アカウントには、SDKブロックチェーンの一意に識別された外部ユーザーの認証情報が含まれるほか、公開鍵、アドレス、リプレイ保護のためのアカウント番号／シークエンス番号などが含まれます。効率化のために、アカウントの残高を取得して料金を支払う必要があるため、アカウントにはユーザーの残高も保存します。
authモジュールはそれ自身のトランザクション・ハンドラを持ちませんが、アンティ・ハンドラ（AnteHandler）と呼ばれる特別なハンドラを公開しています。これはトランザクションの基本的な有効性チェックを行うために使用されるため、それがミーム・プール（memempool）から投げ出される可能性があります。アンティ・ハンドラはCheckTxだけでなく、DeliverTxでも呼び出されることに注意してください。
AnteHandlerは設定可能で、追加のチェックミドルウェアを追加することができます。初期状態では、AnteHandlerは以下のチェックを実行します。
トランザクション - 既知のトランザクションタイプのみ許可
トランザクション署名チェック
手数料額チェック
authモジュールはAccountKeeperという 1 つのキーパーのみを公開しています。また、反射攻撃を保護するのためのユーティリティ機能も提供します。キーパーが公開するメソッドは以下です：
指定されたアドレスを持つアカウント・オブジェクトを生成する
連続した口座番号を持つ口座オブジェクトを生成する
ストアからアカウントを取得
ストアにアカウントを持続させる
ストアからアカウントを削除する
すべてのアカウントで反復処理
アドレスに基づいてアカウントの公開鍵を取得する
アドレスに基づいてアカウントのシーケンスを取得する
次のグローバルアカウント番号を取得する
authモジュールは、以下の構成を提供します：
トランザクション（取引）にメモとしてアタッチできるデータの最大量。メモは、オフチェーン処理を呼び出すために使用することができます
1つのトランザクションに含めることができる署名の数の上限
署名検証の規模と費用で決まる取引手数料の仕組み。
Txモジュールは、口座間のコイン送金を処理し、特定の種類の口座（特に預金口座の結合/非結合）とは異なる動作をする必要のある特別なケースの疑似転送を追跡します。 ユーザーバランスを変更する必要がある他のモジュールとの安全な相互作用のためのさまざまな機能を持ついくつかのインターフェイスを公開します。
現在のところ、Tx モジュールは固有の状態を持たず、auth モジュールの アカウント・キーパー（AccountKeeper ）を使用してアカウントを読み書きするだけです。ほとんどのトランザクションには(手数料のための)コインが含まれていることが予想されるため、コインデータをアカウントに納めることで、コインデータを個別に読み込む手間を省くことができるため、この実装は、必要な状態の読み取り/書き込みを最小限に抑えることを目的としています。
Tx モジュールは 3 つの異なるエクスポートされた3つの異なるキーパーインターフェースを提供します：
BaseKeeper - 完全許されたアクセスを提供する: アカウントの残高を任意に変更したり、コインを発行したりバーンしたりすることができる。
setCoins - アドレスでアカウントを取得し、アカウントにコインを設定し、アカウントを保存します。
addCoins/subtractCoins - アカウントのコインを取得し、指定した金額を加算/減算し、アカウントを保存します。これにより、総供給量が増加/減少します。
SendKeeper - アカウントの残高にアクセスし、アカウント間でコインを転送する機能を提供しますが、総供給量を変更することはできません：
sendCoins - あるアカウントから別のアカウントにコインを転送します。
ViewKeeper - 口座残高読み取り専用のアクセスを提供しますが、残高変更機能はありません。すべての残高検索は、一定の時間と空間の複雑さの中で行われます：
getCoins - アカウントに関連付けられたコインを返す
hasCoins - アカウントが少なくとも指定した量のコインを持っているかどうかを返す
Tx モジュールは、複数の送金残高を複数の受信アカウントに転送することをサポートする MsgSend タイプの 1 つのトランザクションのみを処理します。
以下のイベントがバンクモジュールから発生します：
Type: transfer, Key: recipient, Value:
Type: transfer, Key: amount, Value: <amount>
Type: message, Key: module, Value: bank
Type: message, Key: action, Value: send
Type: message, Key: sender, Value: <address>
Tx モジュールは、以下の設定を提供します：
トークン転送機能が有効かどうか。これは、すべての転送がロックされるコンセンサスプロトコルのテストフェーズで使用されます。
分配モジュール
この分配モジュールは、ネットワーク参加者間で報酬を受動的に分配する機能を有しています。計算の最適化のために、このメカニズムは積極的に資金を分配するのではなく、ユーザーが報酬を請求できるようにします。
分配モジュールは、モジュールまたはモジュールアカウントのいずれかでなるプールで構成されています。全体的な分配メカニズムは下図に示した通りです：
インフレ分配 - ブロックごとに発生する年間1%のインフレは、発行モジュールから転送され、AnathaマスターモジュールとNetwork Validatorリワードプールに割り当てられます
ネットワーク検証報酬プールは、普通預金口座モジュールで計算された報酬の量をロックし、前のブロックで獲得した報酬に対して残りを次のブロックに分配します。貯金プールへのアウトバウンド分配は、次のように計算されます：
普通預金口座モジュールは、24時間に1回、担保が少なくとも24時間ロックされていたすべての預金者に分配をアクティブ化します
ANATHAマスターモジュールの分配機能は1日1回発動し、以下の方法で資金を分配します：
分配金の50％は、過去24時間以内にHRAを保有していたHRA保有者の間で分配されます。報酬の対象となるのは、1口座につき1つのHRAのみです
分配金の25％がアナタ開発基金口座に振り込まれる
分配金の25%は、保有しているセキュリティ・トークンの量に比例して、セキュリティ・トークン保有者の間で分配されます。
上述のすべてのコイン分配は、積極的には行われませんが、ユーザーが自分のアカウントの引き出しを呼び出すトランザクションの送金が決定された時点まで予約されています。
Anathaマスターモジュールは、ブロックチェーンが稼働している最初の365日間の特典出金をブロックします。
ディストリビューションモジュールは以下のメッセージを処理します：
MsgWithdrawValidatorRewardsAll - バリデータが報酬を撤回したい場合は、MsgWithdrawValidatorRewardsAll を送金しなければなりません。このトランザクションはバリデータの報酬とセルフ・ステークで獲得した報酬を撤回します。このトランザクションロジックの一部は、アンボンドなどのデリゲーションの変更があった場合にもトリガーされることに注意してください。
危機モジュールは、ブロックチェーンの不変性が破られた場合にブロックチェーンを停止させます。
不変量は、アプリケーションの初期化処理中にアプリケーションに登録することができます。各モジュールは、その経路を含む不変量を危機モジュールに公開することができます。不変量は 1 つずつチェックすることができ、トランザクション（取引）料金の支払いが必要です。
不変量の検証に必要な多額のガスコストが予想されるため（および最大許容ブロックガス制限を超える可能性があるため）、標準的なガス消費方法の代わりに一定の料金が使用されます。定額料金は、標準的なガス消費方式で不変量を実行する際に予想される場合のガスコストよりも大きくなるように設定されています。
ブロックチェーンの不変性は、チェックする不変性を正確に指定するMsgVerifyInvariantメッセージを使用してチェックすることができます。このメッセージは、送金者が一定の料金支払に十分なコインを持っていない場合や、不変ルートが登録されていない場合に失敗することが予想されます。このメッセージは提供された不変量をチェックし、不変量が保たれている場合はパニックを起こし、ブロックチェーンを停止させます。不変量が保たれていない場合、トランザクションがブロックにコミットされることはないので、定数料金が差し引かれることはありません（返金に相当します）。しかし、もし不変要素が保たれていれば、一定の手数料は返金されません。
危機モジュールからは以下のイベントが発生します：
Type: invariant, Key: route, Value: <route>
Type: message, Key: module, Value: crisis
Type: message, Key: action, Value: verify_invariant
Type: message, Key: sender, Value: <address>
定額 パラメーターはグローバルパラメーターストアに保持されます。
ガバナンス・モジュールは、ブロックチェーンがオンチェーンのガバナンス・システムをサポートすることを可能にします。分散型ガバナンスシステムに進化する前に、このモジュールは閾値オンチェーン・マルチシグネチャモデルに基づいたガバナンス手順を実装します。つまり、ジェネシスブロックに登録されている参加者だけがガバナンスの提案を作成し、投票することができます。アップグレードモジュールのメカニズムを利用して、ガバナンスモジュールは分散型ガバナンスへのセルフアップグレードが可能です。(このガバナンスモジュールが構築されている間は、ANATHAマスターコントラクトからの最初のグローバル配信(ソフトローンチまでの12ヶ月間)の後に機能するようになり、ノード運営者のコンプライアンスを必要とするネットワークアップグレードを介して達成されることに注意してください。ソフトローンチの12ヶ月間、ガバナンスは2つのことを行います。トレジャリーアカウントの管理権限の付与と、ノードのソフトウェアアップデートの提案です。)
ガバナンスプロセスは、以下のステップに分かれています。
提案書の提出。提案は、事前に定義されたガバナンス・マネージャーのいずれかによってブロックチェーンに提出されます。
投票。提案書が提出されると、投票が開始されます。他の定義済みのガバナンスマネージャーは、その後、提案に投票するためにTxGovVoteトランザクションを行うことができます。
提案にソフトウェアのアップグレードが含まれている場合：
シグナル：バリデータは、新しいバージョンに切り替える準備ができたことシグナルで知らせます。
切り替え：バリデータの75%以上が切り替えの準備ができたとき、バリデータのソフトウェアが自動的に新バージョンに切り替わります。
ガバナンス・モジュールの初期バージョンでは、2種類の提案があります：
PlainTextProposal - ソースコードの変更を伴わないすべての提案がこのタイプに該当します。例えば、世論調査は PlainTextProposal タイプの提案を使用します。
SoftwareUpgradeProposal - 受け入れられた場合、バリデータは提案に従ってソフトウェアをアップデートすることが期待されます。このメカニズムはアップグレードモジュールで説明されています。
他のモジュールで公開されているプロポーザル・ハンドラとモジュール
他のモジュールは、独自のプロポーザルタイプとハンドラを実装することで、ガバナンスモジュールを拡張することができます。これらのタイプは登録され、ガバナンスモジュール（例：ParamChangeProposal、TreasuryProposal、SofwareUpgradeProposal）を介して処理されます。提案が通過すると、それぞれのモジュールの提案ハンドラが実行されます。このカスタムハンドラは、任意の状態変更を実行することができます。
初期のオプションセットには、以下のオプションが含まれています。Yes、No、Noによる拒否権（NoWithVeto）、棄権。Noによる拒否権はNoとカウントされますが、拒否権も追加されます。棄権オプションでは、有権者は提案に賛成または反対の投票をしませんが、投票結果を受け入れるという意思表示をすることができます。
定足数とは、投票結果を有効にするために提案に対して投じなければならない投票権の最小割合と定義されています。しきい値とは、提案を承認するために必要な Yes 票 (棄権票を除く) の最低割合と定義されます。
棄権票を除く投票の1/3以上がNoによる拒否権票であった場合に拒否権を行使できる可能性があります。つまり、投票期間終了時のYes票（棄権票を除く）の割合が50%を超え、Noによる拒否権の票の割合が1/3以下（棄権票を除く）であれば、提案が可決されることになります。
ガバナンス・モジュールが使用する主なデータ構造：
マッピング マップ[proposalID] -> 提案。提案タイプは、コンテンツ、ID、ステータス、結果、および異なるタイムスタンプなどの提案に関する基本情報を納めます。
map[proposedID][address] to Voteのマッピングです。このマッピングにより、提案に投票したすべてのアドレスとその投票結果を照会することができます。
ガバナンス・モジュールが処理するメッセージは以下の通りです：
TxGovSubmitProposal - 提案の提出
TxGovVote - 投票取引
発行機構は、システム内にインフレ率を発生させるように設計されています。インフレ率は最初は年1%に設定され、毎日（またはブロックごとに）計算されます。このモジュールは、いくつかのパラメータに基づく動的なインフレ率をサポートしていますが、ガバナンスの提案やネットワークのアップグレード手順によって変更することができる、固定の年間1%のインフレ率で開始します。
発行モジュールの状態は、2つの異なるストアで構成されています：
モジュールレベルのストア - 現在の年間インフレ率と現在の年間予想引当金を保持します。これらの値は、ネットワークに受け入れられた前のブロックのブロックごとに更新されます。
グローバル・パラメータ・ストア - ガバナンス提案で変更可能なパラメータ。パラメータのセクションで説明します。
発行パラメータは再計算され、以前に処理されたブロックの各ブロックの最初にインフレ率が支払われます。
目標年間インフレ率は、各ブロックごとに再計算されます。設定によって、インフレ率はまた、所望のステイク／貯金率からの距離に応じてレートの影響（正または負）も受けます。最大年間インフレ率の変化は、年間インフレの最大値と最小値だけでなく、個別に設定できます。
年次引当金は、現在の総供給量とインフレ率に基づいて各ブロックで次の式で計算されます：
ブロック条項は、現在の年間規定に基づいて各ブロックに対して生成されます。 次に、規定は発行モジュールの発行モジュールアカウントによって作成され、authのFeeCollectorモジュールアカウントに転送されます。 ブロック条項は次の式で計算されます：
グローバル・パラメータ・ストアに保存されている発行モジュールの構成可能なパラメータです：
MintDenom - 発行するコインの種類
InflationRateChange - インフレ率の年間最大変化率
InflationMax - 最大インフレ率
InflationMin - 最小インフレ率
GoalBonded - 保税資産の割合の目標
BlocksPerYear - 年間のブロックの推定値。ブロックチェーン上での時間ベースの計算には使用されませんが、推定ブロック引当金の計算にのみ使用されます。
注意: 年率1%のインフレ率を一定にするには、パラメータInflationMaxとInflationMinの両方を1%に設定する必要があります。
イベント
危機モジュールからは、以下のようなイベントが発生します：
Type: mint, Key: bonded_ratio, Value: <bonded_ratio>
Type: mint, Key: inflation, Value: <inflation>
Type: mint, Key: annual_provisions, Value: <annual_provisions>
Type: mint, Key: amount, Value: <amount>
パラメータモジュールは、さまざまなモジュールを設定するために使用できるグローバルなパラメータストアを提供します。このモジュールは、許可されたパラメータストアへのアクセスをサポートしています。
パラメータストアには主に2つのタイプがあります：
ラメータ・ストア - 既存のすべてのスペースにアクセスする権限を持っています。モジュールで使用するためには、モジュールの初期化時に注入する必要があります。
サブスペース - パラメータ保存用の隔離されたネーム・スペースで、キーの前には事前に設定された空間名が付けられます。サブ・スペースは、他のキーパー（keepr）が変更できないプライベートなパラメータ・ストアを必要とする他のモジュールで使用することができます。
このモジュールは、ブロックチェーンがプルーフ・オブ・ステークシステムをサポートすることを可能にします。このシステムでは、チェーンのネイティブ・ステーク・トークンの保有者がバリデーターとなり、ステーク・トークンを利用して、最終的にシステムの有効なバリデーター・セットを決定することができます。他のPoSネットワークとの具体的な違いは、このシステムでは、すべてのバリデータが自分のステークと同じ議決権を持つということです。このメカニズムはHRA保有者のみが利用可能です。
報酬モジュールは、ユーザーが担保をロックアップし、２４時間以内にその利息を受け取ることを可能にします。報酬モジュールは資金を預けた口座のリストを保存します。それは、Dev Ojha氏が提案したオンチェーン手数料分配モジュールを実行するためのデータ構造を保存します。リワード資金は、Distributionモジュールで説明したNetwork Validator Reward Poolから転送されます。
Anatha バリデータは、以下の 3 つの状態のいずれかになります：
アンボンド - バリデータはアクティブなセットにはありません。ブロックに署名することはできず、報酬も得られません。
ボンド済み - バリデータが十分なボンドトークンをステークすると、EndBlock中に自動的にアクティブなセットに参加し、ステータスがボンド済みに更新されます。ブロックに署名することで、報酬を受け取ることができます。悪質な行為をした場合は削減される可能性があります。もしバリデータがバリデーティングを停止したい場合は、その旨をアナウンスし、チェーン固有のパラメータであるアンボンド・タイム（UnbondingTime）の期間を待たなければなりません。その間、トークンの結合期間中に違反が犯された場合、それらの違反は引き続き削減されます。
Unbonding-バリデーターが選択によって、またはスラッシングやトゥームストーンによってアクティブセットを離れると、トークンがBondedPoolから転送される前に、ステークのアンボンドが開始され、指定されたアンボンド・タイムが続きます。
現在のステイクの実装では、以下のような重要な概念があります：
演算子 - バリデータを実行し、トークンをステイクするエンティティを表すキーペア
バリデータ - コンセンサスに参加するキーペア。一人のオペレータがそのバリデータキーを変更することを決めることができます。Tendermint が見ているのは、次のようなものです。
バリデータセットはトップの MaxValidators から形成され、バリデータセットに参加している時間の長さで分けられます。このセットは頻繁に変更されるわけではないので、待機しているバリデータに対してインセンティブを与えます。
ステイクモジュールは以下のメッセージを処理します：
MsgCreateValidator - ブロックチェーンに新しいバリデータの可能性を通知します。メッセージには、ステークされるMinSelfDelegationコインの事前定義された量が含まれていなければなりません。
MsgEditValidator - バリデータの情報を次のように変更できるようにします：アドレス、説明
MsgBeginUnbonding - バリデータがコンセンサスアルゴリズムに参加する必要が無くなったことを ネットワークに通知します。バリデーターは、利害関係を主張する前にUnbondingTimeを待つ必要があります。
終了ブロックイベントでは、いくつかの重要な変更が行われます：
この処理の間にステークバリデータセットが更新されます。この処理の一環として、更新されたバリデータは テンダーミント（Tendermint） に戻され、コンセンサスレイヤーでテンダーミント・メッセージの検証を行う テンダーミント・バリデータセットに含まれます。新しいバリデータセットは、パワー順にソートされた上位の MaxValidators で構成されます。このバリデータセットは前のバリデータセットと比較され、不足しているバリデータはすべてトークンのバインドを解除し始め、新しいバリデータは即座に結合されます。トークンの転送はすべて 結合プールと非結合プールの間で行われます。
バリデーターが（投獄されているか、十分な数のトークンが結合されていない）結合されたバリデーターセットを離れると、結合解除プロセスが開始されます。 この時点で、バリデーターはunbondingバリデーターと呼ばれ、UnbondingTime期間が経過すると、「unbondedバリデーター」になります。 各ブロックのバリデーターキューは、成熟した非結合バリデーターをチェックされます。 この時点で、成熟したバリデーターはすべて状態から削除されます。
ステイクモジュールは以下のパラメータを提供します。
MinSelfDelegation - すべてのバリデータが投入しなければならないステークの量
UnbondingTime - バリデーションの停止を決定した後、バリデータの担保を解除するのに必要な時間
MaxValidators - 1回のコンセンサスラウンドで使用できるバリデータの最大数
BondDenom - 世界的なステーキング通貨のデノミネーション
スラッシング・モジュールは、プロトコルに認識されたアクターによるあらゆる起因アクションにペナルティを課す（「スラッシング」）ことで、問題となる可能性を持つアクションを無効化します。 ペナルティは次のとおりです。
ある程度のステークをバーンします
一定期間、将来のブロックに投票する機能を削除します
任意の時点で、状態マシンに登録されているバリデータの数はいくらでもあります。ブロックごとに、ロックされていない MaxValidators のトップバリデータは保釈され、 ブロックの提案や投票を行うことができるようになる。保留されているバリデータが、プロトコルの誤りを犯した場合にその一部または全部が危険にさらされることを意味します。
スラッシング・モジュールが処理するプロトコル障害は以下の通りです：
ダブルブロックサイン (Equivocation)
Liveness faults - バリデータは、いくつかのブロックのプレコミットのリストに含まれなかった場合、自動的にロッカーに入れられたり、潜在的にスラッシュされたり、拘束されなくなったりすることで、ペナルティを受けます。
スラッシング・モジュールは、すべてのスラッシング違反に対する罰則をグローバルに保存していますが、Livenessの違反は軽い違反であるため、Livenessの違反のみを扱い、より深刻なコンセンサス違反は証拠モジュールで扱います。
Livenessのスラッシュは違反が発生するとすぐに検出されるため、さらに違反の証明を受け取るためのスラッシュ期間は必要ありません。バリデータはすぐにロッカーに入れられ、逸脱トランザクションを送金するまでは別の違反を犯すことはできません。
各ブロックには、前のブロックのバリデータによるプレコミット（ precommit）のセットが含まれており、これは Tendermint が提供する LastCommitInfo として知られています。LastCommitInfoは、総投票力の+2/3のプレコミットが含まれている限り有効です。
バリデータの活性化活動に関する情報は ValidatorSigningInfo によって追跡されます。これは以下のようにストア内でインデックス化されます：
ValidatorSigningInfoは、コンセンサスアドレスをキーとするマップに格納されます。
MissedBlocksBitArrayはマップに格納されます。キーはコンセンサスアドレスであり、値はビット配列を表します。各ビットは、バリデーターがビット配列の特定のインデックスのブロックをミスしたかどうかを表します。
ValidatorSigningInfo構造体は、以下の情報を保持します：
Address - バリデータのコンセンサスアドレス
StartHeight - 候補者がアクティブなバリデータになったときの高さ（投票力が 0 でない場合）
IndexOffset - バリデータがブロック内で結合されるたびにインクリメントされるインデックスで、プレコミットに署名したかどうかを示します
JailedUntil - バリデータがライブネスのダウンタイムによって停止するまでの時間
Tombstoned. バリデータがtombstoned（廃棄）になっているかどうかを示します。この値は、バリデータが等号化をコミットしたときやその他の設定された不正行為があったときに設定されます。
MissedBlocksCounter：配列の不必要な読み込みを避けるためのカウンタです。SumMissedBlocksBitArray)は常にMissedBlocksCounterに等しいことに注意してください。
スラッシング モジュールは以下のメッセージを処理します：
Unjail - バリデータがダウンタイムのために自動的に結合を解除され、オンラインに復帰して結合セットに復帰することを希望する場合。MaximumBondedValidators の上位に入るための十分なステークを持っているバリデータは、自動的に結合が解除され、再び報酬を収集し始めます。
各ブロックの開始時に、各バリデータの ValidatorSigningInfo を更新して、スライディングウィンドウを越えて活性化のしきい値を下回ったかどうかをチェックします。このスライディングウィンドウは SignedBlocksWindow で定義され、このスライディングウィンドウ内のインデックスは ValidatorSigningInfo に含まれる IndexOffset で決定されます。処理されるブロックごとに、バリデータが署名したかどうかにかかわらず IndexOffset がインクリメントされます。インデックスが決まると、MissedBlocksBitArrayとMissedBlocksCounterもそれに応じて更新されます。
最後に、バリデータが活性初期値を下回ったかどうかを判断するために、 失敗したブロックの最大数を出します：
そして、活性度を判断できる最小の高さ (minHeight) を取得します。現在のブロックが minHeight よりも大きく、バリデータの MissedBlocksCounter の値が MaxMissed よりも大きい場合、バリデータは SlashFractionDowntime で切断され、DowntimeJailDuration に拘留され、以下の値がリセットされます。MissedBlocksBitArray、MissedBlocksCounter、IndexOffsetです。
スラッシング・モジュールは、以下の設定可能なパラメータを提供します：
SignedBlocksWindow
MinSignedPerWindow
ダウンタイム・ジェイル期間
スラッシュフラクションダブルサイン
スラッシュフラクションダウンタイム
注記 ： 説明のないパラ メーターについては、開始ブロック の章で説明しています。
証拠モジュールでは、不正行為の恣意的な証拠の提出と処理を可能にします。
このモジュールは、他のモジュールがCrisisモジュールと同様の証拠チェックロジックを登録するためのAPIを提供します。 提出された証拠は、最初に証拠モジュールのルーターを介してルーティングされ、その特定の証拠タイプに対応する登録済みハンドラーを見つけようとします。 各証拠タイプは、正常にルーティングおよび実行されるために、証拠モジュールのキーパーにハンドラーが登録されている必要があります。 特定の証拠タイプのハンドラーは、スラッシング、ジェイル、トゥームストーンなど、任意の状態を遷移できます。
現在、エビデンスモジュールは、州内で有効に提出されたエビデンスのリストのみを保存しています。
証拠は、MsgSubmitEvidence メッセージを通して送金されます。メッセージ内で提供された証拠は、正しく処理されルーティングされるために、 証拠モジュールの ルーター に登録された対応ハンドラを持っていなければなりません。
アプリケーションレベルの証拠処理のための一般化されたフレームワークとは別に、証拠 モジュールは、基礎となるコンセンサスエンジンのためのビルトイン（built-in）の証拠ハンドラを提供します。関連する情報は abci.RequestBeginBlock の ABCI Evidence としてアプリケーションに転送され、それに応じてバリデータは罰せられます。
現在、証拠モジュールは、開始ブロック中にテンダーミント（Tendermint）のABCIEvidenceTypeDuplicateVoteから派生した二重署名タイプの証拠のみを扱います。
有効であるけれど曖昧な証拠がブロックに含まれている場合、バリデーターのステークは、スラッシングモジュールによって定義されたSlashFractionDoubleSignによってスラッシュされ、違反が発生したとき（証拠が発見されたときではなく）のステークが何であったかを示します。さらに、そのバリデータは永久に投獄され、トューム・ストーン（墓石）化されてしまうので、そのバリデータがバリデータセットに再入力できなくなります。指定したMaxEvidenceAgeよりも古くない証拠のみが考慮されます。
エビデンスモジュールには、以下のパラメータが含まれています。
MaxEvidenceAge - パラメータよりも古い証拠は考慮されません。
供給モジュールは、チェーン内のコインの総供給量を受動的に追跡し、他のモジュールがコインを保持/操作するためのパターンを提供し、チェーンの総供給量を検証するためのセキュリティ不変チェックを導入します。
ネットワークの総供給量は、すべてのアカウントからのすべてのコインの合計に等しくなります。総供給量はコインが発行されたりバーンされたりするたびに更新されます。
供給モジュールは新しいタイプのアカウント(ModuleAccount)を導入し、モジュールがトークンを割り当てたり、特別な場合には発行やバーンをするために使用することができます。基本的に、これらのモジュールアカウントは、アカウントや他のモジュールアカウントとの間でトークンを送受信することができます。
各モジュールアカウントは、特定のアクションを実行するための異なるオブジェクト機能を提供する異なるパーミッションのセットを持っています。権限は 供給キーパー の作成時に登録しておく必要があり、モジュールアカウントが許可された機能を呼び出すたびに、キーパーが特定のアカウントの権限を調べ、アクションを実行するかしないかを決めることができます。
状態
供給モジュールストアは、チェーンの総供給量を追跡するだけです。
供給キーパーは、モジュールアカウントに関連した AuthKeeper, BankKeeper のラッパー関数を提供して、以下の機能を可能にします：
ModuleAccounts の名前を指定することで、ModuleAccounts を取得・設定する
名前を渡すことで、他のModuleAccountsや標準アカウントからコインを送金します
モジュール・アカウントからコインを発行したり、バーンしたりします
アップグレード・モジュールは、ライブチェーンをスムーズに新しい（ブレークする）ソフトウェアバージョンにアップグレードさせることができます。これはBeginBlockerフックを提供することで実現され、事前に定義されたアップグレードブロックの時間や高さに達すると、ブロックチェーンの状態マシンが進行しないようにします。 このモジュールは、ガバナンスがどのようにアップグレードを決定するかについては何も想定していません。アップグレードをソフトウェアがサポートしていない場合、 ライブチェーンのアップグレードは高リスクを抱えています。 なぜなら、すべてのバリデータがプロセス中のまったく同じポイントで 状態マシンを一時停止させる必要があるからです。これが正しく行われていないと、状態の不整合状態によって、復旧が困難になる可能性があります。
アップグレード・モジュールでは、ライブアップグレードが予定されているプランタイプを定義します。プランは、特定のブロックの高さや時間でスケジュールすることができますが、両方ではありません。プランは、適切なアップグレードハンドラと一緒に（フリーズした）リリース候補が合意された時に作成されます。通常、プランは、SoftwareUpgradeProposal のガバナンス提案プロセスを通じて作成されます。プランの情報には、アップグレードに関するさまざまなメタデータを含めることができます。一般的には、アプリケーション固有のアップグレード情報、例えばバリデータが自動的にアップグレードできるようにするための git コミットなどをオンチェーンで含めることができます。アップグレードのプロセスは、ノードの運用者が完全に自動化することができます。Info フィールドに必要な情報を入力することで、バイナリを自動的にダウンロードすることができます。
アップグレードモジュールの内部状態は、比較的最小限でシンプルです。状態には、現在アクティブなアップグレードプラン（存在する場合）がキー 0x0 で示され、プランが「完了」とマークされている場合はキー 0x1 で示されます。
このモジュールにメッセージをリレーするルートは、アップグレード計画を開始する唯一の方法である Governance モジュールにのみ渡されます。
以下のメッセージは、Governance モジュールで利用可能です：
ソフトウェアアップグレード提案
ソフトウェア アップグレード提案のキャンセル
保存モジュールでは、ユーザーは担保をロックアップし、24時間以内に利子を受け取ることができます。
節約モジュールは、資金を預けた口座のリストを保存します。これは、Dev Ojha氏が提案したオンチェーン手数料分配モジュールを実行するためのデータ構造を保存します（https://drops.dagstuhl.de/opus/volltexte/2019/11400）。貯蓄資金は、Distribution モジュールで説明した ネットワーク・バリデータ報酬プール から転送されます。
保存モジュールは以下のメッセージを処理します：
MsgDeposit - ユーザーは自分のアカウントで利用可能な資金の25%を超えないように入金することができます。
MsgWithdraw-ユーザーが普通預金口座から指定された金額を引き出すことができます。 このアクションは、貯蓄ブロック時間をリセットし、指定された普通預金口座が24時間以上触れられていない利息支払い期間に利息の累積が開始されます。
MsgWithdrawInterest - ユーザーが自分のアカウントに利息を引き出すことができます。
保存モジュールには、ガバナンスによって変更可能な構成可能な金利が含まれます。
このモジュールには、Anathaアドレスを1人以上の人間が読めるアドレス（HRA）とそれらのメタデータにリンクするすべてのロジックが含まれています。これらには、多通貨ウォレットやその他の暗号アドレスが含まれる場合があります。
各ユーザーは複数のHRAを持つことができます。これらのHRAのそれぞれは、ネイティブのAnathaアドレスを指しています。各Anathaアドレスは、暗号通貨と同じ暗号通貨内のアドレスの順序によってグループ化された複数の暗号通貨のアドレスのマッピングを保持しています。ユーザーは、複数の暗号通貨から複数のアドレスを追加する機能を持っています。Anatha Platform内の既知の暗号通貨の最初に登録されたアドレスは、登録料が減額されます。それ以降の登録アドレスには、手数料が増額されます。料金の仕組みは、ネットワークに過剰な負担をかける悪意のある取引を減らすために設定されています。
内部のHRAストレージは、以下で構成されています：
map[AnathaAddress] -> HRA[] - Anatha アドレスから、アドレス所有者が所有する HRA のリストへのマッピング
map[HRA] -> AnathaAddress - HRA のハッシュ値から所有者のアドレスへのマッピング
map[HRA] -> HraInfo - HRAのハッシュ値から，与えられたHRAの仕様を記述する構造体へのマッピング
map[AnathaAddress][CryptocurrencyId][Index] -> Address - Anathaアドレスを複数の暗号通貨の複数のアドレスにマッピングするマッピング
各 HraInfo 構造体は、以下のフィールドで構成されています：
ExpiryTime - HRAの有効期限タイムスタンプ
価格 - uANATHAでHRAを販売できる価格。販売されていない場合は0
HRAモジュールは、以下のメッセージの処理をサポートします：
RegisterHRA - 署名者のアドレスを登録されたHRAに結びつけるパラメータ化されたコストを持つメッセージ。このトランザクションへの追加データとして、ユーザーは、Anathaに結び付けたい初期の暗号通貨ウォレット・アドレスを渡すことができます。これがHRAの最初の登録である場合、Anathaウォレットで生成されたアドレスは、自動的に所有者のアドレスに紐付けられることになります。
RenewHRA - パラメータ化された手数料がかかる1年間のHRAよりも所有権を増やすメッセージ
SetSellingPrice - 指定した HRA の価格を設定するメッセージ
BuyHRA - メッセージは、HRAの販売価格と一致する供給価格で送金された場合、HRAを買い手に転送します
DeleteHRA - AnathaAddress -> HRA の関連付けを削除するメッセージ。これがユーザーのHRAの最後のものであれば、すべての暗号通貨アドレスのマッピングが削除されます
TransferHRA - HRAを他のユーザーに転送するメッセージ
RegisterAddress - ユーザーが外部の暗号通貨アドレスをANATHAのアドレスに結びつけ、HRAを通じてアクセスできるようにします
DeregisterAddress - 以前登録された外部の暗号通貨アドレスを削除することができます
HRAモジュールは、アドレスの変換を必要とする他のモジュールからアクセス可能なメインキーパーを公開します。キーパーが提供する関数の大まかなリストは以下の通りです：
GetHRAInfo - HRAの基本情報を返す
GetHRAByAddress - 指定したアドレスが所有するすべての HRA を返す
GetAddressByHRA - ANATHAのアドレスを返す
PersistHRAInfo - 変更された HRA 関連データを保存する
すべてのブロックの開始時に、期限切れのHRA情報とマッピングの剪定を含むメンテナンス手順が実行されます。
HRADenomination - デフォルトuANATHA
HRAAnnualPrice - 前のパラメータと組み合わせて、年間登録の合計価格を計算します。デフォルト 100000000 = 1 ANATHA
トレジャリー・モジュールは、ANATHAの初期供給を保持し、トレジャリーから転送されたANATHAの量に基づいてトレジャリー公売価格を生成し、外部のトレジャリーシステムによって買い戻されたANATHAを受け取ります。トレジャリー・モジュールは、ジェネシス・ファイルで指定された閾値要件を持つオンチェーン・マルチシグネチャ・ウォレットによって制御されます。製品ドキュメントの目的を達成するために、このオンチェーンモジュールは、バックエンドサービスのセクションで説明されている補完的なオフチェーンモジュールが必要となっています。
トレジャリー・モジュールは、このモジュールのメソッドを呼び出すことができるガバナンスモジュールへのルートを公開します。
トレジャリー・モジュールには買い戻しキューがあり、ANATHA保有者はANATHAを注文として送金し、交換で取得する暗号通貨を指定することになります。トレジャリー・バックエンドの流動性が許可される場合、転送を行いANATHAを創造します。
トレジャリー・モジュールは、ANATHAの初期供給の流入と流出に基づいて、クエリ可能な現在の価格を米ドルで保持します。0.01ドルから始まり、ANATHAトークン価格は、ANATHAが10,000,000,000（1,000万）売却されるごとに0.01ドルずつ上昇します。
0～1,000,000,000トークン販売：$0.01
10,000,001～20,000,000トークン販売：$0.02
20,000,001 - 30,000,000トークン販売：$0.03
30,000,001 - 40,000,000トークン販売: $0.04
...
7,690,000,001 - 7,700,000,000トークン販売：$7.70
トレジャリーは、実行買い戻し注文のキュー（queue ）を保持します：
ユーザーごとの注文 map[アドレス] -> Order[]
注文のグローバルリスト -> Order[]
トレジャリー・モジュールのキーパーは、以下の機能を提供します：
販売価格の更新
販売価格を公開
キュー（queue）からの注文を管理する
TransferFunds-トレジャリーから指定されたアドレスへの資金調達に基づくガバナンス提案
DepositFunds - 買い戻したANATHAの返還と売却価格の再調整
セルバック-ANATHAをトレジャリー・ファンドに預け入れ、メッセージ・メタデータにはANATHA保有者が取得を望む暗号通貨識別子が含まれるようになります
DeleteOrder - ユーザーが注文を削除できるようにします
FulfillOrder - 売戻注文を行った後、トレジャリー・バックエンドのみが送金できるメッセージです。ロックされた資金をトレジャリーの資金に戻すことになります
ガバナンス・モジュールは、ブロックチェーン上のオンチェーンのガバナンス・システムをサポートします。分散型ガバナンスシステムの展開前に、このモジュールはオンチェーン・マルチシグ（ multi-signature ）モデルのしきい値に基づいてガバナンス手順を実装します。つまり、ジェネシス・ブロックに登録されている参加者だけがガバナンスの提案を作成し、投票することができます。アップグレードモジュールのメカニズムを利用して、ガバナンス・モジュールは分散型ガバナンスへのセルフアップグレードが可能です。
Anatha管理者は、さまざまなプライベート・ネットワーク・データにアクセスし、ネットワーク・アクティビティを監視することができます。管理者ダッシュボード内のコントロールパネルから特定のシステム全体の設定を編集することもできます。
トレジャリー・バックエンドは、トレジャリー・ブロックチェーン・モジュールとの並行動作を目的としており、以下を行います：
トレジャリーバックエンドによって管理されているアカウントに転送されたANATHAの管理
様々な支払い方法を処理し、オンチェーンモジュールによって指定されたUSDの販売価格に伝えるバイヤーにANATHAを支払います。
高度な実装では、システムは、それが安く購入注文を満たすことができれば、市場をスキャンします。その際、利益はANATHAによって維持されます。
トランザクションおよびネットワーク全体のデータにアクセスするためのAPI接続性とWebインターフェースを提供する標準的なエクスプローラです。エクスプローラは、ネットワーク（ブロック、トランザクション、アドレス、残高）、HRA レジストリ（HRA ルックアップ、HRAmappings）、バリデータ（アクティブ数、パフォーマンス）に関する一般的な情報を提供します。
有資格者がバリデータとしてオンボードし、Anathaブロックチェーンのブロックを検証することを可能にするプログラム。バリデータのセキュリティと一般的なパラメータは、Anathaネットワークによって定められた基準に基づいて定義されています。バリデータの最低要件には、アクティブなHRAを所有していること、利用可能な50万のANATHAを所有していること、サーバーのアップタイムが99%以上であることなどが含まれます。
制限：
最初に開始するノードの最大数 - 50
最終的なノード数の最大数 - 300
待機リストの最大ノード数 - 無制限
Anathaが実行しているノードの総数 - 3
待機リストのリーダーボード
インデックスサービスは、ウォレットアドレスとトランザクション（取引）ハッシュによってトランザクションをインデックス化し、特定のアドレスに関連付けられたトランザクションを簡単にフィルタリングし、そのユニークなハッシュ（トランザクション・オブジェクト全体のSHA256ハッシュ）によって単一のトランザクションを簡単に照会できるようにします。
インデックスサービスは、既存のブロックチェーンノードからの新しいトランザクション（取引）を常にサブスクライブしているほか、インデックス化されたデータをRedisのデータストアに保存しています。何らかの理由でインデックスサービスの動作が停止しても、既存のデータを失うことはなく、最後に保存されたブロックから同期は継続されます。インデックス作成プロセスの一環として、無効なトランザクションも保存されますが、無効なフラグが付けらるようになっています。
インデックスサービスは、ブロックチェーンから直接クエリできない情報を提供する、利用可能性の高いAPIを提供しています。これらのAPIは、ブロックチェーンエクスプローラーやウォレットなどの様々なフロントエンドで使用されます。
インデクサーがインデックスを作成する項目：
有効期限別のHRA
アドレスによる取引
Anatha SDKは、npmレジストリからインストールできるJavaScript/Node.jsライブラリです。これには、Anathaブロックチェーンと通信するためのメソッドが含まれています。Anatha SDKは、開発者がAnathaブロックチェーン上にインターフェースやアプリケーションを構築するために使用することを目的としています。
Anatha SDKは、すべてのトランザクション・タイプをインポートし、ペイロード（payload）を作成し、コアで指定された各トランザクションに署名するためのインターフェースを提供します。トランザクションの作成、署名、中継とは別に、Anatha SDKはブロックチェーンのクエリ機能を備えています。また、基本的なウォレット関連の機能もサポートします。その意味では、SDKはCLIツールと同じ機能を提供しますが、JavaScript環境用に調整されています。現在SDKが提供している機能の一部を紹介します。
Anatha ウォレットの初期化（キーペア）
キーペアを生成することで
未加工のプライベートキーをインポートすることで
アドレスの残高確認
ANATHAコインの署名・取引
各ブロックおよび各トランザクションで発生するWebSocketイベントリスナー
モジュールのクエリとトランザクション関連の機能：
接続されているノードの状態を問い合わせる
クエリ：
Block - 指定された高さのブロックの検証済みデータを取得する
トランザクション - 与えられたタグ（イベント）またはハッシュに一致するすべてのトランザクションを検索します。
口座残高
状態は、すべてのモジュール（ガバナンス、ディストリビューション、ステーク、スラッシュ、HRA、保存、トレジャリー...）で公開されています。
トランザクション：
署名されたトランザクションの作成と中継をします
オフラインで生成された署名をブロードキャストします
すべてのモジュールで公開されているメッセージ（ガバナンス、ディストリビューション、ステーク、スラッシュ、HRA、保存、トレジャリーなど
アプリケーションの主なインターフェースの一つは、コマンドラインインターフェースです。このエントリポイントは、エンドユーザがメッセージやクエリを作成できるように、アプリケーションのモジュールからコマンドを追加します。
トランザクションは、有効なブロックに含まれるようになったときに状態変化を引き起こすメッセージをラップするために、ユーザによって作成されます。トランザクション・コマンドは通常、各モジュールの tx.go ファイルで公開されます。
クエリを使用すると、ユーザーはアプリケーションまたはネットワークの状態に関する情報を収集できます。 それらはアプリケーションによってルーティングされ、それらが定義されているモジュールによって処理されます。 通常、クエリコマンドには独自のquery.goファイルがあります。
CLI ツールは anathacli と呼ばれ、コンパイルされた Golang バイナリ実行ファイルになります。
リストされたモジュールからの各メッセージは、CLIによって細工することができます。
アドレス Bech 32 プレフィックス
パブリックBech32プレフィックス
定義
anatha
anathaパブ（anathapub）
アカウントアドレス／パブリックキー
anathaバルコン（anathavalcons）
anathaバル共同体
バリデータのコンセンサスアドレス／公開鍵
anathaヴァルパー（anathavaloper）
anathaバルーパーパブ（anathavaloperpub）
バリデータオペレータのアドレス／公開鍵
