Anthropic 的最新模型 Mythos，到底强到什么程度了？会不会像核不扩散一样，被美国死死掐在手里？

今天咱们来聊一个很吓人的话题。Anthropic 最新曝光、后来又正式官宣的模型，叫 Claude Mythos Preview，中文大概可以叫“克劳德·神话预览版”。它到底有多吓人？

Mythos 为什么引发巨大关注

这个模型，之前我们还分析过。从名字上看，它绝对不是 5.0 这样的普通版本升级，而更像是规模上的扩大。所以以后 Anthropic 的模型，可能每次升级就是 Mythos、Opus、Sonnet 和 Haiku 一起升级。

Haiku 是很小的、讲究音节的诗，Sonnet 是十四行诗，Opus 是作品、篇章，而 Mythos 是神话。从命名上来看，这个东西应该是非常非常强大的。

这一次发布有一个非常神奇的地方，就是它不给别人用。我发布了，但并不向大家公开，不让大家直接使用。它开了一个计划，叫“玻璃翅膀计划”。

“玻璃翅膀计划”到底是什么意思

为什么要用这样的方式？因为这个东西实在太危险了。Anthropic 当时就在讲，Mythos 在网络安全方面非常强，可以去攻击漏洞，也可以去发现漏洞。

一旦拿出来，现有的操作系统、网络设备以及芯片，很多问题可能都会被它找出来，而且它还可以自动去攻击。这件事情实在太危险了。

那怎么办？Anthropic 邀请了一些友好的合作伙伴，先把这个产品拿出来，把漏洞补上，补完以后再说。它做了这样一个“玻璃翅膀计划”。

这个名字也让人想到一个神话故事：有人用蜡做的翅膀飞向太阳，最后离太阳太近，翅膀化掉了，人就摔死了。所以这个“玻璃翅膀计划”，按照 Anthropic 一贯喜欢用“人类”“故事”一类命名规则来看，应该也是一个类似寓意的名字。

Mythos 可怕在哪：不只是找漏洞，还可能自动利用漏洞

那么 Mythos 到底有多吓人？很明显，Anthropic 担心这样的模型一旦流出，坏人就可以用。用 Anthropic 的话来说，Mythos 是一个“两用技术”。我们现在也经常讲两用技术，就是既可以民用，也可以军用。所以它显然也具备做军用用途的可能。

据说它在训练过程中就发现了数以千计的额外高危或严重级别漏洞，非常非常多。你会说，我们这么多系统，积累了这么多年，也是人类智慧的结晶，怎么会千疮百孔？

其实很简单。当一个系统复杂度达到一定程度以后，里面一定会有一些以人力无法找到的漏洞。人力有时而穷，但现在有了 AI，它就可以把这些原来靠人力找不到的问题，通通给你找出来。

所以我们以前使用的各种防护系统、操作系统、网络设备、芯片，在 Mythos 面前，基本上可以认为是在裸奔了。这是一个非常危险的事情。

而且它不仅能找，还会打。传统上，很多模型或者工具更多是辅助分析，比如我拿你的源代码分析一下，看看哪里可能有问题。Mythos 让人紧张的地方就在于，它已经不只是告诉你哪里可能有 bug 了，它还可以进一步参与：

• 漏洞分析
• 利用链的构成
• 攻击路径的演练
• 提权链的拼接
• 更复杂的漏洞利用代码开发

所谓“提权”，就是我进去以后把自己的权限提高。它甚至可以直接写出漏洞利用代码，把漏洞打开。它还可能直接突破主流操作系统和主流浏览器。

Anthropic 的公开材料里写过，Mythos 在每一个主要网页浏览器中都识别并利用了漏洞。相当于某种病毒突然进化到让所有抗生素、所有免疫系统都拿它没办法的地步了。

Anthropic 已公开了哪些信息

那它到底发现了哪些漏洞？现在 Anthropic 其实已经公开了一些，但严格来说，这叫“负责任的披露”。

什么是“负责任的披露”

很多黑客其实没有自己发现漏洞的能力，他们怎么攻击别人？他们看新闻，看到哪里有漏洞被公开了，就去打那里。那为什么公开的漏洞还能被利用？因为你升级升不过来。

今天这边说某个漏洞发现了、补丁出了，结果你那边还没补，很多黑客就是干这样的事情。

所谓负责任的披露，可能就是说：

• 我告诉你哪有漏洞了，但我不告诉公众具体漏洞细节
• 同时我会通知厂商
• 还要等厂商自己决定怎么公开、怎么让用户升级

比如告诉苹果，你家的操作系统和浏览器有什么问题；告诉谷歌，你家的 Android 和 Chrome 有什么问题。并且在告诉之后，还要等厂商自己决定怎么公开、怎么让用户升级。

现在真正被点名的，其实只是少数案例，大量案例还没有说出来。

目前提到的典型案例

比如，OpenBSD 有一个 27 年的老 bug 被它找到了，27 年都没人发现。OpenBSD 是什么？我们现在使用的苹果 macOS、iOS、iPadOS，这些系统的底层都和 BSD 有很深的关系。还有任天堂 Switch、索尼 PS5，底层也都和 BSD 有关系。这样一个老漏洞被它拎了出来。

另外，FreeBSD 一个 17 年的远程代码执行漏洞也被找到了。BSD 本身也有很多分支。Linux 内核的本地提权链条也被它找到了，它可以直接进入 Linux 内核里提权。

你可能说我又不是服务器，但安卓手机的核心就是 Linux。只要你是安卓手机，它就可以通过 Linux 内核提权链条把权限提上去。

至于主流浏览器，Anthropic 官方已经确认，Mythos 在主流浏览器中识别并利用了漏洞，但细节没有公开。浏览器其实比操作系统还复杂，因为浏览器要打开网页，而每个网页里实际上有很多很多 JavaScript 代码，这些代码可以利用浏览器漏洞做各种事情，这就非常危险，所以这部分它不敢细说。

Anthropic 是怎么官宣 Mythos 的

Anthropic 的官宣时间线也很值得注意：

1. 2026 年 3 月 26 日，媒体先发现了端倪。《财富》杂志说他们发现 Anthropic 的 CMS 系统泄露了一个新模型名字，叫 Mythos。
2. 2026 年 4 月 7 日，Anthropic 正式官宣，说我们有一个“玻璃翅膀计划”。
3. 同时放出了 Claude Mythos Preview System Card，也就是预览版系统卡。
4. 此外还发布了一些安全研究文章，以及平台上的 release notes，也就是更新说明。

这些都是正式发布出来的材料。

第一批参与“玻璃翅膀计划”的组织有哪些

但是，到底给谁用、不给谁用？这就涉及参与项目的名单了。第一批大概包括以下这些组织：

• Amazon AWS：亚马逊云科技。上面有大量云主机，如果这块搞不明白，风险极大。
• 苹果：有 iOS、macOS、iPhone、Safari 浏览器，还有自己的芯片，漏洞必须赶紧补。
• 博通：做各种 ASIC 芯片，比如谷歌 TPU，很多定制算力芯片也与它相关。
• Cisco 思科：专门做路由器，网络攻击里路由器一定是重点目标。
• CrowdStrike：专门做网络安全防护的公司。
• 谷歌：Android、Chrome 都在里面，底层还有 Linux。
• JPMorgan 摩根大通：银行系统也要做预案和补救准备。
• Linux Foundation：Linux 基金会下面有大量开源项目需要一起补。
• 微软：有操作系统、Office、网络设备和云服务。
• 英伟达
• Palo Alto Networks：大型网络安全公司。
• Anthropic 自己

后面官方说还会逐渐扩充到 40 多家额外组织，但这些额外组织到底能不能拿到完整的 Mythos，这事就不好说了。刚才点名的这些公司，具体怎么用 Mythos，其实也没有说得特别清楚。

所以现在能看到的情况是：模型出来了，但先别发布给公众。先把受影响的基础设施拉个小群，封闭起来，把 bug 修一修，然后再说后面的事。

Mythos 以后会开放给公众吗

那是不是等 bug 修完以后，Mythos 就可以开放了？这个还真不好说。所以前面才会说，这件事情有点像核不扩散协议的玩法。

Anthropic 当前的逻辑是：先给少数可信的合作方使用，先帮助关键系统、关键软件、关键开源项目找漏洞并修补。在这个过程中，建立更强的安全措施和防护机制，也就是安全护栏。然后再看未来怎么安全地部署“Mythos 级别”的模型。

这里“级别”这两个字很关键，意思不是说一定把原生 Mythos 放出来，而是可能放出具有类似能力的产品。也就是说，普通人很可能永远都看不到原生的 Mythos 模型了。

Anthropic 有没有说什么时候开放给公众？截至目前，没有给出开放时间表。而且官方说得非常明确：我们不计划让 Claude Mythos Preview 普遍可用。

也就是说，他们压根没打算把这个版本全面开放。它的意思并不是永远不会有类似能力的产品发布，而是当前这个 Preview 版本不准备全民开放。未来在他们认为比较安全的时候，可能会开放一些 Mythos 级别的产品出来。至于到那个时候产品是什么样，现在不好说。

这像不像“AI 版核不扩散”

这就有点像核能利用。高浓缩铀谁都不允许有，但你要和平利用核能，比如做放射医疗，或者建核电站，使用低浓缩铀，是不是可以？未来 Mythos 级别产品，也可能朝这个方向发展。

至于 Mythos 的价格，现在也没有完全公开。很多报道说没有明确价格，但成本太高，这东西实在太贵，普通人就算给你用，你也用不起。

这个大家其实可以想象，它可能是一个极其巨大的模型。Opus 就已经比 Sonnet 大很多了，那 Mythos 很可能比 Opus 还大。整个模型跑起来，可能非常非常不经济，这也可能是它没办法向公众开放的原因之一。

当然，也许未来硬件成本进一步下降，比如显卡算力变得更便宜，这个东西才有可能开放出来。成本可承受了，才有机会普及。

至于前面那些参加项目的组织，Anthropic 也给出了参与方价格，但普通人肯定拿不到：

• 输入价格：每百万 Token 25 美元
• 输出价格：每百万 Token 125 美元

比现在常见模型贵很多，普通人目前根本没法用。

它会不会被美国严控

那么最敏感的问题来了：它会不会像核不扩散一样被美国严控？

首先讲，目前没有明确证据表明 Mythos 已经进入了类似核不扩散那样的正式国际治理架构。这更像是一个标题上的类比。但是从战略效果上说，它确实已经出现了一点“高端网络能力受控扩散”的意味。

Anthropic 自己也说这是一个两用技术。既然是两用的，那到底给谁用、不给谁用，怎么防止别人用上，这就是他们真正要思考的问题。

因为你看 OpenAI 不给中国大陆直接用，其实也不是真的拦得住。我们可以去美国建机房，可以在新加坡建机房，照样可以用。我想蒸馏你，你一点都拦不住。所以这种两用能力到底怎么管控，是个很现实的问题。

可以从三个层次理解这件事

第一层：它不是核武器，但像网络安全时代的战略工具

核武器的特点是极端稀缺、门槛极高、扩散极敏感。Mythos 这样的模型未必有核武器那种一锤定音的破坏力，但它可能在另一个维度上造成类似效果：

• 谁先拿到，谁就更快找到漏洞
• 谁先拿到，谁就更快修补自己的系统
• 谁先拿到，谁也更可能让别人的系统直接崩溃

所以它不是现实中的炸弹，但它可能是网络安全系统上的一颗巨大炸弹。

第二层：先发优势非常巨大

