Technical specifications
AUTH ModuleANATHA NETWORK
系统结构
架构范围是核心区块链软件，区块链索引器和JavaScript SDK会通过客户端的组件与核心区块链和区块链索引器进行接口。
核心区块链
ANATHA区块链的核心区块链部分将使用Tendermint协议进行保护，并通过利用Cosmos生态系统开发我们自己的ANATHA SDK。Tendermint Core负责执行共识引擎和管理P2P连接层。因此，Tendermint不会获取进行中交易的任何信息。交易有效性检查和交易执行会在ANATHA NETWORK层以单独的功能使用状态机（称为模块）进行。
去中心化式人类可读地址模块
此模块包含将ANATHA地址链接到一个或多个去中心化的人类可读地址（DeHRA）及其元数据（可能包括多货币钱包和其他加密地址）的全部逻辑。每个用户可以有多个DeHRA。每个DeHRA都对应其本地的ANATHA地址。每个ANATHA地址都可以保存多个加密货币的地址映射，这些地址在同一加密货币中按照加密货币类型和地址顺序分组。
用户可以从多种加密货币添加多个地址。已知加密货币在ANATHA平台的首次注册地址享有较低的注册费用。以后每添加一个后续的注册地址会增加相应的费用。有专门的收费机制，避免恶意交易导致网络负担过重。
地址
ANATHA NETWORK在用户必须处理二进制数据的位置上使用Bech32地址格式。Bech32编码具有强大的数据完整性检查，人类可读部分（HRP）会给出上下文提示，帮助UI开发人员获得信息的错误消息。在ANATHA NETWORK中，密钥和地址可以指代网络中的许多不同角色，如帐户、验证器等。
BECH 32前缀地址 公共BECH 32前缀 定义
Address Bech 32 Prefix | Public Bech32 Prefix | Definition |
anatha | anathapub | 帐户地址/公钥 |
anathavalcons | anathavalconspub | 验证器一致地址/公钥 |
anathavaloper | anathavaloperpub | 验证器操作员地址/公钥 |
ANATHA NETWORK模块
在本章中，我们将讨论执行Product文档定义的ANATHA业务逻辑所需的模块。我们还将讨论重新使用现有开源模块以及如何从头开始构建这些模块。
我们将介绍模块定义框架中的所有模块，该框架由以下几个部分组成：
摘要-定义高级模块用途
概念-描述规范中使用的专门概念和定义
状态-指定存储哪些数据以及以哪种数据结构进行存储
消息-模块状态机可以处理的交易
起始区块-指定任何起始区块操作
结束区块-指定任何结束区块操作
连接-描述此模块调用/从中调用的可用连接
记录-模块功能的逻辑划分，这一方法仅在处理程序功能中使用。
事件-从索引中产生。事件包括从模块发出的类型、键和值。
参数-每个模块的配置点。
该列表不具约束力，所有部分均为可选项。
AUTH模块
摘要
Auth模块负责指定应用程序的基本交易和帐户类型。它包含ANTE处理程序（Ante Handler），负责执行所有基本交易有效性检查（签名、随机数、辅助字段），并公开帐户管理员，从而允许其他模块读取、写入和修改帐户。
状态
账户包含SDK区块链唯一标识的外部用户的身份验证信息，包括公钥、地址和账号/序列号，用于重放保护。为了提高效率，考虑到用户需要使用帐户余额来支付费用，因此帐户结构还会存储用户余额。
消息
Auth模块没有自己的交易处理程序，但会公开名为AnteHandler的特殊处理程序，对交易执行基本面进行有效性检查，以便将其放入内存池。
请注意，Ante处理程序可在CheckTx上调用，也可在DeliverTx上调用。
AnteHandler是可配置的，可以向其添加额外的检查中间配件。
初始时，AnteHandler将执行以下检查：
交易类型-仅允许已知交易类型
交易签名检查
费用金额检查
记录者功能
Auth模块只公开一个记录者，即AccountKeeper，可用于读写账户。它还可以提供用于回复攻击保护的实用功能。记录者可以公开以下方法：
生成具有指定地址的账户
生成连续账号的账户对象
从商店检索帐户
将帐户应用于商店。
从商店中删除帐户
对所有客户进行迭代
根据地址检索帐户公钥
根据帐户地址检索帐户序列
取得新的全局账户
参数
Auth模块可以提供以下配置：
可作为备忘录附加到交易的最大数据量。备忘录可用于调用链下操作。
单个交易中可以包含的签名限制
交易费用机制，由签名验证的规模和成本决定
高级Tx模块
摘要
Tx模块负责处理帐户之间的通证转账，并跟踪特殊情况下与特定类型的帐户工作方式不同的伪转账，（特别是针对储蓄帐户的绑定/解除绑定）。它公开了几个具有不同功能的接口，用于与其他模块进行安全交互，这些模块必须改变用户余额。
状态
目前，Tx模块没有固有状态-它只是使用AccountKeeper从auth模块读取和写入帐户。这可以最大限度地减少必要的读/写状态。我们猜测多数交易都涉及通证金额（用于收费），因此，将通证数据存储在帐户中可以避免另外读取的步骤。
记录者功能
TX模块提供三种不同的导出记录接口，可以传递给需要读取或更新帐户余额的其他模块：
BaseKeeper-提供完全权限访问：可以任意修改任何帐户的余额或进行铸币、销毁
setCoins-按地址提取帐户，在帐户上设置通证，然后保存帐户
addCoins/subtractCoins-提取帐户的通证，加/减金额，并保存帐户，这会增加/减少总通证供应量。
·SendKeeper-提供对帐户余额访问以及在帐户之间转移通证的功能，但不能更改总供应量：
sendCoins-将通证在账户间转移
ViewKeeper-提供对帐户余额的只读访问，但不提供余额更改功能。所有余额查询服务都只能在固定的时间和空间复杂度下进行：
getCoins-退回帐户关联的通证
hasCoins-退回通证（不论账户是否有相应数量的通证）
消息
Tx模块只处理一个MsgSend类型的交易，该交易支持将多个发出余额转入到多个接收账户。
事件
银行模块发出以下事件：
类型：转账，密钥：收件人，值：<地址>
类型：转账，键：金额，值：<金额>
类型：消息，密钥：模块，值：银行
类型：消息，键：操作，值：发送
类型：消息，密钥：发送者，值：<地址>
参数
Tx模块将提供以下配置：
通证转移功能是否开启。这用于共识协议测试阶段，此时，所有转账都会被锁仓。
分配模块
摘要
此分配模块实现了在网络参与者之间被动分配奖励的功能。对于计算优化而言，该机制不会主动分配资金，而是允许用户索取奖励。
概念
分配模块由多个池组成，这些池既可以是模块，也可以是模块帐户。整体分配机制如下图所示，由以下部分组成：
通货膨胀分配-从造币模块转移到Anatha主模块和网络验证员奖励池的每个区块将会产生1%的年通胀率
网络验证奖励池在储蓄帐户模块中锁仓一定数量的奖励金额，并将剩余部分分配到下一区块中，用于在前一区块中获得的奖励。储蓄池的出站分配额计算如下：
储蓄账户模块每24小时向所有被锁仓至少24小时的储户进行一次分配。
Anatha Master模块的分配功能每天被激活一次，并会通过以下方式分配资金：
50%会在过去24小时内的HRA所有者之间平分。每个账户只有一个HRA可获得奖励。
25%转入Anatha开发基金账户。
25%在证券型通证持有者之间平分，份额与持有证券型通证的数量成正比
通货膨胀-网络验证器奖励池-储蓄账户
-Tx费用-Anatha主合同-应用程序费用
-Anatha HRA持有者 -Anatha发展基金-证券型通证持有者
所有上述的通证分配都不是主动完成的，而是会保留到用户决定使用帐户金额进行交易时为止。
Anatha Master模块不允许区块链运行的前365天进行奖励提取。
消息
分配模块处理以下消息：
·MsgWithdraValidatorRewardsAll-当验证器要撤回奖励时，必须发送MsgWithdraValidatorRewardsAll。这项交易会撤回验证器的奖励，以及从他们自己的质押中赚取的奖励。请注意，此交易逻辑的一部分也会在单独更改（例如解除绑定）中触发。
CRISIS模块
摘要
CRISIS模块会在区块链不变量被破坏时暂停区块链。
概念
在应用程序初始化过程中，可以向应用程序注册不变量。每个模块都可以向CRISIS模块公开不变量（包括其路径）。模块可以每次检查一个不变量，且收取交易费。
由于验证不变量所需gas成本很高（并有可能超过最大允许区块gas限制），因此使用定价费用代替标准gas消费。不变量费用要高于预期运行不变量gas成本的标准消费。
消息
区块链不变量可以使用MsgVerifyInariant消息进行检查。该消息可以指定哪些是要检查的确切不变量。如果发送者没有足够的通证支付恒定费用，或者不变量路径未注册，则此消息失败。消息会检查提供的不变量，如果不变量被破坏，消息就会死机并导致区块链停止。如果不变量被破坏，则不会扣除固定费用，因为交易不会提交到区块（相当于被退款）。但是，如果不变量没有破坏，不变费用将不予退还。
事件
crisis模块会触发以下事件：
类型：不变量，键：路径，值：<路径>
类型：消息，密钥：模块，值：crisis
类型：消息，密钥：行动，值：验证_不变量
类型：消息，密钥：发送者，值：<地址>
参数
固定费用参数保存在全球参数存储中。
治理模块
摘要
治理模块允许区块链支持链上治理系统。在升级成去中心化治理系统前，该模块将基于一个新的链上多重签名模型开展治理程序，这意味着只有在创世区块中注册的参与者才能参与治理提议和投票。利用升级模块的机制，治理模块可以自我更新为去中心化治理。（请注意，在构建此管理模块的过程中，它将在ANATHA主合同上进行首次全球发行（预发布12个月）后开始运行，并需要合规的节点运营商，通过网络升级来完成。在12个月的预发布期间，治理模块将进行两处操作：分配金库账户的控制权，并进行节点软件更新）。
概念
治理流程分为以下几个步骤：
提议提交：提议由预定义的治理管理者之一提交给区块链
投票：提议提交后，投票开始。然后，其他预定义的治理管理者可以发送TxGovVote交易对提议进行投票
如果提议涉及软件升级：
信号：验证器开始发出信号，表示它们已准备好切换到新版本
切换：一旦超过75%的验证器发出信号表示已准备好进行切换，其软件就会自动切换到新版本
在治理模块的初始版本中，有两种类型的提议：
PlainTextProposal-所有不涉及修改源代码的提议都属于此类型
例如，民意调查将使用PlainTextProposal类型的提议
SoftwareUpgradeProposal-如果接受，验证器应根据提议更新其软件。此机制将在升级模块中进行说明。
提议处理器及类型体现在其他模块中。
其他模块可以通过执行自己的提议类型和处理程序来扩展治理模块。这些类型通过治理模块注册和处理（例如，ParamChangeProposal、SecuryProposal、SofwareUpgradeProposal），然后在提议通过时执行相应模块的提议处理程序。此自定义处理程序可以执行任意状态的更改。
初始选项集合中包括以下选项：“是”、“否”、“否决”、“弃权”。否决视为否，弃权代表选民不打算对提议投赞成票或反对票，但接受投票结果。
法定票数的定义是为使结果有效而需要对提议投下的最低投票百分比。门槛票数的定义是为提议被接受的赞成票（不包括弃权票）的最低百分比。
最初，门槛票数设定为50%，包括有超过三分之一的选票（不包括弃权票）是否决票的可能性。这意味着，如果投票期结束时赞成票（不含弃权票）的比例高于50%，且无人投反对票的比例低于三分之一（不含弃权票），提议就会被接受。
状态
治理模块使用的主要数据结构有：
映射地图[提议ID]->提议。提议类型存储有关提议的基本信息，如内容、ID、状态、结果和不同的时间戳。
映射地图[提议ID][地址]-投票。此映射允许用户查询对提议进行投票的所有地址及其投票。
消息
治理模块处理的消息包括：
TxGovSubmitProposal-提交提议
TxGovVote-投票交易
铸币模块
摘要
铸币机制的设计是为了在系统中产生通货膨胀率。通货膨胀率最初设定为每年1%，按日（或按区块）计算。该模块支持基于多个参数的动态通货膨胀率，但从固定的1%年通货膨胀率开始，就可以通过在治理系统中提议或通过网络升级程序的方式进行更改。
状态
铸币模块状态由两个不同的存储组成：
模块级商店-保留当前的年通货膨胀率和当前的年度预期分配，同时也会在每个区块上更新网络已接受的前一个区块的这些数字。
全球参数存储-可以通过治理提议更改的参数。详情可见参数部分的说明。
起始区块
重新计算铸币参数，并在先前处理的区块的每个区块起始处支付由通货膨胀产生的金额。
每个区块都会重新计算目标年通货膨胀率。进行配置之后，根据所需质押或储蓄率的变化，通货膨胀率也会发生变化（正或负）。年通货膨胀率的最大变化金额以及年通货膨胀率的最大值和最小值可以单独进行设置。
每年的供给量是根据当前的总供应量和通货膨胀率计算出来的，公式如下：
根据当前的年度供给量为每个区块生成区块供给量。随后，这些供给量由制造模块的ModuleMinterAccount创建，然后转移到auth的FeeCollector模块帐户。区块供给量按以下公式计算：
参数
全球参数存储中的铸币模块的可配置参数如下：
MintDenom-制造的通证类型
InflationRateChange-通货膨胀率的最大年度变化
InflationMax-最高通货膨胀率
InflationMin -最低通货膨胀率
GoalBonded--保税资产百分比的目标
BlocksPerYear-预计每年的区块数量。不用于区块链上基于时间的计算，仅用于计算预计区块供给量。
请注意：要实现1%的恒定年通货膨胀率，参数InflationMax和InflationMin都需要设置为1%。
事件
crisis模块发出以下事件：
类型：铸币，键：保税比率，值：<保税比率>
类型：铸币，关键字：通货膨胀，价值：<通货膨胀>
类型：铸币，密钥：年_供给量，值：<年_供给量>
类型：铸币，密钥：金额，值：<金额>
PARAMS模块
摘要
PARAMS模块提供可用于配置不同模块的，全球可用的参数存储。它支持许可的参数存储访问。
概念
主要有两种类型的参数存储：
记录者参数存储—提供访问所有现有空间的权限。模块要想使用这一功能，需要在该模块的初始化过程中导入它。
子空间—用于参数存储的单独命名空间，其中的键会使用预先配置的空间名称作为前缀。需要私有参数存储的其他模块可以使用子空间，而其他记录功能不能修改该私有参数存储。
奖励/质押模块
摘要
通过该模块，区块链可以支持权益证明系统。在该系统中，链的原生通证持有者可以成为验证器，以最终确定系统的有效验证器集。这套系统与其他权益证明网络之间的具体区别在于，在该系统中，所有验证器都将拥有与其持有权益相等的投票权，该机制只对HRA持有者有效。
奖励模块允许用户锁定抵押金，并于24小时内获得利息。奖励模块将保存已存入资金的帐户列表。该模块将存储数据结构，并执行Dev Ojha提出的链上费用分配模块。奖励金将出自分配模块中指明的网络验证器奖励池。
概念
Anatha验证器的三种状态：
未绑定-验证器不在活动集内。它们不能在区块中签名，也不能赚取奖励。
已绑定-一旦验证器获得足够的绑定通证，就会在EndBlock期间自动加入活动集，并且其状态会更新为已绑定。此时，可以在区块中签名，并接受奖励，但如果行为不当，也会被惩罚。如果验证器想要停止验证，则必须进行公布，并且在解绑过程（UnbondingTime）中等待，UnbondingTime是链上专门的参数。在此期间，如果验证器的过错发生在通证绑定时间段内，则它们仍然可以在此期间被惩罚。
解除绑定-如果验证器选择离开活动集，被惩罚或程序崩溃而离开活动集时，在从绑定池传输其通证之前，会开始解除绑定其权益，这一过程会持续到整个解绑时间为止。
在目前的质押操作中，有以下几个重要概念：
操作器-代表运行验证器并具有通证的密钥对。
验证器-参与共识的密钥对。操作器可以决定更改其验证器密钥。
验证器集由顶层MaxValidators组成，这些MaxValidators将根据验证集内的时间量进行排序。为了支持等待验证器，该验证集不会经常更改。
消息
质押模块可以处理以下消息：
MsgCreateValidator-将新的潜在验证器通知给区块链，消息必须包含预定义数量的将被质押的MinSelfDelegation通证。
MsgEditValidator-允许将验证器信息更改为：地址、描述。
MsgBeginUnbinding-将验证器不参与共识算法的消息通知给网络。验证器需要在等待解绑时间完成后才能收回质押。
终止区块
终止区块事件上的重要更改：
在此过程中，质押验证器集会进行更新。任何更新的验证器也会返回Tendermint从而进入Tendermint验证器集中，Tendermint验证器集负责在共识层验证Tendermint消息。新的验证器集由顶层的MaxValidators组成，按功率排序。该验证器集会与前一个验证器集进行比较，所有消失的验证器会被取消通证绑定，同时新验证器会被绑定。所有通证传输都会在未绑定池（NotBondedPool）和绑定池（BondedPool）间进行。
当验证器离开绑定验证器集（因被禁闭或没有足够的绑定通证）时，解绑过程会被触发。在这时，验证器被称作解绑验证器，因此在解绑时间过后，这些验证器将会成为“非绑定验证器”。验证器队列将接受检查，此时，所有到期的验证器都将从状态中删除。
参数
质押模块提供以下参数：
MinSelfDelegation-所有验证器必须投入的押注数量，必须是准确的数字
UnbondingTime-决定停止验证后解锁验证器抵押金所需的时间
MaxValidators-每轮共识中允许的最大验证器数量
BondDenom -全球质押货币的面值
惩罚模块
摘要
惩罚模块通过对协议认可的参与者的质押价值进行惩罚来惩戒所有的可归因行为。
惩罚手段包括：
销毁部分权益
在一段时间内作废对未来区块投票的权利
概念
在任何给定时间内，状态机内都有任意数量的注册验证器。在每个区块中，未被禁闭的顶层MaxValidators验证器将会被绑定，它们可对区块进行提议并投票。被绑定的验证器会存在风险，如果犯了协议错误，其部分或全部权益将面临这些风险。
惩罚模块处理的协议错误包括：
重复区块签名（描述不清）
活跃性错误-如果验证器因自动被禁闭、惩罚和解绑，则不会被纳入拥有一定数量区块预提交列表中，并需要接受惩罚。
惩罚模块中有所有的惩罚都会被储存进全局存储，但因为这类错误程度较轻，该模块只处理活跃性错误。情节严重的共识性错误则会在证据模块中进行处理。
一旦出现违规行为，就会立即触发活跃性惩罚，所以就不需要额外的惩罚时间获取过错证据。验证器会立即被禁闭，以防止进一步的活跃性错误，直到解禁。
状态
每个区块都包含一组验证器为前一个区块执行的预承诺，也被称作由Tendermint提供的LastCommitteeInfo。只要LastCommitteeInfo包含超过总投票权三分之二的的预承诺，它就是有效的。
验证器活跃性的信息由ValidatorSigningInfo进行跟踪。在商店中的索引如下：
ValidatorSigningInfo存储在地图中，以键作为一致地址。
MissedBlocksBitArray存储在映射中，以键作为一致地址，值表示位数组，其中每个位数表示验证器是否遗漏了位数组中给定索引的区块。
ValidatorSigningInfo结构记录以下内容：
Address -验证器的一致地址
StartHeight-候选验证器成为有效验证器（具有非零投票权）的高度
IndexOffset-每次将验证器绑定到区块中时都会递增的索引，可能在预承诺中已签名
JailedUnl-验证器因活跃性停机而被禁闭的时间
Tombstoned：描述验证器是否已被废除。一旦验证器提交模糊不清的信息或出现其他不当行为，就会触发这一功能
MissedBlocksCounter：为避免不必要的数组读取而保留的计数器。请注意，Sum（MissedBlocksBitArray）始终等于MissedBlocksCounter。
消息
惩罚模块可以处理以下消息：
未禁闭-如果验证器因停机而自动解除绑定，并希望重新上线以及可能会重新加入绑定集；如果验证器有足够的权益加入MaximumBondedValidators，它们将被自动重新绑定，并再次获得奖励。
起始区块
在每个起始区块的开始，我们会更新每个验证器的ValidatorSigningInfo，并检查它们是否超过了滑动窗口的活跃性界限值。此滑动窗口由SignedBlocksWindow定义，其中的索引由验证器的ValidatorSigningInfo中的IndexOffset确定。对于每个处理的区块，无论验证器是否签名，IndexOffset都会递增。确定索引后，MissedBlocksBitArray和MissedBlocksCounter将相应更新。
最后，为了确定验证器是否超过活跃性界限值，我们会取回最大的遗漏区块量：
我们可以确定活跃性的最小高度minHeight。如果当前区块大于minHeight并且验证器的MissedBlocksCounter大于MaxMissed，则它们将被SlashFractionDowntime惩罚，禁闭时长为DowntimeJailDuration。MissedBlocksBitArray、MissedBlocksCounter和IndexOffset的值将被重置。
参数
惩罚模块提供以下可配置参数：
SignedBlocksWindow。
MinSignedPerWindow。
DowntimeJailDuration。
SlashFractionDoubleSign。
SlashFractionDowntime。
请注意：在起始区块一章中，我们记录了没有说明的参数。
证据模块
摘要
证据模块允许提交和处理任何不当行为的证据，如模糊不清和反事实签名。
概念
该模块提供了API供其他模块登记证据和检查逻辑，类似于Crisis模块。提交的证据首先通过证据模块的路径器规定路径，在该路径器中，该模块尝试查找特定证据类型的对应处理程序。每种证据类型都必须有一个在证据模块登记的处理程序，才能成功地设置路径并执行。给定证据类型的处理程序可以执行任何状态的转换，如惩罚、禁闭和确认删除。
状态
目前，证据模块仅在状态中存储被提交的有效的证据列表。
消息
证据通过MsgSubmitEvidence消息提交。消息中提供的证据必须具有向证据模块的路径器登记过得相应处理程序，才能正确处理和路径。
起始区块
除应用程序级证据处理的通用框架外，证据模块还为底层共识引擎提供了内置的证据处理程序，如果找到该引擎，该引擎将自动提交程序处理。相关信息作为abci.RequestBeginBlock中的ABCI证据转发到应用程序，验证器便会受到相应的惩罚。
目前，证据模块只处理起始区块期间从Tendermint的ABCIEvidenceTypeDuplicateVote中生成的描述模糊（双重签名）的证据。
如果区块中包含有效的描述模糊的证据，则由惩罚模块定义的SlashFractionDoubleSign将错误发生时（而非证据发现时）的抵押从验证器扣除。此外，如果验证器被永久禁闭并被除名，该验证器永远不能重新进入验证器集。不早于指定的MaxEvidenceAge的证据才会被视为有效证据。
参数
证据模块包含以下参数：
MaxEvidenceAge-早于该参数的证据将不予考虑。
供应模块
摘要
供应模块会被动跟踪链内通证的总供应量，允许其他模块持有通证/与通证交互，并引入安全的不变量检查以验证链上的总供应量。
概念
网络的总供应量等于所有账户全部通证的总和。每次制造或销毁通证时，总供应量都会更新。
供应模块引入了一种全新的帐户类型（模块账户），各模块可以用它来分配通证，在特殊情况下可以用它来制造或销毁通证。就其基本功能而言，这些模块帐户能向各帐户和其他模块帐户发送或接收通证。
每个模块账户都有一组不同的权限，这些权限提供不同的对象功能来执行各类操作。权限需要在创建供应记录器时登记，以便模块账户每次调用允许的函数时，记录器都可以查找该特定帐户的权限，并选择执行或不执行操作。
状态
供应模块存储仅跟踪链的总供应。
记录器
供应记录器为AuthKeeper和BankKeeper提供与模块账户相关的包装功能，以便能够：
通过提供模块账户的名称获取和设置模块账户。
通过传递名称将通证从其他模块账户或标准帐户间转移
从模块账户制造或销毁通证
升级模块
摘要
升级模块有助于将链顺利升级到新的（中断）软件版本。起始区块连接可以实现本操作。该连接可以在达到预定义的升级区块时间或高度后阻止区块链状态机继续运行。对于治理决定如何进行升级的问题，模块不会做出任何假定，而只假定用于协调安全升级的机制。如果没有软件支持升级，升级活动链是有风险的，因为所有验证器都需要在该过程中的完全相同的点同时暂停状态机。如果此操作不正确，可能会出现状态不一致的问题，并很难修复。
概念
升级模块对进行实时升级的计划类型做出了定义。计划可以在特定的区块高度或时间作出安排，但不能同时安排在两个位置。一旦（冻结）候选以及升级处理程序发出，就会创建计划，计划的名称会对应特定的处理程序。通常而言，计划会通过SoftwareUpgradeProposal治理提议流程创建，在该流程中，如果投票完成并通过，将会安排计划。计划的信息可以包含关于升级的各种元数据，通常包括链上专于应用程序的升级信息，例如验证器可以自动升级的提交变化。节点操作器的升级过程可以完全自动化。使用必要信息填入Info字段，可以自动下载二进制文件。
状态
升级模块的内部状态相对最小且简单。状态仅包含键0x0的当前活动升级计划（如有），以及键0x1是否将计划标记为“已完成”。
消息
将消息转到此模块的路径只会传递到治理模块，这是启动升级计划的唯一方法。
以下消息可供治理模块使用：
·SoftwareUpgradeProposal
·CancelSoftwareUpgradeProposal
储蓄模块
摘要
储蓄模块允许用户锁仓抵押金，并在24小时内获得利息。
状态
储蓄模块将保存已存入资金的帐户列表。它在https://drops.dagstuhl.de/opus/volltexte/2019/11400/.中存储数据结构，以执行Dev Ojha提议的链上费用分配模块 储蓄资金将从分配模块中的网络验证器奖励池进行转移。
消息
储蓄模块将处理以下消息：
消息存款-允许用户存入不超过其账户可用资金的25%
MsgWithDrawing-允许用户从储蓄帐户提取指定金额。此操作将重置储蓄区块时间，利息累计将在给定储蓄账户的付息期间开始，付息期间该账户需要停止使用至少24小时。
MsgWithdrawInterest-允许用户将利息提取到其帐户。
参数
储蓄模块内有可配置的利率，该利率可以通过治理进行更改。
HRA-名称模块
摘要
此模块包含将Anatha地址链接到一个或多个人类可读地址（HRA）及其元数据的所有逻辑，其中可能包括多货币钱包和其他加密地址。
概念
每个用户可以拥有多个HRA。在这些HRA中，每个都对应相应的Anatha地址。每个Anatha地址拥有多个加密货币的地址映射，按照加密货币类型和同一加密货币内的地址顺序分组。用户可从多个加密货币中添加多个地址。在Anatha平台上已知加密货币的第一个注册地址可以享受注册费用优惠。后续的每个注册地址都会增加费用。收费机制可避免恶意交易导致的网络负担过重。
状态
内部HRA存储将分配以下结构：
map[AnathaAddress]->HRA[]-从Anatha地址映射到地址所有者的HRA列表。
map[HRA]->AnathaAddress-从HRA的哈希值映射到所有者地址。
map[HRA]->HraInfo-从HRA的哈希值映射到给定HRA细节结构。
map[AnathaAddress][CryptocurrencyId][Index]->Address-映射一个Anatha地址到多个加密货币的多个地址。
每个HraInfo结构由以下字段组成：
ExpiryTime-HRA的过期时间戳。
Price-HRA在uANATHA中出售的价格。如果不可出售，则为0。
消息
HRA模块将支持处理以下消息：
RegisterHRA-拥有将签名者的地址与注册的HRA绑定的参数化成本的消息
作为此交易的附加数据，用户可以传送他们希望绑定到其Anatha的初始加密货币钱包地址。如果是HRA首次注册，Anatha钱包中生成的地址将自动连接到所有者地址
RenewHRA -将HRA所有权增加1年的消息，费用为参数化费用
SetSellingPrice-设置给定HRA价格的消息
BuyHRA-当发出HRA的销售价格与供应价格相匹配时，将HRA传送给买方
DeleteHRA- 删除AnathaAddress->HRA关联的消息。如果是用户的最后一个HRA，则其所有加密货币地址映射都将被删除
TransferHRA-将HRA传输给另外一位用户的消息
RegisterAddress-允许用户将外部加密货币地址绑定到可使用HRA访问的Anatha地址
DeregisterAddress-允许用户删除以前注册的外部加密货币地址
记录器
HRA模块将公开主记录器，其他模块可以访问该记录器，前提是对地址进行转换。记录器的基本功能如下：
GetHRAInfo-返回HRA基本信息
GetHRAByAddress-返回由提供地址的所有HRA
GetAddressByHRA-返回Anatha地址
PersistHRAInfo-存储修改后的HRA相关数据
起始区块
在每个区块起始时，将进行维护，其中包括处理过期的HRA信息和映射。
参数
HRADenomation-默认uANATHA
HRAAnnualPrice-结合年度注册总价的参数计算。默认100000000=1 ANATHA。
金库模块
摘要
金库模块持有Anatha的初始供应，根据从金库转出的Anatha的金额生成金库公开销售价格，并接收已被外部金库系统回购的Anatha通证。金库模块将由链上多重签名钱包控制，其极限要求在Genesis文件中有所规定。为实现产品文档中的目标，此链上模块需要补充链下模块，后续服务章节会详细阐述。
概念
金库模块将向治理模块公开路径，通过这些路径可以调用该模块。
金库模块会有回购队列，ANATHA通证持有者将在回购队列将ANATHA作为订单发送，并指明希望交换的加密货币。如果金库后端的流动性允许，它将进行转移并收走ANATHA通证。
状态
根据Anatha初始供应量的流入和流出，金库模块以美元为单位记录，并可查询当前价格。ANATHA通证的起价为0.01美元，每售出10,000,000美元（1000万美元）ANATHA通证价格就会增加0.01美元。
售出0-10,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枚通证：7.7美元
金库模块有等待执行的回购订单队列：
每个用户的订单映射[地址]-> Order[]
全球订单列表-> Order[]
记录器
金库模块记录器提供以下功能：
更新销售价格
公布销售价格
管理队列中的订单
消息
TransferFunds-基于治理提议，将资金从金库转移到指定地址
DepositFunds-回购Anatha通证并重新调整售价
SellBack-将ANATHA通证附加到金库基金的存款，消息元数据将包括ANATHA通证持有者希望获得的加密货币标识符
DeleteOrder-允许用户删除订单
FulfiOrder-只能由金库后端在完成SellBack订单后发送的消息，将把锁仓返回到金库资金中
ANATHA后端服务/仪表盘
治理仪表盘
通过治理模块，区块链能够支持链上治理系统。在变成去中心化治理系统之前，该模块将由链上多重签名模型实施治理程序，这意味着只有在创世区块中注册的参与者才能参与治理提议和投票。利用升级模块的机制，治理模块可以自己更新成为去中心化治理。
管理员仪表盘
允许Anatha管理员访问各种专用网络数据、监控网络活动的网络仪表盘。Anatha管理员还可以通过管理仪表盘内的控制面板来编辑系统范围的设置。
金库仪表盘
金库后端与金库区块链模块并行工作，并负责：
管理已转入金库后台控制账户的ANATHA通证
处理各种付款方式，并向买家支付ANATHA通证，将其转换成为链上模块指定的美元售价
在高级操作中，如果系统可以低价完成订单，将会扫描市场，并且利润归Anatha所有
区块资源管理器
提供API连接和Web界面的标准资源管理器，用于访问交易和整体网络数据。资源管理器提供有关网络（区块、交易、地址、余额）、HRA注册表（HRA查找、HRAmappings）和验证器（活动数量、性能）的一般信息。
验证器
该计划允许符合条件的个人作为验证器，并验证Anatha区块链的区块。验证器安全性和一般参数是基于由ANATHA Network提出的标准所定义的。验证器的最低要求包括拥有活动HRA、500,000个可用ANATHA通证、99%或更长的服务器正常运行时间。
限制：
起始最大节点数-50
最终最大节点数-300
等待列表中最大节点数-无限制
Anatha正在运行的节点总数-3
候补名单排行榜
索引器
索引服务通过钱包地址和哈希交易来索引交易，这样一来，可以轻松筛选出与特定地址相关联的交易，并且可以轻松通过独特的哈希值（整个交易对象的SHA256哈希）来查询单笔交易。
索引服务会不断跟进现有区块链节点的新交易，并将索引数据存储在Redis数据存储中。一旦索引服务停止工作，不会丢失现有数据，并且将从最后保存的区块继续同步过程。作为索引过程的一部分，无效交易也会被保存，但它们会被标上无效标志。
索引服务提供高度可用的API，该API可以用于检索无法直接从区块链查询的信息。这些API用于各种前端，如区块链浏览器、钱包等。
索引器可以索引的部分内容包括：
按到期日列出的HRA
按地址列出的交易记录
ANATHA JavaScript SDK
Anatha SDK是一个JavaScript/Node.js库，可以从NPM注册表中安装。它包含与Anatha区块链通信的方法。Anatha SDK旨在帮助开发人员与Anatha区块链交互，并在该区块链上构建接口和应用程序。
Anatha SDK将导入所有交易类型，并提供接口，用于创建有效负载，并为Core中指定的每个交易签名。除了铸币、签名和中转交易外，Anatha SDK还可以进行区块链查询。它还可以支持与钱包相关的基本功能。从这个角度而言，SDK可以提供与CLI工具相同的19种功能，但它们是为JavaScript环境专门定制的。SDK目前提供的一些功能包括：
初始化Anatha钱包（密钥对）
生成密钥对
导入原始私钥
检查地址余额
签名、交易Anatha通证
在每个区块和每笔交易上发生的WebSocket事件记录
模块查询和交易相关功能：
查询连接节点的状态
查询：
区块-获取给定高度的区块验证数据
交易-搜索与给定标记（事件）或哈希匹配的全部交易
帐户余额
在每个模块（治理、分配、押注、惩罚、HRA、储蓄、金库等）中公开状态
交易：
创建并中转已签名的交易
公布脱机生成的签名
在每个模块中公开消息（治理、分配、押注、惩罚、HRA、储蓄、金库等）。
命令行工具
应用程序的主要界面之一是命令行界面。此入口点会添加来自应用程序模块的命令，以允许最终用户创建消息和查询。
交易由用户创建，用于包装在有效区块中触发状态更改的消息。交易命令通常显示在每个模块的tx.go文件中。
查询功能允许用户收集有关应用程序或网络状态的信息；它们由应用程序设定路径，并由定义它们的模块进行处理。查询命令通常有自己的query.go文件。
CLI工具被称为anathacli，并将编译进入Golang二进制可执行文件中。
列表中模块的每条消息都可通过CLI编写。
最后更新于
