BNB Chain（BSC）近两年进行了大幅结构升级，特别是在 genesis-template.json 中，引入了多版本硬分叉、时间激活机制、Blob（EIP-4844）、EIP-1559、Deposit 接口等框架性变更，使其从传统 “Parlia 简易模式” 升级为与以太坊主网高度兼容的现代化架构。

本文将对比旧版与新版 BSC genesis-template.json 的结构变化，并解释每个字段设计背后的技术原因。

1. 旧版 BSC Genesis —— 只有 Parlia 配置的简易模式

早期版本的 BSC（包括 Mainnet 与 Testnet 很长时间）仅在 genesis 中包含 Parlia 共识参数：

"parlia": {
  "period": 3,
  "epoch": 200
}

1.1 字段含义

1.2 特点

• 结构简单
• 没有 EIP-1559
• 没有 EIP-4844（Blob）
• 没有时间控制的 Hardfork
• 与现代以太坊协议差距越来越大

旧版 BSC genesis 的核心只有 Parlia 配置，因此功能扩展能力有限。

2. 新版 BSC Genesis —— 多硬分叉 + 时间激活 + Blob 时代

BNB Chain 在 2024–2025 年陆续引入了大量升级（Feynman、Haber、Pascal、Prague、Lorentz…），genesis 文件结构变得高度现代化：

"feynmanFixTime": 0,
"cancunTime": 0,
"haberTime": 0,
"haberFixTime": 0,
"bohrTime": 0,
"pascalTime": 0,
"pragueTime": 0,
"lorentzTime": 0,

"depositContractAddress": "0x0000000000000000000000000000000000000000",

"parlia": {},

"blobSchedule": {
  "cancun": {
    "target": 3,
    "max": 6,
    "baseFeeUpdateFraction": 3338477
  },
  "prague": {
    "target": 3,
    "max": 6,
    "baseFeeUpdateFraction": 3338477
  }
}

下面逐项解析这些字段。

3. 新增字段解析（硬分叉、升级机制、Blob）

3.1 时间激活（Timestamp-based）硬分叉

新版 BSC 使用 Timestamp-based Hardfork 与以太坊主网保持一致。

统一规则：
设置为 0 表示链启动后立即激活所有功能
→ 适合私链 / DevNet / 测试链
→ 公链通常使用具体 Unix 时间戳

从此 BSC 不再使用区块高度（blockNumber）触发升级，而全面迁移到 ETH 的时间触发机制，升级可控性更强。

3.2 parlia 变成空对象

旧版的：

"parlia": {
  "period": 3,
  "epoch": 200
}

新版变成：

"parlia": {}

这是因为：

✔ 新版 BSC 内置默认值

• period = 3
• epoch = 200

如果需要自定义，可以继续写入：

"parlia": {
  "period": 1,
  "epoch": 200
}

3.3 EIP-4844 Blob 交易：blobSchedule

BSC 新版开始兼容以太坊 Cancun 升级（EIP-4844），新增 Blob Gas 调整参数：

"blobSchedule": {
  "cancun": {
    "target": 3,
    "max": 6,
    "baseFeeUpdateFraction": 3338477
  },
  "prague": {
    "target": 3,
    "max": 6,
    "baseFeeUpdateFraction": 3338477
  }
}

这是与 ETH 主网完全一致的 Blob Gas 定价模型，用于 Rollup / 数据可用性（DA）场景。

3.4 depositContractAddress

"depositContractAddress": "0x0000000000000000000000000000000000000000"

目前 BSC 仍是 PoSA（并非 ETH PoS），但这一字段用于兼容未来可能的信标链接口，是预留字段。

4. 对比总结：从「简单模型」到「现代以太坊兼容链」

新版 BSC 通过一套统一的时间激活 hardfork 机制，使其升级模型、blob gas 模型、EIP 兼容性全面向以太坊主网对齐。

5. 为什么 BSC 必须升级？

因此新版 genesis 是一个从 ETH 主网演化而来的高度可扩展结构。

生成 SSH key（推荐 ed25519）

ssh-keygen -t ed25519 -C "jenkins@your-domain" -f /var/jenkins_home/.ssh/id_ed25519

生成后会有：

• 私钥：/var/jenkins_home/.ssh/id_ed25519
• 公钥：/var/jenkins_home/.ssh/id_ed25519.pub

把公钥加到 Git 仓库平台（以 GitHub 为例）

1. 查看公钥内容：

   cat /var/jenkins_home/.ssh/id_ed25519.pub

2. 打开 GitHub → 右上角头像 → Settings → SSH and GPG keys → New SSH key

3. 把刚才复制的公钥粘贴进去，保存。
   GitLab / Gitea / 自建 Git 也类似：找到 SSH Keys 设置，加进去即可。

在 Jenkins 里添加 SSH 凭据（Credentials）

1. 打开 Jenkins Web 页面。
2. 左侧：Manage Jenkins → Credentials → (Global)。
3. 右侧：Add Credentials。
4. 选择：
   • Kind：SSH Username with private key（中文界面类似）
   • Username：
     • GitHub / GitLab 通常填写：git
   • Private Key：
     • 选 Enter directly
     • 把 /var/jenkins_home/.ssh/id_ed25519 里的内容复制进去
       （用 cat /var/jenkins_home/.ssh/id_ed25519 查看，然后复制）
   • ID / Description：随便填一个有意义的，比如：github-ssh-universe
5. 保存。

配置 Job 使用 SSH 仓库 + 关联凭据

1. 确保仓库 URL 是 SSH 形式

例如 GitHub：

git@github.com:xxx/xxx.git

不是：

https://github.com/xxx/xxx.git

在 Pipeline（Jenkinsfile）里使用 SSH 凭据（可选）

如果你用的是声明式 Pipeline，可以这样写：

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git branch: 'main',
                    url: 'git@github.com:universe-web3/universe-deploy-ansible.git',
                    credentialsId: 'github-ssh-universe'
            }
        }
    }
}

注意

Jenkins 用 SSH 拉 github.com 时，要求严格校验证书（StrictHostKeyChecking=yes），但 known_hosts 里没有 github.com 的主机指纹，所以直接拒绝。

在 Jenkins Web 界面里调整 Git Host Key 策略

可以让 Jenkins 自己“自动信任”第一次连接的 host key（安全性稍差，但在你自己控制的环境里一般也可以接受）。

1. 打开 Jenkins → 左侧 Manage Jenkins
2. 找到 Configure Global Security
3. 往下找到 Git Host Key Verification Configuration
4. 选择其中一个策略：
   • Known hosts file Verification Strategy（默认，配合上面方案一）
   • 或者 Accept first connection（第一次自动接受 host key，以后照这个校验）

保存之后，再去构建你的 Job 试一次。

opkg update
opkg install openssh-client-utils

文档：https://accursedgalaxy.github.io/Insider-Monitor/
github: https://github.com/AccursedGalaxy/Insider-Monitor/tree/master

核心代码：
https://github.com/AccursedGalaxy/Insider-Monitor/blob/master/internal/monitor/monitor.go#L108

Roxy-WI 是为那些想要拥有容错基础设施，但又不想深入了解基于 HAProxy、NGINX、Apache 和 Keepalived 的集群的设置和创建细节的人创建的。

https://roxy-wi.org/
https://roxy-wi.org/installation#deb