Zhuang's Diary

事件核心人物与实体

1. 2017年底 - 2018年：偶然诞生与快速崛起

• 核心事件：据早期媒体报道（如链闻2020年的报道），LuBian矿池的创立极具偶然性。几位来自物流、投资等传统行业的合伙人（报道中使用了“刘萍”、“王强”等化名），因一批矿机滞留港口，为减少损失而决定自行挖矿，并创建了矿池。
• 技术背景：报道提及，其中负责技术的合伙人毕业于香港大学，后在杭州创办了一家大数据科技公司。这是其技术能力的来源，但该合伙人及其公司的具体名称未在报道中公开。
• 商业模式：矿池以“路边”为名，凭借低手续费等策略，迅速吸引算力，在短期内跻身全球矿池算力排名前列。

2. 2020年初：高光时刻与漏洞潜伏

• 核心事件：根据BTC.com等矿池数据网站的历史快照，2020年初，LuBian矿池的实时算力排名一度达到全球第五，这是其最辉煌的时刻。
• 漏洞潜伏：此时，导致日后灾难的“伪随机数漏洞”已潜伏在其自研的钱包系统中。这个由技术团队引入的致命弱点，使得矿池的“金库”看似坚固，实则不堪一击。

3. 2020年4月：漏洞爆发，资产被盗

• 核心事件：根据中国国家计算机病毒应急处理中心于2024年底发布的《报告》，2020年4月，攻击者利用伪随机数漏洞，成功盗取了矿池钱包中的127,272枚比特币。在比特币被盗后，陈志及其太子集团曾多次通过区块链的OP_RETURN功能向黑客公开喊话，LuBian矿池通过比特币网络发送了超过1500条消息，请求归还资产并愿意支付赎金。这种行为本身就强烈暗示了他们承认自己是这批资产的实际所有者。一个无关的第三方不可能，也没有理由去为别人的损失支付赎金。
• 关键信息：这是加密货币史上金额最大的盗窃案之一，根本原因是自研系统未采用密码学安全的随机数生成器。

4. 2020年 - 2024年：资产沉寂与幕后追踪

• 核心事件：被盗资产在链上沉寂。美国司法部启动秘密调查。资产控制方（陈志方面）曾通过区块链向黑客喊话。
• 关键信息：这表明损失是真实的，控制方自身也是受害者，降低了“监守自盗”的嫌疑。

5. 2024年底 - 2025年10月：技术披露与司法没收

• 2025年10月：美国司法部对陈志提起刑事指控，并宣布没收其12.7万枚比特币。其起诉书中列出的25个比特币钱包地址，经过区块链分析公司（如Elliptic和Arkham Intelligence）的追踪，证实正是2020年从LuBian矿池被盗走的比特币最终流入的地址。这表明，在法律层面，美国司法部也将这批从LuBian矿池流出的资产直接认定为由陈志控制。12.7万枚比特币（价值150亿美元）已转入政府托管钱包。陈志及多名关联方（包括 3 名新加坡公民）因涉嫌通过加密货币为网络投资诈骗所得的数十亿美元洗钱，遭到美国当局制裁。

私钥的本质：比特币私钥本质上是一个极其庞大的随机数。标准比特币私钥是一个256位的二进制数。这个数字的空间有多大呢？是2的256次方，约等于10的77次方。
LuBian矿池的私钥生成机制在上述两个核心要点上出现了严重失误。使用了一种名为 Mersenne Twister (MT19937-32)​ 的伪随机数生成器（PRNG），并且仅以32位的种子进行初始化。这意味着，尽管生成的私钥在形式上可能仍然是256位，但其背后真正的随机性来源只有32位。根据报告中的计算，假设攻击脚本每秒可以测试100万个密钥，那么理论上遍历所有可能种子只需要大约1.17小时。

