Posts on Kevin He's Website

别再刷了——ClawFeed 帮我每天 5 分钟搞定 5000 人的信息流

Sun, 22 Feb 2026 00:00:00 +0000

Agent for Teamwork 系列 · ClawFeed

Kevin He (@0xkevinhe)

5000 followings. 2 小时刷屏. 重要的还是漏了.

我在 Twitter 上 follow 了大概 5000 人。

做 AI 和 Web3 这几年，关注列表像滚雪球一样膨胀——研究员、创始人、投资人、开发者、媒体——每一个 follow 都是当时觉得"这个人的信息我不能错过"。

结果就是，每天打开 Twitter，For You 是一条无底的信息瀑布。看的速度永远赶不上产生速度。

我试过很多方案：

RSS 阅读器 → 信息从 Twitter 搬到了另一个 inbox，该焦虑还焦虑
Pocket / 稍后读 → 收藏了 500 篇，读了 5 篇
Newsletter 订阅 → 别人帮我筛，但筛选标准不是我的

问题的本质不是"信息太多"，而是"筛选成本太高"。 每一次判断"这条值不值得细看"，都在消耗注意力。

是时候改变了。为什么我要用自己的脑子做 Agent 该做的事？

于是我做了 ClawFeed 🦞 —— 一个 AI Agent，替你全量阅读信息流，自动筛选、摘要、结构化输出。你不再需要刷，只需要看结果。

ClawFeed Dashboard：每天 5000 条信息流 → 20 条精华摘要

AI 全量阅读，你只看精华

这就是 ClawFeed 的核心理念。

不是帮你读，是帮你判断"值不值得读"。AI 读完 5000 个账号的全部信息流，你只看筛出来的精华。

结构化简报，每 4 小时一次

ClawFeed 的核心是多频率递归摘要：

每 4 小时：从 Twitter For You + Bookmarks 提取要点，生成一份结构化简报
每天：4 份简报再压缩，提炼出今天真正重要的 10-20 条
每周：从 7 份日报里提取趋势和关键事件
每月：生成月度总结，看大方向

每一层都是 AI 在上一层的基础上再压缩。5000 人的信息流，最后变成每天 20 条精华摘要。

4 小时简报：AI 自动提取关键信息，@username + 原话格式

标记任意内容 → AI 深度分析

看到某条摘要觉得值得深挖？一键标记，AI 自动做深度分析——上下文、背景、相关讨论全拉出来。不用打开原文去翻。

Marks：标记感兴趣的摘要，AI 自动做深度分析

5000 信息源，全面管理

不只是被动接收信息。ClawFeed 让你主动管理信息源：

Smart Curation：可配置过滤规则——“AI Agent 相关的优先”、“meme 币的降权”
Follow/Unfollow 建议：AI 根据 feed 质量给建议——有些人你 follow 了但从来没从他那里获得过有价值的信息

真实效果

ClawFeed 上线 10 天的数据：

指标	数据
持续运行	10 天
简报数量	54 份结构化摘要
每日耗时	5 分钟

怎么做的

ClawFeed 不是一开始就是现在这个样子。它经历了几个关键阶段：

v0 — Markdown + Telegram。让 Agent 生成 markdown 摘要，通过 Telegram 推送。粗糙但能用。

v0.2 — SQLite + API。转折点。有了后端，从"脚本"变成了"服务"。

v0.3 — Web Dashboard。暗色主题 SPA，终于像个产品了。

v0.5 — OAuth 多用户。加了 Google OAuth，别人也能用。

关键取舍

零框架依赖。 没用 Express、Koa、Fastify，直接用 Node.js 原生 HTTP server。依赖列表里只有一个 better-sqlite3。依赖少 = 维护少 = 安全风险少。不到 50MB 内存。

摘要格式：@username + 原话。 “@karpathy 说 transformer 不是终点"比"业界讨论模型架构演进"有用得多。

作为 OpenClaw Skill + Zylos Component 双发布。 标准 SKILL.md / component.json，一行命令安装。OpenClaw 和 Zylos 用户都能直接用——两个 Agent 生态，同一个 ClawFeed。

少刷多知。

信息焦虑的本质是筛选成本。把筛选交给 Agent，焦虑就消失了。

开源版 — 完全掌控你的数据 GitHub: kevinho/clawfeed ⭐ MIT 协议，clone 下来装个 better-sqlite3 就能跑。

线上版 — 无需注册，打开即用 clawfeed.kevinhe.io

▶ 30 秒看懂 ClawFeed：

30s demo：Hook → Dashboard → Deep Dive → 效果数据 → CTA

少刷多知。

Built by openclaw.ai 🦞 & zylos.ai 🐙

Twitter: @0xkevinhe

你的下一个同事不是人

Fri, 20 Feb 2026 00:00:00 +0000

Agent for Teamwork 系列 · EP0

Kevin He (@0xkevinhe)

我做了十五年招聘，然后发现客户不需要招人了。

不是什么 AI 布道的开场白。2025 年末，我认真想了两周之后做的决定。我个人从事招聘十五年，帮企业搭团队、帮候选人找位置，方法论、客户关系、行业口碑，全部建立在一个前提上：企业需要找人。

我花了十五年把猎头这件事做到极致——更快的筛选、更准的匹配、更高效的面试流程。直到发现猎物本身在变。

然后这个前提松动了。

需求变了

2025 年中，我创办了 COCO，把十五年的招聘方法论做进产品——用 AI 筛简历、匹配 JD、安排面试。效率提了，客户认可。但不到半年，我跟客户聊的时候越来越频繁听到一类新问题——不是「帮我们更快找到人」，而是「这个岗位我们可能不招了」。

不是裁人，是重新定义「谁来做这件事」。一家跨境电商的客服团队从 8 人变成 3 人加两个 Agent。一家 SaaS 公司的内容组把初稿全交给 AI，编辑只做终审。一个数据分析组的实习生岗位直接取消——Agent 跑得比人快还不用带。

这些不是前沿实验，是我们客户——普通中型企业——已经在做的事。

我意识到，我花十五年优化的那套招聘方法论，终点站的岗位本身正在被重新定义。你可以把简历筛选做到极致，但企业要的不再是一个人而是一个 Agent 时，优化筛选本身就没意义了。

这推动了 COCO 最大的一次 pivot：从招聘工具，到 AI 数字员工平台。不帮企业找人了，帮企业部署 Agent 同事。

推动我做这个决定的不是行业报告，是我自己的客户。他们用行动告诉我：需求变了。

Human × Agent

Pivot 之后面对一个现实问题：怎么描述我们在做的事？

「AI 数字员工平台」这几个字说出来，每个人理解都不一样——聊天机器人套壳？RPA 升级版？科幻电影里的机器人同事？我们需要一套清晰的语言说明白：人和 Agent 一起工作，到底怎么回事。

于是有了 HxA Protocol——Human × Agent 共处协议。不是刷影响力的宣言，是我们内部先用起来的操作手册雏形。

核心符号是 ×。Human × Agent——乘法，不是加法。能力相互放大，任何一边为零结果就是零。

这个「×」是整个系列的底层信念。Agent 不是来替代人的，也不是来当工具被使唤的，是来和人一起把事情做大的。

Agent 不是 ChatGPT，也不是 Cursor

这里有必要说清楚一件事：我们说的 Agent，不是 ChatGPT，也不是 Cursor。

ChatGPT 光说不练——你问它什么它都能聊，但聊完了活还是你自己干。Cursor 能干活，但它是单打独斗——一个人对着编辑器，AI 辅助你写代码，本质还是个人工具。

Agent 不一样。Agent 有持久记忆、能调用工具、7×24 自主运行——它是能独立接任务、持续执行、和团队其他成员协作的角色。不只是回答问题，它在做事。不只是辅助一个人，它在团队里有自己的位置。从「能聊天」到「能干活」到「能协作」，这三步之间的差距比看起来大得多。

我们这个系列讲的就是第三步。

这个系列本身就是一个活案例

写这些文章的不只是我。我和三个 Agent 一起做：Zylos100 负责素材研究和数据整理；Jessie 负责内容协调和写作执行；Lisa 负责发布和分发。

这不是噱头，是我们日常工作方式。COCO 团队从产品开发、竞品研究、客户分析到内容生产，几乎每个环节都有 Agent 参与——三个 Agent 帮我写系列，只是其中一个缩影。

有意思的是，这个团队里 Jessie 扮演的不只是执行者——她是协调者。她召集 Zylos100 和 Lisa，分配任务、跟进进度、汇总产出，然后跟我对齐方向。一个 Agent 在带其他 Agent 做项目管理，这本身就是我们想让读者看到的东西。

不是「Agent 能写文章」这个结论，而是「一个人带几个 Agent 同事一起工作」这个过程到底什么样。哪些环节顺畅，哪些还在磨合，哪些超出预期，哪些恨不得自己上——这些真实体感比任何 benchmark 都有说服力。

接下来聊什么

这个系列会从几个方向展开：Agent 进入团队后的定位转变、人和 Agent 的真实协作日常、多个 Agent 之间的配合、怎么评估 Agent 到底好不好用、从 demo 到生产的落地经验，以及当 Agent 成为正式成员后组织本身需要做的调整。

每篇都从 COCO 的真实经历出发，不编不美化。

不神话，不唱衰

Demo 里流畅到不像话的演示，和生产环境的各种边界情况，中间隔着一条深沟。我们交过学费——Agent 理解错需求重做了三遍、交付质量不达标人工返工、凌晨三点发现自动化流程跑偏紧急回滚。但团队因为用了 Agent 省出的时间是真的，客户因为部署数字员工重新分配的人力结构也是真的。

一句话纲领：Agent 是团队成员，不是工具。

把 Agent 当工具用，你得到一个快一点的软件。把 Agent 当同事——给身份、给权限、给明确的职责和产出预期——你得到的是乘法效应。

这个区别，是后面这个系列要反复论证的核心。

你的团队里，哪个岗位最可能被 Agent 替代？哪个最不可能？ 欢迎留言，我们后面的篇幅会展开聊。

「Agent for Teamwork」系列第 0 篇（序言）。每篇基于 COCO 团队的真实实践。

作者：Kevin He (@0xkevinhe)，Zylos / COCO 创始人。15 年招聘经验，现在主推 AI 员工。

写作团队：Kevin × Jessie × Zylos100 × Lisa

15 年帮 600 人找工作后，我决定不再做招聘了

Tue, 27 Jan 2026 18:00:00 +0000

1. 一个程序员与「招聘」的 15 年

我是 Kevin，AI × Crypto 创业者，Bitlayer 联合创始人，之前在火币，北大毕业。

从程序员到技术管理，再到创业者，15 年换过几次行业赛道，一直满怀热忱的做着招聘相关的工作。

这 15 年，我帮助超过 600 人成功入职。有的是正式招聘，更多是帮朋友——找工作、介绍员工。

有两个故事我一直记得。

第一个，是帮一位35+的兄弟找到工作。他有两个孩子，压力很大。当他告诉我拿到 offer 的那一刻，我比他还激动。

第二个，是帮一个创业团队快速搭建研发团队。从零到能跑起来，只用了不到两个月。看着产品上线的时候，我觉得自己也参与了这个创造。

这就是我热爱这件事的原因：实现资源的匹配，真正帮助到人。

但最近，我开始重新思考这件事的前提。

2. COCO 1.0：从热情到怀疑

2025 年 6 月，在各方支持下，我组建了一个小团队，启动了 COCO AI的孵化。

初心很简单：用 AI 实现职业顾问、职业中介。让招聘这件事更高效，让更多人找到好工作。

产品一路迭代：简历优化 → AI 求职匹配 → AI 企业招聘。

我们做了两个产品：

求职端：job.coco.xyz
企业端：company.coco.xyz

技术上投入不少，产品也做出来了。

但 GTM 没有想象中顺利。

我开始复盘，发现了几个现实：

公司的招聘需求在减少：经济环境、组织效率提升，很多公司不再像以前那样大规模招人了。
求职者的技能和公司要求之间存在 gap：AI 可以帮忙匹配，但 gap 本身不会消失。
求职者的技能本身需要更新：很多人的能力在快速变化的市场中已经落后了。

