icp

我之所以深刻理解实现计算完全去中心化的真正重要性，背后有一段颇为特别的经历，这个故事值得一讲，且听我慢慢道来。
早在 2015 年，我就已投身于早期的加密货币领域，但我同时也继续运营着自己此前创立的 “Fight My Monster” - 这是一个拥有 300 万用户、且在财务上能够自给自足的、获风投支持的 MMO（大型多人在线）游戏兼社交网络平台。
虽然我已在去中心化计算领域找到了长期的事业归宿，但我无法辜负那些一直支持这款游戏的玩家群体。
“Fight My Monster” 开发于 2010 年至 2012 年间，采用了一种在当时极具创新性的架构，这种架构使平台能够以低成本和极少的运维工作量实现规模化扩展（即容纳海量用户）。
从本质上讲，该系统由三个核心后端组件构成，第一个是简单的 Web 托管服务，负责将前端游戏代码和资源分发到用户的 Web 浏览器中（我当时使用的是主流的内容分发网络，即 CDN）。
与 Web 托管服务一样，另外两个后端组件也必须具备“水平扩展”能力，这意味着，为了支持更多用户及其相关的计算与数据需求，我只需增加硬件资源，而无需重写后端软件代码，也无需进行繁琐的系统管理工作，这种特性使我在项目早期仅凭极少的人员和资金投入，就能实现快速的规模扩张。
第二个组件是一个名为 “Starburst” 的水平可扩展游戏服务器框架，这是我倾注心血亲自打造的成果，它构建于一个支持 RTMP 协议的开源服务器之上 - RTMP 是 Adobe 开发的一种网络协议，允许在 Web 浏览器中运行的 Flash 媒体资源（还记得 Flash 吗？）与服务器直接通信，Starburst 负责承载游戏及社交网络的逻辑，并近乎实时地将游戏中产生的大量事件路由分发给用户。
第三个组件是一个名为 Cassandra 的水平可扩展 NoSQL 数据库（如果你关注数据库领域，想必知道它的一个现代衍生版本 ScyllaDB，该版本目前在满足实时 AI 需求方面表现出色）。
值得一提的是，我的团队中拥有除了 Cassandra 原开发公司之外，唯一的 Cassandra 核心代码提交者（core committer），此外，我是最早将 Cassandra 测试版（beta）真正投入高强度生产环境的用户之一，当用户量达到 80 万时，数据库发生了损坏，随后的 24 小时简直让人神经紧绷 - 我必须争分夺秒地恢复数据并让系统重新上线（那一刻，我感觉自己正冲向云端，下一刻又觉得一切都已无可挽回，好在最终有惊无险）。
Cassandra 最棒的地方在于，你可以直接增加节点（即配备大容量硬盘的服务器）来实现存储容量、读取吞吐量以及 - 最关键的 - 写入吞吐量的水平扩展，这种特性非常罕见，但对我的应用而言至关重要，因为 “Fight My Monster” 会产生海量数据。
当然，Cassandra 的另一个重要优势是具备容错能力，我设置了 5 副本（replication factor 为 5），这意味着每个人的数据都非常安全（至少当时我是这么认为的……），5 副本的配置意味着，对于任何特定的“数据法定人数（quorum）”而言，只要有 3 个节点在线，系统就能正常写入数据。
与区块链不同，Cassandra 并不具备拜占庭容错能力，这意味着我必须严密管理基础设施的安全，防止黑客或恶意软件入侵，不过，当时的黑客对一个主要用户群为儿童的 MMO 游戏兼社交网络并不感兴趣，而且它本身也不是那种供他人在此基础上构建应用的通用平台。
我面临的主要技术压力在于，由于数据生成量巨大，承载数据库的节点承受着极大的负荷，导致它们经常“崩溃”！这意味着我需要不时登录基础设施，下线故障节点并添加新节点，好在操作起来并不困难：得益于容错机制，这项工作无需刻不容缓地完成，而且这些“裸机（bare metal）”服务器也能通过我的云服务提供商进行统一调度……
“Fight My Monster” 采用了一套领先于时代的架构，让我能够轻松实现扩展，此外，其容错能力以及仅包含 3 个核心系统组件的简洁后端架构，意味着维护系统运行所需的管理工作量和压力都降到了最低，那么，究竟是哪一课如此重要，以至于至今仍深刻影响着我的思维方式以及 ICP 的发展？你肯定能感觉到当时发生了一件非同寻常的事 - 现在，我将首次公开讲述这段经历。
当时，我正在亚洲各地奔波，作为早期以太坊核心社区“巡回团队”的一员，拜访相关各方（人们往往忽视了亚洲 - 尤其是中国 - 在早期加密货币领域发展中所起的重要支撑作用），并参加各类以太坊相关的活动，在这些场合，我主要探讨的是自己开发的一些复杂的计算机科学技术，希望能借此提升比特币和以太坊等网络的扩展性与性能。
我不想喋喋不休地谈论“加密货币领域的往昔岁月”，但我得说，那是一段充满魔力的时光，那些早期参与者为我留下了许多美好的回忆，对此我深表感激，那段经历引人入胜，让我甚至无暇去查看邮件。
结果，我在旅途中错过了无数封邮件 - 这些邮件都在警告我：用于支付 Fight My Monster 项目 Cassandra 节点费用的信用卡已经过期了……
那么，当我在几周内（具体时间记不清了，但并不长）没有回应时，云服务商做了什么呢？很简单，他们直接删除了所有的节点！！！
很难形容当我回到加州帕洛阿尔托（Palo Alto）发现这一切时是种什么心情，那是一种震惊与惊恐交织的感觉：胃里空落落的，肾上腺素飙升，恐惧感不断蔓延，我拼命试图挽救，却最终确认一切已无法挽回，那些在加密货币领域遭遇过黑客攻击的人，一定能体会这种感觉。
一切就这样结束了，Fight My Monster 彻底消亡了，社区里甚至有人在 Change.org 上发起请愿，恳求让它重新上线。
尽管失去了它本可能创造的价值，我也感到内疚，但在某种程度上，这也让我感到一种解脱 - 我不再需要承担维护它的责任（否则我可能会为了社区无休止地维护下去），此外，它成为了玩过这款游戏的一代孩子（以及部分成年人）的美好回忆，而且它在变得老旧乏味之前就已落幕，这也让我能够专注于自己当时痴迷的领域 - 去中心化计算网络。
然而，我从中吸取了一个非常深刻的教训：你可以构建出具备可扩展性和容错能力的去中心化计算基础设施，但只要在任何时间、任何环节存在单点故障，整个系统就可能彻底崩溃。
正因如此，每当我听说某些区块链依赖核心开发者持有的管理员密钥，或者听说当大量节点因云服务商关停或技术故障而下线（甚至濒临瘫痪）时，我总是感到担忧，这种极度脆弱的问题在我们的行业中远比你想象的要普遍。
Fight My Monster 那次惨痛经历所带来的教训，深刻影响了 Internet Computer 的设计理念，重要的不仅仅是节点的数量，还有其他更关键的因素，如果节点是匿名的，那么实际运行大部分节点的独立实体数量可能远少于你的预期，此外，尽管节点数量庞大，但它们往往运行在少数几家云服务商的平台上 - 即便它们由不同的实体拥有和运营，云服务商也可能突然决定不再支持它们，并在一夜之间将其关闭（正如 Hetzner 曾对某个知名区块链项目所做的那样）。
在实际应用中，真正重要的是运行节点的独立实体数量，以及节点在物理位置和管辖权上的独立性，这一简单的洞察正是“确定性去中心化”（deterministic decentralization）理念的基石，该理念将以全新的形式体现在 Internet Computer 即将推出的 “ICP 云引擎”（ICP cloud engines）扩展功能中。
ICP 云引擎允许企业（通常情况下）创建实际上属于自己的 Internet Computer 子网，并自行控制其配置，企业可以通过从一个充当“市场”的节点池中选择节点来进行组合，目前，已有超过 1500 个节点处于待命状态，且数量仍在持续增长。
“引擎”提供了一个具备卓越特性的无服务器（serverless）云平台，它是构建 AI 应用和服务的理想场所，因为其技术栈专为支持 AI 轻松生成先进的 AIware 软件而设计，而这些 AIware 软件既安全又具有极强的韧性。
这些应用具备防篡改（免疫基础设施层面的黑客攻击）、全天候在线（因而具有极高的韧性）、可选自主运行（意味着不存在后门）、原生支持数字资产等多种特性，引擎还可以运行诸如 Open SaaS 套件之类的 AIware 应用，支持企业实现端到端的业务运营，云引擎让 Open CRM 或 Open Email 等复杂应用的安装与维护变得像手机应用一样简单。
节点支持热插拔，这意味着你可以调整计算副本因子（compute replication factor）或更换节点，而无需中断云引擎所托管的服务，从而摆脱了对特定计算服务商的依赖，此外，你还可以选择使用部署在超大规模云服务商（hyperscalers）上的新型节点，以及传统的 Internet Computer 节点，使其成为一个通用的计算资源市场。
云引擎（Cloud Engine）框架引导用户组合具有独立性的节点，同时提供了共享式 Internet Computer 托管所不具备的灵活性，例如，一家德国企业可能会选择仅位于欧盟境内的节点，以满足 GDPR（通用数据保护条例）的要求。
然而，由 Internet Computer 网络托管并由 NNS（网络神经系统，即全球最先进的 DAO）负责更新的自主云引擎控制台，会为用户提供指引，如果用户组合了来自同一节点提供商、位于同一数据中心或由同一云运营商运营的节点，该控制台会发出强烈的警告。
因此，即便是在 ICP 云引擎（Cloud Engines）的背景下，“Fight My Monster” 项目所带来的经验教训依然具有现实意义。
人们可能会好奇，为什么该框架极力推动将各个独立节点结合起来，其实这背后有着充分的理由 - 这一理由对于当今更广泛的区块链社区而言，正如 2015 年时那样重要。
期待不久后与大家分享云引擎的相关内容。
#ICP #DFINITY #IC
你关心的 IC 内容
技术进展 | 项目信息 | 全球活动
收藏关注 IC 币安频道
掌握最新资讯

Per-User Subaccount Isolation on the Official ICP Ledger
Centralized exchanges pool user deposits into omnibus hot wallets, commingling funds and creating massive systemic honeypots vulnerable to internal mismanagement and catastrophic breaches.
ICPay utilizes an on-chain custodial architecture with strict cryptographic separation of user balances.
───────────────
Core Technical Architecture & Mechanisms
───────────────
1. Deterministic Subaccount Derivation
Every registered account maps to a unique 32-byte subaccount derived from the user authenticated principal. Funds are held in dedicated ledger subaccounts under canister 6vbhm-nqaaa-aaaan-q6muq-cai.
2. Principal-Enforced Access Control
The backend Motoko actor enforces caller identity on every state mutation. Only the authenticated principal possessing the verified Internet Identity credential can initiate outbound disbursements.
3. Auditable On-Chain Ledger Records
Because each subaccount is indexed directly on the official ICP ledger, balance states and transaction histories are publicly verifiable at any time.
$ICP #ICP #Architecture