kBlnWCOSCon'25 的 Web3.0 开源论坛议程正式发布了。看到消息的时候我正好在跟几个做开源基础设施的朋友聊今年大会值得蹲哪些议题，点开议程清单扫了一遍，第一反应是：今年终于没有再把"去中心化"当成一个时髦前缀，而是把它放回到工程、治理、商业化的真实坐标系里来讨论了。去中心化、开源、Web3.0、COSCon，这四个词放在一起，过去几年常被讲成概念故事，但这一届的议题设置明显开始回答一些更扎手的问题：系统到底怎么跑起来？治理到底怎么落地？贡献者到底靠什么持续投入？
这篇文章不打算复述议程表，而是按我自己的理解，把这届论坛值得关注的内容拆成几条线：先看议程整体透露了什么信号，再看去中心化生态的创新路径到底落在哪些层面，然后聊聊为什么开源是这一切绕不开的底座，最后给不同角色的参会者一些实际的路线建议。如果你也在关注开源和去中心化方向，或者打算去现场，这篇文章应该能帮你省下不少筛选信息的时间。
1. 议程全貌：Web3.0 分论坛在讲什么，以及这次的不同
1.1 从模块设计看论坛定位
COSCon 的 Web3.0 论坛过去几年有个常见问题：讲趋势的多，讲系统的少。今年从公开的议程结构看，明显做了调整。整个论坛大致分成了几个模块：主题演讲、圆桌讨论、专题分享、工作坊、炉边对话。这种结构本身不算新鲜，但看具体议题分配，会发现它更像一个"技术布道 + 落地复盘 + 现场演练"的复合体，而不是单纯的概念宣讲。
其中比较典型的是工作坊的设置。去中心化方向的会议过去很容易开成"大家坐着听 PPT"，今年安排了动手环节，涉及去中心化应用的开发调试、节点部署、跨链互操作测试这类内容。这说明组织者意识到一个问题：Web3.0 的开发者生态要起来，不能只靠理念感召，得让人真的能把代码跑起来。我见过太多人听完一场去中心化存储的演讲很兴奋，回去想动手却不知道从哪开始，工作坊其实就是补上这个断层。
另一个值得注意的是圆桌议题的设计。今年有几场圆桌没有停留在"去中心化前景如何"这种务虚话题，而是把开源社区治理、去中心化治理、开发者激励、项目可持续性放进了同一张桌子上。这个组合很有意思，因为它默认了一件事：去中心化生态缺的不只是技术，更是人和组织之间的协作规则。
1.2 今年最值得注意的三个信号
如果只挑三个信号来概括这届 Web3.0 论坛的变化，我会选这三个。
第一，基础设施议题明显变重。去中心化存储、去中心化计算、节点网络、跨链协议这些词在议程里高频出现，而且不是泛泛而谈，很多是具体项目方的架构分享。这说明行业共识正在从"去中心化是什么"转向"去中心化系统怎么做到可用"。一个系统如果连基本的读写延迟、容错能力、升级机制都讲不清楚，谈生态就是空中楼阁。今年愿意把这些硬骨头搬上台面，本身是好事。
第二，AI 与去中心化的交叉成了主线之一。有多场分享直接涉及开放模型、去中心化算力、模型数据溯源、联邦学习。这个方向最近半年在开发者社区里讨论度很高，论坛把它纳入正式议程，等于承认了"开源模型"与"去中心化基础设施"之间正在形成真实的化学反应。模型权重怎么分发、训练数据怎么确权、推理算力怎么调度，这些以前分开谈的问题，现在被迫放在一起解决。
第三，国内团队的落地案例比例上升。前几年这类论坛的讲台上，海外项目的名字出现频率很高，今年能看到不少国内开源团队带着实际产品来复盘。这背后是开源项目的国产化进程在加速，无论是操作系统、中间件还是应用层工具，都有团队在认真做去中心化方向的尝试。对于参会的国内开发者来说，这些案例的参考价值往往比海外项目更高，因为同样的合规环境、同样的用户习惯，意味着更可迁移的经验。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四条创新主线：从议题单里读出的生态路径
2.1 基础设施：从"能跑"到"跑得稳"
去中心化生态的创新路径，第一层永远落在基础设施。今年议程里关于基础设施的讨论，重点已经明显从"能不能跑"过渡到"跑得稳不稳"。
以去中心化存储为例，早年的讨论集中在内容寻址、去重、冗余备份这些基础概念，今年则更关注存储节点之间的调度效率、数据修复机制、检索性能优化。这些听起来不如"存储永不丢失"那么性感，但恰恰是决定一个去中心化存储网络能不能承载真实应用的关键。我接触过一些做去中心化应用的项目方，他们最常抱怨的不是存储概念不好，而是存储网关的稳定性和读写延迟达不到生产要求。基础设施议题变重，本质上是在回应这类真实痛点。
去中心化计算也是一样。过去讲去中心化计算，容易陷入"用闲置算力跑任务"的单一叙事，今年涉及可信执行环境、算力调度、任务验证机制的讨论明显更多。算力网络的难点从来不只是把机器连起来，而是怎么让任务请求方和算力提供方在互不信任的前提下完成协作——这需要密码学、分布式系统、经济激励三重知识的叠加。论坛愿意在这个深度上展开，说明议题设置者对听众的技术水平是有期待的。
2.2 身份与数据：把数据的控制权还给使用者
如果说基础设施是去中心化生态的骨架，身份与数据就是血肉。这一届专门设置了关于去中心化身份、可验证凭证、数据可携带性、隐私保护的专题，而且不只在概念层面，更多是在讲工具链和落地方案。
去中心化身份，简单说就是让用户在数字世界里拥有一个自己能够掌控、不依赖单一平台存续的身份标识。与之配套的可验证凭证，则让用户能够有选择地向服务方披露信息，而不是把整个身份档案都交出去。这个方向的工程难度不低，涉及密钥管理、凭证签发与验证、撤销机制、跨域互认等一系列问题，每一个都是硬骨头。
我比较关注的是数据可携带性相关的讨论。目前主流互联网服务之间，用户数据迁移的成本依然很高，平台锁定效应明显。去中心化方案在数据层面给出了另一种可能：数据存在用户可控制的存储中，应用只是数据的调用者而不是占有者。这个思路真正落地并不容易，但议程里已经有团队在分享实践路径，包括与开源数据协议、开源存储框架的结合方式。对开发者来说，这些才是可以带回去直接参考的东西。
2.3 治理与协作：开源社区治理经验正在"外溢"
去中心化生态创新路径里最容易被人忽视、但在我看来后劲最大的一条，是治理机制。今年的圆桌话题把开源社区治理与去中心化组织治理放在一起讨论，这个设计很聪明，因为两者本质上共享同一套底层问题：一群互不隶属的人，如何在没有传统科层管理的情况下协作出成果。
开源社区在过去几十年积累了大量治理经验。从贡献者阶梯设计、维护者轮值机制，到行为准则、决策投票流程，这些都是经过实战检验的制度工具。而去中心化组织在治理上面临的问题——提案怎么提出、投票怎么组织、资金怎么分配、分歧怎么处理——跟大型开源社区遇到的治理挑战高度相似。差别在于，去中心化组织试图把这些规则写进代码，让治理过程尽可能自动化、透明化。
这种"代码化治理"的实验非常值得关注。今年的议程里有关于治理工具链的分享，涉及提案管理、投票合约、资金多签管理、社区讨论与链上治理的衔接。对于做开源项目治理的人来说，这些工具虽然还在早期，但已经能提供不少参考。我甚至觉得，未来开源项目的治理方式很可能会反过来借鉴去中心化治理工具，尤其是跨时区、跨组织的协作场景。
2.4 AI 与去中心化的交汇：开放模型带来的新变量
这一届论坛把 AI 相关议题放进 Web3.0 分论坛，说实话我一点也不意外。过去半年，开源大模型的讨论热度持续走高，大量团队开始基于开放权重模型构建应用，而"模型开源了，数据呢？算力呢？"这个问题随之浮出水面。
去中心化算力是其中最直接的交叉点。训练和推理大模型需要大量 GPU 资源，但不是每个团队都有能力自建算力。去中心化算力网络把分散的算力聚合起来，通过调度和验证机制向需求方提供计算服务，理论上能显著降低中小团队获取算力的门槛。当然，工程上还有很多问题要解决，比如算力提供方的可信度、任务结果验证、数据隐私保护。这些正好是密码学和分布式系统研究者的主场，也是论坛相关分享的切入点。
另一个值得关注的方向是开放模型与去中心化数据结合。训练数据的来源、质量、授权情况，在大模型时代越来越敏感。开源模型权重的分发相对成熟，但训练数据的确权和溯源还处在非常早期。有人开始尝试把数据贡献、隐私计算、模型微调结合起来，形成一种更尊重数据提供者权益的协作方式。这类探索能不能成规模，现在下结论太早，但生态创新往往就是从这种"技术可能性 + 协作方式变化"的交叉点长出来的。
3. 为什么去中心化生态的底座必须是开源
3.1 可验证性：信任不能靠"请相信我"
想理解为什么开源是去中心化生态绕不开的底座，最简单的方法是追问一个问题：你凭什么信任一个去中心化系统？
传统互联网的信任建立在品牌和合同上，平台说数据不会泄露，你选择相信它，出事了再通过法律追责。但去中心化系统的设计目标恰恰是尽量降低对单一实体的信任依赖。如果系统核心代码闭源，用户根本无法验证节点是否按规则运行、协议是否存在后门、数据是否被篡改。那去中心化就从技术架构退化成了一句口号。
开源在这里提供了最底层的可验证性。源码公开意味着任何人都可以审查系统行为，可以自行运行节点来验证网络的真实性，可以在发现漏洞时提补丁，而不是只能等待厂商修复。许多去中心化项目把"代码即法律"挂在嘴边，但如果代码本身不公开，这句话就是空谈。我经常跟朋友说，开源对去中心化而言不是可选项，而是信任模型的技术前提。一个闭源的去中心化系统，就像一间墙壁不透明的银行金库，招牌上写着"绝对安全"，却没有办法证实。
3.2 许可证：Web3 项目选型时容易被忽视的约束
开源与去中心化结合的时候，许可证问题往往被低估，但它实际上能决定一个项目的生态边界。不同许可证对代码使用、修改、再分发的约束差异很大，在去中心化场景下还会遇到一些传统软件行业不太常见的特殊情况。
比如强copyleft许可证与网络服务场景之间的张力。传统的 GPL 约束的是分发行为，如果只是把软件跑在服务器上而不做分发，约束并不直接触发。但一些项目选择 AGPL 这类许可证，明确覆盖了网络交互场景，要求即使通过网络提供服务，也需要开放修改后的源码。对去中心化项目来说，节点运营者、网关提供者、上层应用开发者各自身处什么位置、触发了哪些许可证义务，是需要仔细梳理的合规问题。
我注意到近期开源社区里关于许可证选型的讨论特别多，尤其是国产开源项目如何选择许可证、Gitee 上托管项目时用哪个协议更合适，这类问题一直有热度。在 Web3.0 语境下，我建议项目方尽早把许可证问题纳入架构设计，而不是等项目做大了再回头处理。许可证一旦定下来，后面想改牵扯到所有贡献者的授权，成本极高。今年的论坛如果有关于开源合规与许可证的分享，值得专门去听一下。
3.3 治理模式：开源社区的制度遗产
去中心化生态从开源社区继承的第二笔重要遗产，是治理模式。
开源项目尤其是大型基金会治理的项目，早已发展出一套成熟的协作制度：贡献者从提交 pull request 开始，逐步获得信任，成为维护者，进入治理委员会；重大决策通过讨论、投票、共识流程推进；资金使用由基金会或专门委员会管理。这套制度解决的核心问题是：如何在没有雇佣关系的情况下，让分布在世界各地的人持续、有序地为一个共同目标做贡献。
去中心化组织试图通过智能合约把其中一部分规则自动化。提案投票上链、资金多签托管、贡献记录存证，这些都是在用代码强化治理的透明性和执行刚性。但代码只能承载"已形成的规则"，规则本身怎么来、怎么修改，仍然需要人的讨论和共识。这正是开源社区治理经验最有价值的输出。一个去中心化项目如果只有合约代码而没有治理文化，很容易在第一次重大分歧时陷入瘫痪。
所以我在看这届论坛的治理议题时，关心的不是某个工具多炫酷，而是讨论中有没有真正触及治理的文化层面：贡献者怎么被认可、不同利益方怎么对话、决策失败后怎么纠错。这些软性机制才是生态能否长期存续的关键。
4. 参会指南：按角色选择路线，避免逛完一脸懵
4.1 开发者路线：源码、工作坊与动手
如果你是开发者，这届论坛最值得投入的是工作坊和带具体技术栈的专题分享。
我的建议是提前做功课：官网上一般会放出工作坊的报名入口和准备要求，有些动手环节需要提前装好开发环境、配好依赖，现场临时装容易浪费时间。去之前把重点议题对应的代码仓库 clone 下来跑一遍示例，比在现场干听要有效得多。遇到没跑通的，正好带到现场问维护者，这种一对一的交流效率远高于茶歇时的随意聊天。
听技术分享的时候，我有个习惯：不太关注演讲者演示的顺利部分，反而会留意他们提到哪些坑。比如节点同步慢、存储网关超时、跨链交易的确认时间不可控，这些真实问题才是技术选型时最有价值的参考。如果演讲者愿意公开讲失败经历，那这场分享的含金量通常不低。
4.2 创业者/项目负责人路线：找场景、找伙伴
如果你是创业者或项目负责人，逛这种论坛的目标不是学写代码，而是找场景、找伙伴、验证判断。
今年议程里国内落地案例的比例上升，对这些参会者是好消息。同样在国内合规环境下做产品，别人的路径选择、技术架构、遇到的问题，往往比海外案例更有代入感。听案例分享的时候，我建议重点听三件事：第一，为什么选这个技术方向而不是更主流的方案；第二，冷启动阶段怎么找到第一批用户；第三，开源和商业化之间怎么搭桥。这三件事能讲清楚，基本上就能看出一个项目是否真的想明白了。
另外，圆桌讨论其实是观察项目方真实水平的好场景。圆桌上没有 PPT，拼的是临场反应和对行业理解的深度。多留意那些不绕弯子、敢直接回应尖锐问题的发言人，他们所在的项目往往值得后续跟踪。会后可以主动约聊，去中心化圈子其实不大，一个真诚的技术问题很容易打开话匣子。
4.3 观察者/研究者路线：积累一手素材
如果你是做研究、写行业观察或者做投资分析的，我建议不要只泡在主会场，多关注专题分享里的细节数据。比如节点分布、存储容量的实际增长、治理提案的参与率、贡献者数量的变化，这些一手数据在公开渠道往往很难找，但论坛现场可能有人在分享中披露。
对于研究者来说，治理圆桌尤其值得完整记录。不同项目方对治理的看法、对去中心化程度的取舍，这些观点本身就有研究价值。我认识几个做开源社区治理研究的朋友，每次大会结束都能整理出一批很有价值的访谈素材。他们通常的做法是提前确定几个开放性问题，在社交环节有针对性地找不同背景的人聊，而不是随缘认识人。
4.4 现场实操提醒
最后给几条现场实操上的建议。
一是时间冲突要提前规划。大会议程一般会并行好几个分论坛，Session 之间的转场时间有限，提前标记必听场次，留出缓冲，避免因为赶场错过重点。
二是工作坊必须提前预约。这类动手环节通常有人数限制，现场排队基本进不去。
三是社交不要只加微信。加完联系方式之后最好随手记几笔：这个人是做什么方向的、当时聊了什么话题、后续可能有什么合作点。不然三天会开完，通讯录里多了几十个名字，过两周再翻完全想不起来是谁。
四是提问环节尽量问具体问题。像"你这个方案跟某某比有什么优势"这类问题，专家很难三言两语讲清楚，不如问"节点故障时你的恢复机制具体是怎么设计的"这种细节问题，反而更容易获得高质量回答。
5. 提前给"去中心化热"降降温：三个容易误解的问题
5.1 去中心化不是"没有中心"，而是"可审查的中心"
聊去中心化这么些年，我遇到过最常见的误解，就是把去中心化等同于"无中心、无管理、自由放任"。这个理解是错的。
任何一个复杂的系统都需要某种形式的协调，区别在于协调机制是否透明、参与者是否能审查和影响它。比特币算力再分散，客户端实现的核心维护者依然是事实上的中心节点；以太坊再强调去中心化，核心开发者团队对协议演进的推动作用依然极其关键。去中心化并不是消灭中心，而是把中心变成可审查、可替换、可制衡的。
对生态创新来说，这个认知很重要。如果创业团队以为去中心化就是不要运营、不要治理、不要规则，那项目很快会陷入混乱。真正有生命力的去中心化项目，背后往往有一个非常高效的协调团队，只是把权力的边界和存续方式设计得更加透明。论坛上如果有关于项目治理的分享，建议带着这个视角去听，会更有收获。
5.2 开源不等于安全：供应链是一个真实问题
开源社区里有一句常被引用的话：只要有足够多的眼睛，所有 bug 都会无所遁形。这句话有一定道理，但它描述的是理想状态，实际工程中代码公开与代码安全之间还有很长的距离。
很多开源项目长期缺乏足够的代码审计，核心依赖可能只有少数维护者在跟进。近两年软件供应链安全事件频发，攻击者不再直接攻击目标系统，而是攻击目标系统依赖的上游开源库。开源生态的信任链条是环环相扣的，任何一个环节失守都可能波及大量下游项目。对于去中心化项目来说，这个问题更加突出，因为节点软件一旦被植入恶意代码，影响的是整个网络。
所以当论坛上有关于开源安全、供应链安全、依赖审计的议题时，我建议多留一点时间。项目方做技术选型时，也要关注依赖库的维护活跃度、发布包的签名校验机制、镜像源的可信度。安全不是一次审计就能解决的问题，而是一个持续投入的工程过程。
5.3 生态创新真正的瓶颈在协作机制
这届论坛主题叫"解码去中心化生态创新路径"，我的理解是，创新路径不等同于技术路径。技术方案在今天的开源生态里已经非常丰富，真正稀缺的是让不同主体长期协作的机制。
一个去中心化生态要长起来，需要开发者贡献代码、用户提供反馈、节点运营者提供资源、项目方做应用落地、研究者提供理论支撑。这些角色的动机各不相同，如果没有合理的激励机制和治理规则，生态很容易变成一潭死水。这也是为什么我特别在意这届论坛里的治理讨论：它看似没有技术分享那么硬核，实际上决定着其他所有环节能否持续运转。
我个人这两年参加各类开源和去中心化会议，最大的体会是：一个生态最健康的时候，不是喊口号最响的时候，而是大家开始愿意坐下来聊规则的时候。议题里出现大量关于治理、激励、可持续性的讨论，说明这个领域正在从少年期走入青年期。接下来半年，我会重点关注治理工具的实际使用数据、开源项目与去中心化治理结合的试验案例，以及 AI 算力与开放模型的协作模式到底能跑出什么结果。如果你也要去现场，希望这篇文章能让你带着更清晰的视角，淘到真正对自己有用的东西。