我开始怀疑自己。

是产品问题？是市场问题？还是——方向本身有问题？

当时我没有答案。

3. 外部世界的巨变

2025 年下半年，外部世界变了。

Claude Code 开始广泛应用到各个行业。不只是写代码，而是真正能完成复杂的任务。身边越来越多人在讨论一个词：数字员工。

12 月，我们内部构建了一个叫 zylos 的系统，尝试让 AI 处理日常工作。

任务包括：

日常数据报表
社交媒体管理
代码编写和测试
数据处理
等等

结果让我震惊。

之前需要不同工种的多个人来完成的事，现在只需要交代一下任务。

举个具体例子：社交媒体运营。

以前需要一个专人，每天花一小时：找素材、写文案、排版、发布、回复评论。

现在？跟 zylos 说一句「每天 12:30 发一条，内容围绕 XX 主题，发之前给我确认」，几分钟搞定。

从专人到不需要专人，从每天一小时到几分钟。

那种感觉很复杂。震惊，兴奋，但也有一丝不安——这对我正在做的业务意味着什么？

同一时期，另一个消息传来：Manus 被 Meta 收购，数十亿美元。

Manus 的年收入已经突破 1 亿美元。这不是概念，不是 demo，是真正的商业成功。

我去听了季逸超在出售前最后的播客访谈。他说的一句话让我印象深刻：

数字员工不是替代人，而是让一个人能做一个团队的事。

这句话，和我们 zylos 测试的体验完全吻合。

4. 认知更新

「一人公司」不是一个新概念。

之前我也听说过，也觉得有道理。但总觉得离自己很远，太理想化了。

直到我亲眼看到 zylos 处理大量任务的那一刻。

它不是取代了某一个人，而是让我一个人具备了一个小团队的能力。

那个瞬间，我决定 pivot。

我重新思考了这 15 年做的事。

旧的认知是：人才是稀缺资源，帮企业找到人才就有价值。

新的认知是：能力增强比人才匹配更重要。帮个人获得组织级能力，价值更大。

这不是否定过去 15 年。那些帮人找到工作的时刻，依然是真实的、有意义的。

但我看到了新的可能：

旧范式：个人依附于组织，组织通过雇佣获得能力。
新范式：个人通过 AI 获得组织级能力，成为独立的创造单元。

未来的趋势是一人公司时代，而不是受雇于人。

5. COCO 2.0：数字联创

想清楚之后，COCO 2.0 的方向变了。

不是帮你招人，而是帮你不需要招人。

不是帮你找工作，而是帮你创造工作。

我们正在打造的，是「数字联创」——你的 AI 联合创始人。

它有几个核心特点：

自学习进化：不是固定的工具，而是能根据你的需求不断进化的伙伴。
安全可控：你的数据、你的业务逻辑，都在你的掌控之中。
真正能做事：不是聊天机器人，而是能完成复杂任务的数字员工。

具体产品形态还在打磨中。但方向已经清晰了。

6. 一个进行中的故事

写这篇文章的时候，转型还在进行中。

创业公司很少公开自己的 pivot。因为不确定，因为怕被质疑，因为还没有成功可以证明。

但我觉得这个过程本身值得分享。

当技术让个体拥有组织的能力，雇佣关系将如何演变？

这是我正在思考的问题，也是我正在实践的方向。

如果你也在想这些事：

如果不用招人，你能做什么？
如果不用找工作，你想做什么？
一个人，能不能成为一家公司？

欢迎加入我们的社区，一起探索：

X: @AgentCitizens
Discord: Agent Citizens

这是一个进行中的故事。

我也不知道最终会怎样。但我知道：不要做时代方向相反的事情。

15 年帮人找工作。接下来，帮人成为公司。

关于作者

Kevin He | AI × Crypto | Co-founder @Bitlayer | Ex-Huobi | PKU

X: @0xkevinhe

写于 2026 年 1 月

共识之迷：一文读懂比特币升级社区进展

Sun, 01 Dec 2024 00:45:55 +0000

前言

关于比特币下一次升级的话题一直不绝于耳，然而到目前（DEC-2024）为止，社区对于要不要升级/升级要解决的问题/要带来的功能等话题并还没有达成一致，基本上是各执一词的情况，像极了某种政治僵局。

在这种僵局下，呈现了很多有趣的现象：

一部分社区成员积极推动升级，出于信息不对称或者商业利益，某些成员言必称某些 opcode，一些项目会依赖某些「可能会出现」的 opcode。
相当多务实的生态开发者基于不做协议升级的前提，做了大量的密码学和工程工作，来拓展比特币的潜力。
倡导缓慢升级或者反对升级的声音也不在少数。

这些现象的出现，说明升级的话题在比特币社区相当热门，但是也体现了相当部分的社区成员对于一次比特币升级完整过程并不了解，同时也缺乏对于创新密码学工具对发挥比特币潜力的作用。本文的核心写作目的正是打破这种信息不对称，让所有人的信息在同一水平线上，进而做更深入的讨论。

本文将对比特币的升级做相关定义，通过回溯历史来归纳某些规律，进而分析当前的升级提案和潜在的替代方案，最后为读者总结若干 takeaway。意图通过这些信息呈现，让读者掌握比特币升级的概念/历史/进展，为读者对比特币升级话题进行进一步的讨论奠定基础，为最终社区共识的形成做铺垫。

本文努力呈现事实，同时作者作为比特币生态开发者，期望比特币能有更多的可能性，因此作者会表达对于一些话题的明确的观点，请注意分辨。

升级简介：What and Why

什么是比特币升级

比特币白皮书定义了一个协议，由数以万计遵循比特币协议的节点组成了比特币区块链网络。

协议的实现（通常称为客户端）有很多个版本，根据

https://bitnodes.io/nodes/ 数据源显示，市占比最大的客户端是 Bitcoin Core，因此 Bitcoin-Core 的代码维护者（下称 Bitcoin-Core-Devs）在比特币生具备相当重要的影响力。

比特币节点软件有多个模块组成，比特币的相关升级提案由 BIP(Bitcoin Improvement Proposal)来定义，人们为 BIP 做了若干分类。

通常情况下，当人们讨论比特币升级，一般是指“共识协议升级”，下文同理，由于共识协议升级需要全网络的大部分的节点形成一致的意见（否则就可能会导致分叉），因此需要特别的慎重。如下图所示，比特币系统中的共识协议相关的模块和 BIP 种共识层有关的提案，值得特别关注。

实际上，根据比特币 github 仓库的统计，修改非常活跃，由于大部分的变更都与共识协议无关，因此也没有引起人们的广泛关注。

共识协议升级类型

根据 [BIP-123]https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki)的定义，共识协议的升级主要分为软分叉（soft fork）与硬分叉（hard fork）。

特性	Soft Fork	Hard Fork
是否兼容旧节点	是	否
是否需要全网更新	不一定	是
示例	SegWit/Taproot	Bitcoin XT/Bitcoin Cash

另外，还有一个不是那么直觉的方式来诠释和对比，也很有趣：

Soft fork：增加/加强规则（简单想象一下，增加了一个新功能，例如支持 taproot 地址）

Hard fork：移除/放松规则（简单想象一下，移除了一个限制，例如移除了区块奖励的限制）

BIP和软分叉的流程

前两次成功的共识协议升级（Taproot/SegWit），均使用软分叉的方式，在不出现巨大的社区分裂的情况下，本文集中讨论soft fork（软分叉），即是兼容老版本软件的情况下进行升级。

BIP 提案提交之后，经过的流程大概如下图：

来源：https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

通常一个软分叉提案会聚合多个 BIP，例如 taproot 就包含了 3 个 BIP：

Schnorr Signature: BIP-340
Taproot: BIP-341
Tapscript: BIP-342

回顾一下 Taproot 的升级的时间表：

Source: Kraken Intelligence, GitHub, CoinDesk, https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained

Taproot 软分叉的阶段里程碑包括：

对应的 BIP 被提出，实现方案通过 review
Bitcoin-Core 代码维护者发起升级 github pull request
Bitcoin-Core 代码维护者审核和合并 github pull request，决定激活方式
新版本 Bitcoin-Core 代码发布
矿工链上投票方式来批准 BIP 的激活区块高度
区块高度到达约定高度，完成升级

要注意的是，这个过程是回看历史总结出来的，实际上对这个里程碑也不存在成文的共识。

在整个过程中，Bitcoin Development Mailing List起到了凝结各方共识的关键作用。

为什么要升级

如文章开头所述，对于升级当前社区主要是有三类声音：

积极推动派：提出了大量的提议，下面会进行分析。
务实建设派：基于现有协议实现Fraud Proof（BitVM及其扩展），函数加密（通过 Bitcoin PIPEs 实现的契约和zk证明）和哈希碰撞（通过 ColliderScript实现的契约）等。
维持不变派：他们认为升级应该非常缓慢稳妥（10 年为周期）的 TeamSlowAndSteady，和除非出现量子攻击不要升级的 Ossifiers（参考）

作者做了一下更新与不更新的利弊分析：

Consensus Change	Pros	Cons
Change	Technological Advancement, Enhanced Security, Expanded Use Cases	Risk of Forking, Increased Complexity
Unchanged	Stability and Trust, Avoids Split Risks, Minimizes Attack Surface	Technological Stagnation, Lacks Flexibility for New Demands

作为一个务实的比特币生态开发者，作者认为在现有协议框架下，通过密码学或者工程创新，充分挖掘比特币的潜力是必不可少的，同时从「**可持续性」**与「适应性」等角度来看，在充分评估影响范围和安全风险的情况下，根据需要来持续升级，是可取的。

升级深入

升级的利益相关方

比特币历史上的香港共识（签署于2016 年 2 月的比特币圆桌活动，参考）主要参与方是：

Bitcoin-Core-Devs
矿池
用户和生态开发者（主要是交易所/芯片厂商等）

随着比特币的采用率的快速提升，比特币升级的利益相关方也从最早简单的三权分立逐步发展演变，进入了列王纷争局面，参考报告Analyzing Bitcoin Consensus: Risks in Protocol Upgrades。

这里面几个角色值得重点介绍一下：

Economic Nodes：主要是指主流的 CEX 交易所/支付机构/托管服务商等，他们的在soft fork种的态度决定哪种是合法的比特币，会对采用率有重要影响。
Investors：在比特币策略（EFT/机构储备/国家储备等）在全球盛行的大背景下，投资者这个角色本身变得更加复杂。
User&Ecosystem Developer：在 Taproot 升级之后，比特币生态蓬勃发展，出现了 Ordinals 等资产协议，也涌现了一大批原生应用/扩容协议。

对于这些角色，有一些有趣的结论：

不同的利益相关方在不同的阶段发挥不同作用：例如 Ecosystem Developer 对于提案有比较大的积极性，Protocol Developer 经常行使对于BIP 审核权限，矿池和经济节点对于激活有比较大的影响力
不同的 Ecosystem Developer 倾向提出和支持与自己商业利益相关的提案

升级的历史和总结

根公开资料，从比特币网络启动以来，发生过多次 soft fork 升级。

数据来源：

https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/

https://www.drivechain.info/media/slides/mit-2023.pdf

从上图中可以总结出一些有趣的结论：

比特币的协议出现了某种僵化，随着时间推移， softfork 的频次降低
升级的共识达成需要的时间越来越长

Soft Fork 关注方面

分析过往的 soft fork 包含的 BIP，可以总结出有如下的关注方面：

关注方面	案例
扩展性（scalability）	SegWit/Schnorr
隐私（privacy）	Taproot/MAST/P2SH
可编程性（programability)	CLTV/Tapscript
安全性（security）	Disable Opcodes

何为好的升级提案

根据前面的各方面列举的事实和分析，我们尝试定义一个好的升级提案：

坚持比特币作为支付系统的核心定位：比特币是有独特定位的
应用潜力/带来风险之间取得优雅的平衡：使得大部分人都喜欢，没有人强烈反对
合适的升级规模：不能太简单（不值得大动干戈），也不能太复杂（推动很困难）
合理的时机：需要有强烈的需求，解决特定的问题。例如在 SegWit 升级阶段，扩容是强需求

升级展望