如果美国公司和美国盟友的关键厂商先拿到这种能力，那他们至少在几个维度上会比别人更快：

• 更快发现自己系统的问题
• 更快补上开源和商用组件上的问题
• 更快建立 AI + 漏洞治理 + 补丁分发的新体系

在这里，时间差非常重要。

第三层：未必是永久垄断，但一定是阶段性领先

它不像核武器那样，别人几十年也追不上。因为网络安全最终还是要落到补丁、配置、代码审计、供应链治理、自动更新系统这些基础工作上。

也就是说，后发国家并不是完全没路，但这个时间差非常要命。

下面这些属于大胆猜测，不是已证实事实

猜测一：Mythos 的意义可能是一条漏洞发现工业化流水线

过去找漏洞靠的是顶级研究员长时间审计少量高价值目标，而 Mythos 可能代表着把漏洞发现、利用链拼接、风险评估、修复建议，推向半自动化、规模化和工业化。

原来很多虽然做得很烂，但没有太大被利用价值的系统，烂也就烂了；有了 Mythos 这样的模型以后，可能全都暴露出来。

猜测二：Anthropic 不公开，不只是出于道德

第二种猜测，Anthropic 现在不公开，不只是出于道德，也可能是因为这个东西太敏感、太贵、太难控制。官方当然会强调安全和负责任，这没有问题，但从现实角度看，可能还叠加了几层原因。

原因一：太危险

拿到这样的系统以后，整个世界都可能变得更可怕，而且太容易被国家级攻击者利用。之前就有说法称，有中国团队曾利用 Opus 模型去写各种攻击代码。一旦 Mythos 这种模型被攻破或者被越狱，后果会非常可怕。

这有点像什么？像锦衣卫监察百官，然后又建立东厂监察锦衣卫，再建立西厂监察东厂。你说如果锦衣卫、东厂、西厂自己腐败了，或者被人攻破了，那危害就极大。

现在等于 Mythos 站在最上面，它成了新的监督者。一旦它被越狱，这件事就很难控制。

原因二：容易引发监管震荡

另外，这个产品太容易引发监管震荡。再加上它的算力成本太高，一旦开放，输出边界基本没法控制。

猜测三：未来最吃亏的是补丁链条慢、设备老旧、升级困难的系统

以后最吃亏的，不是没有大模型的国家，而是补丁链条慢、设备老旧、升级困难的系统。比如中国现在大量系统，其实也是拿 Linux 改一改，或者拿 Android 改一改。别听那些吹牛，说什么从头自主研发、自主知识产权。很多底层漏洞，你还是得等 Linux 那边去修。

但问题是，Linux 修了，我们也打上了，中国这些系统就安全吗？平时不打仗，可能看起来没毛病。但你真到冲突环境里，你相信别人会把所有漏洞都补给你吗？会不会自己留两个？你要是完完全全相信对方是好人，那就太天真了。

当然，还有像鸿蒙这种号称从头自己做、没有参考其他系统的东西。那你就没法直接跟着别人的补丁体系去升级。以后如果我们自己做不出同样级别的能力，这种号称完全自主开发的操作系统、浏览器或者各种编译系统，就没有任何安全性可言。你没有参与到这个圈子里，问题就会很大。

Mythos 可能带来的现实变化

这种系统出来以后，会带来什么变化？一个非常现实的变化就是“以旧换新”必须加快推进。为什么？因为不是所有系统都可以打补丁，不是所有设备都能把漏洞补上。有很多设备根本没法整。

比如华为在全世界卖了那么多网络通信设备，你现在又没有被邀请进那个补丁体系里，人家做的各种修补你未必用得上。因为你自己号称自主研发、自主知识产权。那么这些设备可能就该以旧换新了。

所以，Mythos 模型的发布，可能会极大推进全世界华为设备的淘汰。这也是一种推测。

另一个猜想：Claude Gov 可能已经在用 Mythos

还有一个猜想：Claude Gov 可能早就已经用上 Mythos 了。这纯属猜测，没有事实依据。

因为美国、以色列和伊朗之间的冲突里，很多人都在说，伊朗内部各种网络安全设施形同虚设，漏洞多得像筛子，间谍也好，内鬼也好，到处都是。

可你要想清楚，很多高职位的内鬼未必懂计算机，低职位的人又未必有能力决定重大行动。但现在伊朗各种内部安全系统，包括监控系统，看上去就像给美国开着地图打仗一样。那是不是 Mythos 已经在里面干活了？这只是个人猜测，没有任何事实依据。

最后的判断：Mythos 的真正危险是什么

最后给一个完整判断。

Anthropic 的 Mythos 不是核武器，但它有一定的“核属性”。它是两用技术，是战略能力倍增器，可以看成网络安全领域的战略能力倍增器。

它最可怕的，不是能找到几个 bug，而是它可能意味着：

• 漏洞发现被规模化
• 利用开发被自动化
• 防守与进攻之间的时间差被急剧压缩

原来我发现问题了，到真正攻击你，中间还有一段时间，你还能补。现在这个时间差可能直接就没了。

关键基础设施里的老旧系统，必须加速以旧换新，因为这些系统会越来越不安全。谁先掌握这类模型，谁就能掌握安全节奏。

而 Anthropic 现在的做法，说白了就是一句话：这东西太强，强到不能像普通模型那样，先扔给所有人再说。

所以今天大家最该盯住的，已经不是它会不会写诗、会不会做题，而是它会不会把全球网络安全正式推进到一个 AI 大规模找漏洞的新阶段。因为一旦到了这个阶段，全球网络可能会出现大规模震荡。

如果真到了这一步，Mythos 也许不是终点，它只是第一个开枪的人。就像美国在广岛扔下原子弹以后，斯大林马上就下令必须去做一样。我相信国内的各种安全公司、大模型公司，现在应该也在奋起直追。

这个事情，还是非常非常危险的。

背景图片

25年12月底宝塔砺行计划正式上线！面向在校学生的实践支持计划。可连续白嫖宝塔面板Linux专业版！

砺行：在实践和行动中不断磨炼自己、提升品行与能力

难道我幻觉了？我咋记得之前有段时间叫：堡塔

支持对象

「砺行计划」面向：

• 全日制在校学生（初中 / 高中 / 专科 / 本科 / 研究生均可）
• 正在使用宝塔面板进行学习或项目实践
• 年龄不超过 24 周岁

实践场景包括但不限于：

• 课程作业
• 毕业设计
• 技术实验 / 学习项目
• 学生组织或社团站点
• 个人技术博客或练手项目

申请地址

https://wj.qq.com/s2/25305011/e5cb/

简要操作

1，访问地址：https://51.ruyo.net/btaff  注册账号！

2，必须实名认证，实名认证必须 手机号实名+身份证号码+姓名 一致，否则认证失败。

3，访问申请地址，填写相关信息。特别注意，核验方式支持2种。

• 教育邮箱
• 学生证明图片

4，如果你没有教育邮箱，那只能选择学生证明文件了。博主选择教育邮箱。

5，稍微等几天官方会给教育邮箱发一封确认邮件，按要求回复姓名即可。

6，再等几天就收到官方审核通过邮件，同时宝塔账号中多了一张1个月专业版的抵用券，这个券貌似没有过期时间。

7，抵用券到期前7天可再发邮件申请（有点折腾哈~）。

8，想申请更长有效期的抵用券？？可按要求完成实践内容。

华为云云创计划又又放福利了！可申请500元代金券，可用于购买云服务器！童鞋们抓紧时间！走过路过不能错过！

更多内容：华为云 / 主机测评 / 国内服务器

省流白嫖

1，先用户华为云账号，点击这里去注册：https://51.ruyo.net/huaweicloud

2，注册开通开发者，点击这里前往：https://51.ruyo.net/huaweicloud_devcloud

3，登录开发者平台后，访问：https://developer.huaweicloud.com/space/incentive/program-activity

4，沃土云创计划-个人  -   通用权益  -  申请

5，申请权益：选择学习代金券（应用开发与构建）；申请代金券：选择 通用代金券；原因：自己写一段儿

6，提交申请后 等待官方审核 发券

详细说明

特别说明：24年已经申请过401代金券的童鞋这波还可以上车！

历史文章：0元购华为云14个月云服务器，附Flexus云服务器详细测评

如果童鞋你没注册账号，点击这里注册账号以及开通开发者平台！

提醒：每个身份证可注册多个华为云账号！但是开发者平台一个实名信息只能开通一个！！！

申请领券

1，访问【激励管理】 - 【计划权益】 - 【沃土云创计划-个人】  -   【通用权益 】，点击申请

2，按下面填写申请表单，点击提交即可~

申请权益：学习代金券（应用开发与构建）

申请代金券：通用代金券

原因：自己写一段儿

3，提交成功后，申请记录中可见一条记录。处于审核中状态

4，博主实测是10月17日申请的，约在10月21日审核通过且发放了代金券

代金券

代金券面额500元，有效期3个月，适用产品如图。实测支持续费 Flexus云服务器

续费Flexus

个人认为续费Flexus云服务器最划算！当然如果你想续费CDN，域名也可以。

由于代金券使用限制，不能叠加其他官方优惠。所以新购续费Flexus云服务器需分2笔。可轻松续费18个月服务器！

第一笔：购买或者续费 11个月，支付319.11元

第二笔：继续续费7个月，需要自己支付22元。如果续费6个月自己一分也不用花。如果确实想把代金券利用干净，可以调整【统一到期日】尽量接近代金券余额。

申请技巧

就是博主申请的话术，感兴趣可看看！

此处内容需要关注微信才能查看

提交

由于内容特殊性，请见谅！
微信扫码关注公众号，回复：访问密码，即可获取密码！

最后总结

1，抓紧申请！申请人越多可能审核越慢。申请原因写的认真一些！

2，代金券一旦到账尽快使用，最好不要屯。

3，每个实名信息只能开通一个开发者账号，不支持多实名。

老读者都知道我是一个受情绪影响很大的人。

心情好的时候恣意张狂，做什么事情都很热心，充满了人生力量。在那些阶段，我写了很多文章，比如前妻文，英语学习文，心障文，学习曲线（十年经验）文等。我也创业做自己的产品，还有帮助有道做了有道词典iOS第一版。

但是我心情差的时候，抑郁的时候，我就什么都干不了。比如我的公众号、知识星球、youtube频道漫长的动不动就持续数月的断更期。

心情好的时候的产物并不多，因为我持续稳定心情愉快的时间并不多，一些外物和莫名其妙的周期会让我时不时的抑郁，走向封闭，走向沉默，一个自媒体最大的品德就是输出。而在抑郁的期间，我只保持维持生命的沟通，不乐意跟任何人沟通，也无法输出。

最近这个周期是我人生最长的一次，从疫情结束到现在吧。大家知道我去年这个时候发文说我又离婚了。并不是因为离婚而抑郁。

而是我的人生没有了目标。我突然觉得我之前追寻的一切都消失了。活着没有了意义。倒不是我会去死。而是觉得一切目标都没有了激情。

漫长的2年多，其实我一直在追寻意义，我买了火车模型，那是我去日本旅游的时候，在商场里面盯了几个小时的东西。拼好了，还设计了一个颇有点难度的轨道规划，然后，就收起了箱子。我买了一堆乐高和高达，大多数他们还在盒子里面。前些日子我买了几个印料，刻刀，学习了怎么刻印，然后也就放在那里了。

这两年间，我设计了一堆网站、app、youtube节目、公众号文章的规划，然后都半途而废了。有些已经删除了，有些还在。

做什么都找不到年轻的时候的激情了。

