Chainlink 仓库 go.md 深度解读如何用一张模块依赖图看懂 Chainlink 多模块 Go Monorepo【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlinkgo.md是 Chainlink 仓库根目录下自动生成的一份 Mermaid 模块依赖图它把整个仓库及其外部依赖的全部 Go 模块module以有向图形式画出节点是一个 Go 模块路径边表示谁依赖谁虚线框subgraph表示每个模块所属的源代码仓库。读完后你能掌握三件事Chainlink 根模块chainlink/v2依赖了哪些外部模块与功能域、仓库内 39 个嵌套go.mod各自承担什么职责以及这份图是如何被make modgraph与 pre-commit 钩子自动保鲜的。go.md 是生成物而非手写文档理解go.md的第一步是认识到它不是人工维护的文档而是由依赖图工具 modgraph 的固定版本输出通过以下链路生成和保鲜手动全量生成main.go 中声明了//go:generate make modgraph指令GNUmakefile 中定义了对应目标.PHONY: modgraph modgraph: $(call ensure_go_tool,modgraph,github.com/jmank88/modgraph,v0.1.4) ./tools/bin/modgraph go.md即先确保安装github.com/jmank88/modgraph的 v0.1.4 版本到tools/bin/再将其标准输出重定向覆盖go.md。提交时自动再生成lefthook.yml 的go-generatepre-commit 任务匹配*.go、*.proto、go.mod、go.sum、.mockery.yaml等文件调用tools/githooks/.bin/githooks generate并把修复结果重新暂存。其核心逻辑在 generate.go 中generate.go 在扫描变更文件时只要文件名是go.mod或go.sum就置位runModGraph标记generate.go 随后在并发任务组中执行modgraph命令generate.go 的defaultRunner实际执行tools/bin/modgraph并以 0644 权限把输出写回go.md注释明确要求权限与被跟踪文件一致。单元测试 generate_test.go 用桩 runner 验证了传入go.mod、deployment/go.sum等文件时恰好触发一次modgraph的行为。因此任何 PR 修改了模块依赖go.mod/go.sum却未同步更新go.md都会在本地钩子或 CI 层面被要求补齐再生成。两个图章节Main module 与 All modulesgo.md 全文只包含两节对应两张 Mermaidflowchart LR图章节覆盖范围适用读者Main modulego.md以根模块chainlink/v2为中心画出它的直接依赖以及这些依赖之间的相互边并标注各模块所属外部仓库想弄清node 二进制直接由哪些模块构成的开发者All modulesgo.md全仓库视角除上述内容外还加入本仓库内的嵌套模块chainlink/deployment、chainlink/system-tests/lib、chainlink/core/scripts等以及更多外部仓库如chainlink-solana、chainlink-stellar、testrig、mcms、quarantine想理解整个 monorepo 模块划分与测试体系的全景两张图共享同一套绘图约定节点名即 Go 模块导入路径例如chainlink-ccip/chains/evm、chainlink-protos/cre/go有向边--表示上游依赖下游subgraph按外部仓库分组如chainlink-ccip-repo、chainlink-protos-repo、cre-sdk-go-repo并配合click ... href让 Mermaid 渲染时节点可跳转到对应源码仓库末尾classDef outline stroke-dasharray:6,fill:none;把所有仓库级 subgraph 设为虚线描边视觉上区分仓库与模块两个层级。根模块 chainlink/v2 的直接依赖与功能域Main module图中从chainlink/v2发出的边与根 go.mod 的直接require块一一对应。按功能域归类后大致是功能域直接依赖的模块见 go.mod作用跨链互操作 CCIPchainlink-ccip、chainlink-ccip/chains/evm、chainlink-ccip/chains/solana、chainlink-ccip/chains/solana/gobindings、chainlink-ton/cciplibCCIP 消息协议、各链的合约绑定与执行器跨链托管 CCVchainlink-ccv跨链验证委员会协议node 内对应 services/ccv 等服务EVM 与合约chainlink-evm、chainlink-evm/gethwrappers、chainlink-evm/contracts/cre/gobindings基于 go-ethereum 的链抽象、geth 生成的合约 wrapper、CRE 合约 Go 绑定数据流与链上合约chainlink-data-streams、chainlink-feeds流式数据Stream与 Data Feeds 相关实现能力/链框架chainlink-framework/capabilities、chainlink-framework/chains、chainlink-framework/multinode能力注册、多链配置、多节点协调的公共框架gRPC/Protobuf 类型chainlink-protos/billing/go、.../cre/go、.../data-feeds、.../linking-service/go、.../metering/go、.../node-platform、.../ring/go、.../storage-service、.../workflows/go等各服务的 IDL 生成 Go 类型CRECompute and Relay Enginecre-sdk-go、cre-sdk-go/capabilities/networking/http、cre-sdk-go/capabilities/scheduler/cron通用计算/中继引擎的 SDK 与能力模块多链 SDKchainlink-aptos/codec、chainlink-sui/codecAptos、Sui 等链的编解码模块密码学与多节点底层libocr、smdkg、tdh2/go/tdh2、wsrpc、chain-selectors、freeportOCR 共识库、秘密共享/DKG、可信硬件 TDH2、RPC、链选择器通用公共库chainlink-common、chainlink-common/keystore、chainlink-common/pkg/chipingress跨产品共享的公共包与 keystore从Main module图的边还可以看出几个枢纽节点chainlink-common被最多模块指向chainlink-ccip、chainlink-feeds、chainlink-framework/capabilities、chainlink-sui/codec、chainlink-ton/cciplib、chainlink-tron/relayer、chainlink-aptos/codec等同时它又依赖chainlink-protos下的 billing/cre/linking-service/metering/node-platform/storage-service 六个模块以及freeport、grpc-proxy、libocr——从图中结构看它是整个依赖树的公共底座chainlink-protos仓库内部也自成小图billing/go -- workflows/go、chainlink-ccv/committee-verifier -- verifier、message-discovery -- verifier、cre/go -- chain-selectors、orchestrator -- wsrpcchainlink-ccip/chains/evm是图中出度最高的模块之一指向ccip-owner-contracts、chainlink-aptos、chainlink-canton、chainlink-solana、chainlink-sui、chainlink-ton、mcms、go-daml、chainlink-deployments-framework等说明 CCIP EVM 侧承担跨链部署与验证的集成职责chainlink-common/keystore -- smdkg -- libocr, tdh2/go/tdh2这条链把 keystore 与秘密共享SMDKG、可信硬件TDH2关联起来与 node 中 services/keystore 的职责相对应。下面摘取Main module图中根模块周边最关键的一小组边原文约 180 行边定义此处只保留核心骨架完整图请直接阅读 go.mdAll modules仓库内的嵌套模块版图仓库共有 39 个go.mod。All modules图把其中属于本仓库的模块图中归入chainlink-reposubgraph与外部模块放在一起。本仓库内的主要模块及职责如下模块import path 前缀目录职责github.com/smartcontractkit/chainlink/v2根目录go.modnode 主程序对应 core 与 main.gogithub.com/smartcontractkit/chainlink/deploymentdeployment/go.mod合约部署/changeset 框架图中显示它依赖chainlink/v2、chainlink-aptos/deployment、chainlink-solana/contracts、chainlink-sui/deployment、chainlink-ton/deployment、cld-changesets等github.com/smartcontractkit/chainlink/integration-testsintegration-tests/go.mod集成测试依赖chainlink/deploymentgithub.com/smartcontractkit/chainlink/load-testsintegration-tests/load/go.mod负载测试依赖chainlink-testing-framework/havoc与 integration-testsgithub.com/smartcontractkit/chainlink/system-tests/libsystem-tests/lib/go.mod系统测试公共库依赖chainlink-confidential-compute、testing-framework 的chiprouter/dockercompose/fake组件github.com/smartcontractkit/chainlink/system-tests/testssystem-tests/tests/go.mod系统测试用例主体聚合引用下各 CRE 用例子模块各 CRE 冒烟/回归用例模块如 system-tests/tests/smoke/cre/evm/evmread/go.mod、system-tests/tests/regression/cre/consensus/go.mod 等共 18 个每个用例是独立模块按需依赖cre-sdk-go的blockchain/*、networking/http、scheduler/cron等能力github.com/smartcontractkit/chainlink/devenvdevenv/go.mod本地开发环境编排依赖chainlink-evm、chainlink-protos/job-distributor、testing-framework 的fake组件.../devenv/fakesdevenv/fakes/go.mod开发环境的假服务devenv/fakes/main.go.../core/scripts及其 CRE 示例工作流core/scripts/go.mod、core/scripts/cre/environment/examples/workflows/proof-of-reserve/cron-based/go.mod 等运维脚本与可运行的 CRE 工作流示例cron、time、http、proof-of-reserve 等.../v2/tools/ci、.../v2/tools/githooks、.../v2/tools/testtools/ci/go.mod、tools/githooks/go.mod、tools/test/go.modCI CLI、git 钩子、测试工具的独立构建从这些拆分方式可以推断出 monorepo 的设计动机测试体系与主 node 解耦各自维护go.sum避免测试依赖污染 node 的构建图、每个 CRE 用例独立版本化可按需引用 cre-sdk-go 的某个能力子模块、部署工具复用各链仓库的 deployment 模块chainlink-aptos/deployment、chainlink-sui/deployment等仅被 deployment 模块引用而非 node 主模块。跨仓库的 smartcontractkit 模块族go.md的另一半价值是勾勒出 Chainlink node 之外的一族外部 Go 模块每个 subgraph 对应一个独立源码仓库chainlink-common公共包keystore、pkg/chipingress、pkg/monitoring、pkg/values、pkg/workflows/sdk/v2/pbchainlink-protos17 个 protos 子模块覆盖 billing、cre、metering、data-feeds、linking-service、storage-service、node-platform、ring、svr、workflows、job-distributor、op-catalog、orchestrator 及 chainlink-ccv 系列committee-verifier/heartbeat/message-discovery/message-rules/verifierchainlink-evmgethwrappers、gethwrappers/helpers、contracts/cre/gobindings是 node 读取/写入 EVM 合约的绑定层chainlink-frameworkcapabilities、chains、metrics、multinode图中可见capabilities -- chainlink-common、chains -- multinode -- metrics -- chainlink-common的层次chainlink-ccip协议核心与chains/evm、chains/solana、deployment等子模块chainlink-ccv依赖 CCV 相关 protos 与chainlink-solanacre-sdk-goCRE 能力模块族capabilities/blockchain/{aptos,evm,solana,stellar}、networking/http、scheduler/cron其中blockchain/evm额外依赖chainlink-common/pkg/workflows/sdk/v2/pb密码学/密钥族libocr -- go-sumtype2、smdkg -- libocr, tdh2/go/tdh2、chainlink-confidential-compute -- tdh2/go/tdh2构成 OCR 共识、秘密共享与可信执行的底层测试与部署族chainlink-testing-frameworkframework、wasp、parrot、seth、havoc等、chainlink-deployments-framework、cld-changesets、mcms、testrig支撑部署编排与系统级测试。对于 LLM/Agent 而言这张图也是天然的依赖导航表当需要定位某个功能的类型来源时可以按go.md中的边从使用方一路追踪到定义方所在的模块。如何查看与再生成 go.md查看直接阅读 go.md任意支持 Mermaid 的 Markdown 渲染器均可显示可点击的依赖图全量再生成在仓库根目录执行make modgraph目标定义见 GNUmakefile它会自动拉取固定版本v0.1.4的 modgraph 并覆盖写出go.md随提交自动更新配置了 lefthook 钩子后lefthook.yml只要暂存文件涉及go.mod/go.sum/.proto/*.go等pre-commit 的go-generate任务就会按 tools/githooks/README.md 描述的定向代码生成策略只对受影响的包运行对应生成器并把go.md、mocks 等产物重新暂存保证图与依赖声明始终一致。需要注意的适用前提go.md反映的是模块级go.mod粒度依赖而非包级导入关系图中版本信息来自各go.mod的解析结果具体版本号请对照根 go.mod 与go.sum若你只改了某个测试子模块的go.sum全量make modgraph会同时重算 Main module 与 All modules 两张图二者应一起提交更新。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考