最后，LuBian矿池使用的有缺陷的随机数生成器（Mersenne Twister, MT19937-32）和低熵（32位）问题，与加密货币领域已知的多个重大漏洞（如Libbitcoin的“MilkSad”漏洞、Trust Wallet的历史漏洞）高度相似。这种“重复前人重大错误”的模式，更符合一种缺乏安全审计和经验导致的疏忽。这可能是一个故意留下的后门，比如一个只有设计者知道的“主密钥”。但LuBian矿池的这种低熵漏洞，一旦被外界知晓，相当于把金库的钥匙放在了一个能被很多人猜到的地方。这对于后门设置者本身来说风险也极高。
如果LuBian矿池严格使用比特币核心（Bitcoin Core）或其他成熟的开源钱包软件来生成和管理私钥，那么几乎可以100%避免这个导致灾难性后果的“伪随机数漏洞”。

参考链接：
https://finance.sina.com.cn/chanjing/gsnews/2025-11-13/doc-infxhqmu3714863.shtml
https://zh.wikipedia.org/zh-hant/%E9%99%B3%E5%BF%97_(%E5%95%86%E4%BA%BA)

Best Practice Framework: Idea → Requirements → Design → Tasks → Implementation

1. Idea Phase

• Articulate the core concept - What problem are you solving?
• Define the value proposition - Why does this matter?
• Identify the target outcome - What success looks like
• Consider alternatives - Are there simpler approaches?

2. Requirements Phase

• Functional requirements - What must the system do?
• Non-functional requirements - Performance, security, scalability
• Constraints - Time, resources, existing tech stack
• Acceptance criteria - How do we know it’s done?

3. Design Phase

• Architecture decisions - High-level structure
• Technology choices - Frameworks, libraries, patterns
• Data flow - How information moves through the system
• Interface contracts - APIs, function signatures, data schemas

4. Tasks Phase

• Break down into atomic units - Each task should be independently completable
• Sequence dependencies - What must happen before what
• Identify risks - Where might things go wrong?
• Plan validation - How to test each task

5. Implementation Phase

• Execute in planned order - Follow the task sequence
• Minimal viable code - Only what’s needed for the requirement
• Validate incrementally - Test each piece as you build
• Refactor if needed - Clean up after core functionality works

Why This Prevents Amazon Q Hanging/Inefficiency

The Problem with Skipping Idea Phase:

1
2
3
4
5

❌ "Build me a user system"
→ Amazon Q guesses at requirements
→ Implements generic solution
→ Doesn't match your actual vision
→ Multiple revision cycles

The Power of Starting with Idea:

1
2
3
4
5

✅ "I want users to collaborate on documents in real-time, like Google Docs"
→ Clear idea and vision
→ Specific requirements emerge naturally
→ Design choices become obvious
→ Implementation is focused and efficient

Practical Application Examples

Example 1: E-commerce Feature

Idea: “Customers abandon carts because checkout is too complex”
Requirements: One-click checkout for returning customers
Design: Store payment methods, streamlined UI flow
Tasks: Payment storage, UI simplification, security validation
Implementation: Minimal code for core flow

Example 2: API Optimization

Idea: “Our API is slow because we’re making too many database calls”
Requirements: Reduce response time by 50% without changing API contract
Design: Implement caching layer and query optimization
Tasks: Add Redis, optimize queries, implement cache invalidation
Implementation: Focused changes to bottleneck areas only

Amazon Q Interaction Best Practices

Communicate the Full Journey

1
2
3
4

"IDEA: I want to add real-time notifications to keep users engaged
REQUIREMENTS: Push notifications for comments, mentions, and updates
DESIGN: WebSocket connection with fallback to polling
CONTEXT: @workspace (existing Express.js app with Socket.io already installed)"

Use Progressive Disclosure

1. Start with the idea and get alignment
2. Drill into requirements together
3. Explore design options
4. Plan tasks collaboratively
5. Execute implementation efficiently

Leverage Context Effectively

@workspacefor understanding the bigger picture
@folder for architectural context
@file for implementation details
Share your idea first, then provide relevant context

Red Flags That Indicate Skipped Phases

• Vague requests - “Make it better” (missing idea)
• Feature creep - Requirements keep expanding (unclear idea)
• Over-engineering - Complex solutions for simple problems (poor design)
• Rework cycles - Constant revisions (inadequate planning)