那时候，我充满了激情，想改变世界，现在似乎我只想跟这个世界凑合。这个世界也充满了可以用来凑合的养老。比如抖音，比如番茄小说，比如红果短剧。刷一天很快24小时就过去了。饭也没必要好好吃，点点外卖，把吃剩的米饭冻在冰箱里。然后无聊刷剧的时候再用外卖点一堆零食。非常不健康，但是消磨时光的速度很快。

存款也很快就见底了。

但是仍旧无法激起去挣钱的动力。

事实上，我一直不是一个简单可以靠金钱驱动的人。我做的大多数事情，是靠激情。

但是我不得不面对，我已经没有激情的这个事实。

只好回到规律上来。我现在还是没有写文章抒发感情的激情，因为一涉及到写作就无数的烦恼上来。抒发胸臆会不会让大家同情我，鄙夷我，是不是我树立的积极、努力、向上的形象就彻底崩塌了。我以前写文章写过我抑郁，但是都是在走出抑郁周期才开始写的。这次我要在抑郁周期坦白我的想法。

我觉得我自己是一块烂肉，我无可救药，我活着毫无意义，但是我又不想死。

怎么办？

刚才在私信里看到某个读者说，看了我的某篇快10年前的老文章，得到了启发和帮助。那

么，我换个思路，不管我心情好坏，我都继续输出，用输出去换的内心平静。2015年，我持续日更了1年，虽然好文章不多，大多数时候就是敷衍成文。但是奠定了我的公众号的基础。

那个事情我的公司收入稳定，我生活顺遂。

现在我没有事业，心情抑郁。

但是我相信，我还是能输出些有价值的东西，最不济，我可以陪伴大家。我一直抗拒规律的输出，我喜欢激情牵引的感觉。但是我现在没有激情，只能靠规律了。以后，希望可以陪好大家，也期待大家可以继续陪着我。

最近是我最抑郁的时光，但是我想陪大家一起努力过好我们的人生最先出现在Tinyfool的个人网站。

翻译自：From Zero to Hero: How to Create Your First YouTube Channel

你是否曾梦想开设一个 YouTube 频道，却因不知从何入手而感到不知所措？别担心——你并不孤单。今天你看到的每一位创作者，无论多么成功，都曾和你一样：盯着一个空空如也、零订阅的频道，心想“真的会有人看我的视频吗？”

好消息是：开始其实比你想象的要容易。下面是一份循序渐进的指南，带你从完全新手走向自信的 YouTuber。

步骤 1：明确你的“为什么”

在按下录制键之前，先问自己：我为什么要做这个？

你是想分享知识、建立个人品牌，还是单纯想找点乐子？或者你是想通过 YouTube 频道赚钱？明确目标能帮助你选择合适的细分领域——无论是科技测评、烹饪、美体健身，还是日常 vlog——并吸引正确的观众。

记住，YouTube 不只是上传视频，而是要为那些和你关注点一致的人创造价值。

步骤 2：设置你的频道

你需要一个 Google 账号才能开始。登录后，进入 YouTube → 点击个人头像 → “你的频道” → 创建。

给频道取一个能反映内容的名字，再加上头像和横幅。这些小细节能立刻让你的频道更专业。像 Canva 这样的工具能让设计变得简单，即便你完全没有美工经验。

步骤 3：别等完美设备

一个秘密：很多爆款视频只用一部手机就拍出来了。

最重要的是清晰的声音和良好的光线。如果有额外预算，先投资一个不错的麦克风和环形灯，再考虑昂贵的相机。至于剪辑，免费的 DaVinci Resolve、Final Cut Pro 或 iMovie 就足够起步。

步骤 4：制作你的第一个视频

你的第一个视频不会完美——没关系。

先写个简单的脚本或大纲。保持视频简短（5–10 分钟），专注于传递价值——无论是教学、讲故事，还是带来欢笑。记住要像跟朋友聊天一样说话；真实感总是胜过完美。

步骤 5：上传并优化

视频完成后，上传并确保它能被注意到：

• 标题：清晰且包含关键词。
• 描述：总结观众能学到什么，并附上有用链接。
• 缩略图：醒目大胆——观众总是先点缩略图才会观看。
• 标签和播放列表：帮助 YouTube 理解并推荐你的内容。

把这当成是给视频做包装，让更多人想要“打开”它。

步骤 6：分享与推广

不要光等 YouTube 的算法。把视频分享至社交媒体、相关的线上社区，并与其他小创作者合作。尤其在起步阶段，每一点曝光都很重要。

步骤 7：保持一致

坚持更新是成长的关键。选一个更新频率——每周、双周或每月——并遵守。随着时间推移，观众会期待你的新内容，而 YouTube 也会奖励你的稳定性。

记住：前 10 个视频都是练习，每一次都会比上一次更好。

步骤 8：从数据分析中学习

YouTube Studio 是你最好的朋友，它能告诉你哪些地方做得好，哪些需要改进：

• 哪些视频能让观众持续观看。
• 有多少人点击了你的缩略图。
• 观众最活跃的时间段。

利用这些数据来优化内容，就像得到了一份 YouTube 提供的免费教练服务。

步骤 9：让热情变现

当你达到 1000 订阅者和 4000 小时观看时长时，就能申请加入 YouTube 合作伙伴计划，从广告中获得收入。但这只是开始——许多创作者还通过赞助、联盟营销、甚至自有产品销售赚钱。

步骤 10：坚持走下去

最难的部分，是在没人观看的早期阶段坚持下去。但记住，每位大创作者都是从零播放量和零订阅开始的。不同之处在于，他们选择了坚持。

只要你保持更新、持续学习，并享受这个过程，终有一天你会回头发现：自己已经从零搭建起了非凡的成就。

最后的感想：不要等到自己觉得“准备好了”再开始。你的旅程始于第一个视频。按下录制键、上传，然后让全世界看到你想分享的东西吧。

从零开始到成功：如何创建你的第一个 YouTube 频道最先出现在Tinyfool的个人网站。

项目动机

在对 Arc 项目 进行分析的过程中，发现 Arc 干了一件很有意思的事情，先是自己开发了 Rust 版本的 Tendermint 共识 malachite，接着开发了一个对接 Reth 和 malachite 的兼容层 malaketh-layered，也就是说，Arc 这条链的架构是这样：

Reth -> malaketh-layered -> malachite

最终形成了一条完全以太坊等价的 PBFT 链。

那么有没有类似架构的链，直接把 Geth 和 CometBFT 给结合起来呢。是有的，Berachain 开发了一个beacon-kit，干的就是这样的事情，Berachain 主网本身就是这种架构启动的。

但是 beacon-kit 有一个问题，就是代码过度 “复杂”，不但自己设计了 slot 的概念，还把 Berachain 的一些经济模型的设计、LST 质押之类的东西都放到了 beacon-kit 中。所以虽然 beacon-kit 在工程上是一个 Geth+CometBFT 可行的实践，但是它本身并不是工具性质的立场在做，夹带了不少私货。

因此我觉得需要一个通用的、工具性质的兼容层项目，目前命名为 EthBFT。这个项目的愿景是，提供简洁、开放、最小实现、工具性质的架构，达到集成 Geth 和 CometBFT 的目的。整个区块链网络的架构会是这样：

Geth -> EthBFT -> CometBFT

EthBFT 主要干两件事情：

1. 通过以太坊执行层的 Engine API 拿区块数据
2. 把区块数据通过 ABCI 接口提交到 CometBFT

这里虽然用 Geth 举例，但对于其他以太坊的执行层客户端，应该也是通用的，因为以太坊的执行层和共识层客户端，本来就是互相兼容的，仅仅通过 RPC 接口通信。所以预计 EthBFT 可以兼容全部的以太坊执行层客户端。

而 EthBFT 的设计，自然不会和 Geth 或者 CometBFT 有代码层面的耦合，EthBFT 是一个独立的进程，可以单独启动，Geth 也可以单独启动，CometBFT 也可以单独启动，3 个组件之间，彼此通过 RPC 接口通信，具体的 RPC 接口地址等信息则会体现在 EthBFT 的配置文件中。

这就让 3 个组件互相之间，完全解耦了。

对 PBFT 的信心

我之前以为区块链技术的发展会趋于追新，也会趋于去中心化，但是发现似乎不是那样。

从前两年的 Celestia 使用了 PBFT，到 Hyperliquid 改进了 PBFT 共识，再到最近 Arc 项目自己实现了 PBFT 共识，证明在高TPS的场景下，PBFT算法还非常有活力。

PoW 和 PoS 去中心化程度高，但是不能满足高 TPS 的需求，也不能达到最终一致性的要求，这些都是 PBFT 特有的优势，尤其是企业级的应用场景下，没那么在意去中心化。

我们也许会有疑问，如果不在乎去中心化，那直接用 Server 端提供服务不就行了吗，用区块链干什么。在丢失去中心化特性的前提下，至少区块链还保留有数据公开、数据变更可追溯等特点，也是一些不错的优势。

因此，PBFT 这种诞生接近 30 年的算法，将来还会继续发光发热。也因此，去搞一个 PBFT 相关的项目，不会有太大问题。

项目前景

EthBFT 肯定不会受到市场的关注，因为大家只在乎一条链能不能发币，能不能套利，并不在乎你的技术架构是什么。

EthBFT 只是一个工具性质的项目。如果一个开发者，想要一条以太坊完备的链，同时又想要高 TPS，在没有 EthBFT 的情况下，需要怎么做呢。我懒得展开分析对比搭建链的方案了，总之我觉得 EthBFT 可以填补这部分的空缺，非侵入式那种。世界上缺一个这样的工具。

对 AI 技术的怀疑

现在 smallyunet/EthBFT 项目已经有了基本的框架，能跑通最小版本，我把它归档为 v0.0.1 版本。能跑通的表现是 Geth 的区块高度会逐渐增加，CometBFT 也在正常出块，Geth 和 CometBFT 的区块高度保持同步。当然现在还属于非常早期的版本，开发时间有限，功能上肯定有不完善的地方，接下来还会继续改进。

我之前说 鼓吹 Cursor 的人技术能力都差，因为 AI 可以放大你的能力，但是不可能代替你懂。v0.0.1 版本的 EthBFT，全部代码都是 AI 写的，没错，但是以 EthBFT 这个项目为例，现在要干的事情非常清晰，你可以试试，在不懂以太坊和 Cosmos，甚至不懂技术的情况下，完全托管给 AI，能不能搞出一个能运行的、EthBFT 这样的项目。

如果你自己对技术的理解不清晰，或者有错误，关键是 AI 不会纠正你的错误，因为 AI 并不知道你心里想要的 “正确” 是什么。AI 会非常听话地按照你的描述写代码，如果你语焉不详，AI 写出来的代码必然会跑偏，朝着错误的方向发展，而且很多时候 AI 会自己偷偷埋坑，你以为它实现了，结果它要么没写全，放了个 TODO 在那儿，要么按照自己的理解写出一大堆不需要的代码。

所以让 AI 把代码写对，其实不是一件容易的事情，首先你自己得懂，然后你得时刻盯着它干活。AI 始终只是助手而已。

我给这个项目命名为 echoevm.com，主要目标是从最简单的堆栈操作开始，逐步实现一个完整的以太坊字节码执行环境。

为什么选择这个方向？解析下以太坊客户端的技术模块：

