Skandha 声誉系统源码解读:throttling、ban 机制与防恶意攻击策略全指南

📅 2026/8/27 13:41:14
Skandha 声誉系统源码解读:throttling、ban 机制与防恶意攻击策略全指南
Skandha 声誉系统源码解读throttling、ban 机制与防恶意攻击策略全指南【免费下载链接】skandhaA modular typescript implementation of ERC4337 (Account Abstraction) bundler client.项目地址: https://gitcode.com/gh_mirrors/sk/skandhaSkandha 是一个模块化的 TypeScript 版 ERC-4337账户抽象Bundler 客户端实现。它的声誉系统Reputation System是 Bundler 抵御垃圾 UserOperation、资源耗尽DOS等恶意攻击的核心防线通过 throttling限流与 ban封禁两级机制动态评估 paymaster、factory、aggregator 等实体确保节点资源只花在靠谱的交易上。本文将带你完整解读这套声誉体系的源码逻辑、衰减算法与防攻击策略新手也能看懂。为什么 Bundler 需要声誉系统在 ERC-4337 账户抽象中一笔 UserOperation 除了用户账户外还涉及paymaster付费方、factory合约工厂、aggregator聚合器等第三方实体。这些实体是开放的——任何人都可以部署并随意提交交易。如果不加限制恶意攻击者可以 疯狂提交大量无效 UserOperation占满内存池mempool 提交大量永远无法被打包的交易浪费 Bundler 的模拟与验证资源 利用 paymaster 余额反复尝试造成资源耗尽DOSSkandha 的解法很简单给每个实体记账。看得多opsSeen但上链少opsIncluded的实体说明它的交易大多石沉大海声誉自然下降先被限流再被拉黑。核心数据opsSeen 与 opsIncluded声誉系统的账本定义在 packages/executor/src/entities/ReputationEntry.ts 的ReputationEntry类中每个实体只记两个数字段含义何时 1opsSeen该实体出现过的 UserOperation 数量交易进入内存池时opsIncluded该实体参与的交易真正被打包上链的数量监听链上UserOperationEvent事件时记账动作由两个模块触发记 seen交易入池时packages/executor/src/services/MempoolService/reputation.ts 中的updateSeenStatus会对 sender需已质押、paymaster、factory、aggregator 逐一 1。记 includedpackages/executor/src/services/EventsService/versions/0.0.8.ts 监听到上链事件后调用updateIncludedStatus为对应实体 1。所有账本持久化在 RocksDB 中读写入口是 packages/executor/src/services/ReputationService.ts。ban 机制全解isBanned 如何触发判定逻辑集中在ReputationEntry的isBanned方法中公式非常直观计算期望最低上链数minExpectedIncluded floor(opsSeen / minInclusionDenominator)若minExpectedIncluded opsIncluded banSlack则判定BANNED默认参数见 packages/executor/src/config.ts 中的bundlerDefaultConfigsminInclusionDenominator 10理论上每看到 10 笔交易至少有 1 笔应上链banSlack 50允许 50 笔的宽容额度举个例子某 paymaster 已提交 10000 笔交易期望至少 1000 笔上链如果实际只有 400 笔上链1000 400 50成立立即封禁。被封禁的实体会在内存池入口被直接拒绝并在组包阶段被清理入池拦截checkEntityCountInMempool发现 BANNED 状态时抛出PAYMASTER_OR_AGGREGATOR_BANNEDRPC 错误。组包清理packages/executor/src/services/BundlingService/service.ts 在挑选交易组包时若 paymaster 或 factory 已被 ban会把这笔 UserOperation 直接标记为Cancelled并记录 revertReason。throttling 机制ban 之前的黄牌警告isThrottled的公式与isBanned完全相同只是把banSlack换成了更严格的throttlingSlack默认 10。由于 10 50throttled 一定先于 banned 触发形成两级梯度惩罚状态触发条件默认参数后果OK上链缺口 ≤ 10正常处理THROTTLED缺口 10 且 ≤ 50内存池配额收紧组包时被跳过BANNED缺口 50拒绝入池已有交易被取消THROTTLED 状态的具体约束有两处入池时被限流实体在内存池中的交易数不得超过THROTTLED_ENTITY_MEMPOOL_COUNT默认 4见 packages/executor/src/services/MempoolService/constants.ts超出即拒绝。组包时BundlingService 直接跳过 throttled 实体的交易等它改过自新。声誉自动衰减24 小时淡忘算法如果只增不减一次失败就会永久拉黑实体。Skandha 的巧妙之处在于声誉不存绝对值而是按时间线性衰减。opsSeen/opsIncluded的 getter 在读取时动态计算每过 1 小时计数按1/24的比例衰减24 小时后计数归零实体自动洗白这意味着 ban 不是永久的——只要攻击者停止作恶24 小时后其声誉自动恢复。这也让整套系统无需额外的解封定时器非常优雅。防恶意攻击策略声誉之外的三重保险光有 ban/throttling 还不够Skandha 还叠加了多重防线1️⃣ 质押校验checkStakeReputationService.checkStake要求非 sender 实体paymaster/factory满足最低质押minStake和解押延迟minUnstakeDelay否则返回STAKE_DELAY_TOO_LOW错误。链上质押相当于保证金作恶会被罚没天然约束恶意行为。白名单whitelisted实体可豁免所有检查。2️⃣ 内存池容量配额每个 sender 最多 4 笔交易在内存池MAX_MEMPOOL_USEROPS_PER_SENDER 4。未质押实体的配额是动态的calculateMaxAllowedMempoolOpsUnstaked按10 上链率 × 10 min(opsIncluded, 10000)计算——历史表现越好配额越高新实体从 10 笔起步形成信用递增模型。3️⃣ 白名单 / 黑名单 组包故障封号addToWhitelist/addToBlacklist提供人工干预通道黑名单实体一票否决。若某笔 bundle 因 paymaster 或 factory 执行崩溃而失败见 packages/executor/src/services/BundlingService/relayers/base.ts 中的crashedHandleOps系统会直接给该实体记 100 seen / 0 included迅速将其推向 throttled/ban 区间防止炸包实体反复消耗资源。4️⃣ 并发安全所有写操作updateSeenStatus、updateIncludedStatus、setReputation都通过Mutex串行执行避免高并发下声誉计数错乱。关键配置参数速查表以下参数可在配置文件中调整见根目录 config.json.default 及 packages/executor/src/config.ts参数默认值作用minInclusionDenominator10期望上链率的倒数throttlingSlack10throttling 宽容额度越小越严格banSlack50ban 宽容额度minStake/minUnstakeDelay按网络配置实体准入的质押门槛如何验证与调试想亲手验证这套机制推荐两条路径单元测试packages/executor/test/unit/services/ReputationService.test.ts 覆盖了 OK/BANNED 状态判定、stake 校验等核心场景是理解边界条件的最佳教材。RPC 调试接口通过skandha_*调试方法实现见 packages/executor/src/modules/debug.ts可以dumpReputation查看全体实体声誉、setReputation手动改账、clearReputation一键重置非常适合本地演练 ban/throttle 行为。总结Skandha 的声誉系统用极小的数据结构两个计数实现了完整的攻防闭环✅记账seen/included 双计数器覆盖 sender、paymaster、factory、aggregator✅梯度惩罚throttled黄牌→ banned红牌缺口容忍度逐级收紧✅自动恢复24 小时线性衰减惩罚不永久✅纵深防御链上质押 动态内存池配额 白黑名单 崩溃连坐对普通用户而言理解这套机制有助于判断交易被拒的原因PAYMASTER_OR_AGGREGATOR_BANNED通常意味着 paymaster 声誉不佳对开发者而言它是一套可直接借鉴的轻量级声誉账本设计范本。【免费下载链接】skandhaA modular typescript implementation of ERC4337 (Account Abstraction) bundler client.项目地址: https://gitcode.com/gh_mirrors/sk/skandha创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考