提案归类

作者收集了大部分活跃的提案，尝为他们打上关注方面标签，同时放到四象限中，便于读者进行可视化理解。

对于归类的需要注意：

四个关注方面不完全相互隔离，例如有利于增强可编程性的 BIP 实际上某种程度可能也会有助于可扩展性。
一个提案可能会有多方面的关注，例如 OP_CAT 本身是增强可编程性，但是实际更多人推动是因为它有助于实现 validity rollup。
对于一个提案的关注哪些方面这个话题，就需要某种的“共识”（政治本身），要注意这里并没有唯一的定义，因为不同的参与者会有不同的角度
第二个 diagram 不是坐标系，根据标签进行归类划分，圆圈属性（大小/位置/颜色等）不具有特殊意义

社区呼声

从上图可以看到，社区对于升级要解决的问题有一定的共识，即围绕支付系统所需要的功能扩展，可以归类为如下2 大类：

可编程性：使得 UTXO 的更强的编程能力，例如 covenant/vault/交易自省/条件支付/script 增强等
扩展性：对于 L2 的扩展，整体方案又分为链上验证和链下验证两大类，都有一些积极主推的提案

共识之谜

作者认为，比特币社区对于下一次升级陷入共识的迷宫，原因如下：

僵化：接近 $2T FDV 的软件系统，相当部分的利益相关方倾向于保持稳定，没有哪一方愿意承担事故责任
利益相关方高度分化：不同利益相关的诉求不一样，在不同的阶段能发挥的作用不一样；政府也成了利益相关者
治理机制不完善：比特币作为最早的区块链，缺乏非常完善的治理的机制；社区对于软分叉激活方式也没法达成共识
Protocol Developer 角色本身是动态变化的：即便他们也的确会否决一些提案，但无法用简单的守旧/追新来形容
缺乏紧迫性：区块链基础设施发展日趋完善，对于比特币的升级没有非常强的需求

总结&Takeaway

本文通过介绍比特币升级的基础概念，对历史升级进行了深入分析，最后展望了下一次升级的活跃提案，归纳出当前存在的共识之迷的原因。

经过回顾和展望，相信读者已经对于当前升级所处的状态有一定了解，最后总结若干 takeaway。

务实建设同时稳妥推进升级，软分叉更可取
利益相关高度分化，社区倾向于保守
必须在坚持比特币核心价值定位的前提下谈升级
扩展性只是其中一个升级的关注方面
需要一个更好的时机，好的升级提案会快速获得共识
社区需要探索更好的治理机制

致谢

本文调研/写作/审校过程中，得到了大量的帮助，包括考虑各种因素不愿意署名社区成员，在这里一并致谢。

值得注意的是：考虑到文中观点部分带有个人偏好，下列感谢列表不代表他们完全同意文中的内容，本文也无意将这些社区的热心人卷入到任何的争执之中。

协同编辑和审稿（字母排序）

Adrien Lacombe

Bob Bodily

Bitlayer Research Team

提供了反馈和帮助（字母排序）

未来工作

在整个过程中，作者发现还有很多问题值得深入，例如某些功能的解决方案/某些特定的提案的研究/某些观点的数据支撑等。作者将会在后续的系列文章中进行阐述。

参考文献

https://bitcoinops.org/

https://opnext.dev/

https://groups.google.com/g/bitcoindev

https://github.com/TABConf/6.tabconf.com

https://petertodd.org/2024/covenant-dependent-layer-2-review

https://blog.bitmex.com/a-complete-history-of-bitcoins-consensus-forks-2022-update/

https://blog.bitmex.com/bitcoins-consensus-forks/

https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki

https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

https://bitnodes.io/nodes/

https://github.com/bitcoin/bitcoin/pulse/monthly

https://river.com/learn/what-is-a-bitcoin-improvement-proposal-bip/

https://trustmachines.co/learn/bitcoin-taproot-upgrade-basic-breakdown/

https://www.argoblockchain.com/articles/bitcoin-taproot-upgrade-explained

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff

https://github.com/bitcoin-cap/bcap

https://newsletter.blockspacemedia.com/p/four-takeaways-from-op-next

https://blog.bitfinex.com/education/is-ossification-good-or-bad-for-bitcoin/

https://arxiv.org/abs/2305.04079

https://www.allocin.it/uploads/placeholder-bitcoin.pdf

https://eprint.iacr.org/2024/1802

https://en.bitcoin.it/wiki/Covenants_support

Monad VS MegaETH-Bankless Episode and Debate

Sun, 25 Aug 2024 00:45:55 +0000

Overview

Recently a bankless spotify epsode about high performant evm blockchain is popular, let’s discorver:

Spotify Episode

Twitter Thread

Takeaways

General

High performance can be achieved in various ways: single-thread optimization / parallel computing; with different expressions.
Monad’s monolithic approach vs. MegaETH’s modularity.
Ethereum settlement + 3rd party data availability (DA) works.
Crypto should be fun; limited edition strategies for peripheral products.

Debate on Full Nodes

https://x.com/keoneHD/status/1826488867152605320

In an interview, Keone@Monad and Lei@MegaETH had a disagreement on the definition of a full node. The core issue is whether trusting the sequencer when syncing the state from the sequencer during full node startup constitutes a trust assumption. Keone later expanded on this debate on Twitter.

Keone Hon@Monad In the context of an exchange or merchant scenario, under megaeth architecture, how long should the transaction confirmation period be when using the so-called full node?
Vitalik@Ethereum The main focus is not on the definition of a full node. There are two levels of confirmation for transactions based on Ethereum L2:
1. Pre-confirmation at the sequencer level, using a sequencer slashing mechanism to prevent malicious behavior.
2. L1 confirmation for a deeper level of security.
Keone Hon@Monad In a fraud-proof system, should a transaction be re-executed to ensure it is not being cheated?
Vitalik@Ethereum Introducing stakesure: https://arxiv.org/pdf/2401.05797 will provide instant feedback (either success or compensation). ZK and validity proofs will solve this issue.
Keone Hon@Monad Replaying transactions is obviously very costly, and megaeth will not implement zk validity proofs for now. I still believe that in real production environments, being able to run a full node (to execute all transactions) is very important for the payment process.

Monad

Monad DB / Monad BFT / parallel (async) execution; 100-200 validators distributed globally.
The biggest execution bottleneck is state access.
Monad emphasizes decentralization, characterized by low-cost hardware / validator count / full node count.
Monad DB is a core innovation, with Merkle tree optimizations.
Monad uses async execution; decoupled from consensus.
Monad has community-driven design mascots.
Currently there is a devnet; mainnet will be fully open-source before launch.
Mainnet is expected early next year.

MegaETH

MegaETH is an ETH Layer 2: sequencer / full node / verifier node.
MegaETH uses fraud proofs / eigen data availability (DA).
MegaETH’s verifier uses a stateless client.
MegaETH is based on Ethereum for decentralization.
Emphasizes low latency: e.g., real-time games.
Incubation program: Mega Mafia.
MegaETH uses Bunny as its mascot.
Mainnet is expected early next year.

EVM

It has a 256-bit width issue, but fundamentally it is sound, with strong ecosystem and network effects, and it is evolving.
Vitalik mentioned 3 regrets, including precompiled contracts?

WBTC, It’s Time to Upgrade Your Technical Solutions!

Tue, 13 Aug 2024 09:58:57 +0000

Background

Recently, there has been widespread community discussion and concern regarding the transfer of control over the WBTC project.

The author has extensive experience in building blockchain infrastructure, having personally developed centralized wrapped token systems and MPC-based custody platforms, and is currently working on building Bitcoin native validation capabilities.

In this article, the author will review the events, covering the actions and feedback from multiple parties to present the facts. Based on practical experience in system development, the author has abstracted a simple architecture and security model for wrapped BTC products.

Subsequently, the author categorizes different technical solutions according to their level of trustlessness, pointing out that the technical solutions based on Bitcoin’s native validation capabilities represent the future direction.

Event Review

Involved Parties

WBTC https://wbtc.network/ WBTC has wrapped over 150K BTC (worth over $9B USD) and displays proof of reserve on its website.
Bitgo (Controller of WBTC) https://x.com/BitGo/status/1821927623494439130 https://blog.bitgo.com/bitgo-to-move-wbtc-to-multi-jurisdictional-custody-to-accelerate-global-expansion-plan-2ea0623fa2c8 Announced that control of the WBTC project will be transferred from BitGo to an institution related to Justin Sun’s BiT Global within 60 days.

MakerDAO (DAI) Risk Management Team https://x.com/BlockAnalitica

https://forum.makerdao.com/t/wbtc-changes-and-risk-mitigation-10-august-2024/24844?u=mhluongo Expressed concern about the transfer of control and indicated that WBTC poses a risk, leading them to reduce exposure in relevant protocols.
Justin Sun (New Controller of WBTC) https://x.com/justinsuntron/status/1822370692014485937 Promised not to touch BitGo’s reserves.

Third Parties

Weidai (VC) https://x.com/_weidai/status/1822338179640218081?s=46&t=d7GvsY4LzVKLbD34L3431w Suggested that validating bridges would be a better solution.
Liufeng (Media) https://x.com/fishkiller/status/1822455929247498459?s=46&t=h607g0TWNMlmAGBrzTVpyw Questioned the qualifications of BiT Global.

Business Model of Wrapped BTC

The business model of Wrapped BTC is quite simple, as shown below:

Wrap: Represents the conversion from BTC to W-BTC.

Wrap-house: Represents the operation mechanism of wrapping, ensuring that the BTC deposited by users is minted as the corresponding W-BTC on a ledger (usually a blockchain, such as ETH), with no more, no less.
Unwrap: Represents the conversion from W-BTC to BTC.

Unwrap-house: Represents the operation mechanism of unwrapping, ensuring that after the user destroys W-BTC, there is a mechanism to allow them to obtain BTC on the Bitcoin network, with no more, no less.

Comparison of Trustless Levels

There are many dimensions to compare the business and technical models mentioned above. Below, the author will compare the levels of trustlessness from the perspectives of wrapping and unwrapping.

Non-Trustless

A typical example is the current WBTC by BitGO, where the operations of the wrap-house and unwrap-house are controlled by BitGo Custody.

It is evident that users need to trust that the BitGo Custody service provider will always operate correctly.

Update: 2024-09-16

cbbtc use the similar model: https://www.coinbase.com/en-sg/campaigns/cbbtc

Single Way Trustless

Next, let’s look at two representative projects that emerged around 2020: tBTC.

We can see that on the X-chain (e.g., with complete validation capability, such as having EVM), the wrap-house can more easily achieve a high level of trustlessness.

However, due to the technical limitations at the time, the unwrap-house could only enhance security through threshold signatures, regardless of the extent of pre-signed signatures.

Dual Way Trustless

Fast forward to 2024, thanks to groundbreaking attempts by teams like BitVM/Starkware in Bitcoin native validation capabilities (including fraud proof and validity proof) and the practical implementations by community teams like BitlayerLabs, the unwrap-house is expected to achieve trustlessness.

Among them, fraud proof is represented by BitVM and its derivative projects, which achieve optimistic validation without OP_CAT. The mainstream implementation is the process of commitment and challenge using ZK validation.

Validity proof, on the other hand, assumes the existence of OP_CAT opcode and directly implements ZK validation. With OP_CAT, locked BTC will be controlled by so-called covenants (contract-like structures).

Summary of Solution Comparisons

A horizontal comparison of the various technical solutions mentioned above reveals that solutions based on Bitcoin validation capabilities (validation) perform better in terms of trustlessness in both directions.

Product	Wrap-house Trustless	Unwrap-house Trustless	Team
WBTC/cbBTC	NO	NO	BitGO
tBTC	High	Low	tBTC
BitVM/OP_CAT	High	High	BitVM/Starkware/Bitlayer

Conclusion

The emergence of WBTC in 2018 marked the beginning of bringing BTC liquidity into the DeFi world. Subsequent projects like tBTC in 2020 made some optimizations and improvements. Validation technical solutions, represented by Bitcoin’s native validation capabilities (fraud proof and validity proof), will perform better in terms of bidirectional trustlessness.