1. RPC：GRPC 套壳？重点在于协议设计而不是技术实现
2. P2P：有现成的 libp2p 可用，无非是节点发现、路由表之类，比如深入下 Kademlia DHT？
3. 账户体系：ECDSA？密码学？
4. 交易池：交易分析、密封交易、MEV保护方向
5. 共识机制：共识机制的设计属于研究级别，至少得是个博士发论文、实验室里做研究、出各种测试数据，然后证明在哪方面做出了业界前沿的优化、最后融资雇人做工程化的实现
6. 储存：搞数据库底层的专家应该干什么都一样，哪里都有用武之地，跟区块链没关系
7. 数据结构：去研究 Merkle Patricia Tree 的实现吗？
8. 状态同步：轻节点方向，比如用 Celestia 的核心技术把执行和储存分开，或者 Archive 节点数据的 offload？

综合来看，我倾向于做一件侧重工程而不是学术、同时又有技术含量的事情，无论是从个人技术能力的提升，还是后续有可能带来的成果上，都要有意义。假如这个最小EVM开发出来了，是可以带来一系列成果的，后续也可以基于此延伸出很多更有价值的产品。

从 Solidity 语言到 bytecode 的转换过程，那是编译器专家干的事情，我要做的，是针对 bytecode 做执行，先从最简单的加法运算和 jump 开始，然后是 Gas 的计算、上下文环境的切换，直到能够执行全部以太坊历史交易。

v0.0.1（2025.05.27）

实现了一个非常简单的版本，现在可以用 solc 编译一个 Add.sol 合约，然后让 echoevm 读取生成的 Add.bin 部署代码，就会输出合约部署之后的运行时代码。

在实现这个版本的过程中，学习到的东西是部署代码和运行时代码的区别。我们一般会先部署一个合约到链上，然后再对这个合约产生调用，这实际上是两个不同的操作，但又都在使用相同的 EVM 执行，EVM 并不关心输入的 bytecode 是部署还是调用，只是对不同的操作码处理方式不同。一般部署代码会同时包含 CODECOPY 和 RETURN 两个操作码，可以利用这一点来区分输入的类型。

v0.0.2（2025.06.09）

这个版本增加了运行 runtime bytecode 的能力，也就是先部署合约，然后再针对部署之后的合约内容，进行调用，调用的时候可以带上一些参数，比如：

go run ./cmd/echoevm -bin ./build/Add.bin -function 'add(uint256,uint256)' -args "3,5"

这个命令的含义是，会执行 ./build/Add.bin 文件内的 bytecode，并且调用 add 函数，传入参数 3 和 5，最终程序运行结束后，会返回出计算结果 8。

v0.0.3（2025.06.24）

好消息，现在 echoevm 已经可以执行以太坊主网前 10000 个区块的合约交易！因为前 10000 个区块根本没有合约交易 :P

这个版本新增了执行以太坊区块的模式，可以执行单个区块执行，也可以执行区块范围执行。当然，还需要一个获取区块数据的 url，注意对于以太坊早期的区块数据，得找 archive 模式的节点。整个命令行看起来是这样：

echoevm -start-block 0 -end-block 10000 -rpc <url>

现在 echoevm 支持的字节码有限，如果执行最新的一些区块交易，会发现报错说不支持某些字节码，这个是正常现象。

v0.0.4（2025.07.05）

这个版本新增加了从 artifact 文件读取 bytecode 数据的能力，就是 hardhat 项目在编译的时候会生成的那个 artifact 文件。之前的版本只能用读取 solc 编译生成的二进制文件，编译合约的命令是这样：

# 编译合约生成字节码npx --yes solc --bin Add.sol -o ./build# 运行 echoevm 来执行字节码go run ./cmd/echoevm run -bin ./test/bins/build/Add_sol_Add.bin -function "add(uint256,uint256)" -args "1,2"

现在的版本更简单一点，对于标准的 hardhat 项目，每次执行这个编译命令都会生成 artifact 文件，echoevm 可以直接读取 json 文件并执行：

# 编译 hardhat 项目的合约npx hardhat compile# 如果愿意，可以运行 hardhat 项目的测试npx hardhat test# 运行 echoevm 来执行字节码go run ./cmd/echoevm run -artifact ./test/contract/artifacts/contracts/Add.sol/Add.json -function "add(uint256,uint256)" -args "1,2"

这个版本同样新增了一些字节码的支持，但还是不足以执行完整的以太坊区块。接下来会手动按照 Solidity 的语法特性，来逐步增加测试用例和观察字节码的欠缺情况，这也就是为什么这个版本重点优化执行方式的原因。

v0.0.5（2025.07.27）

这是一个小版本，主要是增加了比较完善的 Solidity合约 作为测试用例，涵盖基本数据类型、函数、控制流、modifier、事件、接口、library、内联汇编等 Solidity 的语法特性。

而且提供了便捷的命令，只需要在项目根目录下运行这个命令，就可以看到全部测试的结果：

make test-advanced

当然全部测试是通过的。但是目前仍然无法执行以太坊主网的第 10000000 个区块，意味着缺少的 opcode 不属于 solidity 的基本语法特性，可能是别的什么。

v0.0.6（2025.11.27）

这个 小版本 新增了两个命令，debug 命令可以用于展示字节码的执行过程：

~/work/github/echoevm > ./bin/echoevm run --debug 60016002PC    OP              GAS        STACK (Top)         ------------------------------------------------------------0002  PUSH1           0          0x10004  PUSH1           0          0x2Return: 0x

repl 命令 就像比特币的 btcdeb 一样，可以交互式地输入字节码并执行：

~/work/github/echoevm > ./bin/echoevm repl                EchoEVM REPLType opcodes (e.g., 'PUSH1 01 ADD') or hex (e.g., '600101'). Type 'exit' to quit.>  PUSH1 10Stack [1]:  0000: 0x10> PUSH1 20Stack [2]:  0001: 0x20  0000: 0x10> ADDStack [1]:  0000: 0x30> exit

我给这个系统取名 zkgate.fun，主要想发挥零知识证明的特性，结合区块链做个小工具。关键功能是实现，用户证明自己属于某一个群组，但是不需要暴露自己真实的链上身份。

目前的设想是这样，管理员首先有一个名单列表，可以是以太坊地址的数组，然后根据这个地址列表，计算出一个 Merkle Root Hash。接着把这个 root hash 提交到智能合约上。处于这个名单中的人，可以使用 Circom 电路的 proving key，来给自己生成一个 zk proof，随后将 zk proof 提交到智能合约上。

在智能合约上，会使用 Circom 电路生成的 verifier.sol，对收到的 zk proof 进行验证，判断用于生成 zk proof 的地址，是否在 Merkle Root Hash 中，最后将判断结果返回。

这样的话，管理员不需要公开自己的群组中有哪些地址，属于群组中的地址也不需要声明自己的身份，只需要提交零知识证明生成的 zk proof，就可以证明自己真的归属于这个群组。我接下来会具体在技术上实现这个设计。

更新 v0.1.0 版本 (2025.05.09)

首先要纠正之前设计中的一个错误的地方，管理员必须要公开自己群组的地址列表，否则无法根据地址列表来生成 Merkle Tree，用户也无法根据树结构，来找到自己地址所在的节点位置、生成路径证明。

其次是很高兴地说，现在跑通了一个非常初级的 Demo（smallyunet/zkgate-demo），这个 Demo 功能并不完善，甚至没有办法在电路中验证地址的所有权，但至少是一个工具链路层面的跑通。

具体实现是这样：

1. 有一个 链下程序 来根据地址列表，以及自己的地址，生成 zk 电路的 inputs.json，这个输入文件包含了 Merkle Root Hash 和验证节点位置所需要的路径
2. 根据 电路代码 来编译出一些 二进制文件，这些编译后的产物是用来生成 witness 文件的
3. 基于公开的 ptau 文件 生成 .zkey 文件
4. 从 .zkey 文件中导出 proof.json, public.json, verification_key.json，这 3 个 json 文件可以做链下离线验证，证明 prove 的有效性
5. 从 .zkey 文件中导出 .sol 文件，也就是智能合约代码，部署到链上
6. 拿着 prove.json 文件和 public.json 文件的内容，作为 参数 调用合约的 verifyProof函数，如果 prove 有效则返回 true，否则返回 false

假如一个地址不在群组列表中，有两种情况：

1. 试图用一个不在群组列表中的 地址 生成 inputs.json，然后拿着 inputs.json 去根据电路生成 prove，会直接被电路拒绝报错
2. 试图用一些假的 prove 参数 提交到链上做验证，最终无法通过链上验证

那么目前这个最初级版本的 Demo，问题在于，构建 prove 使用的是明文地址，比如：

const members = [  "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",  "0x70997970C51812dc3A010C7d01b50e0d17dc79C8",  "0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC",];const proofKey = toField(members[0]);const { siblings } = await tree.find(proofKey);

这个语句的含义是在让 zk 电路判断，members[0] 是否属于 members 数组构建出来的树结构，这显然是属于的。如果想要用不属于群组的地址构建 prove，只需要替换一下 proofKey 指向的地址：

const nonMemberAddress = "0x1234567890123456789012345678901234567890";const proofKey = toField(nonMemberAddress);const { siblings } = await tree.find(proofKey);

也就是说，members 列表必须是公开的，而现在的程序只能判断一个地址在不在 members 里面，但即使 members[0] 不是我的地址，我也能用来构建一个合法的 prove。那还要 zk 干嘛？

所以下一步要解决的问题，是让用户用私钥对某个消息进行签名，然后在 zk 电路中根据签名 recover 出地址，接着判断 recover 出来的地址是否属于 members 数组。

这个过程是不是听起来简单？可实际上用 zk 电路来 recover 出一个 ECDSA 签名算法的地址，别说复杂度非常高，难度就像用乐高搭核电站一样。难怪人们都说，搞 zk 真的很掉头发。

更新 v0.2.0 版本（2025.05.13）

这个版本解决了验证地址所有权的问题，基本思路是让 zk 证明和地址所有权的证明分开，链下用 zk 证明地址的路径在 Merkle Root 上，链上需要用户提交用私钥对 root 的签名，并且将签名提交到链上。然后合约 recover 出签名的地址，跟 zk 电路的 prove 中包含的地址信息对比。

1. zk prove 包含地址信息 -> 链上验证 zk prove -> 得知 zk prove 中的地址信息2. 用私钥对 root 签名 -> 链上得到签名 -> recover 出签名对应的地址信息3. 判断 zk prove 中的地址 == 签名 recover 出的地址

演示代码具体改动的地方有：

1. offchain 部分的代码不需要变动，生成 inputs.json 的脚本中 inputs 里已经有 key 的信息了
2. 电路代码中，需要把 inputs 中的 key 变为 public
3. 合约代码需要接受用户的 签名 作为参数，并且得到 recover 出的地址，将这个地址与 proof key 进行对比
4. 调用合约的脚本，需要用私钥对 root 进行签名，并且把签名数据作为参数调用合约

到此为止，zkgate.fun 实现的功能是，群组管理员不必在链上公开自己的群组成员信息，只需要提交 Merkle Root Hash 到链上。对于群组内的成员，需要完整的成员列表，以及自己地址对应私钥签名后的信息，就可以生成 zk prove 去链上，证明自己确实是群组内的成员。

在这个过程中，使用 zk 唯一隐藏掉的信息，是群组成员的完整信息不必上链公开，只需要一个 Merkle Root Hash。而用户的地址目前无法隐藏，必须提交到链上用于验证。

更新（2025.05.14）

有一个现有的、以太坊基金会支持的、工具链和生态都已经比较成熟的 zk 协议，同样是用来做身份验证的项目，叫 Semaphore，官网是这个，可以直接在上面体验一下包含前端界面的 Demo：

