作者：Dr. Awesome Doge

编译：吴说区块链

欧意官网地址：点击进入〉〉〉

欧意app下载地址：点击下载〉〉〉

币安官网地址：点击进入〉〉〉〉

币安app下载地址：点击下载〉〉〉

TON Foundation 这个名字如今响亮而清晰，可它的来路，并不总在聚光灯下——比如 NEWTON 团队。他们不是后来加入的建设者，而是当 testnet2 还在摇晃、仓库权限尚未开放、连官方文档都散落在各处时，就蹲在终端前调试 Fift 编译器的人。

2021 年夏天，@Telegram 官方团队点名认可 NEWTON 的技术交接——没有投票，没有白皮书修订，只有一封公开信、一次 GitHub 权限移交，和一段被社区自发接续的代码主线。那是区块链世界里少有的、静默却彻底的“接管”。

我那时正用一台旧 MacBook Pro 编译 ton-blockchain，报错信息堆满屏幕。三天后，我们建了 NEWTON 组织——不是为了另起炉灶，而是为了让验证器能按时同步，让新来的开发者不用再从头啃 C++ 内存模型。 — @drawesomedoge

介绍：加入 NEWTON 团队及其使命

我第一次 pull request 提交到 ton-blockchain 仓库时，被自动拒绝了——“Permission denied”。那会儿，主干代码由 Telegram 内部维护，testnet2 节点常在凌晨掉块，日志里飘着 unhandled exception 和 timeout。我们没等邀请函，直接搭起自己的 CI 流水线，在 GitHub 上 fork 出 ton-community 镜像，把每次修复打上 newton-patch 标签。

NEWTON 不是公司，没有办公室，甚至没有 Slack 频道——只有 Telegram 群组里一串滚动的 terminal 输出、一份共享的 Notion 文档，和一条不成文的规矩：谁修好了 liteserver 的 TLS 握手问题，谁就 merge 自己的 PR。

从 2020 年底到 2021 年 6 月，我们没发过新闻稿，但做了十件事。它们不是功能列表，而是深夜重启验证器后看到的第一行绿色日志，是某个俄罗斯矿工发来截图说“mytonctrl 让我三分钟跑通了挖矿”，是第一次在 bridge.ton.org 上把 $USDT 推进 TON 钱包时，那个跳出来的 success toast。

1. mytonctrl：自动化节点管理工具

mytonctrl 最初只是个 Bash 脚本，藏在群文件里。它用 curl 调用 tonos-cli，用 sed 替换配置模板，用 expect 模拟交互式输入——直到某天凌晨，有人把它打包成 deb 包，上传到 Launchpad。我们没想做“产品”，只是厌倦了每次部署都要重输十六次密码。

DNS 注册？那会儿根本没 NFT 概念。我们注册的是 .ton 域名，指向钱包地址，用纯文本 TXT 记录存公钥——就像早期互联网用 hosts 文件映射 IP 那样笨拙，却真实可用。

后来加的 CPU 挖矿脚本，其实是为了测试验证器负载均衡。结果意外成了小矿工的救命稻草——他们用树莓派+风扇，在 Telegram 群里晒出每小时 0.003 $TON 的收益截图，配文：“比电费便宜。”

2. tonmon：区块链健康状态可视化工具

tonmon 的首页第一行代码是：`curl -s https://tonmon.dev/api/v1/status | jq '.uptime'`。它没用 fancy 的图表库，前端就是用 `

` 标签直接渲染 JSON，靠 CSS 高亮关键字段。因为当时没人知道网络会不会下一秒就分片失败——我们要的不是美观，是 0.3 秒内看清验证器是否在线。

分片状态那一栏，曾连续 72 小时标红。我们临时写了个 bot，一旦检测到 shard down，就自动向 80 个验证器发送 ping 请求，把响应最慢的三个 IP 发到群公告里。后来发现，其中两个是伊朗数据中心的节点，延迟高不是代码问题，是物理距离。

那会儿全球验证器不到一百个。tonmon 的 “Validator Weight” 图表，经常只显示三条柱状图——因为只有三个人愿意长期运行 full node，其余都是轻节点凑数。

3. tonmine：监控 Giver 合约

Giver 合约的 ABI 是手写的。我们没 API 文档，只能反编译 bytecode，对照 TON Virtual Machine 白皮书第 4.7 节逐字比对 opcodes。tonmine 的第一个版本，就是把 `tvm_slice_parse` 的返回值硬编码成中文提示：“余额不足”、“签名错误”、“Gas 耗尽”。

每天 20 万 $TON 的产出？那是所有 Giver 加起来的数字。但实际分布极不均衡——一个在新加坡的 Giver，因矿工太少，难度常年卡在 0x100；而另一个在德国的，因涌入太多树莓派，难度飙升到 0x8000，矿工平均要试 32768 次哈希才出一块。

tonmine 的终端输出里，有一行不起眼的注释：`# If you see "difficulty too high", check your fan speed.` ——因为真有人把矿机塞进冰箱，只为压低温度多抢几轮选举。

4. 跨链桥

bridge.ton.org 的 SSL 证书是 Let’s Encrypt 免费签发的，Nginx 配置文件里还留着一行注释：`# DO NOT TOUCH — this breaks ETH relay`. 因为第一次上线时，我们误把 Ethereum RPC 的 batch 请求拆成了单条，导致 BSC 链上转账延迟 17 分钟。修复补丁就写在那行注释下面。

桥的合约逻辑很简单：用户把 ERC-20 锁进 Polygon 上的 vault，TON 链上 mint 对应 jetton。但难点在于——怎么让 TON 验证器相信 Polygon 的区块头？我们没用预言机，而是写了个轻客户端，用 Merkle proof 验证每个 Polygon header，然后把 proof 存进 TON 的 storage contract。整个过程不依赖中心化中继，只靠数学。

5. cryptobot：Telegram 机器人钱包

cryptobot 的第一个交易，是我用手机发给自己的：`/send 0.001 $TON to EQB...`。Bot 回复：“ Transaction submitted. Wait for confirmation (≈30 sec).” 我盯着那个秒表动效，刷新了十七次页面，直到看到 on-chain hash。

它支持 $BTC，但不是走闪电网络——而是调用 Blockstream API 查询 UTXO，再用 BitcoinJ 构造原始交易。那段 Java 代码至今还在 GitHub 上，commit message 写着：“fix BTC fee calc — thanks to @bitcoinguru for spotting the satoshi rounding bug.”

6. toncenter：简化区块链数据访问

toncenter 的 API key 是明文写在 HTML 的 `