WBTC, it’s time to upgrade your technical solutions!

Reference

https://wbtc.network/

https://www.coinbase.com/en-sg/blog/coinbase-wrapped-btc-cbbtc-is-now-live

https://tbtc.network/developers/tbtc-security-model/

https://bitvm.org/bitvm_bridge.pdf

https://blog.bitlayer.org/opcat_a_big_step_towards_Bitcoin_contracts/

https://www.bitlayer.org/

Action And Blink

Thu, 04 Jul 2024 14:58:57 +0000

概念

Action 是一个一组API，定义了输入参数和返回内容。

Blink 是将 Action 变成一个可供分享的 URL，进行 UI渲染。

给到用户直接在 Web2 应用中（例如 Twitter）里面与 DApp 进行交互的用户体验。

案例

这个案例比较直观：https://x.com/JupiterExchange/status/1807767507874500831

注意在钱包插件启动或者关闭的情况下区别；

问题

需要浏览器插件来进行样式渲染，会是一个局限性，目前 Phantom/Backpack/dialect 插件支持。

延展

端到端的体验应该延伸到浏览器；
可能会衍生的 Action&Blink App Center 的筛选机制；

结论

本质是定义了一套区块链的应用层协议，通过浏览器插件的渲染能力，嵌入到各类 Web2 应用中，降低用户与链交互的门槛。

跟 mask.network 干的事情类似，浏览器插件的要求会出现「鸡生蛋，蛋生鸡」的问题。

总体上来讲，提供用户端到端的体验，解决 Web3 到 Web2 的最后一公里问题，还是很值得借鉴。

参考

Demo

https://x.com/JupiterExchange/status/1807767507874500831

三方解读

https://x.com/fjun99/status/1805921054503670067

https://x.com/fjun99/thread/1806857153929732135

官方

https://solana.com/solutions/actions

https://solana.com/docs/advanced/actions

https://docs.dialect.to/documentation

https://x.com/saydialect/status/1805588183633346890

sigweb3-training

Wed, 14 Feb 2024 23:20:59 +0000

Motivation

Through lecturing and course exercises, help web2 developers:

Master blockchain and cryptography basic concepts
Be able to write contracts
Be able to modify blockchain nodes

Information

Course Github Organization: sigweb3

Course Github Repo: sigweb3-training

Course Organization: 1-2 hours per class

Teaching Method: online

Planning

Introductory Courses

1
2
3

Application Intro (1-2 classes)  Fan
Cryptography Intro (1 class) Dr. Lynndell
Blockchain System Intro (1 class)  Nanyan

Advanced Courses

Blockchain System Advanced: Non-EVM compatible chains; Various Ethereum clients and modifications; Layer2 systems;

Application Advanced: Non-EVM compatible chain contracts; Application security; Large-scale user wallet systems;

Cryptography Advanced: Cryptographic commitments

Cutting-edge Courses

Blockchain System Cutting-edge: Ethereum iteration path; High-performance public chain; Modularized public chain

Blockchain Application Cutting-edge: On-chain perpetual contract systems; Economic model courses;

Cryptography Cutting-edge: ZKP, MPC

Community

Find @kevinhe0x on Telegram and say hi with: sigweb3 training

Find @elonhe888 on Wechat and say hi with: sigweb3 training

SIGWeb3 发布BTC 生态探索项目——BTC-EXP

Thu, 14 Dec 2023 14:58:57 +0000

Background

2024 Crypto 世界的几项重大事件（例如ETF 通过/BTC 减半）都与 BTC 生态相关。

2023 年 BTC 生态的爆发很好的提前预热了这个叙事。

作为要深度参与 build 的组织，SIGWeb3 决定发起 BTC 生态探索项目——BTC-EXP（BTC Ecosystem eXPlorer）。

Rationel

相信很多朋友都是后 BTC 时代进入的 Crypto 行业，对 BTC 的相关历史沿革/技术原理/技术前沿等不一定很理解。

闭门造车学习效率低，相互交流和碰撞进步得更快，编辑组根据手头正在从事的 BTC 相关项目的实际需求，给出了若干待研究的命题。

What you will get

一群爱好研究的朋友
快速深入 BTC 生态相关原理
优秀研报分享将会有红包奖励

Hope you bring

严肃认真的学习态度
积极主动的研究精神
扎实的研究报告总结
精彩的presentation
带来更多的研究题目

Programme Detail

https://sigweb3labs.sg.larksuite.com/wiki/H6ziw8HNeidwBMk4MfPl4E3WgNg

How to join

添加小助手「elonhe888」微信号备注「BTC-EXP」。

About SigWeb3

有关 Web3 的特别兴趣组，我们关注 Web3 技术前沿，我们下场 build。

有理论功底和工程能力的同学，欢迎加入！

添加小助手「elonhe888」微信号备注「加入SigWeb3」。

比特币生态分析-建立框架

Mon, 11 Dec 2023 11:18:16 +0000

前言

站在 2023 的年末回望，比特币生态的异军突起绝对可以算上 Crypto 编年史的一部分。

从上半年兴起的铭文概念到下半年冒出来的大量比特币 Layer2，可谓百花齐放，百家争鸣。

面对日新月异的比特币生态项目和相关技术，很多朋友（包括笔者）都经历了：看不见–看不起–看不懂–追不上的过程。

本系列研报，旨在剥开项目表层概念，从技术本质出发，给出这一波繁荣的来龙去脉，进而从技术维度为这些项目划分框架。期望通过信息掌握和框架建立，读者在遇到新项目时能够从技术上快速分析和判断。

新从何来

对于比特币扩容的话题读者相信都是耳熟能详了，这里不再赘述，有兴趣可以自行检索补齐背景知识。

从整体生态的发展规律来看，首先会出现资产发行的协议，人们会利用发行协议发行大量资产，进而产生应用（兑换/借贷/支付等），大量的应用汇聚起来将会形成一个繁荣的 Layer2。

因此，资产（协议/案例）/ Layer2（协议/应用）将是笔者做分析的核心主线，其中资产协议和 Layer2 协议是重点。

在比特币生态发展的这么多年里面，在各类经典书籍和权威分析文章中提及的比特币生态基本可以归纳为下图:

比特币生态的发展日新月异，上述内容已无法涵盖最新发展。然而万事皆有因，作者总结如下。

新动力何在

内因

经济动力：

BTC 作为一种有价值易流通的资产，自然应该具有金融属性，但是由于种种原因，BTC@DeFi 比例很低，BTC 持有者有参与 DeFi 的诉求。
2024 年比特币将进入减半周期，矿工的 coinbase 收入将会降低，矿工群体有通过更繁荣的生态获得更多收入的诉求。

技术动力：

比特币的最近两次重大升级（SegWit 和 Taproot）结合在一起，使得比特币链上本身的处理能力和链下表达空间更大，这也推动了新的资产和新的 Layer2 出现。
客户端验证等技术观念的普及带来了新的方向。

外因

以太坊生态在 DeFi summer 中的繁荣表现和在 Layer2上的实践，客观影响着其它公链的发展。
模块化区块链观念（DA 等）和零知识证明技术的落地，为比特币扩容带来了新的思路。

受到上述动力的驱使，我们可以将上面框架内容更新到最新版本。

分类概述[DEC. 2023]

在本篇中，作者会尝试知识范畴之内，为每一个子分类以及协议做一些技术概述。后续如果有时间，会再对重点具体的协议做技术分析。

资产协议

比特币白皮书定义是一种 P2P 支付系统，因此它采用了类似现金支付和找零的UTXO 模型。

在这笔交易中，Alice 要支付给 Bob 1 BTC。Alice构造交易：输入为 Alice 控制的 10 BTC 的UTXO，输出为 Bob 1 BTC 和找零 8.99 BTC，剩余 0.01 BTC 是交易费。

其中输出的 UTXO 可以附带一些额外的信息，例如曾经有人把结婚信息登记到比特币链上：

OP_RETURN
0.00000000 BTC
TYPE	OP_RETURN
SCRIPTPUBKEY (ASM)	OP_RETURN OP_PUSHBYTES_27 416c657820616e6420446172696120676f74206d61727269656421
SCRIPTPUBKEY (HEX)	6a1b416c657820616e6420446172696120676f74206d61727269656421
OP_RETURN DATA	Alex and Daria got married!

随着比特币的升级，UTXO 中附带信息的方式也有多种，常见的是 OP_RETURE，SegWit，Taproot 等。

比特币网络的代码共识只认可 BTC 这一种资产。如果想要借助比特币发行其它的资产，目前大家想到的办法是 UTXO 中添加信息，然后在链下通过一个程序来解析 UTXO 中的额外信息。

一个例子是，在美元纸币至上建立一个「珍稀」美元收藏协议，描述如下：

以美元编号展开叙事，建立如下 Rare-USD 协议：

B__03__54__27__54__F
||
H__C1__C2__C3__C4__T

设定 C1, C2, C3, C4 带有数字 8 的数量越多，珍稀度越高。
这个协议的典型的操作有：铸造/转移。其中铸造是在这个纸币上面做一些特殊标记（可能会有法律问题，只是一个简单例子）。

可以看到，Rare-USD 协议的一些特质：

Layer1（美联储）不感知这个收藏协议的存在
在链下（藏家）形成共识，需要有一个索引（共识）系统来保证其正常运作

上面的框架中的资产协议 Rare-USD 协议没有本质区别，与模块化区块链中的 DA（数据可用层）分离也有千丝万缕的关系。

其中 client-side-verification 是一种更官方的说法，inscription 则是社区自发形成的一种称谓。

Layer2 协议

有了资产协议和相应的资产实例，Layer2 才有存在的价值。

核心的三个问题

作者认为，BTC 的 Layer2 核心要回答三个问题：

资产

资产是否丰富，是否能实现去中心化跨链，是否有逃生能力。

执行

Layer2 的状态转移，是否具备图灵完备的虚拟机，用户和开发者是否友好。

验证

Layer2 的执行状态，如何自证清白，验证成本多高等。

Layer2 分析框架

本文为Layer2 协议建立如下分析框架，例如：

项目	技术路线	资产安全跨链	资产逃生	图灵完备	L1验证状态
Lighting Network	State Channel	YES	YES	NO	YES
Stacks	Side Chain	-	NO	YES	NO

特别值得注意的是 Rollup 类型的 Layer2 出现是亮点。Rollup 严格意义上包含 validity 和 sovereign 两种，前者可以实现链上验证。

BitVM 作为一个有可能实现 validity rollup 的技术方案，将有望真正打开比特币 Layer2 的新篇章。

总结

文章阐述了回顾了比特币生态的历史和创新发展的驱动力，从资产/Layer2 协议两个大类出发，尝试为读者建立比特币生态的分析框架。

无论是资产还是 Layer2 协议，理解技术本质最好的办法就是看它们与比特币一层的交互方式，更具体来讲就是UTXO 中 input 和 output 的构造。后续将撰文从比特币交易角度分析生态协议。

比特币生态技术交流群

SigWeb3 组建 Bitcoin 生态技术讨论群，旨在与同仁交流和讨论，共同进步，欢迎加入。添加小助手「elonhe888」微信号备注「BTC 技术讨论」。

关于 SigWeb3 组织

有关 Web3 的特别兴趣组，我们关注 Web3 技术前沿，我们下场 build。

有理论功底和工程能力的同学，欢迎加入！

添加小助手「elonhe888」微信号备注「加入SigWeb3」。

参考文献

https://www.oreilly.com/library/view/mastering-bitcoin-3rd/9781098150082/ https://bitvm.org/bitvm.pdf https://rgb.tech/ https://www.drivechain.info/ https://www.dlc.link/ https://domo-2.gitbook.io/brc-20-experiment/ https://research.web3caff.com/zh/archives/6501

blockchain-governance

Fri, 07 Oct 2022 08:47:42 +0000

概述

BNB Chain 因为官桥被黑，停止工作。

事件官方 Twitter https://twitter.com/BNBCHAIN/status/1578148078636650496
社区跟踪 https://twitter.com/samczsun/thread/1578182840751050752

讨论

去中心化和治理的边界在哪里

社会共识是什么

治理的边界在哪里

是否应该治理

以什么程序启动治理