• https://semaphore.pse.dev/

在 zkgate.fun 前面两个版本的迭代中，没有选择 Semaphore 使用 EdDSA 账户体系的方案，主要是不想脱离以太坊的账户体系，也不想放弃 ECDSA，而实际上只有 EdDSA 是 zk 友好的，可以使用 Poseidon Hash 签名，zk 电路中也能对签名进行验证，不需要 “链下签名、链上 recover” 这种丑陋的实现方式。

不得不说，从个人学习的角度，虽然没几天的时间，但是我已经大概理解了 zk（工具链）的操作过程。从行业前沿的角度，我仅凭个人力量不可能做的比 Semaphore 更好。即使 zkgate.fun 进一步开发出前端界面、可视化地演示出具体的交互过程，也顶多就是 Semaphore 的这个 Demo 的样子，而且技术上没有 Semaphore 硬核。

所以 zkgate.fun 这个项目不再继续开发，域名一年后会自动到期，不再续费。

产品形态

giveme.wtf 是我刚注册的一个域名，计划做一个 web3 打赏的小工具，类似的 web2 平台有：

• https://buymeacoffee.com/
• https://linktr.ee/

与之不同的是，giveme.wtf 的个人页面上，将显示 web3 钱包的收款地址、二维码，就像 Paypal 的个人收款链接一样，并且同时支持多种链的地址格式，包括比特币、以太坊、狗狗币等，可以自由选择。

giveme.wtf 不做任何资金的中转，仅仅只是展示打赏地址这一信息，比如，访问 giveme.wtf/{username}，这个页面将显示出 username 设置好的收款地址信息，包括以太坊地址文本是什么，二维码是什么。就这么简单。

当然 giveme.wtf/{username} 下，也可以设置简单的 bio，头像、域名、社交媒体等，像是一个小型的个人主页，让人知道你是谁，稍微更值得分享出去一点。

技术实现

• 注册

user 使用 MetaMask 钱包注册，连接钱包后可以设置 username，username 是全局唯一的，在智能合约上管理，user 需要发一笔与合约交互的交易，来将自己心仪的 username 提交到合约上。

• profile 信息

绑定好 EVM 地址与 username 的关系后，就可以设置 profile 信息，包括头像、bio、钱包地址等。

填写信息后，前端页面将数据提交到后端，后端用 IPFS 节点保存这些数据（长期开启 Pin），同时生成 CID 信息，将 CID 返回给前端。

前端收到 CID 后，再发起一次合约交互，将 username->CID 的映射关系，写入到智能合约里。这个步骤可以和注册步骤合并，也可以拆开，因为有时候 user 只想注册，不想设置 profile。

• 展示

合约上的 username->CID 是最权威的数据，前端页面将根据 giveme.wtf/{username} 中的 username，从合约中获取到 CID，再拿着 CID 去 IPFS 的网关查询出具体数据，根据数据渲染出页面。

profile 会是一些非常精简的 json 数据，数据量很小，同时为了加快网关的查询速度，可以用 Cloudflare 提供的 web3 gateway CDN。

• 网络选择

智能合约部署在 base 上。

扩展优化

后期可以根据链上数据，统计出使用打赏系统的收款地址，以及收到打赏的金额总量，做个排行榜，按照 username 或者链分类，分析出一堆数据。

如果上了排行榜，username 下的 bio 可以增大曝光率。给你心目中的偶像上分吧，让他保持在榜首。

还可以增加一些 24小时榜单、PK 性质之类的排名。

同时也可以扩展到社交系统，如有打赏记录的地址可以形成关系图谱，甚至可以直接以某种 IM 工具的方式通讯、自动拉群等。

username 找回

MetaMask 钱包注册的问题在于，钱包丢了怎么办，是不是就失去了对 username 的控制。这里可以设计一个恢复机制，比如允许 username 设置一个恢复地址列表，只要是这个恢复列表中的地址，都可以找回 username 的控制权，进而改变 username 对应的 CID。这个机制主要是针对钱包遗失的情况。

至于钱包被黑了怎么办，黑客岂不是能直接修改恢复地址的列表。他都已经有 username 控制权了，再改也是改成他的地址，加固他对 username 的控制权。那么有没有钱包被黑还能夺回控制权的办法？web3 里没有。

网络的选择

目前必须要选择一条链来部署智能合约，智能合约是数据正确性的来源。那么选择哪条链其实是个问题，因为作为 user，不一定有链上的代币作手续费。

比如选择了 base，那么 user 首先得有 ETH，其次得在 base 上有 ETH，然后才能后续的操作。光是这两步，就能劝退大多数人。

那么为了解决这个问题，后面可以考虑的方向是手续费代付，用 ERC-4337 （现在差不多凉了）的 paymaster，或者比较原始的 Meta Transaction 方式。但是又得考虑到薅羊毛的问题，代付也得付得起才行。

数据可用性

MVP 里的方案是，数据用 IPFS 存，但仅仅只有一个服务器。IPFS 是比较底层的文件路由协议，可以考虑在上面包一层，像 Filecoin 一样，但是不会有 Filecoin 那么复杂，因为 giveme.wtf 的数据量比较小。PoST 难用的地方就在于需要对文件做加密解密，因为文件太大又不能全量校验，但 giveme.wtf 不一样，往简单了做就行，比如验证一下 Merkle Root Hash，也就是说，后面需要在 IPFS 的基础上，加上适当的文件校验和激励机制，让更多的节点愿意存下 giveme.wtf 完整的数据，然后用一种方式来定期检查每个节点是否真的储存了完整数据，如果存了，就给一点奖励。具体奖励给什么再说。

链下数据缓存

每次前端页面都从合约上查 username->CID，交互太慢了，而且消耗节点的 rpc 资源。需要考虑链下来缓存这部分数据，比如有一个中心化的后台程序，监听合约的事件，实时拿到 username->CID 的内容，然后写入到 Cloudflare Workers KV 服务里。前端页面首先请求 Cloudflare Workers KV，如果没有内容再 fallback 到合约上查。

那么这里又涉及到一个问题，如果中心化的服务作恶，或者被黑了怎么办，username->CID 的映射关系一改，钱直接打到黑客的地址上了。

这个链下数据完整性校验的问题，其实是 Optimistic Rollup 在解决的问题，也有相对成熟的方案。然后结合 Zetachain 的跨链逻辑，可以这样设想。

首先用来缓存的链下程序，将每一个 username->CID 的数据作为子节点，构建一个 Merkle Tree，最终会得到一个 Merkle Root Hash，这个 root hash 将是校验数据完整性的凭证，把这个 root hash 定时提交到合约上，前端页面去合约上查一下这个 root hash，就可以知道从缓存里拿到的 CID 有没有被篡改。

其次链下的索引程序可以有多个，通过 TSS 协商出一个私钥，只有这个私钥，才可以向合约提交 Metkle Hash Root，并且这多个索引程序，只有 root hash 相同，才会协商成功。相当于做了多签。

最后是冷静期+挑战期，Merkle Root 提交之后，在冷静期内不生效，同时任何人都可以发起挑战，如果挑战成功，则新提交的 Root 作废，继续用旧的 Root。当然这个步骤中的挑战是很麻烦的，得考虑到怎么发起挑战，尤其是怎么挑战才算是成功这个机制。但是好在不用着急做那么复杂，这个属于后期可以优化的方向。

OIIA OIIA（Spining Cat）是最近很火的一只鬼畜旋转猫，对比 PoW 链上的 DOGE，OIIA 将是 PoS 链上的猫主题 memecoin。

OIIA 与 pump.fun 发行的 memecoin，以及 $Trump 之类不同的地方在于，所有代币的发行量都将通过 PoS 挖矿新增，没有任何预分配（可以验证 genesis 文件），未通过挖矿产生的代币，花钱都买不到。

网络动机

1. 《发行加密货币的最好方式》
2. Oiia 将会提供更便捷的搭建以太坊 PoS 网络的工具，进一步降低搭建以太坊 PoS 网络的难度

为什么使用者要参与

如果参与者没有相关经验，作为学习者，可以：

1. 学习如何搭建一个完整的以太坊 PoS 网络
2. 学习如何启动和运维一个以太坊 Validator 节点，如何质押、如何解除质押
3. 学习如何熟练使用以太坊生态节点相关的工具
4. 发现并解决以太坊生态工具使用上的问题，给以太坊生态做贡献

为什么不用以太坊测试网

作为以太坊网络的学习者，为什么不直接用 Sepolia 这样的测试网去用，而是选择 Oiia Network？

因为 Oiia Network 的定位是 memecoin。

网络 Spec

技术基础

使用以太坊客户端 Geth + Lighthouse 作为初始节点。只修改启动配置和 genesis 文件，不修改代码。

Chain ID 以及 Network ID

十进制：

20220915

十六进制：

0x1348BF3

初始 Validator

128 个，这个是网络启动的最小规模，会直接写入到 genesis.ssz 文件中。

初始 Faucet

由于一开始网络的参与人数会比较少，会预留 128*32 = 4096 OIIA 作为水龙头余额，放到水龙头地址中。

水龙头使用 PoW Faucet（网页挖矿）的形式来分配。

水龙头的目的是提供少量的流通金额用于网络的测试使用，以及早期愿意参与到网络中的 Validator（虽然靠水龙头很难领到 32 个 OIIA）。预留额度上，如果有 128 个 solo-staker，这个网络就算是巨大的成功了，所以认为预留 4096 个 OIIA 够用。

初始发行量

为了避免类似以太坊基金会抛售的问题，OIIA 不会预分配任何金额给开发人员或 DAO，几乎所有网络都会因为预分配受到怀疑。

以太坊的 PoS 共识没有发行量上限，所以网络的初始发行量就是 4096 个 OIIA。网络启动后的流通量全部依靠挖矿奖励来产出，就像比特币一样。

也就是说，从 Oiia Network 的 genesis 文件来看，除了 4096 个 OIIA 预留用于的空投外（创世节点的 128 个 Validator 不体现在 genesis 文件上，价值 4096 OIIA），不会再预分配任何金额给任何地址。

如何成为 Validator

由于网络初始代币发行量特别少，Faucet 上又领不到足够多的 OIIA，所以可以在社区中申请成为 Validator，社区直接从 Faceut 地址转账 32 OIIA 到申请地址。

网络启动进度

由于没有任何商业目的，网络的启动进度会比较随心所欲。

译者按：大部分人都知道，百兆以太网只用了 RJ45 端口中的 2 对 4 根线，分别为 TX、RX 的差分信号。
千兆以太网用了 RJ45 端口中的全部 4 对 8 根线，但是这 4 对 8 根线是怎么定义的？哪些属于 TX，哪些属于 RX？
我也不知道，而且以前居然没有认真去了解过，所以我决定找一篇与此相关的文章翻译一下，分享给大家。

本文是“攻玉计划”的一部分，翻译自 https://www.practicalnetworking.net/stand-alone/ethernet-wiring/

当我们谈到“以太网”的时候，我们可能会讨论各种概念，包括所有线缆规格（10BASE-T, 100BASE-TX, 1000BASE-T 等等）。这些协议规定了导线上的电平（即 0/1 信号）是如何传递的，也规定了如何将电平信号解析为数据帧。

本来，此文只想简单介绍一下交叉线和直通线之间的基本区别，但基于我们的 原则，我们觉得应该更深入一些。

首先，我们会先介绍一些术语，并消除一些歧义，然后回答一些基本的问题：我们为什么要用交叉线或者直通线？到底什么是双绞线？一个个比特位是如何在线上传播的？最后，我们会综合这些概念，并探讨一下千兆以太网的相关标准。

