适用于参与 DefiShares 主网出块的 witness 候选人。本文以稳定运行、密钥安全和及时响应为核心,不以过高硬件配置作为筛选条件。
Applies to witness candidates seeking to produce blocks on the DefiShares mainnet. These requirements prioritize stable operation, key security, and timely response rather than high hardware thresholds.
一、基础软硬件要求
1. Basic Hardware and Infrastructure Requirements
1. 服务器
1. Server
| 项目 | 推荐基础要求 |
|---|---|
| 操作系统 | Ubuntu 22.04 或 24.04 LTS |
| CPU | 2 vCPU 以上 |
| 内存 | 4 GB 以上 |
| 磁盘 | 100 GB SSD 以上;随链数据增长及时扩容 |
| 网络 | 10 Mbps 以上;固定公网 IP 或稳定云服务器地址 |
| 时间 | 启用 NTP 自动时间同步 |
| 服务管理 | 支持开机自启和进程异常自动重启 |
| Item | Recommended baseline |
|---|---|
| Operating system | Ubuntu 22.04 or 24.04 LTS |
| CPU | At least 2 vCPU |
| Memory | At least 4 GB |
| Storage | At least 100 GB SSD; expand as chain data grows |
| Network | At least 10 Mbps; static public IP or stable cloud-host address |
| Time | NTP automatic time synchronization enabled |
| Service management | Starts at boot and automatically restarts after unexpected exits |
节点数据会持续增长,磁盘使用率达到 80% 前必须完成扩容或清理。
Chain data will continue to grow. Storage must be expanded or cleaned before disk utilization reaches 80%.
2. 网络要求
2. Network Requirements
-
节点必须能够连接主网 P2P 网络,且 P2P 端口应允许其他主网节点访问。
-
RPC 接口原则上仅监听本机、内网或 VPN,不建议直接暴露到公网。
-
应连接多个主网节点,避免只依赖单一 seed 或单一服务商。
-
鼓励 witness 分布在不同地区和不同云服务商,降低集中化风险。
-
The node must connect to the mainnet P2P network, and its P2P port should accept connections from other mainnet nodes.
-
RPC should normally listen only on localhost, a private network, or a VPN; direct public exposure is not recommended.
-
Connect to multiple mainnet peers and avoid dependence on a single seed node or provider.
-
Witnesses are encouraged to use different regions and cloud providers to reduce concentration risk.
二、节点软件要求
2. Node Software Requirements
-
使用 DefiShares 官方发布或可验证来源编译的
witness_node。 -
使用官方确认的主网 genesis 文件和 Chain ID。
-
节点完成主网同步后,才可以正式参与出块。
-
启用
witness插件,并正确配置本人链上 witness ID 和对应的 block-signing public key/private key。 -
使用 systemd、Docker 或其他可靠方式管理节点服务,并配置异常退出后自动重启。
-
不得使用测试网配置、旧版本 genesis 或与主网不一致的 Chain ID。
-
Use an official DefiShares release of
witness_node, or a build from a verifiable source. -
Use the officially confirmed mainnet genesis file and Chain ID.
-
A node may produce mainnet blocks only after it has fully synchronized.
-
Enable the
witnessplugin and correctly configure the operator’s on-chain witness ID and matching block-signing public/private key. -
Manage the node with systemd, Docker, or another reliable service manager, and enable automatic restart after unexpected exits.
-
Do not use testnet settings, an obsolete genesis file, or a Chain ID that differs from mainnet.
测试网稳定出块验证
Testnet Stable Block Production Verification
候选人正式参选前,应先在官方测试网或社区认可的测试网络完成稳定出块验证。
Before formally standing for election, a candidate should complete stable block-production verification on the official testnet or a community-recognized test network.
-
使用独立的测试网 witness ID 与出块密钥,配置方式应与计划中的主网部署一致,但不得复用主网私钥。
-
节点完成同步并进入活跃测试网出块名单后,至少连续稳定出块 72 小时;建议累计验证 7 天。
-
验证期间应启用自动化监控,记录进程、
head_block_age、LIB 推进、资源使用情况和漏块情况。 -
应完成至少一次受控重启或故障恢复演练,确认服务自动恢复、节点重新追平且能继续签名出块。
-
提交测试网 witness ID、验证时间段、监控摘要和漏块/故障处理记录,不提交任何私钥。
-
Use a separate testnet witness ID and block-signing key. The configuration should match the intended mainnet deployment, but mainnet private keys must never be reused.
-
After synchronization and entry into the active testnet witness schedule, produce blocks stably for at least 72 consecutive hours; a cumulative 7-day verification period is recommended.
-
Enable automated monitoring during verification and record process health,
head_block_age, LIB progress, resource utilization, and missed blocks. -
Complete at least one controlled restart or recovery drill to confirm automatic service recovery, resynchronization, and continued block signing.
-
Submit the testnet witness ID, verification period, monitoring summary, and missed-block/incident records. Do not submit private keys.
三、密钥和安全要求
3. Key Management and Security Requirements
-
出块私钥只保存在 witness 节点服务器上;私钥文件权限应为
0600,仅节点运行用户可读取。 -
私钥不得提交到 Git、聊天记录、网页、工单或普通日志。
-
owner key、active key 与出块私钥应分开保存。
-
SSH 建议使用密钥登录,关闭不必要的公网端口,并启用防火墙和安全更新。
-
节点配置、genesis 文件、启动脚本和监控配置应定期备份;私钥备份应加密、离线且分地域保存。
-
发现私钥泄露时,应立即停止使用并更换链上签名密钥。
-
Keep block-signing private keys only on the witness node server. Key files must use
0600permissions and be readable only by the node service user. -
Never commit private keys to Git or disclose them in chats, web pages, tickets, or ordinary logs.
-
Store owner keys, active keys, and block-signing keys separately.
-
Use SSH key authentication where possible, close unnecessary public ports, and enable a firewall and security updates.
-
Back up node configuration, the genesis file, startup scripts, and monitoring configuration regularly. Private-key backups must be encrypted, offline, and geographically separated.
-
If a private key is exposed, immediately stop using it and replace the on-chain signing key.
四、Witness 候选人需提交的资料
4. Information Required From Witness Candidates
候选人报名时应提供以下非敏感信息:
Candidates should provide the following non-sensitive information when applying:
-
witness 账户名、witness ID、block-signing public key;
-
节点所在国家或地区、云服务商或服务器类型;
-
CPU、内存、磁盘和网络配置;
-
节点软件版本、节点运行时间和监控方案;
-
日常维护人员及联系方式;
-
是否承担喂价、API、社区支持等额外工作。
-
Witness account name, witness ID, and block-signing public key;
-
Node country or region, cloud provider, or server type;
-
CPU, memory, storage, and network configuration;
-
Node software version, node uptime, and monitoring plan;
-
Day-to-day maintainer and contact details;
-
Whether the candidate will also provide price feeds, APIs, community support, or other services.
不得提交或公开任何私钥、服务器密码或其他敏感凭据。
Do not submit or publish private keys, server passwords, or any other sensitive credentials.
五、日常工作
5. Ongoing Duties
1. 自动化监控
1. Automated Monitoring
Witness 节点必须使用监控脚本或监控系统进行自动化监控,不以人工定期查看作为主要保障手段。
Witness nodes must use monitoring scripts or a monitoring system. Manual periodic inspection must not be the primary safeguard.
建议每 3 至 10 秒采集一次以下指标:
Collect the following metrics every 3 to 10 seconds:
-
witness_node进程状态; -
head_block_number和head_block_age; -
last_irreversible_block是否持续推进; -
CPU、内存、磁盘容量和磁盘 IO;
-
NTP 时钟偏差;
-
错误日志、异常退出、分叉和重放状态。
-
witness_nodeprocess status; -
head_block_numberandhead_block_age; -
Whether
last_irreversible_blockcontinues to advance; -
CPU, memory, disk capacity, and disk I/O;
-
NTP clock offset;
-
Error logs, unexpected exits, forks, and replay status.
建议设置以下告警阈值:
Use the following alert thresholds:
| 告警条件 | 建议动作 |
|---|---|
head_block_age > 15 秒 |
立即告警 |
| 节点落后超过 2 个区块 | 告警并排查网络、同步或进程状态 |
| 磁盘使用率超过 80% | 扩容或清理 |
| Alert condition | Recommended action |
|---|---|
head_block_age > 15 seconds |
Alert immediately |
| Node falls more than 2 blocks behind | Alert and investigate network, synchronization, or process state |
| Disk utilization exceeds 80% | Expand storage or clean up |
运营者应及时处理监控告警,并保留告警记录和故障处理记录。
Operators should respond to monitoring alerts promptly and retain alert and incident-resolution records.
2. 节点维护
2. Node Maintenance
-
保持节点持续在线和同步,定期检查出块与漏块情况。
-
及时处理异常退出、节点落后、分叉和重放问题。
-
关注官方升级公告,并在规定时间内完成版本升级。
-
升级前备份配置和必要数据;升级后确认 Chain ID、同步状态和出块状态。
-
发生长时间离线、持续漏块或无法恢复时,应及时向社区说明情况。
-
Keep the node online and synchronized, and regularly review production and missed-block status.
-
Address unexpected exits, node lag, forks, and replays promptly.
-
Follow official upgrade announcements and complete upgrades within the stated timeframe.
-
Back up configuration and required data before upgrades; afterward, verify the Chain ID, synchronization status, and block production.
-
Inform the community promptly of prolonged downtime, sustained missed blocks, or an unrecoverable incident.
3. 喂价职责
3. Price Feed Duties
如 witness 同时承担喂价职责,还应:
If a witness also provides price feeds, it should:
-
使用可靠的数据源,并按官方要求及时提交价格;
-
监控喂价是否成功上链;
-
在数据源异常或市场暂停时按规则处理;
-
遵守 DefiShares 的 GOLD 价格规则及相关资产喂价规则。
-
Use reliable data sources and publish prices as required;
-
Monitor whether price feeds are successfully published on-chain;
-
Follow the applicable rules when data sources fail or markets halt;
-
Follow DefiShares GOLD pricing rules and the relevant asset feed rules.
六、选举和持续考核
6. Election and Ongoing Review
1. 基本准入条件
1. Basic Eligibility Conditions
-
Chain ID 和 genesis 文件正确;witness ID 与签名公钥匹配。
-
节点能够完成同步,具备公网 P2P 连接能力,并配置自动化监控。
-
已完成测试网稳定出块验证,并可提供验证记录。
-
有明确的维护人员和联系方式,能够处理升级、重启和常见故障。
-
The Chain ID and genesis file are correct, and the witness ID matches the signing public key.
-
The node can synchronize, accepts public P2P connectivity, and has automated monitoring.
-
Testnet stable-production verification has been completed and records can be provided.
-
A clear maintainer and contact method are available, with the ability to handle upgrades, restarts, and common incidents.
2. 不建议继续支持的情况
2. Conditions for Withdrawing Support
-
长期离线、长期不同步或频繁漏块;
-
没有自动化监控,或磁盘空间不足仍不处理;
-
多次升级不及时、故障后长期不响应,或私钥管理不当;
-
多个 witness 集中在同一服务器或同一基础设施。
-
Prolonged downtime, persistent desynchronization, or frequent missed blocks;
-
No automated monitoring, or failure to address insufficient disk space;
-
Repeatedly late upgrades, prolonged lack of response after incidents, or poor private-key management;
-
Multiple witnesses concentrated on the same server or infrastructure.
3. 推荐考核指标
3. Recommended Evaluation Metrics
| 指标 | 建议标准 |
|---|---|
| 节点在线率 | 最近 30 天建议不低于 99.9% |
| 漏块率 | 保持较低水平,并能解释与修复异常漏块 |
| 同步状态 | 无持续落后,LIB 持续推进 |
| 告警与恢复 | 能够及时响应监控告警,有明确故障处理流程 |
| 社区服务 | 按承诺完成喂价、技术支持或其他职责 |
| Metric | Recommended standard |
|---|---|
| Node availability | At least 99.9% over the preceding 30 days |
| Missed-block rate | Keep it low, and explain and correct abnormal missed blocks |
| Synchronization | No sustained lag; LIB continues to advance |
| Alerting and recovery | Respond to monitoring alerts promptly and maintain a clear incident process |
| Community service | Deliver promised price feeds, technical support, or other responsibilities |
4. 补充评价原则
4. Additional Evaluation Principles
-
节点是否长期稳定运行,是否具备自动化监控和及时故障处置能力;
-
是否做好密钥与服务器安全,并愿意公开必要的运行状态;
-
是否具有良好的社区响应能力,以及足够的地域和云服务商分散度。
-
Whether the node operates reliably over time and has automated monitoring and timely incident-response capability;
-
Whether key and server security are well managed, and necessary operational status is disclosed;
-
Whether the operator responds well to the community and provides adequate regional and cloud-provider diversity.