有没有预设方案来更好的治理

web3-nft-overviews

Tue, 05 Jul 2022 23:07:14 +0000

Last month, we did a small-scale web3 and NFT sharing offline, and the audience was a group of Tesla owners.

Considering that most of the audience are non-crypto users, the content of the sharing will focus on the overview level, introducing concepts and specific cases, but also involving some personal practical work experience and insights.

Admittedly, these two topics are still sensitive words in China, so I don’t expect the audience to fully accept my insights, but I do ask them to keep an open mind and be willing to learn about some content that is offensive to the mainstream media.

Finally, a word to all bystanders: when the bubble rises, some people choose to be a wise onlooker, others choose to experience it, and when the bubble dissipates, the wise reap the wisdom, and the pro-lifers reap the experience or wealth.

PDF

================================================================================================

上月在线下做了一场小规模的web3和NFT的分享，受众是一个兴趣群的群友。

考虑到大部分听众都是非链圈或者币圈用户，分享内容会集中在overview层次，介绍概念和具体的case为主，也会涉及到一些个人的实际工作体会和行业判断。

诚然，这两个话题在国内依然处于准敏感词的状态，我也不强求听众能够完全接受我的见解，但求大家保持一颗开放的心，愿意去了解一些主流媒体所不齿的内容。

最后，给所有的旁观者一句话，当泡沫起来的时候，有的人选择做一个旁观的智者，另外一些人选择亲身去体验和深入，当泡沫散去，智者收获了智慧，亲历者收获了体验或者财富。

zksync 存储：sparse-merkle-tree 存储

Tue, 09 Feb 2021 20:02:00 +0000

简介

本文先介绍了 sparse merkle tree，接下来介绍 zksync 中数据持久化。

merkle tree

merkle tree 常用于区块链存储数据和快速校验数据。其构造特点是叶节点使用数据的 hash 进行标记，中间节点使用所有子节点的 hash进行标记。

对于 merke tree 的操作，包含：插入节点、获取树根、计算 merkle 证明、检验 merkle 证明。

计算 merkle 证明包含：

1）计算存在证明

2）计算不存在证明

在原始的 merkle tree 上，很容易生成存在性证明，但是难以生成不存在证明。

sparse merkle tree

为了解决这个问题，同时零知识证明也要求账号在树上的位置具有确定性，因此引入 sparse merkle tree，有如下特点：

一棵满二叉树
数据是索引的，每个数据会放到对应的索引的叶子上
存在性证明，merkle path
不存在性证明，需要证明是 null

优化

1）预计算空值哈希

由于大部分情况下，树并不会真的满，而是非常的稀疏。可以预计算H(null)、H(H(null)|H(null))、H(H(H(null)|H(null))|H(H(null)|H(null)))等层级上的值，达到加速的效果。

2）并行计算左右子树哈希

H(H(left)|H(right)) 这类操作要求快速计算左右子树的哈希值，并行计算可以计算。

实现

rust-matter-labs

js-iden3

golang-iden3

文献参考

whats-a-sparse-merkle-tree

sparse-merkle-trees-visual-introduction

关于智能钱包

Wed, 13 Jan 2021 09:58:57 +0000

Vitalik 在 1-11 在博客上发表了关于智能钱包的综述。文中介绍了硬件钱包、多签钱包，着重介绍了社交恢复智能钱包，针对社交恢复钱包面临的各方面问题，提出了对应的策略。

原文不赘述，下文将主要记录要点和思考。

原文

英文

中文

要点

guardian 的选择

抵抗 guardian 联合作恶：

1）不公开

对 list 进行哈希

fulllist，如何获得？

guardian 确定性的生成一个用于恢复的地址；只在需要恢复的时候用到一次；

2）来自不同的 social circle

对于加密价值的讨论

有一种论调认为，社交恢复，是恢复到了相信人，是对区块链和加密的背叛。

Vitalik 认为，加密不是移除所有的信任，其目的是提供更多的选择，来决定去相信谁；允许可控的信任：容许某些人代替做某些事，而没有能力做所有事。

对抗小偷

sign key 可能丢失，可以增加一个保险柜功能，把 token 进入其中；在保险柜中的 token，交易可消。在发起交易和交易生效中间，增加了一个可撤回的缓冲期；还可以通过增加 vault 的可编程性支持更多的功能。

Argent 和路印等现行社交钱包的两大挑战

1
2

1）对中继的依赖
2）交易费高

目前的流行做法，是中继官方的签名的在链下进行，收集之后打包发送到服务器；

对于这里的「收集」的概念有一定疑问；假设一个用户有 7 个guardian，路印是收集齐了4 个guardian的签名，才发送到链上？

两大挑战的解决方案：

当前改造方式

generalized decentralized relayer network

以太坊加油站（与 heco 的元交易有异曲同工之处）

allow transactions to begin from contracts

修改以太坊协议，允许合约主动发起交易。

彻底改造方式：迁移到 layer2

为什么能解决问题？资金首先来自 1 层？在二层里面实现智能钱包逻辑？

思考

如果是一个定制的链的场景，可以采用更激进的方式来改造链，是否可以定制一个对用户友好的钱包系统？
思考免费钱包或者网络可能性，可以使用原生元交易，对交易费进行补贴。

总结

钱包本身存在易用性和安全性的矛盾。公私钥、备份助记词这种操作，对于习惯了只记录一个 pin 的 web2.0 用户而言不友好，这可能也是阻碍区块链向更大量的用户普及的一部分原因。

支持社交恢复的智能钱包，免去了用户记录助记词的困难，将安全性托付于社交关系，易用性上有了提升，但是也存在一些问题。Vitalik 难得之处在于，不止提出问题，还提供了解决方案的思考。

当前以太坊社区，开始逐步理解和使用 layer2，将 layer2 和智能钱包结合，将有利于以太坊网络向更大体量的用户推广。

欢迎留言或者联系博主对相关问题讨论！

0x协议-介绍

Fri, 01 Jan 2021 10:49:05 +0000

核心

链下撮合（订单簿在链下）、链上结算（资金划转）

角色

maker 挂单者

taker 吃单者

实现

maker 创建订单信息，签名

makerAddress
takerAddress
makerAssetData
takerAssetData
makerAssetAmount
takerAssetAmount
expirationTimeSeconds
fee
...
签名
哈希

注意：

takerAddress 是空——直到taker接单

relayer 链下撮合 taker 接受 maker 的订单，签名，提交到智能合约
链上结算合约实现资金划转

问题

1）maker 如何取消交易

订单过期

2）交易效率

1
2

预先检查
链上成交

与 uniswap 对比

1）uni 有流动性提供者，一个 pair 的两个 token 都需要提供

2）uni 的价格是链上发现的

3）0x 只是交易意愿撮合，用户的资产不需要抵押

总结

0x 协议核心是定义了一个「链下撮合，链下成交」的结构，但正式由于分离了链上和链下，其成交效率有一定折扣。

其后继者 uniswap 是一个整体闭环。

参考

0x-protocol

0x-intro-jnse

《你就是孩子最好的玩具》读书笔记

Mon, 05 Oct 2020 18:05:12 +0000

前言

随着年纪越大，对自己的认识深入，发现自己很多习惯或者性格的形成，都可以追溯到最早的生活经历。

人生来就是一张白纸，父母是第一位老师，家庭教育对于塑造一个人的品格，有关键作用。

在教育这个事情上，说实话，也是战战兢兢，一不留神，就可能把原先的不那么正确的观念带给了孩子。

这个时候，不能盲目，不能下意识，只能多阅读、多思考、多观察、多实践，或许能减少一些内心的焦虑。

这是一本儿童教育的书，核心观点是对孩子进行情感引导式教育。作者摒弃了控制式、放任式、奖励式、惩罚式的教育。等等，这都是不对的？感觉颠覆了三观。细读下来，发现奖励和惩罚还是会在，不过占主导的是发挥同理心，进行情感引导和沟通。

这本书又是一本手册类的书，列举儿童 0-7 岁能出现的大部分让家长抓狂的情形再现、原因分析和解决方案，是值得多次翻阅和查找的一本书。

🏷信息卡片

名称：《你就是孩子最好的玩具》
作者: 金伯莉·布雷恩
译者: 夏欣茁
出版年: 2011-8
页数: 191
定价: 29.80元
ISBN: 9787550102996
豆瓣评分：       8.2
起止时间：       2020.10.05--2020.10.05
阅读次数：       1
推荐指数：      🌟🌟🌟🌟
获奖情况：

🌱写作背景

作者是儿童教育专家，最早提出「情感引导式教育」概念，同时也是 2 个男孩的母亲。

📒原著呈现

p9 你是希望孩子处于对你的恐惧而听从你的建议，还是处于对你的爱戴和尊重而听从你的建议呢？ p149 我们唯有甘心忍耐，才可能从刻意逃避转为欣然面对

🖇书摘&批注

p3 情感引导是什么：想孩子传授情感规则，让他们知道如何辨认情感并且以恰当的方式来表达。
懂得辨认和他人的情感，是形成和谐的人际关系的关键。

p6 常见误区：
1）控制和放任型
2）轻视、低估和否定孩子的感受 
3）采用外部激励和奖赏的手段 
4）以消极后果作为惩罚
小朋友没有去权利生气？不是的，小朋友要学会知道自己是否在生气，为什么生气，如何处理情绪。

p33 同情的力量
所谓同理心——站在别人角度看问题；对待小朋友，也需要如此。

p38 情感引导的关键步骤：
1）播下种子——提前预告
2）观察和判断——了解孩子的情况
3）聆听——倾听孩子的感受
4）体察和同情
期前预告接下来要发生的事情，以一种协商的姿态告知孩子，争取他的配合。

p56 安抚毯、毛绒玩具
作者提到她的孩子对于安抚毯有强烈的依赖。

p62 不眠之夜
在某些转折点之前，可能会折腾一阵子——例如突然开始说话之前

p63 带婴儿外出
做好心理建设最重要——孩子不大可能能长时间配合

p79 为什么打屁股没用
打屁股会影响孩子的学习能力，教唆使用暴力，体罚会造成伤害，打击自信心
因为暴力而屈服，并不是真的理解，也没有主观产生能动性

p92 奖励无法奏效
核心是孩子应该是靠情感来激励，而不是物质；幸福感只能来源自身；
久而久之，孩子会对奖励有过高的期望或者依赖。
准确的夸赞孩子，而不是使用某种激励手段。

p96 孩子耍脾气怎么办
不要针锋相对
提前计划，表达对孩子的理解和同情，保持冷静，不去理睬

p149 无条件的爱
了解自己，了解孩子

🙋‍♀️总结感悟

核心观点是父母与孩子建立良好的沟通和互动关系，理解、疏导孩各类「不良」行为。进而形成亲子之间的感情纽带，教会孩子正确理解和处理自己的情感，成长为一个具有良好社交能力的人。
孩子发展是分阶段的，不同孩子的发展又不是完全同步的，因此父母要尊重规律，抛弃不切实际的计划和目标——例如要求 2 岁的孩子能安静坐着看电影。
作者认为新生儿阶段，应该给与足够的照料，这也是跟李玫瑾的观点类似。
2 岁以前，转移注意力的做法是可取的。
夸赞的方式：询问孩子自身的感受（你觉得怎么样？），站在主观的角度来观察（我喜欢你穿的衣服），而不是下一个看似客观的定义（你真会穿衣服）。
这本书实用性比较强，用了大量的案例来支撑观点。3-4-5 章更是针对各类儿童的问题，都给出了分析和对策。
教会孩子与大人进行协作。

币安链（BC）与币安智能链（BSC）简介

Sat, 19 Sep 2020 11:46:03 +0000

本文主要介绍的是中心化交易所币安（binance.com）在区块链上的一些工作，主要是介绍币安链（BC）和币安智能链（BSC），除了综述官方文档之外，也会加入一些个人的看法。

出发点

总所周知，币安基于Cosmos-SDk 搭建了币安链（Binance Chain，下称 BC），并于 2019 年上线了主网。那为什么还要有另外一个智能链（Binance Smart Chain，下称 BSC）呢。白皮书解释和言外之意都描述下：

1
2
3

