AnomaNode 深入解析Anoma 协议的 Elixir/OTP 节点应用、安装配置与监督架构【免费下载链接】anoma-archiveReference implementation of Anoma项目地址: https://gitcode.com/GitHub_Trending/an/anoma-archive本文以仓库根目录的 README.md 为主体围绕 AnomaNode——Anoma 协议的参考实现节点应用——展开先说明它的定位与安装方式再结合 mix.exs、config/config.exs 与lib/下的源码完整讲清一个节点应用从启动、监督树组织到多节点管理的运行方式。读完本文你可以独立配置、启动并验证一个 AnomaNode 实例并理解它内部由哪些“引擎”Engine协作完成状态变更处理。1. 项目定位AnomaNode 是什么README.md 对项目的定义是I am the Anoma Node application. I provide the main functionality of the Anoma protocol. In particular, I instantiate all the Engine functionality and state-change processing of Anoma.即 AnomaNode 是整个 Anoma 协议的节点应用它负责实例化协议中的全部引擎Engine并承担 Anoma 协议的状态变更state-change处理。从 mix.exs 可以确认其工程身份OTP 应用名为:anoma_node通过mod: {Anoma.Node, []}指定了应用入口模块见 lib/node.ex要求 Elixir~ 1.17mix.exs版本由 version.exs 单独维护当前仓库版本为1.0.0。注意 README.md 安装示例中写的~ 0.1.0属于 Mix 项目模板沿用的写法当前仓库的实际版本以 version.exs 为准。此外mix.exs 中声明了自动启动的应用extra_applications:crypto、:debugger、:enacl、:logger、:runtime_tools、:tools、:ex_unitMnesia 被刻意放入included_applications注释明确说明不应自动启动 Mnesia——它的初始化由监督树在需要时驱动见 lib/supervisor.ex 中的Anoma.Tables.initialize_storage/0。2. 安装与依赖2.1 作为 Hex 依赖引入README.md 给出的标准安装方式是把anoma_node加入mix.exs的依赖列表def deps do [ {:anoma_node, ~ 0.1.0} ] end2.2 作为源码直接编译更常见的用法是直接使用仓库源码。依赖关系集中在 global_deps.exs由 mix.exs 引入核心运行时依赖包括依赖说明anoma_libAnoma 核心库git 依赖tag v1.0.1anoma_protobufgRPC 通信使用的 protobuf 定义v1.0.0event_broker事件总线v1.0.0grpc/protobuf节点间与客户端的 gRPC 服务端jasonJSON 编解码typed_struct项目中广泛使用的带类型结构体宏credo/dialyxir/ex_doc仅 dev/test 环境的静态检查与文档工具本地构建与测试可使用仓库自带的 Makefilemake build即mix compile、make testmix test、make release先清理_build、deps再执行mix deps.get与mix release并固定 glibc 2.20 目标以保证二进制兼容性。2.3 文档生成README.md 还说明文档可用 ExDoc 生成并发布到 HexDocs。对应地global_deps.exs 中声明了{:ex_doc, ~ 0.31, only: [:dev]}Makefile 提供了docs与docs-release两个目标前者执行mix toc及scripts/docs.sh、scripts/docs-files.sh后者再追加scripts/docs-version.sh完成版本化文档发布流程。3. 配置一个节点应用的关键开关所有配置集中在 config/config.exs按config_env()再叠加 config/dev.exs、config/test.exs 等环境文件。当前仓库中与节点行为直接相关的配置有三组# 1) 日志生产级收敛只保留 error 级 config :logger, level: :error, handle_otp_reports: false, handle_sasl_reports: false # 2) gRPC 端口可用环境变量 NODE_GRPC_PORT 覆盖默认 50051 config :anoma_node, grpc_port: String.to_integer(System.get_env(NODE_GRPC_PORT) || 50051) # 3) Mnesia 存储行为 config :anoma_node, :mnesia, persist_to_disk: false, rocksdb: falsegrpc_port节点对外暴露 gRPC 服务的端口Anoma.Supervisor在启动时读取该值拉起 gRPC 服务端见 lib/supervisor.ex。需要多节点同机运行时应通过NODE_GRPC_PORT环境变量区分端口。mnesia.persist_to_disk当前配置为false即 Mnesia 数据不持久化到磁盘配置注释中说明了开启后会写入$XDG_DATA_HOME/anoma等平台相关目录。这意味着默认的节点是“临时性”的每次启动都是干净状态——这一点与 USAGE.md 中“ephemeral node可随时创建与销毁的节点”的描述一致。mnesia.rocksdb当前配置为false即默认使用 Mnesia 内存表而非 RocksDB 后端CHANGELOG.md 记录了历史上 RocksDB 表曾被默认启用的演进过程实际取值请以当前配置与所用环境为准。4. 启动流程与监督架构节点是如何被实例化的README 说 AnomaNode “instantiates all the Engine functionality”这句话的实现依据就是两层监督树。4.1 顶层Anoma.Supervisor管理共享进程与多个节点应用入口 lib/node.ex 中的Anoma.Node.start/2仅一行调用Anoma.Supervisor.start_link/1。lib/supervisor.ex 的init/1做了三件事初始化全局存储:ok Anoma.Tables.initialize_storage()注册三个共享子进程Anoma.Node.RegistryElixir.Registryunique 键——以node_id为键定位各个节点进程GRPC.Server.Supervisor——以Anoma.Node.Transport.GRPC.Endpoint为端点、grpc_port为端口启动 gRPC 服务端点实现见 lib/node/transport/grpc/endpoint/endpoint.exAnoma.Node.NodeSupervisorDynamicSupervisor——用于动态地挂载、卸载任意多个节点监督策略为:one_for_all。由此得到 README 所说的“主功能”进程名固定的 gRPC 端点 可动态增删的节点池。4.2 单节点Anoma.Node.Supervisor组织四大引擎每个节点是一棵以 lib/node/supervisor.ex 为根的监督树。start_link/1会用node_id通过Anoma.Node.Registry.via/2生成唯一进程名init/1中实例化四个子系统children [ {Transport.Supervisor, node_id: node_id, node_config: args[:node_config]}, {Transaction.Supervisor, [node_id: node_id] transaction}, {Intents.Supervisor, node_id: node_id}, {Logging, node_id: node_id} ] Supervisor.init(children, strategy: :one_for_all)Transport.Supervisorlib/node/transport/supervisor.ex负责节点间的网络传输层包括 gRPC 端点、节点发现network_register/advertise等Transaction.Supervisorlib/node/transaction/supervisor.ex即 README 所说的“state-change processing”核心内部再分 mempool、ordering、executor、storage 等引擎对应 lib/node/transaction/ 下的各子目录Intents.Supervisorlib/node/intents/supervisor.ex管理意图intent池与 solverLogginglib/node/logging.ex节点级日志引擎。Anoma.Node.Supervisor的合法启动参数args为:node_id、:transaction、:node_config以及默认replay: true——replay默认开启意味着新节点启动时会尝试重放既有状态配合 Mnesia/RocksDB 持久化场景。4.3 节点的动态生命周期start_node / stop_nodeAnoma.Supervisor提供了一对面向节点生命周期的公开 APIlib/supervisor.exstart_node/1先经State.startup_arguments_or_default/1解析启动参数lib/node/replay/start_state.ex再调用Tables.initialize_tables_for_node/1检查该node_id的存储表是created新节点:new_node还是existing既有节点:existing_node最后通过DynamicSupervisor.start_child/2把Anoma.Node.Supervisor挂入动态监督树stop_node/1通过 Registry 按node_id定位节点监督进程并Supervisor.stop/1整个子树。这套机制支撑了 USAGE.md 演示的“临时节点”用法在 IEx 中反复创建、销毁节点而底层的 gRPC 端点与 Registry 保持不变。5. 实操启动一个节点并验证仓库提供了可直接运行的示例模块Anoma.Node.Examples.ENodelib/examples/e_node.ex。start_node/1的行为源码见 lib/examples/e_node.ex用:crypto.strong_rand_bytes(32)生成随机十六进制node_id组装node_config含grpc_host/grpc_port端口取自Application.get_env(:anoma_node, :grpc_port)即第 3 节中可被NODE_GRPC_PORT覆盖的那个值调用Anoma.Supervisor.start_node/1成功或“已启动”时返回%ENode{node_id, pid}结构体失败时记录日志并返回{:error, :failed_to_start_node}。在仓库根目录执行iex -S mix后iex(1) node Anoma.Node.Examples.ENode.start_node() # %Anoma.Node.Examples.ENode{node_id: 3F2A..., pid: #PID0.xxx.0}随后用 test/ 目录中的测试如 test/node_id_test 相关的 registry_test.exs、test/mempool_test.exs 等覆盖 Registry、Mempool、gRPC 传输、pubsub、replay 等面作为行为参照make test或mix test即完整回归。需要强调的适用前提是当前仓库配置下 Mnesia 不写盘persist_to_disk: false节点重启后状态不保留如需持久化应自行调整:anoma_node, :mnesia配置项且该行为的默认值以 config/config.exs 及对应环境文件为准。6. 质量工具与版本脉络静态检查mix.exs 配置了 Dialyzer本地 PLT 位于plts/anoma.plt关闭 improper list 警告——项目有意使用裸 consglobal_deps.exs 同时提供 Credo版本演进CHANGELOG.md 记录了从 v0.11 到 v0.21 的功能轨迹与本文所述的“引擎”结构一脉相承存储引擎化、Pinger 的 CQRS 化、Transport 引擎进入路由、Cairo 后端、Shielded RM 与事件总线event broker的合入v0.20等。README 中 “Engine functionality and state-change processing” 的表述正是这条演进路线的浓缩文档ExDoc 文档按 scripts/ 下的脚本生成与版本化make docs是入口命令。小结README.md 用不到 20 行定义了 AnomaNode 的身份它是 Anoma 协议的节点应用承载全部引擎与状态变更处理。仓库源码把这句话落实为一个以 lib/supervisor.ex 为顶、Registry 固定 gRPC 端点 动态节点池的顶层结构以及每个节点内部由 Transport、Transaction、Intents、Logging 四大子树构成的监督体系lib/node/supervisor.ex。结合 config/config.exs 的端口与存储开关、Makefile 的构建/测试/文档流程以及 lib/examples/e_node.ex 的启动示例即可完整地把“安装—配置—启动—验证”整条链路走通。【免费下载链接】anoma-archiveReference implementation of Anoma项目地址: https://gitcode.com/GitHub_Trending/an/anoma-archive创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AnomaNode 深入解析：Anoma 协议的 Elixir/OTP 节点应用、安装配置与监督架构
AnomaNode 深入解析Anoma 协议的 Elixir/OTP 节点应用、安装配置与监督架构【免费下载链接】anoma-archiveReference implementation of Anoma项目地址: https://gitcode.com/GitHub_Trending/an/anoma-archive本文以仓库根目录的 README.md 为主体围绕 AnomaNode——Anoma 协议的参考实现节点应用——展开先说明它的定位与安装方式再结合 mix.exs、config/config.exs 与lib/下的源码完整讲清一个节点应用从启动、监督树组织到多节点管理的运行方式。读完本文你可以独立配置、启动并验证一个 AnomaNode 实例并理解它内部由哪些“引擎”Engine协作完成状态变更处理。1. 项目定位AnomaNode 是什么README.md 对项目的定义是I am the Anoma Node application. I provide the main functionality of the Anoma protocol. In particular, I instantiate all the Engine functionality and state-change processing of Anoma.即 AnomaNode 是整个 Anoma 协议的节点应用它负责实例化协议中的全部引擎Engine并承担 Anoma 协议的状态变更state-change处理。从 mix.exs 可以确认其工程身份OTP 应用名为:anoma_node通过mod: {Anoma.Node, []}指定了应用入口模块见 lib/node.ex要求 Elixir~ 1.17mix.exs版本由 version.exs 单独维护当前仓库版本为1.0.0。注意 README.md 安装示例中写的~ 0.1.0属于 Mix 项目模板沿用的写法当前仓库的实际版本以 version.exs 为准。此外mix.exs 中声明了自动启动的应用extra_applications:crypto、:debugger、:enacl、:logger、:runtime_tools、:tools、:ex_unitMnesia 被刻意放入included_applications注释明确说明不应自动启动 Mnesia——它的初始化由监督树在需要时驱动见 lib/supervisor.ex 中的Anoma.Tables.initialize_storage/0。2. 安装与依赖2.1 作为 Hex 依赖引入README.md 给出的标准安装方式是把anoma_node加入mix.exs的依赖列表def deps do [ {:anoma_node, ~ 0.1.0} ] end2.2 作为源码直接编译更常见的用法是直接使用仓库源码。依赖关系集中在 global_deps.exs由 mix.exs 引入核心运行时依赖包括依赖说明anoma_libAnoma 核心库git 依赖tag v1.0.1anoma_protobufgRPC 通信使用的 protobuf 定义v1.0.0event_broker事件总线v1.0.0grpc/protobuf节点间与客户端的 gRPC 服务端jasonJSON 编解码typed_struct项目中广泛使用的带类型结构体宏credo/dialyxir/ex_doc仅 dev/test 环境的静态检查与文档工具本地构建与测试可使用仓库自带的 Makefilemake build即mix compile、make testmix test、make release先清理_build、deps再执行mix deps.get与mix release并固定 glibc 2.20 目标以保证二进制兼容性。2.3 文档生成README.md 还说明文档可用 ExDoc 生成并发布到 HexDocs。对应地global_deps.exs 中声明了{:ex_doc, ~ 0.31, only: [:dev]}Makefile 提供了docs与docs-release两个目标前者执行mix toc及scripts/docs.sh、scripts/docs-files.sh后者再追加scripts/docs-version.sh完成版本化文档发布流程。3. 配置一个节点应用的关键开关所有配置集中在 config/config.exs按config_env()再叠加 config/dev.exs、config/test.exs 等环境文件。当前仓库中与节点行为直接相关的配置有三组# 1) 日志生产级收敛只保留 error 级 config :logger, level: :error, handle_otp_reports: false, handle_sasl_reports: false # 2) gRPC 端口可用环境变量 NODE_GRPC_PORT 覆盖默认 50051 config :anoma_node, grpc_port: String.to_integer(System.get_env(NODE_GRPC_PORT) || 50051) # 3) Mnesia 存储行为 config :anoma_node, :mnesia, persist_to_disk: false, rocksdb: falsegrpc_port节点对外暴露 gRPC 服务的端口Anoma.Supervisor在启动时读取该值拉起 gRPC 服务端见 lib/supervisor.ex。需要多节点同机运行时应通过NODE_GRPC_PORT环境变量区分端口。mnesia.persist_to_disk当前配置为false即 Mnesia 数据不持久化到磁盘配置注释中说明了开启后会写入$XDG_DATA_HOME/anoma等平台相关目录。这意味着默认的节点是“临时性”的每次启动都是干净状态——这一点与 USAGE.md 中“ephemeral node可随时创建与销毁的节点”的描述一致。mnesia.rocksdb当前配置为false即默认使用 Mnesia 内存表而非 RocksDB 后端CHANGELOG.md 记录了历史上 RocksDB 表曾被默认启用的演进过程实际取值请以当前配置与所用环境为准。4. 启动流程与监督架构节点是如何被实例化的README 说 AnomaNode “instantiates all the Engine functionality”这句话的实现依据就是两层监督树。4.1 顶层Anoma.Supervisor管理共享进程与多个节点应用入口 lib/node.ex 中的Anoma.Node.start/2仅一行调用Anoma.Supervisor.start_link/1。lib/supervisor.ex 的init/1做了三件事初始化全局存储:ok Anoma.Tables.initialize_storage()注册三个共享子进程Anoma.Node.RegistryElixir.Registryunique 键——以node_id为键定位各个节点进程GRPC.Server.Supervisor——以Anoma.Node.Transport.GRPC.Endpoint为端点、grpc_port为端口启动 gRPC 服务端点实现见 lib/node/transport/grpc/endpoint/endpoint.exAnoma.Node.NodeSupervisorDynamicSupervisor——用于动态地挂载、卸载任意多个节点监督策略为:one_for_all。由此得到 README 所说的“主功能”进程名固定的 gRPC 端点 可动态增删的节点池。4.2 单节点Anoma.Node.Supervisor组织四大引擎每个节点是一棵以 lib/node/supervisor.ex 为根的监督树。start_link/1会用node_id通过Anoma.Node.Registry.via/2生成唯一进程名init/1中实例化四个子系统children [ {Transport.Supervisor, node_id: node_id, node_config: args[:node_config]}, {Transaction.Supervisor, [node_id: node_id] transaction}, {Intents.Supervisor, node_id: node_id}, {Logging, node_id: node_id} ] Supervisor.init(children, strategy: :one_for_all)Transport.Supervisorlib/node/transport/supervisor.ex负责节点间的网络传输层包括 gRPC 端点、节点发现network_register/advertise等Transaction.Supervisorlib/node/transaction/supervisor.ex即 README 所说的“state-change processing”核心内部再分 mempool、ordering、executor、storage 等引擎对应 lib/node/transaction/ 下的各子目录Intents.Supervisorlib/node/intents/supervisor.ex管理意图intent池与 solverLogginglib/node/logging.ex节点级日志引擎。Anoma.Node.Supervisor的合法启动参数args为:node_id、:transaction、:node_config以及默认replay: true——replay默认开启意味着新节点启动时会尝试重放既有状态配合 Mnesia/RocksDB 持久化场景。4.3 节点的动态生命周期start_node / stop_nodeAnoma.Supervisor提供了一对面向节点生命周期的公开 APIlib/supervisor.exstart_node/1先经State.startup_arguments_or_default/1解析启动参数lib/node/replay/start_state.ex再调用Tables.initialize_tables_for_node/1检查该node_id的存储表是created新节点:new_node还是existing既有节点:existing_node最后通过DynamicSupervisor.start_child/2把Anoma.Node.Supervisor挂入动态监督树stop_node/1通过 Registry 按node_id定位节点监督进程并Supervisor.stop/1整个子树。这套机制支撑了 USAGE.md 演示的“临时节点”用法在 IEx 中反复创建、销毁节点而底层的 gRPC 端点与 Registry 保持不变。5. 实操启动一个节点并验证仓库提供了可直接运行的示例模块Anoma.Node.Examples.ENodelib/examples/e_node.ex。start_node/1的行为源码见 lib/examples/e_node.ex用:crypto.strong_rand_bytes(32)生成随机十六进制node_id组装node_config含grpc_host/grpc_port端口取自Application.get_env(:anoma_node, :grpc_port)即第 3 节中可被NODE_GRPC_PORT覆盖的那个值调用Anoma.Supervisor.start_node/1成功或“已启动”时返回%ENode{node_id, pid}结构体失败时记录日志并返回{:error, :failed_to_start_node}。在仓库根目录执行iex -S mix后iex(1) node Anoma.Node.Examples.ENode.start_node() # %Anoma.Node.Examples.ENode{node_id: 3F2A..., pid: #PID0.xxx.0}随后用 test/ 目录中的测试如 test/node_id_test 相关的 registry_test.exs、test/mempool_test.exs 等覆盖 Registry、Mempool、gRPC 传输、pubsub、replay 等面作为行为参照make test或mix test即完整回归。需要强调的适用前提是当前仓库配置下 Mnesia 不写盘persist_to_disk: false节点重启后状态不保留如需持久化应自行调整:anoma_node, :mnesia配置项且该行为的默认值以 config/config.exs 及对应环境文件为准。6. 质量工具与版本脉络静态检查mix.exs 配置了 Dialyzer本地 PLT 位于plts/anoma.plt关闭 improper list 警告——项目有意使用裸 consglobal_deps.exs 同时提供 Credo版本演进CHANGELOG.md 记录了从 v0.11 到 v0.21 的功能轨迹与本文所述的“引擎”结构一脉相承存储引擎化、Pinger 的 CQRS 化、Transport 引擎进入路由、Cairo 后端、Shielded RM 与事件总线event broker的合入v0.20等。README 中 “Engine functionality and state-change processing” 的表述正是这条演进路线的浓缩文档ExDoc 文档按 scripts/ 下的脚本生成与版本化make docs是入口命令。小结README.md 用不到 20 行定义了 AnomaNode 的身份它是 Anoma 协议的节点应用承载全部引擎与状态变更处理。仓库源码把这句话落实为一个以 lib/supervisor.ex 为顶、Registry 固定 gRPC 端点 动态节点池的顶层结构以及每个节点内部由 Transport、Transaction、Intents、Logging 四大子树构成的监督体系lib/node/supervisor.ex。结合 config/config.exs 的端口与存储开关、Makefile 的构建/测试/文档流程以及 lib/examples/e_node.ex 的启动示例即可完整地把“安装—配置—启动—验证”整条链路走通。【免费下载链接】anoma-archiveReference implementation of Anoma项目地址: https://gitcode.com/GitHub_Trending/an/anoma-archive创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考