网络与分布式2022dl.acm.org编辑精选
IPFS 的设计与评估：去中心化 Web 的存储层
Design and evaluation of IPFS: a storage layer for the decentralized web
进阶 · 约 70 分钟读完前置知识：分布式系统基础、P2P网络与DHT、网络性能测量
导读
这篇论文系统介绍 IPFS 作为去中心化 Web 存储层的设计，并基于实际部署数据评估其内容检索等性能。评估显示跨区域检索延迟中位数约 2.9 秒，P90/P95 约 4.3/4.7 秒，虽逐年改善但离实时仍有距离。
HN 关注点：IPFS 的真实性能、节点可追踪性与隐私风险，以及论文作者与 Protocol Labs 的关系对数据来源的影响。
HN 评论精选
这几条评论里：质疑 1 补充 3
质疑指出 IPFS 的节点身份暴露、DHT 可查询托管者和资源开销带来隐私、DDoS 与运行成本问题。
提醒几点：IPFS 会把所有网络接口（内网和外网）绑定到你的身份；Tor 传输仍由第三方实现且属实验性。因此托管内容很容易追溯到用户机器，即使有 NAT；机器密钥也会加剧这一点（虽可更换），让人能轻易 DDoS 托管不受欢迎内容的端点。向 DHT 查询某个内容键的持有者也很简单，可拿到全部（或前 50 个？）托管该内容的机器，这对“敏感”内容很关键。运行节点仍然很吃 CPU、内存和网络，所以用 VPS 把 IPFS 移出本地网络也并不稳妥。
noasaservice查看英文原文
Lets remind everyone: 1. IPFS attaches ALL network interfaces (internal and external) to your identity. 2. Tor is still "experimental" done by 3rd parties. https://flyingzumwalt.gitbooks.io/decentralized-web-primer/content/avenues-for-access/lessons/tor-transport.html 3. Due to 1 and 2, any hosted content is EASILY trackable to a user's computer, even behind NATs. A machine cryptokey also helps cement that (but can be changed). This allows easy DDoS'ing of any and all endpoints hosting content you don't like. 4. It is trivial to ask the dHT for *who* has a certain content key, and get all (or the top 50?) computers hosting that content. (this matters with regards to "sensitive" content) 5. Running a node is still high cpu, ram, and network chattiness - so using a VPS to keep IPFS off your local network is still tenuous to run.
补充作者与项目方的关系解释了其数据来源。
有 3 位作者在 Protocol Labs（开发 IPFS 的公司）工作，这很可能是论文能分析 ipfs.io 网关数据的原因。
eminence32查看英文原文
3 of the authors work for Protocol Labs (the company that develops IPFS), which is likely why the paper is able to analyze data from the ipfs.io gateways
补充延迟仍偏高，建议原生压缩；并期待 IPFS 改进能推动去中心化大数据处理。
论文提到跨所有区域的内容检索在 P50、P90、P95 分别为 2.90 秒、4.34 秒、4.74 秒。相比往年是明显进步，但离“软实时”还差得远。不确定这些服务器是否在发送前做动态 gzip 压缩，但应该考虑在 `ipfs add` 命令中原生加入文件或块级压缩。2016-17 年有一篇有趣的论文“Hadoop on IPFS”，希望这些持续改进能在 v1.0 前推动大数据和分析去中心化。
truth_seeker查看英文原文
> The content retrieval process across all regions takes 2.90 s, 4.34 s, and 4.74 s in the 50th, 90th, and 95th percentiles Good improvement over the years but still a long way to go feel it even soft real time. Not sure these servers are using on the fly gzip compression before sending over network but they should consider adding compression feature at file or block level natively in "ipfs add" command. There was an interesting paper "Hadoop on IPFS" (around year 2016-17). I hope these continuous improvement will play good role in making big data and analytics decentralised before it hits v1.0 https://s3-ap-southeast-2.amazonaws.com/scott-brisbane-thesis/decentralising-big-data-processing.pdf
补充LibGen 的实际使用说明 IPFS 在内容分发上有现实价值。
我只知道 IPFS 是 Library Genesis 下载的支撑技术之一，真高兴它对它们这么好用。
dartharva查看英文原文
I only know IPFS from it being one of the enablers in downloading from Library Genesis, and man am I glad that it works so good for them..
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2022Hacker News 讨论帖193 分 · 68 评
同领域还值得读
Paxos vs. Raft：分布式共识是否已达成共识？
Paxos vs. Raft: Have we reached consensus on distributed consensus?
重新审视了 Paxos 与 Raft 两种分布式共识算法之间的差异，试图在一个统一的框架下比较它们，并论证二者的相似程度远高于通常的认知，许多所谓的差别只是表述层面的。
网络与分布式2020 · 343 分 · 65 评 · 引用 10进阶 · 约 28 分钟编辑精选Stellar 协议：互联网级共识的联邦模型
Stellar Protocol: A Federated Model for Internet-Level Consensus (2016)
提出 Stellar Consensus Protocol（SCP），一种面向互联网级共识的联邦拜占庭协议模型。
网络与分布式2018 · 301 分 · 61 评专业 · 约 90 分钟编辑精选拜占庭将军问题（1982）
The Byzantine Generals Problem (1982)
这篇 1982 年论文提出并形式化了拜占庭将军问题：在分布式系统中，部分节点可能叛变或故障、通信不可完全信任时，忠诚节点如何达成一致行动。
网络与分布式2018 · 290 分 · 77 评进阶 · 约 75 分钟编辑精选Google 变差了吗？对搜索引擎中 SEO 垃圾的纵向调查
Is Google Getting Worse? A Longitudinal Investigation of SEO Spam in Search
对搜索引擎结果中的 SEO 垃圾内容做了纵向追踪：作者团队在一段时间内持续采集 Google、Bing、DuckDuckGo 等引擎针对商品评测类查询的结果，用分类器识别联盟营销…
网络与分布式2024 · 276 分 · 274 评入门 · 约 45 分钟编辑精选使 CRDT 能够容忍拜占庭故障
Making CRDTs Byzantine Fault Tolerant
Martin Kleppmann 等人的论文研究如何让 CRDT（无冲突复制数据类型）抵御拜占庭故障节点，即部分参与者恶意篡改数据时仍能保证一致性。
网络与分布式2022 · 266 分 · 40 评进阶 · 约 90 分钟编辑精选