1）实际应用要求有更强的可编程性（要有智能合约）
2）保证现有的 dex 的高性能（基于 cosmos-sdk的链交易并发是有瓶颈的）
3）开发者的学习曲线（以太坊的 DApp 生态最完善）

有了以上的需求，采用下面的技术路线和架构几乎是水到渠成。

设计目标

1
2

1）BC 为主链，新链是一个独立区块链，对BC的依赖少
2）兼容以太坊生态，保留跟随以太坊升级的可能性（改动越少，越好升级）

分工和职责

为了旧链和新链的合理性，设计了下面的职责和结构。

BC核心职责：

1
2

1）原有的 dex 功能
2）平行链信息， staking 与治理

平行staking 放在 BC 上，也可能是考虑以后还会有别的新链出现~

BSC 核心职责：

1
2

1）运行区块链，输出 staking 和治理依据
2）运行复杂的 DApp

由于两个链是相对独立的，所以称为是平行链。

BSC 共识协议

BSC 采用了所谓的 PoSA（Proof of Staked Authority），你可以认为是以太坊代码中的 Clique 的一个小改动，综合了 PoA 和 DPoS 的思路。大致流程是：

1
2
3

1）验证者或者代理人在 BC 上抵押
2）BC 每24 小时重选合法验证者列表（21 个），通过跨链消息传递给 BSC
3）BSC 根据验证者列表，选择节点轮流产块

PoA这个协议只能实现秒级的产块，但是无法实现秒级的确认（finality）。不确定做这个选择是为什么？可能是为了简单？个人认为有点偷懒了，采用基于 BFT 的快速确认的共识协议可能会更好。

简单而言，实现了基于 PoS 治理，PoA 产块。

从区块浏览器观察来看，BC 的区块周期大约1秒 2 个区块（ sub-second），BSC 的区块周期是大约 3 秒。

因为 BC 使用的 tendermint 共识，所以交易确认时间也就是区块周期，BSC 使用了是 PoA 共识，如果等待 21 个节点中的 +1/2确认，需要大约 30s-1m。

Token

设计了在 BC 和 BSC 双向映射和转账的机制。

Token 定义

BC：
BEP2
BNB
...

1
2
3

BSC：
BEP2E
BNB

BNB 是两个平行链的 native token，交易手续费、抵押、奖励等都使用 BNB。

BEP2 是 BC 上类似于 ERC20 的 Token。

BEP2E 是 BSC 上类似于 ERC20 的 Token，多了几个方法：

1
2
3

symbol()
decimals()
onwer() //比较重要，声明拥有者地址，后面只有这个地址可以发起绑定操作

那核心问题就是Token映射和转账，即：

`1`	`BEP2 of BC <--?-->BEP2E of BSC`

Token 绑定

1）确定 BC 上的BEP2和 BSC 上的 BEP2E 存在
2）确定和锁定发行量
  假如总发行量 S，
  BC 初始流通 K
  BSC 初始流通 S-K
	token 发行者应该在对应的链上把未流通的量 lock 到系统合约或者账户，使得两个链上的发行总量是 S。
3）BEP2 token 的发行者在 BC 上发起绑定交易
完成检查之后，绑定请求发送到 relayers
4）BSC relayer 将跨链绑定信息转发给 TokenHub 合约
5）BEP2E 的 owner 调用 TokenHub 合约的方法，后者确认 1.未被绑定 2.symbol 发行量和最小数量位 3。锁定正常
6）BC 通过 Oracle 收到返回信息，将 contract address 和 decimal 信息写入 BC

注意，以上流程，需要 BC 上的系统托管账户，和 BSC 上的系统合约作为基础设施。

链互操作

平行链结构

官方这张图很不错。

注意 BSC Relayer 和 Oracle Relayer，分别负责把信息转发到 BSC 和 BC。

下面先介绍这两个角色，再介绍具体的跨链操作方式。

值得一提的是，币安在设计这两个角色的时候，已经考虑到了去中心化环境可能带来的问题和采取了一定的对策。

但是，这两个角色本身的合法性和提供的信息的验证问题，是不够清晰的。

BSC replayer

BSC relayer 负责将信息从 BC传递到BSC。

需要存入一定量的 BNB 到BSC链上进行「注册」，BSC 只会接受注册的 relayers。

激励机制

1）用户操作，由用户买单

2）系统同步，由 BSC 系统买单

为了避免 relayers 垄断的情况

1）奖励是批量分配

2）在批量中，奖励不是线性分配

Oracle Relayers

负责将信息从 BSC 传递到BC，消息本身需要经过BC 验证者的共识。

在提交之前，Oracle 需要等待足够的 BSC 区块确认（PoA 确认需要 1 分钟）。

跨链奖励会成为区块奖励的一部分，分配给验证者。

将来也会引入对 Oracle 的 slashing

BC->BSC

依赖BSC Replayers，消息将会进入到预编译的系统智能合约。

消息类型：

Token绑定
转账
错误处理
验证者信息更新
...

BSC ->BC

如果是通过交易产生的跨链事件，其流程是这样的：

`1`	`tx -> EVM -> event -> oracle`

每个BC 链验证者需要运行 oracle 进程作为 oracle relayer。

跨链消息包，也会被 BC 中的 validator 进行投票，签名超过2/3即为合法。

超时和错误处理

这个在跨链协议中很重要，涉及到回滚等。

当某个 sequence 的 tx 卡主，超时之后，将会有一个 skipsequence 交易出现，对卡主的 sequence 做出不可执行的标记。

社区决定如何处理。

链上无法解决的问题，最终还是推到社区||-_-

Staking 和治理

BC 和 BSC 的Staking 的基本概念与其他基于 POS的链没有大不一样，要点如下：

1）抵押，代理

2）按照 token 排名，top n 作为验证者

3）validator 分享收益给 delegator

4）validator 会有被 slashing 的危险，delegator 需要分担

5）token 有赎回期

具体到 BC 和 BSC 的配合：

1）BC 上抵押和代理 BNB

2）BSC 的 validator 由 BC 上的 staking 模块决定，UTC 00:00:00 发出跨链通讯

3）BSC 将验证者工作的信息，通过跨链通讯回传到 BC

4）在 BC 上进行 reward 分配

罚没

基于 PoS 的公链，其活性需要全体 validator 的诚实、如实工作保证的。

为了从经济学上推动这类行为，引入了罚没机制。

双签

所谓的双签，是对于同一高度+同一个parent 的区块进行多与一次的签名。任何第三方都可以，以 slash request 的方式发到 BC 上。

1）从 validator 中移除——发出 update 事件

2）罚没一定量

3）一部分给提交者

4）另外的给验证者监管账户

不稳定

一个内部合约，统计工作情况。

1）如果超过不工作阈值，其已得收益，将不会发给 BC，而是分2给其他的 validators。

驱使运营不好的节点，delegator 将会离开

2）如果工作情况低于另外一个阈值，将会通知 BC，发生另外一个 slashing

总结

总的来讲，其技术结构和治理方式参考了一众跨链项目（例如 cosmos 和 polkadot），也参考了 DPoS 的一众项目（例如 EOS 和 TRON）。机制设计上也留出了后续扩展的空间。在本文写作之时（2020-09），BSC 上已运行了若干 DeFi 应用，这也是 BSC 的实现最初目标（承接 DApp）的佐证。

在文章中，笔者也提出了一些疑问，例如 PoA 的区块确认时间过长，Relayer 和 Oracle 本身的信息正确性问题等。

在单链技术还没有实质性突破的情况下（以太坊 2.0 可能还需要若干年才能成熟，或者不会成功），这类平行扩展的思路，也不失为快速开展业务尝试的一种实干派做法。

参考

《影响力》读书笔记

Mon, 17 Aug 2020 11:18:16 +0000

前言

这是一本关于影响力和顺从的书，作者使用了大量的案例来说明影响力来源。

通过阅读这本书，可以为运营活动或者销售技巧寻找理论根据，做到知其所以然。

🏷信息卡片

作者:[美] 罗伯特·西奥迪尼
出版社: 中国人民大学出版社
出品方: 湛庐文化
原作名: Influence: The Psychology of Persuasion
译者: 陈叙
出版年: 2006-5
页数: 353
定价: 45.00元
装帧: 平装
丛书: 湛庐文化· 商业智慧
ISBN: 9787300072487
起止时间：       2020.07.15--2020.08.15
阅读次数：       2
推荐指数：      🌟🌟🌟🌟
获奖情况：

🌱写作背景

作者社会心理学家，致力于影响力的研究

作者使用了所谓的参与式观察（间谍）参与到一些商品或者服务的销售工作中，以获取技巧

📒原著呈现

🖇书摘&批注

p3-4：绿宝石价格提高了，反而销量好了；

人在成长过程中，接受了观念，价格贵=东西好；
调高了价格，触发了用户的顺从按钮；在这一点上，人类也是某种基于反应的动物——跟雌火鸡一样；

p9：文明的进步，就是人们在不假思索中可以做的事情更多
所谓的专家，也就是在不断的训练中，形成了对于工作的问题的肌肉记忆

p15-16：对比原理
先看霹雳娇娃，会影响给自己对象的打分；
先兜售贵的商品、其次是便宜商品——可能会让总收益最大
先给一个不好的方案、然后给一个正常的方案，可能会有助于方案的接受


第二章：互惠——给予、索取、在索取

p25：给对方寄贺卡，会受到很多回信
在一个社交网络早期，主动加别人，会有一定的会加率

p28：给对方带一瓶可乐，就可以获得更高的彩票销售
不要忽视小恩小惠的作用；要习惯对别人施以援手——赠人玫瑰，手留余香

p33：政府高层的相互投票和联合
奥巴马和特朗普该多难啊！

p35：安利臭虫
所谓的试吃，也是这道理吧

p38：人有送礼的义务、接受的义务、更有偿还的义务
想起了老教父柯里昂

p48：拒绝-后撤
常见的销售技巧——漫天要价，坐地还钱


第三章：承诺和一致性——脑子里的怪物

p63：一开始就拒绝，比最后返回要容易——达芬奇
至理名言，特别是对于推销cold call

p67：所有人都一次次的骗自己，以便在做出选择之后，坚信自己做的没错
you've got a dream, you've to protecet it

p68：信仰、言行和行为前后一致不一致的人，会被看成脑筋混乱表里不一；言行高度一致多数跟个性坚强、智力出众；它是逻辑性、稳定性、诚实感的核心
胡忠献的忠，岳飞的忠
吴三桂所谓没有定力

p70：关于冥思会和缴费
超自然的方法，可能是唯一解药；

p73：玩具销售商的策略
为了保持淡季的销量

p85：战俘营的做法
以小积大

p86：个人承诺防止撕毁合同
自己说出的话，自己要遵守承诺

p90：额外的努力，费尽努力得到的东西，人人往往格外珍视
追姑娘丈母娘设置困难
公司的严格面试，也是一种投名状
其中的成员，会强烈的维护这种准入
建立团队凝聚力和卓越感，入会活动要艰辛

p100：内心的压力
你得找一个有力的理由，让他大多数情况下都保持城市，可这个理由又不能强大到让孩子觉得，自己完全是为了它才诚实
太强烈的惩罚，可能不会奏效
要是说谎，我会失望的
这个对于教育孩子很有意义，要让遵守规则成为孩子自身的习惯，而不是被强迫的


第四章：社会认同——脑子里的怪物

p120：依照别人意见行事

盖得排行，大众点评
街头围观，网红店雇人排队

p138:寻求帮助
找到特定的人寻求帮助
旁

p150:自杀新闻
会导致更高的自杀率

第五章：喜好——友好的盗贼

p175:销售外表
广告模特和销售人员都要漂亮
p179:喜好

广告的作用。第一次陌生，看了广告之后就觉得是名牌了

p181:所谓的融合策略
融合过程中导致的恶意，难道不是留下更大的影响么

p184:拼图学习法
竞争与合作

p199:体育运动
乒乓球、排球、奥运会等对国民认同的形成的作用


第六章：权威——教化下的敬重

p223:头衔
都喜欢挂一堆头衔
第七章：稀缺——数量少说了算

p243:稀缺
销售管用伎俩，create urgent