术语解释

即使你刚接触网络通信不久，也应该听说了很多网线相关的概念，例如“以太网”“双绞线”“RJ45”“屏蔽线”“非屏蔽线”等。

但这些概念代表了什么含义？互相之间又有什么异同？有没有什么概念被误用了？坦白而言，这些概念经常被误用，不妨看看：

8P8C

这是网线两端接口的物理标准，表示它有 8 个卡口位（Position）和 8 个触点（Contacts）。这也定义了此塑料透明接口的外形设计和尺寸。

RJ45

标准插座接口（Registered Jack）第 45 号标准定义了线缆中导线的个数以及线序，并规定使用 8P8C 的物理接口。

特别地，RJ45 定义了两种线序标准：T568a 和 T568b：

请注意，两个标准唯一的实际区别是第 2 对线和第 3 对线的颜色不同。

很多人经常用 RJ45 来指代 8P8C 插口，但这是不对的。还有另一种叫 RJ61 的类似标准，也使用了 8P8C 的插口，但其内部的线序不一样。标准插座接口定义家族中还有很多其他 RJxx 的接口，但接线定义和物理尺寸都不一样。

双绞线

双绞线是一种组合线缆，包含了 8 根独立的导线，其中每两根作为一对，每对的两根线互相绞绕在一起。由此得到 4 对导线，每对导线作为一个数据传输通道。

导线成对出现这一概念很重要，我们在后文中会讲到，简而言之，这有助于减少电磁干扰（EMI）。

通常，双绞线有两种规格：屏蔽线及非屏蔽线。

注意，不管哪种规格，网线中都有 4 对导线，也就是 4 个独立的数据通道。

非屏蔽线

非屏蔽线（Unshielded Twisted Pair）（UTP）在实际工程部署中更为常见。它对外部的电磁噪声没有额外的防护，但得益于双绞线的固有特性，其数据传输也非常可靠。我们将在后文详细阐述。

非屏蔽线更便宜，物理韧性更好，也更软。这些优点使得非屏蔽线在大多数场合更受欢迎。

屏蔽线

屏蔽线（Shielded Twisted Pair）（STP）在每对双绞线、以及全部 4 对导线最外侧都包有额外的金属屏蔽壳，这有助于隔离信号传输时的电磁噪声。

但同时，如果屏蔽壳的某个地方出现了破损，或者屏蔽壳在网线两端没有都良好接地，它自身可能会成为一个天线，并且会因为空间中随处可见的无线电波（比如 Wi-Fi 信号）而给信号传输带来额外的电磁噪声。

更为甚者，屏蔽线必须与带屏蔽的 8P8C 插头一起使用，才能实现全链路端到端的屏蔽功能。

显然，屏蔽线肯定更贵，也比非屏蔽线更脆弱，因为如果屏蔽线被过度弯曲的话，其屏蔽壳很容易破损。因此，屏蔽线的使用场合比非屏蔽线少得多。

屏蔽线通常只会用在对电磁屏蔽高度敏感的场合，例如，网线紧挨着发电机或者重型机械的输电线等。

以太网

就像我们之前说的，以太网（Ethernet）是一系列标准的合集，其中之一就是不同的接线规格：10BASE-T，100BASE-TX，1000BASE-T 等等。

以太网协议也定义了每个比特（1 和 0）如何在线缆上传输，以及如何将这些比特流组合为有意义的数据帧。例如，以太网规定每帧数据的前 56 个比特必须是交替出现的 1 和 0（即“前导码”），接下来 8 个比特必须是 10101011（即帧起始标志），再接下来 48 个比特是目标 MAC 地址，然后是 48 个比特的源 MAC 地址……直到整个数据帧被全部传输完毕。

接下来，我们将讨论以太网标准中不同规格的接线规格。

BASE T* 相关术语

本节讲述的概念都与网线内部的导线如何使用相关。例如，哪些用来发送数据，哪些用来接收数据，如何发送信号，以及电压等级。

BASE T* 这一概念有三个组成部分，所以在我们讲述特定的标准之前，先来单独了解一下它们，以 100 BASE-T 为例：

100BASE-T 中的“100”

开头的数字表示网线每秒可以传输多少“兆（百万）”比特，即 Mbps。100Mbps 的网线理论上每秒可传输 100,000,000 个比特，大概每秒 12.5 兆字节（MBps），注意大写的 B 和小写的 b 分别代表字节和比特。

这一速率的网线有时被称为“快速以太网”，这是相较于 10Mbps 的“普通以太网”以及 1000Mbps 的“吉比特以太网”而言的。

100BASE-T 中的“BASE”

base 这个概念是“基带”（baseband）信号的缩写，对应的概念是“宽带”（broadband）信号。这些概念刚出现的时候，其区别是：基带在介质中传输数字信号，宽带在介质中传输模拟信号。

数字信号和模拟信号的区别在于其可被解析的值个数。

模拟信号可以表示无数种不同的值，例如，我们可以用一根线上某个特定的电压值来表示一个绿色的像素点，而另一个电压值来表示红色的像素点，以此类推，这样，这根线就能传输一张图片上的每一个像素点。

数字信号可以表示有限个不同的值，通常就两个：1 和 0。如果上述的图片用一根数字信号线来传输的话，我们会传输一系列 1 和 0 的信号流。接收端可以解析这些二进制数据为一系列数字，例如基于 RGB 颜色编码，就能构造出每一个像素点。

也就是说，数字信号和模拟信号的主要区别就是，模拟信号线上可获得无穷多中不同的值，而数字信号线上，要么是 0，要么是 1，不可能出现第三种情况。

如此一来，数字信号传输具有更高的容错率，因为导线上的电压范围只被分为了两种情况（1 或者 0）。

译者按：原文在此处举了更多的例子来详细阐述“模拟信号”和“数字信号”的区别，但译者认为过于冗余，故略去这部分篇幅。

100BASE-T 中的“-T”

“-T”表示其为双绞线（Twisted Pair）。相似的标准还有“-2”及“-5”，表示其是最大长度为 200 和 500 米的同轴电缆，以及“-SR”和“-LR”，表示其为短距离（Short Range）和长距离（Long Range）光纤。

以上解释了 BASE T* 相关术语的三个独立部分，我们现在可以探讨下快速以太网的两个重要规范（对于吉比特以太网的相关规范，我们会在后文继续探讨）：

100BASE-T4

100BASE-T4 使用了网线中全部 4 对 8 根线。其中一对仅仅用于发送信号（TX），一对仅仅用于接收信号（RX）。剩下两对既可以用于 RX 也可以用于 TX，这通过网线两端设备的协商来决定具体用途。

T4 是双绞线早期的标准之一，但由于其过于复杂且必要性不强，如今已很少使用。

100BASE-TX

100BASE-TX 只使用了网线中的 2 对 4 根线，其中一对用于 TX，另一对用于 RX，剩下两根线没有使用。你完全可以做一根只有 4 根线的网线以实现 100BASE-TX 的所有功能，只要插口触点位置正确即可（位号1，2，3，6），但通常网线铺设过程中，另外 4 根线也保留了下来，用于占位，并适配未来可能的场景升级。

100BASE-TX （包括全部 8 根线）是如今最常用的快速以太网标准。但是，它通常被简写成了 100BASE-T。再强调一下，T 只表示其为双绞线，而 TX 才表示其使用了 1&2 及 3&6 两对线。

以上介绍可从实用性和技术性的角度帮读者理解相关概念。而在实际情况中，即使你不理解原理，直接使用这些产品也非常简单，就算犯一些小错误，也是允许的。

为什么使用交叉线

网上能找到很多“交叉线”及“直通线”应用场景的相关教程，但他们一般很少解释其原理。本节我们会深入探讨一下相关概念。

100BASE-TX 及 10BASE-T 标准中定义的网线，都包含 8 根导线，两两以双绞线的形式结合为 4 对。

在这四对线中，实际只用到两对：第 2、3 对。每根线都是单工的介质，也就是说，信号只能按照指定的单方向传输。

为了实现全双工通讯，某对线将始终沿某个方向传输数据，而另一对线将始终沿相反的方向传输数据。

网络接口卡（Network Interface Card）（NIC）的配置会决定哪对线用于发送数据，哪对线用于接收数据。

使用第 2 对线（1 号和 2 号引脚）发送数据（TX）、且使用第 3 对线（3 号和 6 号引脚）接收（RX）数据的的 NIC 被称作介质相关接口（Media Dependent Interface）（MDI），与之相反，使用第 3 对线作为 RX、第 2 对线作为 TX 的 NIC 被称为交叉模式介质相关接口（Media Dependent Interface Crossover）（MDI-X）。

电脑之间直连通讯

假设一台电脑使用 MDI 模式的 NIC ，那么它就总是用第 2 对线发送数据，用第 3 对线接收数据。但如果两台用网线连接在一起的电脑都用第 2 对线发送数据，那么就会产生冲突。与此同时，两台电脑也都无法从第 3 对线上接收到数据。

因此，网线对需要交叉一下，以便从一台电脑的第 2 对线发送的数据，会被另一台电脑的第 3 对线接收到，反之亦然。

下图是一个简单的示意（无需在意示意图中线的颜色，这只是为了区分两个不通的路径而已）：

注意，两台电脑都在独立的通道上发送数据，并且依靠交叉线机制（如图所示中间的 X），两台电脑都能接收到对方发送的数据。

因此，两台电脑直连后，必须使用交叉线才能通讯。

电脑之间通过交换机通讯

交换机使得同一网络下两台电脑的通讯变得更简单。交换机的 NIC 都采用 MDI-X 标准，也就是说，交换机总是在第 3 对线上发送数据，在第 2 对线上接收数据（与电脑的 NIC 相反）。

也就是说，交换机内部有一个交叉的机制，网线本身也就不需要交叉了：

可见，连接在交换机上的电脑可以直接使用直通线，让交换机处理线序交叉即可。端到端的通讯路径也是一样的：每个设备都在自己的 TX 线上发送数据，在 RX 线上接收数据。

电脑之间通过两个串联的交换机

我们刚刚讨论了，两台电脑直连，需要使用交叉线；类似的，两台交换机之间也需要交叉线：

在这种情况下，端到端的通讯路径也与上述方式无异。

路由器与集线器

那么，路由器和集线器呢？他们用了怎样的 NIC ？

实际情况是，路由器与电脑类似，使用了 MDI 标准（第 2 对线是 TX，第 3 对线是 RX），因此，你可以将上述图片中的任意电脑换成路由器，通讯路径分析也是一样的。

而集线器与交换机类似，使用 MDI-X 标准。

译者按：此处的“路由器”是狭义上仅具有“路由”功能的设备，不等于常见的家用无线路由器

以太网线序图

前文讲到，RJ45 的导线颜色有两种标准：T568a 和 T568b。双绞线两侧所使用的标准决定了其是交叉线还是直通线。

要想做一根直通线，只要保证线两端的标准一致就行了，都是 T568a 或者都是 T568b：

要想做一根交叉线，只需其中一端为 T568a，另一端为 T568b 即可。

注意，第 1 对线和第 4 对线没有使用（蓝色对和棕色对）。理论上你的网线中可以去掉这几根线，但是去掉之后剩下的线排列起来有些困难。

另外，这两对线因为用不到，所以无需交叉。但是，吉比特以太网标准需要用到全部 8 根线，所以为了一致性，通常所有网线对都被交叉。我们会在后文讨论吉比特以太网。

