Day 148
Day 148：系统设计练习 — 45分钟设计一个多链收益聚合平台
系统设计面试实战：需求分析（5min）、高层架构（10min）、核心组件详细设计（15min）、关键技术决策（10min）、扩展讨论（5min），包含策略引擎/风险引擎/执行引擎/数据库设计/安全设计/架构图
2026-05-25
理财系统设计收益聚合架构面试System DesignDay148
题目描述
面试官："请在45分钟内，设计一个支持多链的DeFi收益聚合平台，让用户一键存入资金并获得最优收益。"
你的目标：展示产品思维 + 架构能力 + DeFi深度理解
时间分配：
═══════════════════════════════════════════════════════════
0 5 15 30 40 45
├─────────┼──────────┼───────────┼───────────┼────┤
│ 需求分析 │ 高层架构 │ 详细设计 │ 技术决策 │扩展│
│ 5min │ 10min │ 15min │ 10min │5min│
└─────────┴──────────┴───────────┴───────────┴────┘
关键原则：
├── 先问后画：先澄清需求，再开始设计
├── 先宽后深：先给出全景，再深入关键组件
├── 先主后次：先解决核心问题，再讨论边缘情况
└── 数据说话：用具体数字支撑设计决策
Phase 1：需求分析（5分钟）
澄清问题（向面试官确认）
我会先问几个关键问题来澄清需求：
Q1: 目标用户是谁？
→ 假设：主要是散户用户，兼顾机构用户
散户：简单一键操作，追求最优收益
机构：需要额外的合规/风控/审计功能
Q2: 支持哪些链？
→ 假设：Ethereum, Arbitrum, Base, Polygon
优先以太坊生态，后续可扩展
Q3: 支持哪些收益来源？
→ 假设：
- 借贷协议（Aave, Compound, Morpho）
- 流动性提供（Uniswap V3, Curve）
- 质押（Lido stETH, Rocket Pool）
- Yield Farming（Convex, Yearn）
Q4: 规模预期？
→ 假设：
- TVL目标：$1B
- 活跃用户：100K
- 日交易量：10K笔
- 策略数量：50+
Q5: 最重要的非功能需求？
→ 假设：安全性 > 可用性 > 性能
功能需求
功能需求汇总：
═══════════════════════════════════════════════════════════
核心功能（Must Have）：
├── F1: 一键存入/取出
│ ├── 用户选择资产和金额
│ ├── 系统自动选择最优策略
│ ├── 用户确认并执行
│ └── 支持单一交易完成（含跨链）
│
├── F2: 多链收益率聚合展示
│ ├── 实时显示各链/各协议的APY
│ ├── 历史收益率趋势
│ ├── 风险评级标记
│ └── 推荐最优策略
│
├── F3: 自动策略路由
│ ├── 基于收益率/风险/流动性综合评分
│ ├── 自动跨链转移至最优链
│ ├── 定期再平衡（可配置频率）
│ └── Gas成本纳入收益计算
│
├── F4: 风险评级系统
│ ├── 每个策略/协议的风险评级（A-D）
│ ├── 智能合约风险、经济风险、流动性风险
│ ├── 用户可设置风险偏好
│ └── 风险评级变化时通知用户
│
└── F5: 收益追踪和报告
├── 实时P&L
├── 历史收益图表
├── 收益来源拆解
└── 税务报告导出
增强功能（Should Have）：
├── F6: 机构专属功能（多签/审批/审计）
├── F7: 策略提供者市场（第三方策略）
├── F8: 社交功能（跟单/分享）
└── F9: 治理代币和DAO投票
非功能需求
非功能需求：
═══════════════════════════════════════════════════════════
安全性（最高优先）：
├── 智能合约经过至少2次独立审计
├── 渐进式部署（先小额→逐步提升上限）
├── 紧急暂停机制（多签 + Timelock）
├── Bug Bounty（Immunefi，$1M+赏金）
└── 实时安全监控
可用性：
├── 99.9% 上线时间（年度最多8.7小时宕机）
├── 前端加载 < 3秒
├── 链上操作 < 30秒确认（L2）
└── 链下API响应 < 500ms
可扩展性：
├── 新链支持：2周内完成集成
├── 新策略支持：1周内完成集成
├── 水平扩展：服务可独立扩容
└── 数据存储：支持TB级链上数据索引
可维护性：
├── 微服务架构（独立部署/升级）
├── 全面的监控和告警
├── 自动化测试覆盖率 > 90%
└── 文档齐全
规模估算
Back-of-Envelope 计算：
═══════════════════════════════════════════════════════════
用户规模：
├── 目标：100K 活跃用户
├── 峰值并发：10K（假设10%同时在线）
├── 日新用户：500
└── 月活跃率：30%
交易规模：
├── 日均存入/取出：10K笔
├── 日均再平衡：5K笔（自动化）
├── 峰值TPS：50笔/秒
└── 年总交易量：$50B
数据规模：
├── 链上数据索引：~500GB/年（4条链）
├── 收益率快照：每5分钟/每个策略
│ = 50策略 × 288次/天 × 365天 = 5.3M行/年
├── 用户数据：100K用户 × 10KB = 1GB
└── 交易日志：15K笔/天 × 2KB = 30MB/天
Gas成本：
├── Ethereum L1存入：~$5/笔（2026估算）
├── Arbitrum存入：~$0.05/笔
├── Base存入：~$0.01/笔
├── 再平衡Gas：~$0.1/笔（L2）
└── 年度Gas预算：~$500K（假设主要在L2）
收入模型：
├── 管理费：0.5% AUM → $1B × 0.5% = $5M/年
├── 绩效费：10%超额收益 → ~$2M/年
├── 协议费用：策略合作分成 → ~$1M/年
└── 总预期收入：~$8M/年
Phase 2：高层架构设计（10分钟）
系统架构总览
多链收益聚合平台 — 高层架构：
═══════════════════════════════════════════════════════════
┌─────────────────────────────────────────────────────────┐
│ 用户层 (Frontend) │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web App │ │ Mobile │ │ API │ │
│ │ Next.js │ │ React │ │ 第三方 │ │
│ │ + Wagmi │ │ Native │ │ 集成 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
│ └──────────────┼──────────────┘ │
└───────────────────────┼─────────────────────────────────┘
│ HTTPS / WSS
┌───────────────────────┼─────────────────────────────────┐
│ API 网关层 │
│ ┌───────────────────▼───────────────────────┐ │
│ │ API Gateway (Kong/AWS) │ │
│ │ 认证 │ 限流 │ 路由 │ 缓存 │ 日志 │ │
│ └───────────────────┬───────────────────────┘ │
└───────────────────────┼─────────────────────────────────┘
│
┌───────────────────────┼─────────────────────────────────┐
│ 核心服务层 (Microservices) │
│ │ │
│ ┌───────────┐ ┌────▼──────┐ ┌───────────┐ │
│ │ 用户服务 │ │ 策略引擎 │ │ 风险引擎 │ │
│ │ User │ │ Strategy │ │ Risk │ │
│ │ Service │ │ Engine │ │ Engine │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ 执行引擎 │ │ 定价引擎 │ │ 报告引擎 │ │
│ │ Execution│ │ Pricing │ │ Report │ │
│ │ Engine │ │ Engine │ │ Engine │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ 再平衡 │ │ 通知服务 │ │
│ │ Rebalance│ │ Notific. │ │
│ │ Scheduler│ │ Service │ │
│ └───────────┘ └───────────┘ │
└───────────────────────┬─────────────────────────────────┘
│
┌───────────────────────┼─────────────────────────────────┐
│ 数据层 (Data Layer) │
│ │ │
│ ┌───────────┐ ┌────▼──────┐ ┌───────────┐ │
│ │ PostgreSQL│ │ Redis │ │TimescaleDB│ │
│ │ 用户/策略 │ │ 缓存/队列│ │ 时序数据 │ │
│ │ /交易 │ │ │ │ 收益率 │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
│ ┌───────────┐ ┌───────────┐ │
│ │ The Graph │ │ S3/IPFS │ │
│ │ 链上索引 │ │ 静态存储 │ │
│ └───────────┘ └───────────┘ │
└───────────────────────┬─────────────────────────────────┘
│
┌───────────────────────┼─────────────────────────────────┐
│ 链上层 (On-Chain Layer) │
│ │ │
│ ┌────────────────────────────────────────────┐ │
│ │ Router Contract │ │
│ │ (用户交互入口，路由到各Vault) │ │
│ └──────┬─────────┬──────────┬────────────────┘ │
│ │ │ │ │
│ ┌──────▼───┐ ┌──▼──────┐ ┌▼──────────┐ │
│ │ ETH │ │ ARB │ │ BASE │ │
│ │ Vaults │ │ Vaults │ │ Vaults │ │
│ │ (ERC4626)│ │(ERC4626)│ │(ERC4626) │ │
│ └──────────┘ └─────────┘ └───────────┘ │
│ │ │ │ │
│ ┌──────▼─────────▼──────────▼────────────────┐ │
│ │ 底层DeFi协议 │ │
│ │ Aave │ Compound │ Lido │ Uniswap │ Curve │ │
│ └────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ 跨链桥 │ │
│ │ LayerZero │ Across │ 官方桥 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ 监控与安全 │ │
│ │ OpenZeppelin Defender │ Forta │ 自定义Bot │ │
│ └────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
核心数据流
用户存入资金的完整流程：
═══════════════════════════════════════════════════════════
步骤 1: 用户请求存入
User → Frontend → API Gateway → 用户服务(验证) → 策略引擎
步骤 2: 策略引擎计算最优路由
策略引擎:
├── 收集数据：
│ ├── 各链各协议当前APY（定价引擎）
│ ├── 各策略风险评级（风险引擎）
│ ├── 跨链Gas成本（执行引擎）
│ └── 用户风险偏好（用户服务）
├── 计算最优路由：
│ ├── 对每个可用策略计算"净APY"
│ │ 净APY = 毛APY - Gas成本 - 协议费 - 风险折扣
│ ├── 按用户风险偏好过滤
│ └── 返回Top 3推荐策略
└── 输出：推荐策略 + 预期收益 + 风险等级
步骤 3: 用户确认
Frontend展示推荐策略 → 用户选择/确认
步骤 4: 执行引擎执行
执行引擎:
├── Pre-Check:
│ ├── 余额检查
│ ├── 授权检查（Approve ERC20）
│ ├── 风控检查（限额/白名单）
│ └── Gas估算
├── 执行:
│ ├── 如果目标在同链：直接调用Router合约
│ ├── 如果目标在异链：
│ │ 1. 调用跨链桥 → 资金转移
│ │ 2. 目标链上调用Router合约 → 存入Vault
│ └── 等待交易确认
├── Post-Execution:
│ ├── 更新用户头寸（数据库）
│ ├── 记录交易日志
│ ├── 发送通知（成功/失败）
│ └── 更新策略TVL
└── 错误处理:
├── 交易失败：自动重试（最多3次）
├── 跨链失败：标记pending → 人工处理
└── 滑点超限：回滚并通知用户
步骤 5: 持续监控
再平衡调度器:
├── 每小时检查所有策略的APY变化
├── 如果当前策略APY下降 > 2%（可配置）
│ 且存在更优策略（扣除Gas后）
├── 触发再平衡：
│ 1. 从当前Vault取出
│ 2. 存入新的最优Vault
│ 3. 通知用户（"已为您切换至更优策略"）
└── 风控检查：
├── 再平衡不超过日限额
├── 目标策略通过风控检查
└── Gas成本合理（收益 > Gas × 30天）
Phase 3：核心组件详细设计（15分钟）
组件 1：策略引擎（Strategy Engine）
策略引擎详细设计：
═══════════════════════════════════════════════════════════
输入：
├── 用户请求（资产类型、金额、风险偏好）
├── 实时APY数据（各链各协议）
├── 风险评级数据（各策略）
├── Gas价格数据（各链）
└── 协议TVL和流动性数据
核心算法 — 策略评分：
Score = w1 × NetAPY + w2 × RiskScore + w3 × LiquidityScore
其中：
├── NetAPY = GrossAPY - GasCost - ProtocolFee
│ ├── GrossAPY: 策略的毛收益率
│ ├── GasCost: 存入+取出+再平衡的Gas成本（年化）
│ └── ProtocolFee: 协议收取的管理费
│
├── RiskScore (0-100, 越高越安全):
│ ├── 智能合约风险 (40%权重)
│ │ ├── 审计次数和质量
│ │ ├── TVL大小（越大越安全）
│ │ ├── 运营时间
│ │ ├── 历史安全记录
│ │ └── Bug Bounty规模
│ ├── 经济风险 (30%权重)
│ │ ├── 收益来源可持续性
│ │ ├── 代币通胀率
│ │ ├── 脱钩风险（稳定币）
│ │ └── 清算风险（借贷）
│ └── 流动性风险 (30%权重)
│ ├── 可以多快取出资金
│ ├── 大额取出对价格的影响
│ └── 锁定期限制
│
├── LiquidityScore (0-100):
│ ├── 即时可取出比例
│ ├── 取出等待时间
│ └── 大额取出滑点
│
└── 权重 w1, w2, w3 基于用户风险偏好：
├── 保守型：w1=0.3, w2=0.5, w3=0.2
├── 平衡型：w1=0.4, w2=0.3, w3=0.3
└── 积极型：w1=0.6, w2=0.2, w3=0.2
策略类型定义：
// TypeScript 伪代码
interface Strategy {
id: string;
name: string;
chain: 'ethereum' | 'arbitrum' | 'base' | 'polygon';
protocol: string; // 'aave' | 'compound' | 'lido' | ...
asset: string; // 'USDC' | 'ETH' | 'stETH' | ...
type: 'lending' | 'staking' | 'lp' | 'farming';
currentAPY: number; // 实时APY
riskRating: 'A' | 'B' | 'C' | 'D';
tvl: bigint; // 当前TVL
minDeposit: bigint; // 最低存入
maxDeposit: bigint; // 最高存入（风控限额）
lockPeriod: number; // 锁定期（秒）
isActive: boolean; // 是否激活
vaultAddress: string; // 链上Vault地址
}
interface StrategyRecommendation {
strategy: Strategy;
netAPY: number; // 扣除费用后APY
riskScore: number; // 0-100
totalScore: number; // 综合评分
estimatedGasCost: bigint;
estimatedAnnualReturn: bigint;
}
// 策略路由函数
function routeStrategy(
asset: string,
amount: bigint,
riskPreference: 'conservative' | 'balanced' | 'aggressive',
sourceChain: string
): StrategyRecommendation[] {
// 1. 获取所有匹配资产的活跃策略
const candidates = getActiveStrategies(asset);
// 2. 过滤：风险偏好 + 金额范围 + 容量
const filtered = candidates.filter(s => {
if (riskPreference === 'conservative' && s.riskRating > 'B') return false;
if (amount < s.minDeposit || amount > s.maxDeposit) return false;
if (s.tvl + amount > s.maxCapacity) return false;
return true;
});
// 3. 计算每个策略的综合评分
const scored = filtered.map(s => {
const gasCost = estimateGasCost(sourceChain, s.chain, amount);
const netAPY = s.currentAPY - annualizeGasCost(gasCost, amount) - PROTOCOL_FEE;
const riskScore = getRiskScore(s);
const liquidityScore = getLiquidityScore(s);
const weights = getWeights(riskPreference);
const totalScore = weights.apy * netAPY
+ weights.risk * riskScore
+ weights.liquidity * liquidityScore;
return { strategy: s, netAPY, riskScore, totalScore, estimatedGasCost: gasCost };
});
// 4. 排序并返回Top 3
return scored.sort((a, b) => b.totalScore - a.totalScore).slice(0, 3);
}
组件 2：风险引擎（Risk Engine）
风险引擎详细设计：
═══════════════════════════════════════════════════════════
风险评估模型：
1. 智能合约风险评估
├── 自动化检查：
│ ├── 合约是否开源 → 否则直接标记为D
│ ├── 是否经过审计 → 审计方可信度评分
│ ├── 合约年龄 → 越老越安全
│ ├── 历史安全事件 → 有重大事件降级
│ ├── 是否可升级 → 可升级加风险分
│ ├── 管理员权限 → 权限越多风险越高
│ └── Bug Bounty → 有且金额大加安全分
├── 评分公式：
│ SC_Score = Audit × 0.35
│ + Age × 0.20
│ + TVL_Safety × 0.15
│ + History × 0.15
│ + BugBounty × 0.15
└── 数据源：DeFi Safety / L2Beat / DefiLlama
2. 经济风险评估
├── 收益可持续性分析：
│ ├── 收益来源分类：
│ │ ├── 真实收益（交易费/利息） → 低风险
│ │ ├── 代币激励 → 中风险
│ │ ├── 代币通胀 → 高风险
│ │ └── 复杂衍生品 → 根据具体评估
│ ├── 如果APY > 20%且主要来自代币激励
│ │ → 标记"可能不可持续"
│ └── 对比历史APY趋势 → 持续下降的降级
├── 脱钩风险（稳定币相关策略）：
│ ├── USDC：低风险（Circle合规+储备）
│ ├── DAI：低-中风险（超额抵押+治理风险）
│ ├── FRAX：中风险（部分算法）
│ ├── USDe：中-高风险（delta neutral机制风险）
│ └── 新稳定币：高风险（缺乏历史数据）
└── 清算风险（借贷/杠杆策略）：
├── 当前Health Factor
├── 资产波动性（30天vol）
├── 清算阈值距离
└── 市场深度（能否顺利清算）
3. 流动性风险评估
├── 即时取出测试：
│ ├── 模拟取出用户金额的100%
│ ├── 计算价格影响（滑点）
│ └── 评估可用流动性深度
├── 锁定期评估：
│ ├── 无锁定 → 最低风险
│ ├── <7天 → 低风险
│ ├── 7-30天 → 中风险
│ └── >30天 → 高风险
└── 退出拥挤风险：
├── 如果所有用户同时退出会怎样？
├── 是否有退出队列机制？
└── 历史最大单日取出量
综合风险等级映射：
┌─────┬────────────┬──────────────────────────────────┐
│ 等级 │ 综合分 │ 说明 │
├─────┼────────────┼──────────────────────────────────┤
│ A │ 80-100 │ 最低风险：顶级审计协议 + │
│ │ │ 真实收益 + 高流动性 │
│ │ │ 例：Aave USDC lending │
├─────┼────────────┼──────────────────────────────────┤
│ B │ 60-79 │ 低风险：已审计 + 混合收益来源 + │
│ │ │ 中等流动性 │
│ │ │ 例：Lido stETH staking │
├─────┼────────────┼──────────────────────────────────┤
│ C │ 40-59 │ 中风险：已审计但较新 + │
│ │ │ 部分代币激励 + 有锁定期 │
│ │ │ 例：新协议farming │
├─────┼────────────┼──────────────────────────────────┤
│ D │ 0-39 │ 高风险：未审计/历史安全问题 + │
│ │ │ 高度依赖代币激励 │
│ │ │ 例：未审计的新Fork协议 │
└─────┴────────────┴──────────────────────────────────┘
组件 3：执行引擎（Execution Engine）
执行引擎详细设计：
═══════════════════════════════════════════════════════════
执行流程：
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 接收请求 │───▶│ Pre-Check│───▶│ 构建交易 │
└──────────┘ └──────────┘ └──────────┘
│
┌────────────────▼─────────────┐
│ 同链 or 跨链？ │
└───┬────────────────────┬─────┘
│ │
┌────▼────┐ ┌────▼────────┐
│ 同链执行 │ │ 跨链执行 │
│ │ │ 1.桥接 │
│ Router │ │ 2.等待确认 │
│ .deposit│ │ 3.目标链执行 │
└────┬────┘ └────┬────────┘
│ │
┌────▼────────────────────▼────┐
│ 等待确认 │
└──────────────┬────────────────┘
│
┌──────────────▼────────────────┐
│ Post-Execution │
│ 更新DB / 通知用户 / 记录日志 │
└────────────────────────────────┘
跨链桥接方案选择：
┌──────────────┬──────────┬──────────┬──────────────┐
│ 桥接方案 │ 安全性 │ 速度 │ 适用场景 │
├──────────────┼──────────┼──────────┼──────────────┤
│ 官方桥 │ ★★★★★ │ ★★☆☆☆ │ 大额/非紧急 │
│ (Optimistic │ │ 7天退出 │ 安全优先 │
│ Rollup) │ │ │ │
├──────────────┼──────────┼──────────┼──────────────┤
│ LayerZero │ ★★★★☆ │ ★★★★☆ │ 中等金额 │
│ │ │ 分钟级 │ 速度与安全 │
│ │ │ │ 平衡 │
├──────────────┼──────────┼──────────┼──────────────┤
│ Across │ ★★★★☆ │ ★★★★★ │ 快速桥接 │
│ │ │ 秒级 │ 用户体验优先 │
├──────────────┼──────────┼──────────┼──────────────┤
│ Stargate │ ★★★☆☆ │ ★★★★☆ │ 多链支持 │
│ │ │ 分钟级 │ 链覆盖优先 │
└──────────────┴──────────┴──────────┴──────────────┘
我们的选择：
├── 默认：Across（速度快 + 安全性好）
├── 大额（>$1M）：官方桥（安全优先）
├── 备选：LayerZero（Across不支持时）
└── 紧急回退：用户手动桥接
Router合约设计（Solidity伪代码）：
// SPDX-License-Identifier: MIT
// 简化版Router合约
contract YieldRouter {
// Vault注册表
mapping(bytes32 => address) public vaults; // strategyId => vault
mapping(address => bool) public approvedVaults;
// 管理员（多签）
address public admin; // Timelock + Multisig
// 紧急暂停
bool public paused;
modifier whenNotPaused() {
require(!paused, "Paused");
_;
}
// 存入
function deposit(
bytes32 strategyId,
address asset,
uint256 amount,
uint256 minShares // 滑点保护
) external whenNotPaused returns (uint256 shares) {
address vault = vaults[strategyId];
require(approvedVaults[vault], "Vault not approved");
// 1. 转入资产
IERC20(asset).transferFrom(msg.sender, address(this), amount);
// 2. 授权Vault
IERC20(asset).approve(vault, amount);
// 3. 存入Vault（ERC-4626标准）
shares = IERC4626(vault).deposit(amount, msg.sender);
// 4. 滑点检查
require(shares >= minShares, "Slippage too high");
// 5. 事件
emit Deposited(msg.sender, strategyId, amount, shares);
}
// 取出
function withdraw(
bytes32 strategyId,
uint256 shares,
uint256 minAssets // 滑点保护
) external whenNotPaused returns (uint256 assets) {
address vault = vaults[strategyId];
// 1. 从Vault取出
assets = IERC4626(vault).redeem(
shares,
msg.sender, // 接收者
msg.sender // 所有者
);
// 2. 滑点检查
require(assets >= minAssets, "Slippage too high");
emit Withdrawn(msg.sender, strategyId, shares, assets);
}
// 再平衡（仅授权Keeper调用）
function rebalance(
bytes32 fromStrategy,
bytes32 toStrategy,
uint256 shares,
uint256 minShares
) external onlyKeeper whenNotPaused {
// 1. 从旧Vault取出
address fromVault = vaults[fromStrategy];
uint256 assets = IERC4626(fromVault).redeem(
shares, address(this), address(this)
);
// 2. 存入新Vault
address toVault = vaults[toStrategy];
address asset = IERC4626(toVault).asset();
IERC20(asset).approve(toVault, assets);
uint256 newShares = IERC4626(toVault).deposit(
assets, msg.sender
);
require(newShares >= minShares, "Slippage too high");
emit Rebalanced(fromStrategy, toStrategy, assets);
}
// 紧急暂停
function pause() external onlyAdmin {
paused = true;
emit Paused(msg.sender);
}
// 紧急全部取出
function emergencyWithdrawAll(
bytes32 strategyId
) external onlyAdmin {
// 从Vault取出所有资金到Router
// 用户可以后续claim
}
}
组件 4：数据库设计
数据库Schema设计：
═══════════════════════════════════════════════════════════
PostgreSQL（关系数据）：
-- 用户表
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
wallet_address VARCHAR(42) UNIQUE NOT NULL,
risk_preference VARCHAR(20) DEFAULT 'balanced',
-- 'conservative' | 'balanced' | 'aggressive'
auto_rebalance BOOLEAN DEFAULT true,
rebalance_threshold DECIMAL(5,2) DEFAULT 2.00, -- APY差异%
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
-- 策略表
CREATE TABLE strategies (
id VARCHAR(64) PRIMARY KEY, -- strategyId
name VARCHAR(255) NOT NULL,
chain VARCHAR(20) NOT NULL,
protocol VARCHAR(50) NOT NULL,
asset VARCHAR(20) NOT NULL,
type VARCHAR(20) NOT NULL,
vault_address VARCHAR(42) NOT NULL,
risk_rating CHAR(1) NOT NULL, -- A/B/C/D
is_active BOOLEAN DEFAULT true,
min_deposit NUMERIC(78,0) DEFAULT 0,
max_deposit NUMERIC(78,0),
max_capacity NUMERIC(78,0),
lock_period_seconds INTEGER DEFAULT 0,
protocol_fee_bps INTEGER DEFAULT 0, -- basis points
created_at TIMESTAMP DEFAULT NOW()
);
-- 用户头寸表
CREATE TABLE positions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
strategy_id VARCHAR(64) REFERENCES strategies(id),
shares NUMERIC(78,0) NOT NULL, -- vault shares
deposited_amount NUMERIC(78,0) NOT NULL, -- 初始存入
deposited_at TIMESTAMP NOT NULL,
status VARCHAR(20) DEFAULT 'active',
-- 'active' | 'withdrawing' | 'closed'
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_positions_user ON positions(user_id);
CREATE INDEX idx_positions_strategy ON positions(strategy_id);
-- 交易记录表
CREATE TABLE transactions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
type VARCHAR(20) NOT NULL,
-- 'deposit' | 'withdraw' | 'rebalance' | 'claim'
from_strategy VARCHAR(64),
to_strategy VARCHAR(64),
amount NUMERIC(78,0) NOT NULL,
shares NUMERIC(78,0),
chain VARCHAR(20) NOT NULL,
tx_hash VARCHAR(66),
status VARCHAR(20) DEFAULT 'pending',
-- 'pending' | 'confirmed' | 'failed' | 'reverted'
gas_used NUMERIC(78,0),
gas_price NUMERIC(78,0),
error_message TEXT,
created_at TIMESTAMP DEFAULT NOW(),
confirmed_at TIMESTAMP
);
CREATE INDEX idx_tx_user ON transactions(user_id);
CREATE INDEX idx_tx_status ON transactions(status);
-- 风险评估记录表
CREATE TABLE risk_assessments (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
strategy_id VARCHAR(64) REFERENCES strategies(id),
smart_contract_score DECIMAL(5,2),
economic_score DECIMAL(5,2),
liquidity_score DECIMAL(5,2),
total_score DECIMAL(5,2),
risk_rating CHAR(1),
details JSONB, -- 详细评估数据
assessed_at TIMESTAMP DEFAULT NOW()
);
TimescaleDB（时序数据）：
-- 收益率快照（每5分钟）
CREATE TABLE yield_snapshots (
time TIMESTAMPTZ NOT NULL,
strategy_id VARCHAR(64) NOT NULL,
apy DECIMAL(10,4),
tvl NUMERIC(78,0),
utilization DECIMAL(5,4),
price_per_share NUMERIC(78,18)
);
SELECT create_hypertable('yield_snapshots', 'time');
CREATE INDEX idx_yield_strategy ON yield_snapshots(strategy_id, time DESC);
-- 用户收益快照（每小时）
CREATE TABLE user_yield_snapshots (
time TIMESTAMPTZ NOT NULL,
user_id UUID NOT NULL,
total_value_usd DECIMAL(20,2),
total_deposited_usd DECIMAL(20,2),
unrealized_pnl_usd DECIMAL(20,2),
realized_pnl_usd DECIMAL(20,2)
);
SELECT create_hypertable('user_yield_snapshots', 'time');
Redis（缓存 + 消息队列）：
// 实时APY缓存（TTL: 30秒）
SET strategy:{id}:apy "5.23" EX 30
// 用户session
SET user:{wallet}:session "{...}" EX 3600
// Gas价格缓存（TTL: 15秒）
SET chain:{chain}:gas_price "25000000000" EX 15
// 交易队列
LPUSH tx_queue "{tx_data}"
// 实时通知发布
PUBLISH notifications:{user_id} "{notification}"
Phase 4：关键技术决策（10分钟）
决策 1：链上 vs 链下策略计算
决策：策略路由在哪里计算？
选项A：链上计算（智能合约内）
├── 优势：
│ ├── 完全透明和可验证
│ ├── 无信任假设
│ └── 原子性执行
├── 劣势：
│ ├── Gas成本极高（复杂计算）
│ ├── 链上数据有限（不能获取跨链数据）
│ ├── 计算能力受限
│ └── 更新困难（需合约升级）
└── 适合：简单的同链路由
选项B：链下计算 + 链上执行 ✅ 我们的选择
├── 优势：
│ ├── 计算能力无限
│ ├── 可以聚合跨链数据
│ ├── 更新灵活（不需升级合约）
│ ├── Gas成本低
│ └── 可以集成AI/ML模型
├── 劣势：
│ ├── 引入中心化依赖
│ ├── 可能被操纵
│ └── 需要信任链下组件
├── 缓解措施：
│ ├── 链上滑点保护（minShares/minAssets）
│ ├── 策略白名单（链上维护）
│ ├── 多个独立Keeper竞争执行
│ └── 开源链下代码供验证
└── 适合：复杂的多链收益聚合 ✅
选项C：ZK证明（未来）
├── 链下计算 → 生成ZK证明 → 链上验证
├── 结合A和B的优势
├── 当前：技术不成熟+成本高
└── 未来：可以逐步迁移
决策 2：推 vs 拉模式的收益率更新
决策：如何获取和更新收益率数据？
选项A：拉模式（Pull）
├── 用户请求时实时拉取
├── 优势：数据最新
├── 劣势：延迟高、成本高、可能失败
└── 适合：低频查询
选项B：推模式（Push）✅ 我们的选择
├── 定时任务定期抓取并缓存
├── 频率：每5分钟
├── 优势：响应快、可靠性高
├── 劣势：数据可能略过时（最多5分钟）
├── 实现：
│ ├── Cron Job每5分钟触发
│ ├── 从各协议合约/Subgraph拉取APY
│ ├── 写入TimescaleDB（历史）+ Redis（实时）
│ └── 前端WebSocket推送变化
└── 适合：高频展示+策略计算 ✅
选项C：混合模式（实际采用）
├── 常规数据：推模式（5分钟刷新）
├── 交易时数据：拉模式（实时获取最新APY）
├── 异常检测：Event监听（协议参数变更）
└── 最佳用户体验 + 数据准确性
决策 3：预言机选择
决策：如何获取资产价格？
选项A：Chainlink ✅ 主要方案
├── 优势：
│ ├── 行业标准
│ ├── 去中心化节点网络
│ ├── 覆盖面广
│ └── 安全记录好
├── 劣势：
│ ├── 更新频率有限（Heartbeat: 1小时 / 0.5%偏差）
│ └── 不是所有Token都有Feed
└── 使用：主流资产定价
选项B：TWAP（Time-Weighted Average Price）
├── 来源：Uniswap V3 Oracle
├── 优势：链上数据、无需外部依赖
├── 劣势：可能被操纵（闪电贷攻击）
└── 使用：Chainlink不支持的Token
选项C：混合方案 ✅ 实际采用
├── 主流资产：Chainlink（ETH/BTC/USDC/DAI等）
├── DeFi Token：Chainlink + TWAP双重验证
├── 长尾资产：TWAP + 偏差检查
├── 异常处理：
│ ├── Chainlink stale → 降级到TWAP
│ ├── 价格偏差 > 5% → 暂停该资产操作
│ └── 两个源都异常 → 暂停全部操作
└── 关键：永远不要依赖单一价格源
决策 4：紧急暂停机制
决策：如何设计紧急暂停机制？
多层安全机制：
Layer 1: 自动熔断（Bot）
├── 触发条件（任一即触发）：
│ ├── TVL下降 > 20%（1小时内）
│ ├── 单一Vault资产损失 > 5%
│ ├── 预言机价格异常（偏差>10%）
│ ├── 异常大额取出（>TVL的5%单笔）
│ └── 底层协议安全事件（Forta检测）
├── 动作：
│ ├── 暂停受影响的策略（非全局）
│ ├── 通知团队（PagerDuty P0）
│ └── 记录事件日志
└── 恢复：需要人工确认
Layer 2: 人工暂停（团队）
├── 2-of-5 多签即可暂停
├── 适用：团队发现问题但Bot未检测到
├── 范围：可以暂停单个策略/单条链/全局
└── 恢复：需要3-of-5多签
Layer 3: 全局暂停（Timelock多签）
├── 3-of-5 多签 + 24小时Timelock
├── 适用：极端情况（全平台暂停）
├── 包括：暂停所有存入，允许取出
└── 恢复：4-of-5多签 + 48小时Timelock
Layer 4: 紧急取出（用户）
├── 即使平台暂停，用户仍可直接从Vault取出
├── 链上合约保证：用户资金始终可取
├── emergencyWithdraw函数：
│ ├── 不经过Router
│ ├── 直接从Vault取出
│ └── 可能损失部分收益但保证本金
└── 这是最后的安全网
Phase 5：安全设计
安全设计全景：
═══════════════════════════════════════════════════════════
1. 智能合约安全
开发流程：
├── 编码标准：OpenZeppelin库优先使用
├── 测试覆盖：单元+集成+模糊测试 > 95%
├── 形式化验证：核心逻辑（Certora/K Framework）
├── 审计流程：
│ ├── Round 1：内部代码审查
│ ├── Round 2：第一家审计公司（Trail of Bits）
│ ├── Round 3：第二家审计公司（OpenZeppelin）
│ ├── Round 4：社区审计（Code4rena竞赛）
│ └── 修复后 → 再次审计确认
└── 部署后：
├── Immunefi Bug Bounty（$1M+赏金）
├── 渐进式容量限制：
│ Week 1: $1M TVL上限
│ Week 2: $10M
│ Month 1: $50M
│ Month 2: $100M
│ Month 3+: 逐步放开
└── 实时监控（OpenZeppelin Defender + Forta）
2. 运营安全
├── 密钥管理：
│ ├── 部署密钥：硬件钱包 + 多签
│ ├── Keeper密钥：MPC + 自动轮换
│ ├── API密钥：Vault存储 + 定期轮换
│ └── 无任何密钥存储在代码/环境变量中
│
├── 权限管理：
│ ├── 最小权限原则
│ ├── 角色分离（部署/操作/管理/审计）
│ ├── 定期权限审查
│ └── 链上权限变更需Timelock
│
└── 事件响应：
├── P0（资金风险）：15分钟响应
├── P1（功能中断）：1小时响应
├── P2（性能问题）：4小时响应
└── 事后复盘（每次P0/P1事件后48小时内）
3. 保险集成
├── 链上保险：
│ ├── Nexus Mutual（智能合约风险覆盖）
│ ├── 保费：~2-3% TVL/年
│ └── 覆盖：智能合约漏洞导致的损失
│
├── 传统保险：
│ ├── 运营风险保险
│ ├── 董事责任保险（D&O）
│ └── 网络安全保险
│
└── 自保基金：
├── 协议收入的10%存入保险基金
├── 用于小额事件的快速赔付
└── 保险基金存放于最安全的策略
Phase 5续：扩展讨论（5分钟）
如何添加新链支持？
新链集成流程（目标：2周完成）：
═══════════════════════════════════════════════════════════
Week 1: 准备
├── Day 1-2: 链基础设施
│ ├── 部署RPC节点（或使用Alchemy/Infura）
│ ├── Subgraph部署（或自建Indexer）
│ ├── 区块浏览器集成
│ └── Gas价格Oracle集成
│
├── Day 3-4: 合约部署
│ ├── 部署Router合约（已审计模板）
│ ├── 部署Vault合约（ERC-4626）
│ ├── 配置权限和Timelock
│ └── 合约验证
│
└── Day 5: 桥接集成
├── 确认桥接方案（Across/LayerZero/官方桥）
├── 配置桥接参数
└── 测试跨链转账
Week 2: 集成测试
├── Day 6-7: 后端集成
│ ├── 策略引擎添加新链数据源
│ ├── 执行引擎添加新链支持
│ ├── 风险引擎评估新链上协议
│ └── 数据库更新
│
├── Day 8-9: 前端集成
│ ├── 链选择器添加新链
│ ├── 策略展示包含新链
│ └── 交易流程支持新链
│
├── Day 10: 测试
│ ├── E2E测试（存入/取出/再平衡）
│ ├── 跨链测试
│ ├── 安全测试
│ └── 性能测试
│
└── 部署
├── 灰度发布（1%用户）
├── 监控24小时
├── 全量发布
└── 公告通知
关键设计原则：
├── 合约模板化 → 每条链部署相同的审计过的合约
├── 后端插件化 → 新链只需实现ChainAdapter接口
├── 前端配置化 → 新链通过配置文件添加，无需改代码
└── 风险独立化 → 每条链独立风险评估，不影响其他链
如何集成AI策略？
AI增强收益聚合：
═══════════════════════════════════════════════════════════
Phase 1: AI辅助策略推荐（当前可做）
├── 基于历史数据训练的APY预测模型
├── 用户行为分析 → 个性化推荐
├── 风险预警（异常检测模型）
└── 实现：链下ML模型 → API → 策略引擎
Phase 2: AI驱动的再平衡（中期）
├── 强化学习模型优化再平衡时机
├── 考虑因素：
│ ├── APY预测（而非当前APY）
│ ├── Gas价格预测（低Gas时再平衡）
│ ├── 市场情绪指标
│ └── 协议风险动态评估
├── 模型每天训练更新
└── 人工审核 → 逐步自动化
Phase 3: AI Agent自主策略（远期）
├── 自主发现新收益机会
├── 自动构建新策略
├── 风险自评估
├── 需要解决：
│ ├── AI决策透明性
│ ├── 风险控制边界
│ ├── 监管合规
│ └── 用户信任
└── 参考：Yearn V3的策略自动化演进
安全边界：
├── AI只提供建议，执行仍需通过风控系统
├── 单一AI策略最大TVL占比 < 10%
├── AI策略必须有人工审查的退出机制
└── AI模型输出可解释性要求
如何支持机构合规？
机构合规扩展：
═══════════════════════════════════════════════════════════
在现有架构上添加合规层：
┌─────────────────────────────────────────────────────┐
│ 现有架构 │
│ [用户层] → [API网关] → [核心服务] → [链上层] │
└──────────────────┬──────────────────────────────────┘
│
┌─────────▼─────────┐
│ 合规中间层（新增） │
│ │
│ ┌───────────────┐ │
│ │ KYC/AML Gate │ │ → 机构用户必须通过
│ │ (Civic/Onfido)│ │
│ └───────────────┘ │
│ ┌───────────────┐ │
│ │ 审批工作流 │ │ → 多级审批
│ │ (Custom) │ │
│ └───────────────┘ │
│ ┌───────────────┐ │
│ │ 审计追踪 │ │ → 不可篡改日志
│ │ (Immutable) │ │
│ └───────────────┘ │
│ ┌───────────────┐ │
│ │ 合规报告 │ │ → 自动生成
│ │ (Report Gen) │ │
│ └───────────────┘ │
└───────────────────┘
实现方式：
├── 散户用户：直接使用现有架构（无需KYC）
├── 机构用户：经过合规中间层后使用
├── 策略分离：机构可以只投"合规策略"
│ ├── 合规策略 = 只包含合规协议的策略
│ ├── 例：USDC Lending on Aave（最合规）
│ └── 排除：未审计协议 / 匿名协议
└── 报告自动化：按月/季度自动生成合规报告
性能优化
性能优化策略：
═══════════════════════════════════════════════════════════
1. 前端优化
├── SSR + 静态生成（Next.js ISR）
├── 链上数据缓存（React Query + Redis）
├── WebSocket实时更新（增量推送）
├── 图表懒加载（仅可视区域渲染）
└── 目标：LCP < 2s
2. 后端优化
├── API响应缓存（Redis, TTL=30s）
├── 数据库读写分离
├── 热点数据预计算（APY/风险评分）
├── 异步处理（交易执行走消息队列）
└── 目标：P99 < 500ms
3. 链上优化
├── 批量操作（Multicall）
│ ├── 多个操作合并为一笔交易
│ └── 节省Gas 30-50%
├── L2优先（Arbitrum/Base的Gas更低）
├── Gas Price预测（低Gas时执行再平衡）
├── EIP-4844 Blob Data（L2成本进一步降低）
└── 目标：用户Gas成本最小化
4. 数据层优化
├── TimescaleDB压缩（90天前数据自动压缩）
├── 热数据/冷数据分层存储
├── 链上索引优化（Subgraph + 自建补充）
└── 读优化：物化视图（常用查询预计算）
完整架构图（ASCII Art）
多链收益聚合平台 — 完整系统架构图
═══════════════════════════════════════════════════════════
用户
│
┌────▼────┐
│ CDN/WAF │ Cloudflare
└────┬────┘
│
┌─────────────────────────▼──────────────────────────────┐
│ 前端 (Vercel) │
│ Next.js 14 │ Wagmi v2 │ TanStack Query │ WebSocket │
└─────────────────────────┬──────────────────────────────┘
│ HTTPS/WSS
┌─────────────────────────▼──────────────────────────────┐
│ API Gateway (Kong) │
│ JWT Auth │ Rate Limit │ Load Balance │ Logging │
└──────┬────────┬────────┬─────────┬────────┬────────────┘
│ │ │ │ │
┌──────▼──┐ ┌──▼────┐ ┌▼───────┐ ┌▼─────┐ ┌▼────────┐
│ User │ │Strategy│ │ Risk │ │ Exec │ │ Report │
│ Service │ │ Engine │ │ Engine │ │Engine│ │ Engine │
│ │ │ │ │ │ │ │ │ │
│ 用户 │ │ 策略 │ │ 风险 │ │ 执行 │ │ 报告 │
│ 管理 │ │ 路由 │ │ 评估 │ │ 交易 │ │ 生成 │
└────┬────┘ └──┬─────┘ └──┬─────┘ └──┬───┘ └────┬────┘
│ │ │ │ │
│ ┌────▼──────────▼──────────▼──┐ │
│ │ Message Queue │ │
│ │ (Redis) │ │
│ └────────────┬────────────────┘ │
│ │ │
┌────▼─────────────────▼─────────────────────────▼───────┐
│ Data Layer │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │PostgreSQL│ │ Redis │ │ TimescaleDB │ │
│ │ │ │ │ │ │ │
│ │ Users │ │ Cache │ │ Yield Snaps │ │
│ │ Strategy │ │ Sessions │ │ User PnL │ │
│ │ Position │ │ Gas Price│ │ Risk History │ │
│ │ Tx Log │ │ APY │ │ │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ The Graph (Subgraph) │ │
│ │ ETH Indexer │ ARB Indexer │ BASE Indexer │ │
│ └──────────────────────────────────────────┘ │
└───────────────────────────┬────────────────────────────┘
│
┌───────────────────────────▼────────────────────────────┐
│ On-Chain Layer │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Cross-Chain Bridge │ │
│ │ Across │ LayerZero │ Official Bridge │ │
│ └──────┬────────────┬────────────┬─────────┘ │
│ │ │ │ │
│ ┌──────▼──┐ ┌──────▼──┐ ┌─────▼───┐ │
│ │Ethereum │ │Arbitrum │ │ Base │ │
│ │ │ │ │ │ │ │
│ │┌──────┐ │ │┌──────┐ │ │┌──────┐ │ │
│ ││Router│ │ ││Router│ │ ││Router│ │ │
│ │└──┬───┘ │ │└──┬───┘ │ │└──┬───┘ │ │
│ │┌──▼───┐ │ │┌──▼───┐ │ │┌──▼───┐ │ │
│ ││Vaults│ │ ││Vaults│ │ ││Vaults│ │ │
│ ││(4626)│ │ ││(4626)│ │ ││(4626)│ │ │
│ │└──┬───┘ │ │└──┬───┘ │ │└──┬───┘ │ │
│ │┌──▼───┐ │ │┌──▼───┐ │ │┌──▼───┐ │ │
│ ││Aave │ │ ││Aave │ │ ││Aave │ │ │
│ ││Comp. │ │ ││GMX │ │ ││Morpho│ │ │
│ ││Lido │ │ ││Curve │ │ ││Aero │ │ │
│ │└──────┘ │ │└──────┘ │ │└──────┘ │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Security & Monitoring │ │
│ │ OZ Defender │ Forta │ Custom Bots │ │
│ │ Chainlink │ Tenderly │ Immunefi │ │
│ └──────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘
PM视角：系统设计如何体现PM和架构师的双重能力
这个系统设计展示的核心能力：
═══════════════════════════════════════════════════════════
PM能力体现：
├── 1. 需求分析能力
│ ├── 先问后做（5分钟澄清需求）
│ ├── 用户分层（散户 vs 机构）
│ ├── 优先级排序（Must Have vs Should Have）
│ └── 规模估算（Back-of-Envelope计算）
│
├── 2. 产品思维
│ ├── 用户旅程（存入→监控→再平衡→取出）
│ ├── 风险分层（A-D评级让用户自主选择）
│ ├── 渐进式上线（TVL逐步提升）
│ └── 商业模式（管理费+绩效费+协议费）
│
├── 3. 市场理解
│ ├── 竞品分析（Yearn vs Beefy vs 自建）
│ ├── 差异化（多链+风险评级+机构支持）
│ └── Go-to-Market策略
│
└── 4. 用户体验
├── 一键操作（降低复杂性）
├── 风险透明（评级+警示）
└── 税务报告（用户价值）
架构师能力体现：
├── 1. 系统设计能力
│ ├── 分层架构（前端/API/服务/数据/链上）
│ ├── 微服务拆分（合理的服务边界）
│ ├── 数据库设计（关系+时序+缓存）
│ └── 接口设计（合约接口+API）
│
├── 2. 技术深度
│ ├── 智能合约设计（ERC-4626 Vault）
│ ├── 跨链方案选择（Bridge比较）
│ ├── 预言机方案（Chainlink+TWAP混合）
│ └── 安全设计（多层防护）
│
├── 3. Trade-off分析
│ ├── 链上vs链下计算
│ ├── 推vs拉模式
│ ├── 安全vs速度（桥接方案）
│ └── 去中心化vs效率
│
├── 4. 可扩展性设计
│ ├── 新链2周集成
│ ├── 新策略1周集成
│ ├── 服务独立扩容
│ └── 数据层水平扩展
│
└── 5. 安全意识
├── 渐进式部署
├── 多层熔断机制
├── 审计流程
└── 保险集成
双重能力的交叉点：
┌─────────────────────────────────────────────┐
│ │
│ PM理解"为什么做" │
│ 架构师理解"怎么做" │
│ 双重能力 = "做对的事" + "把事做对" │
│ │
│ 这个系统设计展示了： │
│ ├── 产品需求 → 技术方案的转化能力 │
│ ├── 商业逻辑 → 系统架构的映射能力 │
│ ├── 用户体验 → 技术实现的平衡能力 │
│ └── 风险识别 → 安全设计的落地能力 │
│ │
└─────────────────────────────────────────────┘
面试追问准备
"如何处理跨链交易失败？"
跨链交易失败处理机制：
═══════════════════════════════════════════════════════════
失败类型及处理：
Type 1: 源链交易失败
├── 原因：Gas不足/Nonce错误/余额不足
├── 处理：
│ ├── 自动重试（提高Gas，最多3次）
│ ├── 如果持续失败 → 回滚 + 通知用户
│ └── 用户资金未离开，无损失
└── 风险等级：低
Type 2: 桥接中间失败
├── 原因：桥接超时/中继器故障
├── 处理：
│ ├── 监控桥接状态（轮询/事件监听）
│ ├── 超过30分钟未到账 → 标记为pending
│ ├── 尝试通过桥接协议的claim机制手动领取
│ ├── 如果资金卡在桥上 → 使用桥的退款机制
│ └── 最坏情况 → 人工介入 + 联系桥接团队
├── 用户沟通：
│ ├── 实时状态更新（"跨链中..."/"等待确认..."）
│ ├── 预估到达时间
│ └── 如果超时："资金安全，正在处理中"
└── 风险等级：中（通常可恢复）
Type 3: 目标链执行失败
├── 原因：Vault满了/滑点超限/合约异常
├── 处理：
│ ├── 资金已到达目标链但未存入Vault
│ ├── 自动重试（调整参数）
│ ├── 如果策略Vault不可用 → 自动选择备选策略
│ ├── 如果所有策略不可用 → 资金存放在Router合约
│ └── 通知用户手动处理或等待自动重试
└── 风险等级：中低（资金在链上安全）
Type 4: 部分失败（最复杂）
├── 原因：批量操作中某些步骤失败
├── 处理：
│ ├── 交易应设计为原子性（all-or-nothing）
│ ├── 如果无法原子性 → 记录中间状态
│ ├── 恢复任务定期检查pending交易
│ └── 人工干预流程
└── 风险等级：中
状态机设计：
INITIATED → SOURCE_TX_SENT → SOURCE_CONFIRMED
→ BRIDGE_INITIATED → BRIDGE_PENDING → BRIDGE_CONFIRMED
→ TARGET_TX_SENT → TARGET_CONFIRMED → COMPLETED
任何步骤失败 → 标记为对应的FAILED状态
每个FAILED状态有独立的恢复策略
"如何防止策略被MEV攻击？"
MEV防护策略：
═══════════════════════════════════════════════════════════
攻击场景：
├── 三明治攻击：在大额存入/取出前后夹击
├── 抢跑交易：看到再平衡交易后抢先执行
└── 长尾MEV：利用策略信息提前布局
防护措施：
1. 交易层防护
├── 使用私有内存池：
│ ├── Flashbots Protect（免费）
│ ├── MEV Blocker
│ └── 交易不进入公共内存池 → 无法被夹击
├── 滑点保护：
│ ├── 合约级minShares/minAssets
│ ├── 动态滑点计算（基于交易大小）
│ └── 超过滑点限制 → 交易回滚
└── 交易时机：
├── 大额操作在低MEV时段执行（如凌晨）
└── 批量操作合并（减少暴露次数）
2. 策略层防护
├── 再平衡随机化：
│ ├── 不在固定时间再平衡
│ ├── 添加随机延迟（0-30分钟）
│ └── 分批执行（大额拆分为多笔小额）
├── 意图系统（Intent-Based）：
│ ├── 提交意图而非直接交易
│ ├── Solver竞争最优执行
│ ├── 类似UniswapX/CoW Protocol
│ └── 用户获得更好的执行价格
└── 信息隐藏：
├── 不公开即将执行的策略变更
├── 再平衡交易延迟广播
└── 策略分配比例适度模糊化
3. 架构层防护
├── ERC-4626 Vault保护：
│ ├── 存入时按当前份额价格
│ ├── 取出时有短暂延迟（可配置）
│ └── 防止闪电贷攻击
├── Keeper网络：
│ ├── 多个独立Keeper竞争执行
│ ├── 使用Flashbots Bundle
│ └── Keeper收益 > Gas成本才执行
└── 金额阈值：
├── 小额交易（<$10K）：正常执行
├── 中额交易（$10K-$100K）：私有内存池
└── 大额交易（>$100K）：分批+私有+时间随机
"如何设计费率结构？"
费率结构设计：
═══════════════════════════════════════════════════════════
收费类型：
1. 管理费（Management Fee）
├── 费率：0.5% AUM/年
├── 收取方式：每天从Vault中自动扣除（1/365）
├── 体现在share价格中（用户无感）
├── 对标：
│ ├── Yearn: 2% AUM
│ ├── Beefy: 0%（只收绩效费）
│ └── 我们: 0.5%（竞争力定价）
└── 减免：TVL > $10M的机构用户可谈判至0.25%
2. 绩效费（Performance Fee）
├── 费率：10%的超额收益
├── 超额定义：超过基准利率的部分
│ ├── 稳定币策略基准：国债利率（~4.5%）
│ ├── ETH策略基准：ETH质押利率（~3.5%）
│ └── 例：策略APY 12%，基准4.5% → 7.5%×10% = 0.75%
├── High-Water Mark：只对新高收益收费
│ └── 避免亏损后恢复期重复收费
├── 收取时机：用户取出时结算
└── 对标：
├── Yearn: 20%
├── 传统对冲基金: 20%
└── 我们: 10%（更低，更有竞争力）
3. 再平衡费
├── 费率：0（不额外收费）
├── 原因：再平衡是为用户优化收益
├── Gas成本：由协议基金承担（用管理费覆盖）
├── 避免：用户因Gas成本而关闭自动再平衡
└── 竞争优势：大多数竞品将Gas成本转嫁用户
4. 提前取出费（可选）
├── 费率：0.1%（仅限有锁定期的策略）
├── 目的：防止频繁进出影响策略表现
├── 免除条件：
│ ├── 存入 > 30天免收
│ ├── 紧急暂停时免收
│ └── 机构用户可协商免除
└── 去向：100%进入保险基金
收入预测（$1B TVL场景）：
├── 管理费：$1B × 0.5% = $5M/年
├── 绩效费：$1B × ~7% 平均超额 × 10% = $7M/年
├── 总收入：~$12M/年
├── 运营成本：~$4M/年
│ ├── 基础设施：$1M
│ ├── 团队：$2M
│ ├── 审计/安全：$500K
│ └── Gas/保险：$500K
└── 净利润：~$8M/年（67%利润率）
费率竞争力分析：
┌──────────┬──────────┬──────────┬──────────┐
│ │ 管理费 │ 绩效费 │ 用户净APY │
│ │ │ │(基于10%毛)│
├──────────┼──────────┼──────────┼──────────┤
│ Yearn │ 2.0% │ 20% │ 6.4% │
│ Beefy │ 0% │ 4.5% │ 9.55% │
│ 我们 │ 0.5% │ 10% │ 8.95% │
│ 自己做 │ 0% │ 0% │ 10%* │
└──────────┴──────────┴──────────┴──────────┘
* 自己做需承担Gas+时间成本
价值主张：比自己做只低~1%，但获得：
├── 自动策略优化
├── 跨链路由
├── 风险管理
├── 安全保障（审计+保险）
└── 税务报告
今日总结
Day 148 核心收获：
═══════════════════════════════════════════════════════════
系统设计面试的核心方法论：
1. 时间管理是关键
├── 5分钟需求分析：不要跳过这一步！
├── 10分钟高层架构：先画大图
├── 15分钟详细设计：深入2-3个核心组件
├── 10分钟技术决策：展示Trade-off分析能力
└── 5分钟扩展讨论：展示视野和远见
2. DeFi系统设计的特殊考量
├── 安全是第一优先级（不是性能，不是可用性）
├── 链上+链下混合架构是标准模式
├── ERC-4626是收益聚合的标准接口
├── 跨链桥接是最复杂最脆弱的环节
├── MEV防护必须在设计中考虑
└── 渐进式部署是必须的（不是可选的）
3. PM + 架构师的双重视角
├── PM：为什么做？做什么？给谁用？
├── 架构师：怎么做？如何保证质量？如何扩展？
├── 交叉点：产品需求 → 技术实现的映射
└── 差异化：大多数工程师只能讲技术
你还能讲清楚商业逻辑和用户价值
4. 面试中的展示技巧
├── 先问再答（展示产品思维）
├── 用数字说话（规模估算展示分析能力）
├── 画图说明（ASCII图足够，清晰最重要）
├── 主动提Trade-off（展示决策能力）
├── 承认不确定性（"这里我不确定，但我的思路是..."）
└── 留钩子（"如果时间允许，我还想讨论..."）
5. 这个设计可以用于真实面试的场景
├── "设计一个DeFi收益聚合器"
├── "设计一个多链资产管理平台"
├── "设计一个智能投顾DApp"
├── "设计一个机构级DeFi服务"
└── 核心组件可复用：策略引擎+风险引擎+执行引擎
关键收获：
┌─────────────────────────────────────────────┐
│ 系统设计面试 = 沟通能力 > 完美方案 │
│ │
│ 面试官看的是： │
│ 1. 你如何拆解问题（结构化思维） │
│ 2. 你如何做决策（Trade-off分析） │
│ 3. 你对领域的理解深度 │
│ 4. 你能否清晰地表达想法 │
│ │
│ 不需要完美方案，需要清晰思路 │
└─────────────────────────────────────────────┘
差异化优势重申：
┌─────────────────────────────────────┐
│ 10 年金融零售经验 │
│ + Web3 90 天系统学习 │
│ + 21 个实战项目 │
│ + 251 天架构笔记 │
│ + 理财专题深度 │
│ ──────────────────── │
│ = 能做系统设计的 Web3 PM │
│ 这在行业中极为稀缺 │
└─────────────────────────────────────┘