最全面的开源工具，用于监控 Solana 钱包活动、检测余额变化、跟踪潜在内幕交易以及接收 SOL 和所有 SPL 代币的实时警报。

https://accursedgalaxy.github.io/Insider-Monitor/
https://github.com/AccursedGalaxy/Insider-Monitor

背景

使用 upgrades.erc1967.getImplementationAddress 来获取通过 upgrades.deployProxy 部署的合约的逻辑合约地址（implementation address）

测试部署脚本

const [deployer] = await ethers.getSigners();
    console.log("Deployer:", await deployer.getAddress())
    const commonBridgeFactory = await ethers.getContractFactory("CommonBridge", deployer);
    let commonBridgeProxyContract;
    if (deployOutput.commonBridgeProxyContract === undefined || deployOutput.commonBridgeProxyContract === '') {
        commonBridgeProxyContract = await upgrades.deployProxy(
            commonBridgeFactory,
            [
                process.env.DOMAIN_ID,
                process.env.SUPER_ADMIN_ADDRESS,
                process.env.BRIDGE_FEE_ADDRESS
            ],
            {
                constructorArgs: [],
                unsafeAllow: ['constructor', 'state-variable-immutable'],
            });
        console.log('tx hash:', commonBridgeProxyContract.deploymentTransaction().hash);
    } else {
        commonBridgeProxyContract = commonBridgeFactory.attach(deployOutput.commonBridgeProxyContract);
    }

    console.log('commonBridgeProxyContract deployed to:', commonBridgeProxyContract.target);
    await sleep(6000);
    const commonBridgeImpl = await upgrades.erc1967.getImplementationAddress(commonBridgeProxyContract.target);
    console.log('commonBridgeProxyContract implementation deployed to:', commonBridgeImpl);

部署超时

Error: Timed out waiting for implementation contract deployment to address 0x5393... with transaction 0x9492...

解决：增加超时和轮询设置

...
commonBridgeProxyContract = await upgrades.deployProxy(
    commonBridgeFactory,
    [
        process.env.DOMAIN_ID,
        process.env.SUPER_ADMIN_ADDRESS,
        process.env.BRIDGE_FEE_ADDRESS
    ],
    {
        constructorArgs: [],
        unsafeAllow: ['constructor', 'state-variable-immutable'],
        timeout: 300000, // 5分钟
        pollingInterval: 5000, // 每5秒轮询一次
    });
    console.log('tx hash:', commonBridgeProxyContract.deploymentTransaction().hash);
    ...

不符合 ERC1967 标准

使用 upgrades.erc1967.getImplementationAddress 来获取通过 upgrades.deployProxy 部署的合约的逻辑合约地址（implementation address），结果报：部署地址不符合 ERC1967 标准的代理合约（Proxy）

Error: Contract at 0xffa5f716D890CFd4f9D709A40d6EB7Fb19fC43B4 doesn't look like an ERC 1967 proxy with a logic contract address

const implSlot = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc';
const proxyAddress = '0xffa5f716D890CFd4f9D709A40d6EB7Fb19fC43B4';

const storage = await ethers.provider.getStorage(proxyAddress, implSlot);
console.log("Raw implementation slot:", storage);

const implAddress = '0x' + storage.slice(-40);
console.log("Implementation address:", implAddress);

const implAddress1 = await upgrades.erc1967.getImplementationAddress(proxyAddress);
console.log("Implementation address1:", implAddress1);

如果返回的 implStorage 是全零（0x000...），说明实现地址确实没有写进去，可能部署时失败或未初始化。
如果你用其他方式部署 Proxy（比如自己 new TransparentUpgradeableProxy，而不是用 upgrades.deployProxy()），OpenZeppelin 插件就不能保证你用了它支持的初始化逻辑。

解决： 是因为网络延迟原因，增加延迟时间

console.log('commonBridgeProxyContract deployed to:', commonBridgeProxyContract.target);
await sleep(20000); // 提高延迟间隔
const commonBridgeImpl = await upgrades.erc1967.getImplementationAddress(commonBridgeProxyContract.target);
console.log('commonBridgeProxyContract implementation deployed to:', commonBridgeImpl);

最终版本

const [deployer] = await ethers.getSigners();
    console.log("Deployer:", await deployer.getAddress())
    const commonBridgeFactory = await ethers.getContractFactory("CommonBridge", deployer);
    let commonBridgeProxyContract;
    if (deployOutput.commonBridgeProxyContract === undefined || deployOutput.commonBridgeProxyContract === '') {
        commonBridgeProxyContract = await upgrades.deployProxy(
            commonBridgeFactory,
            [
                process.env.DOMAIN_ID,
                process.env.SUPER_ADMIN_ADDRESS,
                process.env.BRIDGE_FEE_ADDRESS
            ],
            {
                constructorArgs: [],
                unsafeAllow: ['constructor', 'state-variable-immutable'],
                timeout: 300000,
                pollingInterval: 5000,
            });
        console.log('tx hash:', commonBridgeProxyContract.deploymentTransaction().hash);
    } else {
        commonBridgeProxyContract = commonBridgeFactory.attach(deployOutput.commonBridgeProxyContract);
    }

    console.log('commonBridgeProxyContract deployed to:', commonBridgeProxyContract.target);
    await sleep(20000);
    const commonBridgeImpl = await upgrades.erc1967.getImplementationAddress(commonBridgeProxyContract.target);
    console.log('commonBridgeProxyContract implementation deployed to:', commonBridgeImpl);