最后需要注意的是，数据信号本身并不在乎导线的颜色，只要它们连在了正确的接口上就能通讯。但能用不代表就是一个好主意，颜色乱接的话，后续维护起来就是噩梦。

助记图

综上所述，我们可以把交叉线和直通线的用法画作一张图：

之所以这么摆放，是因为这样画起来更方便。我们把 L1、L2 层的设备画在左右两侧，L3 层设备画在上下两边，然后两两连接。关于网络协议分层请参见 OSI 模型。

小结一下：

• L1/L2 层设备互相连接，需要交叉线；
• L1/L2 层设备与 L3 层设备连接，需要直通线；
• L3 层设备互相连接，需要交叉线。

或者更简单：

• 同则交叉
• 异则直通

自动 MDI-X

即使知道了什么时候该用直通线，什么时候该用交叉线，对于网络工程师来说，布线也常常是个头疼的事情。

于是，出现了一个新技术，可以自动分析两台设备的接口模式，并决定是否要交叉 TX/RX。这个技术叫做“自动 MDI-X”。

使用自动 MDI-X 技术，任意两台设备之间都可以通过直通线连接，并让两端动态确定是否需要交叉 TX 和 RX。

自动 MDI-X 是 100BASE-T 实现中的一个可选功能，而在所有吉比特以太网设备中是必须的。

自动 MDI-X 的工作原理

那么，自动 MDI-X 是如何实现的？两端的设备如何确定哪对线是 TX 或 RX？如果有必要的话，哪一边的设备会交换 TX 和 RX？本节会介绍其内部工作原理。

记住，交叉线的目的是让一方的 TX 连接到另一方的 RX。也就是说，一方的 NIC 必须用 MDI 标准，另一方必须是 MDI-X 标准。自动 MDI-X 是这样实现这一功能的：

双方都先生成 1-2047 中的一个随机数，如果随机数是奇数，那么这一方会将自己的 NIC 配置为 MDI-X 模式；如果是偶数，则配置为 MDI 模式。而后双方就开始在其所选择的 TX 线上发送连接脉冲信号。

如果双方都能在自己的 RX 线上收到对方的连接脉冲，那么就代表协商完成，因为双方都能在 TX 线上发，在 RX 线上收。

如果双方都不能收到对方的连接脉冲，那么它们肯定都随机到了奇数或都随机到了偶数。因此，它们中的某一方必须将自身的 TX 和 RX 交换。

但是双方不能同时交换 TX 和 RX，因为这样一来依然是冲突的。因此，我们设计了一个系统，以随机的时间间隔切换 TX/RX 对，直到双方成功协商。

前文提到随机生成的数字（1-2047）会循环变化，以便双方能选择一个新的标准（MDI 或者 MDI-X）。但是这个数字不能每次加 1，因为这样的话，双方都会从奇数变为偶数，或者偶数变为奇数。换句话说，如果双方一开始都选择了 MDI 模式，如果同时加 1，它们都会切换为 MDI-X 模式，依然无法协商。

所以，这个随机数使用了叫“线性反馈移位寄存器”的设备以实现循环变化。

线性反馈移位寄存器（Linear-Feedback Shift Register）（LFSR）是一种算法，它会循环遍历某个范围内的所有数字，而且在每一个循环内不会重复。这些数字以一种可预测的、但随机的顺序循环出现（也就是说，它们不按照大小顺序依次出现，但出现的位置是确定的）。

举个例子，如果双方随机的初始值分别为 1000 和 2000，那么它们在 LFSR 序列中下一个数字的奇偶性是完全随机的。但如果双方随机到了同一个初始值，那么它们之后随机出来的数字依然是一样的。

这个过程会一直持续下去，直到双方成功协商。

现在问题来了，万一双方随机到了相同的数字，然后循环的时间间隔也一样呢？我们可以简单计算一下出现这种情况的几率：

双方随机到相同数字的几率是 1/2047，双方选择相同时间间隔的几率是 1/4，也就是说，双方同时切换 MDI/MDI-X 标准的几率是 1/8188。

循环每大概 62ms 运行一遍，也就是说，每秒有大概 16 个循环（每次循环开始时都会重新随机一次）。那么双方在 1 秒之内始终是相同的循环时间的几率是 1/4,294,967,296 （42 亿分之一，1/2^32）。因此，二者结合，双方在一秒内始终随机到相同的随机数、且时间间隔也一样的几率是 1/8,791,798,054,912 （8.7万亿），这种事情几乎不可能发生，就算发生了，你再等一秒就行了。

为什么使用双绞线

在网络的物理连线上使用双绞线似乎毋庸置疑。但是，为什么呢？是什么源于让双绞线在网络布线选择中处于主导地位？

有两个主要的原因，且都与电磁干扰（Electromagnetic Interference）（EMI）相关：

1. 使用双绞线可以极大减少导线向外辐射电磁干扰；
2. 使用双绞线可以减少外部电磁干扰对导线本身的影响。

如果网线需要长距离与其他各种线缆捆绑在一起布置（比如数据中心或者配电箱），以上两个特性都是非常重要的。

减少 EMI 向外辐射

只要导线中有电流信号，那就一定会辐射 EMI，进而影响到周围的线缆——也就是通常所说的“串扰”。EMI 辐射可以通过额外的屏蔽装置补偿掉，但是大名鼎鼎的 贝尔先生 发明了抵消电磁干扰的绝妙方法。

他的想法是使用两根导线，其中一根发送原始信号，另一根发送与原始信号完全相反的信号。如此一来，两根线会辐射恰好反向的 EMI，也就互相抵消了。

简单解释一下，如果一根线发送 +10V 的电压，并辐射了 +0.01V 的 EMI；而另一根线同时发送 -10V 的电压，并辐射了 -0.01V 的 EMI。它们的 EMI 加起来就是 0。

在电气工程中，这两根线通常被称为“差分对”，可以用 TX+ 和 TX- 来表示。

这一发明可以实现不需要大量屏蔽的布线方案，也是当前非屏蔽线得以大量使用的原因之一。

但现在我们只回答了“双绞线”中的“双”，至于为什么还要“绞”，我们继续往下看：

减少外部 EMI 的吸收

即使采用了上述的“差分线”，我们也无法避开所有外部的电磁干扰。无线网络、蓝牙、卫星通讯以及手机等都会成为空间中杂散的无线电波来源。

但幸好贝尔又出现了，并设计了一种非常简单却很有效的方案以屏蔽电磁干扰。

这一设计基于 EMI 的一个基本概念：离 EMI 辐射源越近，收到的干扰越强。如果两根线交替着靠近 EMI 辐射源，它们就能吸收同样多的辐射。如下图所示：

蓝色线的初始电压是 +50V，绿线与之相反为 -50V。EMI 辐射源为图中的红圈，一圈圈向外辐射，离中心越远的圈层干扰电压越小。如果简单将图中每根线上绘制的点受到的干扰电压相加，会发现两根线都增加了 22V 的电压。

尽管上图导线右侧的电压与左侧的不同，但是两根导线之间的电压差却总是一致的，一直都是 100V。EMI 对两根导线的影响是等同的。经过简单的计算与变换，即可根据最终的 100V 电压差得到初始信号分别为 +50V 和 -50V，如下图所示：

提醒一下，以上 EMI 干扰相关电压数值被严重夸大了。实际上，正常情况下 EMI 带来的电压扰动是微伏（µV）级别的，即 1/1000,000 V。但原理依然是一样的。

发送比特位

上文讲到，网线中的数据是以数字信号的方式发送的，也就是一串 1 和 0 的数据流。但双绞线具体是如何发送数据的呢？我们接下来会用一个简化的模型来解释一下。

发送数据信号，本质上来说就是在某段时间内，给导线加上变化的电压。收发双方会先协商好一个时钟频率，以确定传输的每一单位的电压信号将维持多长时间。简便起见，我们称之为“位号”。在给定的时间点，每一个位号只能表示线上传输的 0 或者 1。

不同的标准会规定不同的电压等级，但由于我们简化了模型，所以不用管真正的电压是多少。但我们依然会使用 100BASE-TX 标准所规定的电压等级，即 +2.5V 和 -2.5V。

如果要在某个位号上发送比特 1，发送方会向 TX+ 线上施加 +2.5V 电压；如果要发送比特 0，就向 TX+ 线上发送 -2.5V 电压。

而 TX- 线则始终相反，比特 1 是 -2.5V，比特 0 是 +2.5V。

下表是发送 110010101110 二进制序列的相关情况：

注意上图不是网线的实体布局，只代表 TX+ 和 TX- 线上交替变化的电压信号。双绞线实际是均匀缠绕的。

就像之前讲到的，每对中的两根线上的电压总是互为相反量，一切都很整齐，且在水平方向上是对称的。

现在假设网线附近有 EMI 辐射源，我们在上表中添加一行噪声数据，然后看看最终会变成什么样：

注意到，现在这幅图已经不再对称了。两根线仍然发送相反的电压，但加了一个偏置量。

但是，接收端并不一定要完美的 +2.5V 和 -2.5V，它只需确定哪根线发送更高的电平。如果 TX+ 发送的是高电平，那么这个位号就表示 1，如果 TX- 是更高的电平，那么这个位号就表示 0。

或者更简单，如果上图中蓝线在上面，就代表 1，黄线在上面，就代表 0。

通过这种方式，接收端能一位一位地拼凑好整个数据，不管 EMI 对原始电平有怎样的干扰。可见，非屏蔽线不能消除电磁干扰，但能消除电磁干扰的影响。

吉比特以太网

我们已经详细介绍了快速以太网（100Mbps），现在我们继续讨论一下吉比特以太网（千兆以太网，1000Mbps 或者 1Gbps）。

首要的区别就是，吉比特以太网标准需要用到全部 4 对 8 根线，不像百兆网只用到 2 对。因此，在制造吉比特以太网网线时，全部 4 对线都需要交叉。

前文讲到，RJ45 有两种不同的标准：T-568a 和 T-568b。下图描绘了 4 对线都交叉它们各自的样子：

也就是说，吉比特以太网需要自动 MDI-X。所以，你可以直接在千兆网络中使用直通线，然后让网卡自动选择是否需要交叉。

吉比特以太网有两种布线标准：

1000BASE-TX

此标准使用了全部 4 对线，但规定了其中两对线为 TX，另外两对线为 RX。

理论上讲，这比 1000BASE-T 更简单，但是这需要更昂贵的 Cat6 网线，而不是常见的 Cat5 或 Cat5e 网线。因此，1000BASE-TX 在实际部署中并不常见。

1000BASE-T

这是当前应用最广泛的吉比特以太网标准。它以全双工模式同时使用了全部 4 对线，也就是说每对线都可以同时用作 RX 和 TX。这是通过“回声消除”技术实现的，我们会在下一节详细阐述。

使用这种线序标准的最大优势是，你可以在现有的 Cat5e 网线上跑到千兆，而无需升级到更贵的 Cat6 网线。

1000BASE-T 经常被错误地指代 1000BASE-TX。这可能是因为在快速以太网协议中，占主导地位的标准是 100BASE-TX。另外很多时候，线缆标准也经常合起来称作 10/100/1000 BASE-TX。实际上，各个不同速率下，占主导的以太网协议分别是 10BASE-T、100BASE-TX 以及 1000BASE-T。

在同一对线上实现全双工

上节说到，1000BASE-T 标准可以在同一对线上同时发送和接收数据。在本节我们将解释这是如何实现的。首先，我们来做一个简单的类比。