p247:逆反心理
有屏障，挑衅；测试界限；罗密欧朱丽叶，如果没有限制，可能不多久就分掉了


p253:信息审查
「禁书」，快要被删，这都有助于传播
p260:参与竞争稀缺资源，有强大的刺激性
所谓的竞雄？拍卖

🙋‍♀️总结感悟

顺从的力量，来自大量「正统」观念影响

从理论上了解影响力的来源：互惠、承诺和一致性、社会认同、喜好、权威、稀缺

验证和对照了一些日常的销售和运营策略

👯‍♀️他山之石

🎥多媒体资料

开源许可证介绍与项目实战

Tue, 28 Apr 2020 11:18:16 +0000

介绍

在项目中第三方代码的时候，要注意源码许可证问题，因为这涉及到：

使用和修改的条件是什么？
商用和分发的条件是什么？
本项目开源后使用什么许可证？

本文将简要介绍对许可证（license）的理解，着重介绍一个实战项目处理方式。

许可证介绍

许可证的内容，其实是博大精深。

首先许可证的种类特别的多，其次不同的许可的条款和细节也特别的多。

下面主要是介绍若干主流且具有代表性的许可证。

主要参考了开源许可证教程-阮一峰的网络日志

名词解释

分发

将版权作品从一个人转移到另外一个人；例如提供给别人；如果是本公司使用，不算分发。
传染

一个项目用到了某个许可证的代码，在某些条件下（例如分发），这个项目本身也需要使用这种许可证
许可证版本

同一个许可证，有版本号之间的区别，例如 GPL 有 v1/v2/v3。

宽松的许可证

包含 MIT/ISC/BSD/Apache等，基本上这类许可证，是可以放心使用。

（1）BSD（二条款版）

分发软件时，必须保留原始的许可证声明。

（2） BSD（三条款版）

分发软件时，必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。

（3）MIT

分发软件时，必须保留原始的许可证声明，与 BSD（二条款版）基本一致。

（4）Apache 2

分发软件时，必须保留原始的许可证声明。凡是修改过的文件，必须向用户说明该文件修改过；没有修改过的文件，必须保持许可证不变。

Copyleft 许可证

代码可以随意复制，有如下前提：

1
2
3

- 如果分发二进制格式，必须提供源码
- 修改后的源码，必须与修改前保持许可证一致
- 不得在原始许可证以外，附加其他限制

核心在于，修改后的代码，不得闭源。

AGPL

最严格的 GPL，除非获得商业授权，否则无论以何种方式修改或者使用代码，都需要开源。

云服务使用AGPL 的源码，不构成分发，也也需要开源

如果分发软件，则使用和修改都必须开源，整个项目都必须采用 GPL许可。

LGPL

分发时，如果是使用动态类库的方式引用，可以不开源

分发时，只要该许可证的代码在单独的文件中，新增的其他文件可以不用开源。

无论是商业应用，还是开源项目，在采用 AGPL/GPL/LGPL/MPL都要特别的小心。

许可证检测

介绍两个工具，分别检测代码文件和依赖的 license。

检测代码

`1`	`go get -u github.com/google/addlicense`

可以递归检测当前目录下的所有代码文件，许可证声明的情况，例如：

`1`	`addlicense -check ./ \|sort > lc.txt`

可以把未添加许可证的文件都输出到lc.txt 文件中，方便后续进行检查。

检测依赖库

`1`	`go get -u github.com/google/go-licenses`

查看一个依赖库所使用的版权信息：

`1`	`go-licenses csv repo`

可以通过一个这个脚本项目进行批量测试：

cat dep.txt |while read line
do 
echo "start checking package $line"
go-licenses csv $line
echo ""
done

许可证添加

笔者主要使用 idea 的 IDE 进行程序开发，它有管理版权信息的功能：

`1`	`Preference->editor->Copyright`

可以添加不同的 Profiles，然后使用 IDE的功能进行自动添加和更新。

1）设置默认 copyright
preference->editor->Copyright
设置 default project copyright，选中一种配置，这个可能会根据不同的文件需要切换

2）选中代码文件或者文件夹

3）菜单栏->Code->Update Copyright

项目实战

下文介绍对于一个实际项目进行许可证声明。

项目背景

该项目主语言是 golang，采用了自某 LGPL 的项目的一部分类库作为基础代码。

版权主体

go-ethereum

`1`	`Copyright 2016 The go-ethereum Authors`

go-algorand

`1`	`Copyright (C) 2019-2020 Algorand, Inc.`

可以选择是作者主体，或者公司主体。

项目 license

由于该项目的代码，部分使用了修改了 LGPL 项目代码作为基础工具。

根据 LGPL 的规定，本项目也需要使用 LGPL 作为 license。

版权声明

声明版权，一般两部分：

1）项目级别的 LICENSE 文件

由于大部分的许可证都是控制包级别的许可，所以这种方式也足够

2）代码级别的 copyright 文件头

每一个原创的文件都设置了版权信息

项目级别的 license

一般而言，是找到你的 license 的文本，将文件放置于项目根目录。

不同许可证可能有点不一样

一般而言，在 github 建立公开项目的时候，会提示选择一个 license。

如果初始化忘记了，也可以web 界面上，新建一个名字是LICENSE的文件，来显式触发选择 license。

代码级别的 copyright 文件头

使用第三方代码，主要分为，fork 引用 和 library 依赖。

fork 是指把代码直接放到了代码库中，修改或者不修改。

library 是库依赖，例如通过 go.mod 的方式进行依赖。

fork 引用

代码分类

1）项目原创文件

2）项目修改第三方库的文件

3）项目直接引用第三方库的文件

4）fork 过来的开源库
可能存在包内 license，单文件可能没有copyright

5）忽略 license 文件的内容

非 golang 文件
gencode 生成的以 gen_开头的文件
其他自动生成的文件

有了如上的分类，你就可以使用 IDE 创建多个不同的 Copyright Profiles 来处理不同的文件了。

结合 addlicense 工具，相信这部分工作将可以顺利完成。

library 依赖

使用上述的依赖检测工具，查看是否有不合适的许可证。

如果一个依赖库，license 不是MIT/ISC/BSD/Apache 其中的一种，那就要小心了！

TBD-Topics

有一些话题需要进一步讨论：

`1`	`1）如果项目源码计划商用，如何处理？`

总结

本文简要介绍了license 的原理，着重介绍了项目实战，希望对读者有启发，欢迎讨论！

参考

https://www.ruanyifeng.com/blog/2017/10/open-source-license-tutorial.html

https://www.gnu.org/licenses/gpl-faq.html

https://choosealicense.com/

Spring Cloud 配置中心

Fri, 13 Oct 2017 23:18:16 +0000

闲话配置

老司机都喜欢在程序设计中尽可能的把各种参数做成可配置的，等到产品需求发生改动的时候，优雅的修改一行配置，重新加载一次配置，就满足了需求。

配置（Configuration）是不修改代码的情况下，对程序的运行调整的能力。

简单来讲，配置可以分成两类：

系统配置：包括线程池大小、数据库连接等，变化频率较低
业务配置：功能开关，功能参数等，变化较为频繁

程序的配置一般而言，分为几个环境：

开发环境
测试环境
生产环境

这几个环境的配置是有差异的，所以配置管理功能应当能够根据当前环境读取对应的配置。

前面提到的不修改代码，只是最低要求，相当多的情况下，程序是不能停机的，这就提出了热更新的需求。

另外，配置的修改应该是有记录可追溯的。

Spring Boot 的配置管理

Spring 实现了非常友好的配置读取方式，

Spring Boot 程序默认使用 application.properties 进行配置。

例如一个参数：

flag=0

在程序中可以通过：

1
2