The Compound Benefits

Each phase informs and improves the next:

• Clear idea → More precise requirements
• Precise requirements → Better design choices
• Better design → Cleaner task breakdown
• Clean tasks → Efficient implementation
• Efficient implementation → Less debugging and rework

This approach works for any agentic coding tool, not just Amazon Q. The key is treating the AI as a collaborative partner in the entire creative process, not just a code generator.

Example

requirements.md

Design.md

Task.md

Reference Link ==> https://catalog.workshops.aws/qadvanced/en-US/00-introduction

在大型国际银行的转型中，Core Banking system系统稳定但僵化，移动网银渠道却要求毫秒级响应与全天候在线。

架构设计 - 数据服务层

核心思想​：将散落在各个“烟囱式”系统（银行卡/信用卡支付、风控、保险等）的数据通过技术手段（CDC、日志解析）实时汇聚起来，构建统一、标准的数据模型，并通过 API 的方式透明地提供给前台应用。核心系统停机时，该数据层能提供​“Stand-In”应急服务——支持只读，甚至有限度的暂存式写入。

• 读写分离：读操作快速由数据服务层响应，写操作依赖主系统保障强一致性；
• 容灾能力提升：主系统故障时自动切换至 Stand-In 模式，关键服务仍可继续执行；
• 真正渐进替代：业务逻辑可逐步迁移至服务层，最终实现核心现代化，不需一蹴而就。

主要机制说明：

• 正常模式：
  • 所有读操作由数据服务层提供低延迟响应；
  • 写操作严格通过 Connector 等连接器进入Core Banking system系统，确保主记录一致性；
  • Core Banking system 通过 CDC（如 Debezium）捕获变更并发布至 Kafka，数据服务层实时消费、更新缓存/数据库，最终一致性得以保障。
• 容灾模式：
  • Core Banking system不可用时，API 网关自动切换路由；
  • 写操作由轻量 Stand-In 服务代为接收，校验后写入本地“待处理交易”队列，并立即反馈客户“处理中”状态；
  • 主系统恢复后，后台任务自动逐笔回放交易，完成结算和Core Banking system同步处理。

治理、风险与项目管控：核心现代化控制塔

借鉴 OliverWyman 建议的 Core Modernization Control Tower，可为该架构增设治理层，关键职责包括  ：

• 跨职能治理机制：聚焦业务、运营、技术多方 alignment，确保宏观战略与技术路径一致；
• 风险管理监督：对迁移过程中的操作风险、合规风险、系统风险进行持续审视；
• 迁移节奏策略：统筹“hollow-out”业务削减主机依赖的节奏与业务模块迁移优先级；
• 变更可视化与沟通机制：提供实时反馈与透明度，保障项目顺滑执行。

技术选型与数据架构策略

1. 流式同步与事件驱动

• Debezium + Kafka：主流国际银行采用 Debezium 捕获 DB2 或主机日志，实时推送事件至 Kafka；这已是金融业标准方案  。

2. 存储平台设计

• Redis 集群：用于缓存极热数据，支撑毫秒级读性能；
• TiDB / OceanBase：支持强一致性的分布式关系型存储；适用全量账户与交易数据场景。

3. 数据架构策略

• 结合 Data Mesh / Lakehouse 架构思路提升分析与共享能力；
• 服务层接口应遵循 BIAN / Information Framework 等银行业标准，实现语义统一与模块化服务边界；增强系统的互操作性与标准合规性。

我们得到了什么？

• 弹性与连续性的革命​：Stand-In模式将核心停机从“灾难”变为“可管理的服务降级”，极大提升了业务连续性。
• 解耦开发能力：产品团队可绕开主机耦合，直接基于数据服务层构建灾备能力，实时风控等功能，交付加快；
• 开放 API 驱动：支持开放银行、第三方金融机构接入，实现更灵活生态协同及合作创新，符合当前数字银行趋势。

Modern Core Banking and Wealth Platforms: Who’s Leading with Real Contracts (2019–2025)

https://www.avaloq.com/services/ecosystem