你应该有过这样的经历：在跟别人通电话时，如果对方开了免提，你就能在听筒中听到自己的声音。这是因为你的声音从对方的扬声器中发出，在空间中遇到障碍物反射，又被对方的麦克风接收。这就叫做回声。

高端的电话可以从麦克风收到的声波中剔除扬声器发出的声波——这个技术就叫做回声消除。

回声消除也是吉比特以太网能够在同一对线上同时发送和接收数据的基础。基本原理就是，如果你知道你发送了什么信号，那么你就能从你收到的信号中将其剔除。

前文讲到，发送信号本质上是往导线上施加电压。反之，接收信号就是读取导线上的电压值。

如果发送方往某根导线上施加了以下电压：

1

+0.5V, +1V, -2V, -1V

同时，也是发送方，它在同一个导线上读取到了以下电压值：

1

+1.5V, 0V, -2.5V, +1V

那么，发送方可做一个减法，用读取值减去其发送的值，这样就能得到对方往这根线上加了多高的电压：

1

+1V, -1V, -0.5V, +2V

如此一来，同一根线就能在同一时间，同时发送和接收数据了。

再次强调，上述电压值仅仅为了解释原理，实际情况下，电压值可能完全不同，还会包含 EMI 等。同时，我们刚刚只讨论了双绞线中的一根线，另一根线仍然会承载反向的电压。

使用这种技术，全部 4 对线都可被同时用作 TX 和 RX。另外与前面几节的讨论相同，由于采用了双绞线，它们都还会消除入方向和出方向的 EMI。

总结

读到这里，你应该对以太网和双绞线的知识点有一个宏观的理解了。这些年我们学习并整理出了这篇文章，原来看似简单的网线居然囊括了这么多技术点，现在感觉很对不起那些被我随便就扔掉的网线了。

以太网线充满了许多我们本以为理所当然的技术，但实际却很复杂。本文为了便于理解，也省略了很多细节，如果读者有兴趣可以继续研究。

本文是“攻玉计划”的一部分，翻译自 https://stackoverflow.com/questions/35465557/how-to-apply-color-in-markdown

问题描述

我想用 Markdown 记录文字信息，但我搜了一圈 Google，发现 Markdown 不支持修改字体颜色。而且 StackOverflow 和 GitHub 的 Markdown 编辑模式也不支持指定文字颜色。

有什么办法可以在 Markdown 里指定文字颜色吗？

最佳答案

太长不看系列：

Markdown 自身并不支持色彩配置，但你可以在 Markdown 中添加 HTML 代码，例如：

1

<span style="color:blue">这是**蓝色**的文字</span>

以下是长回答：

根据官方的 语法规则：

Markdown 只有一个用途，就是作为编写网页的一种语法格式。
Markdown 不能取代 HTML，甚至不能实现 HTML 的大部分功能。它的语法很简单，只能覆盖很小一部分的 HTML 标签。Markdown 并不是为了让你更方便地插入 HTML 标签。我的观点是，HTML 标签已经很方便了，而 Markdown 是为了让人更容易读、写、改。HTML 是用于发布的格式，而 Markdown 是给人写的格式。因此，Markdown的语法格式只用来处理可以用纯文本表达的信息。
对于任何 Markdown 未实现的功能，直接插入 HTML 代码即可。

由于 Markdown 并不是用来发布的格式，修改字体的颜色已经超出了 Markdown 的处理范围。但你仍可以插入裸的 HTML 代码（因为 HTML 是发布级的格式），例如以下 Markdown 文本：

1

包含 <span style="color:blue">*蓝色* 文字</span>的 Markdown 语句。

将会转换为以下 HTML 代码：

1

<p>包含 <span style="color:blue"><em>蓝色</em> 文字</span>的 Markdown 语句。</p>

目前，StackOverflow （也许 GitHub 也是）会把 HTML 代码原原本本地显示出来（因为安全性考虑），因此你无法在这些地方实现文字颜色的功能，但你可以在 Markdown 的任何标准实现中使用。

另一种解决方案是，直接使用 Markuru 的非标准属性表。此标准后续被 其它 一些人（可能还有其他类似理念的方案，比如 pandoc 中的 div 和 span 参数）继承开发。如果用了这种方案，你就可以为一段文字或者行内元素配置一个类，然后用 CSS 给这个类定义色彩属性。但显然，你必须使用支持这些非标准方案的编辑工具，并且这样写出来的文档也没法移植到其他系统上。

其他回答 1

如果你不想嵌入 HTML，只想用纯净的 Markdown 语句，可以尝试添加 emoji 以便强调指定语句。比如：⚠️警告⚠️，🔴重要❗🔴 或者 🔥新功能🔥。

其他回答 2

尽管 Markdown 不支持文字颜色属性，但你可以用 CSS 重定义一些格式标签，以便用它们来修改文字颜色。当然，你可以选择是否保留这些格式标签的原有属性。

例如：

1
2
3
4
5
6
7
8

// 重置标签属性
s { text-decoration: none; } // 删除线
em { font-style: normal; font-weight: bold; } // 斜体


// 增加颜色属性
s { color: green }
em { color: blue }

参见 如何使 em 标签标记粗体而不是斜体。

然后，在 Markdown 文本中这样使用：

1
2

~~这是绿色~~
_这是蓝色_

其他回答 3

可以换个思路，你可以用各种颜色的 Unicode 字符以满足相关需求，比如 🔴，U+1F534（大红圈）。

举个例子，在我 GitHub 里的硬件项目中，我会用以下的字符以注明接线的颜色：

1
2
3
4
5
6
7
8

🔴 红色: +5V
🟠 橙色: +3.3V
⚫ 黑色: GND
⚪ 白色: GND (拉低)
🟣 紫色: I2C 信号线
🟢 绿色: 时钟信号
🟡 黄色: WS2812 信号
🔵 蓝色: 电阻桥（模拟）输入

这也许能帮到你，你可以直接复制粘贴上述字符到你的文档中，或者直接在网上搜例如“Unicode 紫色方块”之类。当然，它们也叫做 emoji。

本文是“攻玉计划”的一部分，翻译自 https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

本文旨在介绍 ESP8266 的引脚定义、引脚功能及如何使用它们。

ESP-12E 模块拥有 17 个 GPIO 引脚。但在各个开发板上，ESP8266 芯片的 GPIO 引脚并不一定全部引出，而且某些引脚不建议使用，某些引脚有非常特殊的功能。

本文将指导你如何正确使用 ESP8266 的各个 GPIO，避免用错引脚而浪费时间。

ESP12-E 模块引脚定义

下图阐述了 ESP-12E 模块的引脚定义。当你的项目使用裸 ESP-12E/F 模块的时候，可以参考此图。

🔵注意：某些开发板可能不能使用全部的引脚，但相同的引脚在不同的开发板上，功能肯定是一样的。

当前市场上有很多不同的 ESP8266 模块/开发板，它们的形状、大小、可用 GPIO 数目各不相同。但最常用的是 ESP-01(S)、ESP-12E/F、NodeMCU 开发板以及 Wemos D1 Mini 开发板。你可以自己搜索这些开发板模块的区别。

ESP-01(S) 引脚定义

如果你在用 ESP-01(S) 的板子，可以参考下图的 GPIO 引脚定义。

ESP-12E NodeMCU 开发板

ESP-12E NodeMCU 开发板的引脚定义如下图所示。

Wemos D1 Mini 开发板

Wemos D1 Mini 开发板的引脚定义如下图所示。

ESP8266 的外设

ESP8266 的外设包括：

• 17 个 GPIO
• SPI
• I2C（软件实现）
• I2S（支持 DMA）
• UART
• 10 位 ADC

推荐使用的引脚

需要注意的一点是，ESP8266 开发板上丝印的引脚号，并不是芯片真正的 GPIO 编号。比如，D0 是 GPIO16，D1 是 GPIO5。

下表说明了 ESP8266 开发板上丝印的引脚号与实际 GPIO 编号的对应关系，并提醒你哪些引脚在使用时需要注意。

绿色标记的引脚可以随意使用；黄色标记的引脚可以使用，但需要注意它们在芯片启动时的影响，可能带来意外的问题。红色标记的引脚不建议用作输入或输出功能。

接下来的篇幅将更详细地介绍 ESP8266 GPIO 引脚的功能。

连接 FLASH 芯片的引脚

GPIO6 到 GPIO11 通常用于连接 FLASH 芯片，所以，不推荐使用这几个引脚。

启动过程中用到的引脚

如果某些引脚被拉高或者拉低，ESP8266 可能会启动失败。下表是部分引脚在启动时的状态：

• GPIO16：启动时为高电平
• GPIO0：如果被拉低，则启动失败
• GPIO2：启动时为高电平，如果被拉低，则启动失败
• GPIO15：如果被拉高，则启动失败
• GPIO3：启动时为高电平
• GPIO1：启动时为高电平，如果被拉低，则启动失败
• GPIO10：启动时为高电平
• GPIO9：启动时为高电平

启动时为高电平的引脚

以下引脚在启动时会输出 3.3V 的高电平。如果你在这些引脚上接了继电器之类的外设，可能会带来一些问题：

• GPIO16
• GPIO3
• GPIO1
• GPIO10
• GPIO9

此外，其他引脚（除了 GPIO5 和 GPIO4），在启动时会输出低电平信号，同样可能带来问题。你可以阅读 此文章 以详细了解各个 GPIO 在启动时的状态。

🟢如果需要控制继电器或功率管，GPIO4 和 GPIO5 是最安全的引脚。

模拟输入引脚

ESP8266 只有一个引脚支持模拟输入，此引脚叫 ADC0，丝印上常标记为 A0。

如果使用 ESP8266 裸芯片（ESP-12E/F）的话，此引脚的电压输入范围为 0-1V。如果使用了 NodeMCU 之类的开发板，那么电压输入范围就是 0-3.3V，因为开发板上已经集成了分压器。

板载 LED

大多数 ESP8266 模块均有一个内置的 LED，通常连在 GPIO2 上。LED 亮灭的逻辑是反向的，GPIO2 为高电平时，LED 熄灭；GPIO2 低电平时，LED 亮起。

复位引脚

当 RST 引脚被拉低时，ESP8266 将被复位。按开发板上的 RESET 按键同理。

GPIO0

当 GPIO0 被拉低时，复位 ESP8266，芯片将进入 bootloader 模式。按开发板上的 FLASH/BOOT 按钮同理。

GPIO16

GPIO16 可被用于从深度睡眠中唤醒 ESP8266。要实现此功能，需要将 GPIO16 连接在 RST 引脚上。关于如何实现深度睡眠，请搜索并参考 Arduino 官网上的相关案例。

I2C

ESP8266 没有硬件 I2C 引脚，但可以用软件模拟，所以你可以使用任意引脚实现 I2C。通常我们会使用以下引脚：

• GPIO5：SCL
• GPIO4：SDA

SPI

ESP8266 上的 SPI 引脚如下：

• GPIO12：MISO
• GPIO13：MOSI
• GPIO14：SCLK
• GPIO15：CS

PWM 引脚

我们可以在 ESP8266 的所有引脚（GPIO0 至 GPIO15）上软件实现 PWM 功能。ESP8266 上的 PWM 有 10 位精度。关于如何实现 PWM 功能，请搜索并参考 Arduino 官网上的相关案例。

中断引脚

ESP8266 的所有 GPIO 引脚均支持中断，除了 GPIO16。相关案例请搜索并参考 Arduino 官网上的相关案例。

总结

希望本文能解决你对 ESP8266 GPIO 的相关疑惑，祝好！