FULL v0、Cursor、Manus、Same.dev、Lovable、Devin、Replit Agent、Windsurf Agent、VSCode Agent、Dia Browser、Trae AI 和 Cluely（以及其他开源）系统提示、工具和 AI 模型。

github: https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools

背景

当交易上链后，需要websocket尽快订阅到新发起的交易信息，但已有逻辑有2s左右延迟

目前逻辑

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "blockSubscribe",
  "params": [
    { },
    { "commitment": "finalized" }
  ]
}

当前测试环境为私有网络，且仅有一个Validator

优化延迟

优化链路

• 原有链路：监听服务 -> WAF -> RPC -> Validator
• 压缩链路
  • 监听服务 -> RPC -> Validator
    • 去除WAF防护过程造成的延迟
    • 保留RPC对Validator压力防护
  • 监听服务 -> Validator
    • 在1的基础上去除RPC同步Validator区块的时间
    • 在链路路径上，为最短路径，只适合核心私有服务，时间优先

阶段测试结果

结果：链路优化后，延迟优化效果不明显

排除：排除WAF设置或防护逻辑，以及RPC同步相关对websocket的影响

修改参数

修改blockSubscribe.commitment 参数

测试结果

RPC节点需开启 --rpc-pubsub-enable-block-subscription

总结：当blockSubscribe.commitment 为confirmed时，满足实时性需求

下面继续做具体分析，以及安全性确认

整体分析

commitment

Solana 分别引入了 processed、confirmed 和 finalized 三种 commitment

安全分析

confirmed 还可能丢弃？

Solana 是基于 Turbine + Tower BFT 共识 的区块链，允许 fork 存在，直到达成“supermajority lockout”：

举个例子：

1. Leader A 在 slot 100 产出 block1，包含你的交易 tx1
2. 多数 validator 已投票确认 → tx1 达到 confirmed
3. 但 Leader B 在 slot 100 提出了 fork block2（没有 tx1）
4. 网络切换了分叉，block2 成为主链，block1 被丢弃
5. 最终你会看到 tx1 消失

这种情况虽然极少发生（除非网络分叉非常激烈），但确实有可能，尤其在以下情况下：

• 网络波动严重（多个 validator 未及时同步）
• 特别是在 devnet/testnet 上更常见
• 冲突交易竞争激烈（如套利机器人密集交易）

单一Validator

结论：如果整个网络只有一个 validator，交易一旦被执行（即 processed），就等同于 finalized，不会被回滚或丢弃

原因：Solana 的分叉和回滚机制依赖于 多个 validator 的投票（tower consensus），但如果你只有一个 validator 节点（如私链或测试环境）：

• 所有交易处理都只走 一个 chain path
• 没有投票机制（自己 vote 自己）
• 没有 fork、没有分歧
• 所有被处理的 block/slot 会直接成为 root → 立即 finalized

延迟分析

问题：在只有一个 Validator 的 Solana 网络中，为什么交易已经 confirmed，但还没有立即 finalized？不是说没有其他节点就没有分叉吗？

原因：因为 finalized 状态取决于 root slot 的推进，而 root slot 的推进有“延迟”或“惰性机制”，即使只有一个 validator。

Solana 的 finalized 并不是单纯根据是否有分叉来判断，而是依赖一个特殊机制：

Tower BFT + Root Slot 推进规则：

• 每个 validator 会有自己的 "lockout" 投票历史，形成“投票树”
• 当 validator 在连续的 slot 上投票到一定深度，就能推进 root slot
• 只有 root 之后的 slot 才会被标记为 finalized

即使只有一个 validator：

1. 它仍然要投票 → 进入 lockout（自己 vote 自己）
2. 它仍然需要满足 一定的 slot 深度 才能将旧 slot 设为 root
3. root slot 推进后，对应的交易和 block 才被认为是 finalized

为什么存在“延迟 finalized”？

举例

假设你只有一个 validator，slot 时间 400ms：

1. 你在 slot 100 发出一笔交易
2. 交易执行完成 → processed
3. 自己投票确认该 block → confirmed
4. 继续生产 slot 101、102...
5. 到 slot 104 时，系统满足 root 推进条件，slot 100 被设为 root → 现在它才是 finalized

所以即使没有其他 validator，finalized 仍然比 confirmed 晚 2~4 个 slot（~1.5 秒）

最终总结

1. 通过blockSubscribe (confirmed) 满足业务实时性要求
2. 单一Validator，通过订阅confirmed，不存在安全性问题

安装Chrome扩展

https://chromewebstore.google.com/detail/tokenpocket-web3-crypto-%E9%92%B1/mfgccjchihfkkindfppnaooecgfneiii?utm_source=ext_app_menu

打开资产展示

添加自定义网络

选择SVM

填入私有链对应的RPC，链ID 随意 （对于Solana链没有链ID，这里只是为了与EVM链类型共用布局）

例如

只做演示，BCSkill 技术社区未对外提供私有Solana链支持

添加新增网络

测试

然后回到资产展示，选择新添加的网络即可

注意

不要直接从 系统设置->节点列表->选择Solana->添加自定义节点
这里的添加只能添加Solana官方的节点，添加时会通过RPC 获取getGenesisHash，得到创世hash并与Solana 官方devnet testnet mainnet 进行比对，如果不一致则报错。

应该先添加完自定义网络后，再给自定义网络添加自定义节点