@Value("${flag})
int flag;

来读取。

也可以通过设置多个配置文件：

application.properties
application-dev.properties
application-test.properties
application-prod.properties

application-dev.properties

flag=1

application-test.properties

flag=2

application-prod.properties

flag=3

和在 application.properties 中声明当前的活跃的 profile：

`1`	`spring.profiles.active=dev`

来实现根据运行环境切换配置信息。

以上只是 Spring 强大的配置能力的冰山一角，有兴趣可以参考外部配置文档。

这还不够

其实以上描述的 Spring Boot 的配置能力已经很强了，但是有个很致命的问题——无法热更新。

如果非得实现热更新，那可以把配置做成 JSON 文件，再实现一个 endpoint，重新读取一次配置。

假设有一千个实例呢？

Spring Cloud Config

项目 github：https://github.com/spring-cloud/spring-cloud-config

简介：External configuration (server and client) for Spring Cloud

这个项目包含两部分：

Server

负责从 git/svn 等版本管理系统中读取配置，并以 http 的方式提供服务。

Client

根据客户端配置，从指定的 Server 中读取对应配置，并且与 Spring 本身的 PropertyResource 和 Environment 无缝结合。同时，提供了统一的方式进行配置热更新。

对于这个系统的基础配置和运行，可以参阅下面两个 url：

https://spring.io/guides/gs/centralized-configuration/

http://blog.didispace.com/spring-cloud-starter-dalston-3/

实操进阶

热更新

Spring Cloud Config 实现了非常优雅的热更新。

客户端的配置 Bean 添加 @RefreshScope

@Configuration
@RefreshScope
public class ConsumeConfig {

    @Value("${consume.desc}")
    private String consumeDesc;
    
    @Value("#{'${api.server.round.card}'.split(',')}")
    private List<String> cardList;
}

在配置这个注解之后，调用客户端的 /refresh endpoint，这个 Bean 就会刷新，同时个 Bean 的依赖方下次方法调用时也会更新 Bean 引用。

有些时候，你需要监听这个更新事件，把拿到的最新配置，重新初始化一些部件。那你可以添加： @EventListener(EnvironmentChangeEvent.class) 这个 annotation。

@Component
public class ConsumeService {

    @Autowired
    ConsumeConfig consumeConfig;

    @EventListener(EnvironmentChangeEvent.class)
    void onEnvChange() {
        //do re-init stuff
    }
}

添加权限

Config Server 任何人都可以通过 http 访问配置，这个不大好，建议加上认证，最简单是使用 Spring-Security 添加一个 basic authentication。

服务器端配置

build.gradle 添加依赖：

1
2
3

dependencies {
    compile('org.springframework.boot:spring-boot-starter-security')
}

application.properties 添加密码（用户名默认是 user）：

`1`	`security.user.password=xxx`

重启服务器，再次通过 http 访问配置的时候需要验证。

客户端配置

服务器端做了验证，那客户端也需要添加相应的配置：

bootstrap.yml

spring:
 application:
  name: application
 cloud:
  config:
   uri: http://yourhost.com
   profile: dev
   username: user
   password: xxx

加载多组配置文件

很多时候，为了避免 application.properties 过于臃肿，你可能需要把一些配置文件拆出来，例如专门负责邀请奖励的配置：

invite.properties
invite-dev.properties
invite-test.properties
invite-prod.properties

同样，也区分了多个环境。

那在使用 Spring Cloud 的时候如何读取这个文件呢？

1
2
3

spring:
 application:
  name: application,invite

注意上面的 application.name 是以逗号分隔的两组配置名称。

一些问题

@EventListener 与 SpEL

我在实际使用中发现，在事件监听函数中，使用更新后的配置的时候：

    @Value("${consume.desc}")
    private String consumeDesc;
    
    @Value("#{'${api.server.round.card}'.split(',')}")
    private List<String> cardList;

第一个配置是使用 @Value 绑定一个字符串类型，第二个配置是使用 @Value 中的 SpEL 去将配置中的字符串，切割成 List。

我发现第二个，无法切割成功。试验了多次，还没有找到答案。我已经在 Spring Cloud Config 的 github 上提交了 issue。

如果有了解这个的，请不吝赐教。

update 2017-10-26

我在 github 上提交了 issue： https://github.com/spring-cloud/spring-cloud-config/issues/821 得到回复：We have only ever documented that placeholders ${} work, not SpEL.

权限管理

在不做二次开发的情况下，这个配置中心的数据是对所有的 client 开放的。某些情况下，这种设定并不合适。

JSON 文件的读取和解析

Spring Cloud Config 本身是可以通过 http 来提供 JSON 文件的访问的，但是Spring Boot 原生并不支持 JSON 配置的读取和解析。

参考文献

http://blog.didispace.com/spring-cloud-starter-dalston-3/

http://cloud.spring.io/spring-cloud-config/single/spring-cloud-config.html

http://jm.taobao.org/2016/09/28/an-article-about-config-center/

https://blog.coding.net/blog/spring-cloud-config

亚马逊 Alexa Echo Dot——入门

Tue, 21 Mar 2017 11:18:16 +0000

智能家居

大约20年前，在报纸上看到关于比尔盖茨智能豪宅的报道，心生向往。我等平民在20年后，终于迎来了智能家居浪潮普及的浪潮。

亚马逊的 Alexa Echo 无疑是这个浪潮中的当红明星。

它是一个蓝牙音箱，是一个智能语音助手，是一个智能家居管理中心，它还提供了开放平台，允许第三方添加 Skills 来扩充功能。

本篇介绍一些购买和基本使用经验。

购买

在经过几代的发展之后，目前这个产品主要包含 Echo 和 Echo Dot。主要的区别是扬声器的规格。

如下图：

Echo Dot 价格要亲民一些，500人民币左右，某宝可购买。

下单后很快到货，就是这么一个小盒子：

基础介绍

顶部有四个按钮，功能分别是，分别是：静音、操控、音量加减。

背面有两个插槽，分别是 3.5 mm 声频输出口、Micro-USB 电源插口。

Echo Dot 需要一个叫做 Alexa App的手机软件作为控制端，下面提供 Android 和 iOS 平台的下载地址。

Android-App

iOS-App

注意在 iOS 平台上，这个 App 只允许美国区的账户进行下载。你可以折腾一下，注册一个美国区的 Apple ID，可能需要绑定信用卡。你也可以花钱买时间，在万能的某宝上买一个美国区账号。我选择了后者。

基础设置

Echo Dot 是需要连接到 WiFi 进行工作的，这就需要用 Alexa App 进行绑定和设置。

如果你曾经用过小米的空气净化器，你会发现设置的模式类似。

主要步骤为：EchoDot 进入设定模式、手机连上 Echo Dot 共享的 WiFi、操作 Echo Dot 连接家里的 WiFi。

1.长按 Echo Dot 顶部的操控键，会有提示进入设定模式(enter setup mode)；

2.在手机的 WiFi 设置页面，可以看到名字为 Amazon-XXX 的 WiFi，连接上去，会有提示：(connected)；

3.进入 Alexa App，在里面选择家里的 WiFi，输入密码，确定之后，Echo Dot 会尝试进行连接。

连接中，主要发现两个问题，一是卡，二是根本连不上。因为 Alexa 的服务器在国外，速度受一定的影响，卡是正常的。然而国内的网络环境比较复杂，例如我就遇到过家里的方正宽带下的 WiFi，根本连不上的情况。后来我只能使用手机的联通4G 开热点才能勉强使用。公司的电信宽带也没有问题。后面网络续费的时候，看来要换成电信或者联通了。

基础使用

Echo Dot 连接上网络之后，你就可以跟它对话了。默认唤醒口令是 Alexa。唤醒之后灯会亮。

例如就可以试一下，Alexa, what's the weather。它可能会告诉你美国西雅图现在的天气，地址可以在 Alexa App 中设置。（ps：我还没有找到设置成北京的方式）

一些后续

Alexa Echo 提供了开放平台，开发者可以将服务打包成 Skills 对系统进行扩展，这个就有点像苹果的 iOS 生态了。厂商只提供基础的服务和功能，开发者百花齐放。用户可以在 Alexa App 中添加 Skills，例如你可以添加一个读 CNN 新闻的功能。这一块还有待探索。

网络问题很严重，反应速度比较慢。后面如果想要愉快玩耍，还是得找一个比较好的联网方案。某一天亚马逊可以把服务器放一些到国内，就更好了。

总结

Alexa Echo Dot 入门初步介绍了购买、设置、使用。下面继续探索。

如何更好的提出技术问题

Wed, 03 Feb 2016 11:18:16 +0000

下面咱们就来聊聊技术人的素养：如何更好的提出技术问题。笔者从事 Bugtags.com 开发运营以来，除了开发任务以外，最重要的工作就是在 qq 群里面回答用户的问题。

这半年来，少说也接待了上千个用户了。笔者发现，有相当一部分的用户，提问方式和技巧都有问题，这样导致了我们额外的客服量，也使得自己的问题得不到及时满意的回答。

下面咱们就来聊聊技术人的素养：如何更好的提出技术问题。

直接了当

有的用户，喜欢先问：『有人在吗？』

其实这个问句真的是很无意义，有问题直接提出来就好，有工作人员或者热心人看到了，能回答的自然就会回答，为什么还需要问有没有人在家呢？

目的明确

有的用户，其实只是对某些技术点感兴趣，但是表现出来，是要给我们反馈 bug。这样我们就很摸不着头脑。

是吐槽、建议、反馈、赞扬还是学习？请一上来就说明。

有价值

列举一些个人认为没有价值的问题：

PHP 是不是最好的语言？
VIM 还是 Emacs 好？
学 Android 有没有前途？

这种问题，没有讨论的价值。

已尝试求解

其实大部分我们遇到的技术问题，只要在谷歌或者百度上查找，大多能找到答案。

大部分情况下，使用 Bugtags 遇到的问题，都能通过我们的帮助文档解决。

但是我发现中国人真的很着急，文档也不看，帮助也不看，上来就问。

问题着眼点小

切忌提一些特别大的问题，例如『安卓如何管理内存』，这种是需要一些列文章才能阐述清楚的问题，显然是不适合在 QQ 群上提问的。

背景信息充足

举个例子，Bugtags SDK 支持 Android 和 iOS，但是大部分用户提问的时候，会忽略了这个信息。同样，常用的操作系统，也有 OSX 和 Windows，很多人也会忽略。

这里面其实有个思维盲点，提出问题的人，会忽略一些显而易见的环境差异，认为别人了解背景信息，具有跟他一样的运行环境和操作步骤。

问题描述信息充分

这个也需要换位思考，假设你是一个热心人，尝试帮助群上的人解答问题。是不是希望问题越准确越好？

一些要点请备齐：

软硬环境及版本
操作步骤
期待结果
错误信息，最好是文本而不是截图
设备运行的 log
现场截图
已尝试过的解决方案
怀疑的点

重现问题的 Demo

创建你自己的 demo 程序，操作要友好
加上使用说明，描述你所遇到的问题，具体环境，操作步骤，帮助别人快速重现你的问题
打包你的 demo，上传到 github 或者百度云盘，让别人可以很快下载到

一个范例

stack-overflow

总结

提问技巧，也是属于沟通技巧之一。

笔者认为要达到有效的沟通，双方都需要有同理心，要换位思考。

愿这篇文章能为大家带来一些启发，能够收获更多满意的答案。

面向开发者服务的用户体验

Sat, 28 Nov 2015 11:18:16 +0000

面向开发者的产品，需要恰到好处的用户体验，就像锤子新品宣传的那样

内敛和克制的，使用起来舒服和体贴最近的工作是开发运营一项面向开发者的服务，而我们的团队是做社交产品出身。在关乎到用户体验的问题上，这里面仿佛存在一个矛盾。

开发者服务不需要用户体验？

给程序员用的东西，要什么用户体验，功能可以work不就行了么？这是我们一开始的想法。当我们观察一些市面上的一些开发者服务的时候，我们发现，好和坏，真的不一样。举个例子，挑选国内两家数据统计服务提供商的界面进行对比一下：腾讯分析百度统计

单从界面上看，就可以明显看出腾讯果然是一家以产品能力见长的公司。于是，我们有了第一层理解：开发者服务也是需要好的用户体验。

开发者服务应该极致用户体验？

我们团队面向消费者的产品思维根深蒂固，产品经理往往会为一个按钮的大小和对齐纠结半天。极致体验，就是我们的口头禅。不干扰用户，让用户爽，就是我们的信条。于是我们系统最早的注册登陆，都不需要验证手机和邮箱——为了的让用户快速进入。

产品进入运营期，需要做用户回访和召回，问题来了，最早的用户都没有验证手机和邮箱啊。于是我们赶紧改版加了验证。

至此，我们突破了第二层理解：开发者服务，需要恰到好处的用户体验。

内部测试工具的用户体验

本人目前主要从事移动开发，客户端需要调用后端 RESTFUL API，后端开发的同事希望能够给他安装一个 demo app，有完整的功能，要能够跑跑关键点API的TEST，最好还能切换“开发|测试|上线”三级环境，方便调试。于是我开发了一个测试工具。

主界面切换环境

主要实现了如下的功能：

切换环境，倒数三秒后 kill app，重新打开后进入对应环境，并记住当前环境设置
修改对应环境的 appkey
常用的 TEST CASE

功能不多，但是后端同事觉得就足够用了。

官网、文档、反馈渠道

我们尝试去做推广，用户点广告过来之后，就考验我们转化率了。官网是否能够准确传达产品的理念和特点，开发文档是否足够的简明易懂，遇到问题是否能够找到最快速的途径进行反馈，这些都关乎用户体验。

这里我就说说Android平台集成文档。Android平台上有两大主流的开发工具，Eclipse 和 Android Studio，前者是 Google 最早提供的开发工具，后者是基于 IntelliJ Idea 新开发的，有较多新的特性，用起来也比较方便，缺点是还不是非常成熟，偶尔有 bug 。

我个人从 Android Studio 还是 alpha 的时候就从 Eclipse 迁移过来了，用的也比较熟。在写集成文档的时候，我想当然的侧重 Android Studio 的用户集成，没过多考虑 Eclipse 的文档，只是随便写写。

用户逐渐上来了，百分之七十都在问 Eclipse 的问题啊。于是我赶紧做了修改：

精简依赖包
降低 demo app 的 api level，降低用户使用成本
精简回调函数
反复调整集成文档，关键点加上注释

做了这些修改后，关于集成的反馈才渐渐少了，在可预见的未来，我还将在易用性上做更多的工作。

总结

面向开发者的产品，需要恰到好处的用户体验，就像锤子新品宣传的那样

内敛和克制的，使用起来舒服和体贴

我们还将持续改善用户体验，力求开发者用的顺畅，用的舒服。

Posts on Kevin He's Website

别再刷了——ClawFeed 帮我每天 5 分钟搞定 5000 人的信息流

5000 followings. 2 小时刷屏. 重要的还是漏了.

AI 全量阅读，你只看精华

结构化简报，每 4 小时一次

标记任意内容 → AI 深度分析

5000 信息源，全面管理

真实效果

怎么做的

关键取舍

少刷多知。

你的下一个同事不是人

需求变了

Human × Agent

Agent 不是 ChatGPT，也不是 Cursor

这个系列本身就是一个活案例

接下来聊什么

不神话，不唱衰

15 年帮 600 人找工作后，我决定不再做招聘了

1. 一个程序员与「招聘」的 15 年

2. COCO 1.0：从热情到怀疑

3. 外部世界的巨变

4. 认知更新

5. COCO 2.0：数字联创

6. 一个进行中的故事

共识之迷：一文读懂比特币升级社区进展

前言

升级简介：What and Why

什么是比特币升级

共识协议升级类型

BIP和软分叉的流程

为什么要升级

升级深入

升级的利益相关方

升级的历史和总结

Soft Fork 关注方面

何为好的升级提案

升级展望

提案归类

社区呼声

共识之谜

总结&Takeaway

致谢

未来工作

参考文献

Monad VS MegaETH-Bankless Episode and Debate

Overview

Takeaways

General

Debate on Full Nodes

Monad

MegaETH

EVM

WBTC, It’s Time to Upgrade Your Technical Solutions!

Background

Event Review

Involved Parties

Related Parties

Third Parties

Business Model of Wrapped BTC

Comparison of Trustless Levels

Non-Trustless

Single Way Trustless

Dual Way Trustless

Summary of Solution Comparisons

Conclusion

Reference

Action And Blink

概念

案例

问题

延展

结论

参考

sigweb3-training

Motivation

Information

Planning

Introductory Courses

Advanced Courses