Swarm的基本认知

简介:   Swarm 是分布式存储平台和内容分发服务,是以太坊 web3 栈的本地基础层服务。Swarm 的主要目标是提供充分分散和冗余存储的以太坊公共记录,尤其是存储和分发 DApp 的代码和数据以及区块链数据。从经济角度来看,它允许参与者有效汇集他们的存储容量和带宽资源,以给网络的所有参与者提供这些服务,同时接受以太坊的激励。  目标  Swarm 更广泛的目标,是为去中心化的 web 应用程序(DApp)开发人员提供基础设施服务,特别是:消息传递、数据流、点对点记账、可变资源更新、存储保险、监管扫描和修复、支付渠道和数据库服务。

  Swarm 是分布式存储平台和内容分发服务,是以太坊 web3 栈的本地基础层服务。Swarm 的主要目标是提供充分分散和冗余存储的以太坊公共记录,尤其是存储和分发 DApp 的代码和数据以及区块链数据。从经济角度来看,它允许参与者有效汇集他们的存储容量和带宽资源,以给网络的所有参与者提供这些服务,同时接受以太坊的激励。

  目标

  Swarm 更广泛的目标,是为去中心化的 web 应用程序(DApp)开发人员提供基础设施服务,特别是:消息传递、数据流、点对点记账、可变资源更新、存储保险、监管扫描和修复、支付渠道和数据库服务。

  从终端用户的角度来看,Swarm 和万维网的差别不大,除了上传不托管在特定的服务器上。Swarm 提供了一个点到点的存储和服务解决方案,它具有 DDos 抗性、零停机、容错和审查及自我维持的特性,它内置了激励系统,通过点对点记账,允许用户为交易资源进行支付。Swarm 旨在和以太坊的 devp2p 多协议网络层以及以太坊区块链进行深度集成,以进行域名解析(利用 ENS)、服务支付和内容可用性保证。

  请注意: 为了解析 ENS 域名,Swarm 节点必须要连接到以太坊区块链上(主网或测试网)。

  概述

  Swarm 旨在给新的去中心化互联网提供基础层的基础设施。Swarm 是点对点的节点网络,通过彼此之间贡献资源(存储、消息转发、支付处理)提供分布式数字服务。以太坊基金会运作 Swarm 测试网,可以用来以类似于以太坊测试网络(ropsten)的方式测试功能。每个人都可以通过在自己的服务器、台式机、笔记本电脑或移动设备上运行 Swarm 客户节点加入到网络中。请参阅 《Swarm 入门(

  swarm-guide.readthedocs/en/latest/gettingstarted.html#getting-started)》一文以了解操作方法。Swarm 客户端是以太坊栈的一部分,参考实现是用 golang 编写的,可以在 go-ethereum 存储库中找到它。目前在所有节点上运行的是 POC 0.3 版。

  Swarm 提供 本地 HTTP 代理 API,DApp 或命令行工具可以用来和 Swarm 进行交互。像 消息传递 这样的模块只能基于 PRC-JSON API 才可使用。在测试网(testnet)上的基础服务提供公共网关,用于轻松演示功能和允许免费的访问,以便人们无需运行任何自己的节点即可尝试 Swarm。

  Swarm 是 devp2p 网络的节点集合,其中的每个节点在同一个网络 ID 上运行 bzz 协议套件。

  Swarm 节点也可以连接到一个(或多个)以太坊区块链上,以进行域名解析,并连接到一个以太坊区块链进行带宽和存储补偿。运行相同网络 ID 的节点应该连接到相同的区块链上以进行支付。Swarm 网络由其网络 ID 标识,该网络 ID 是一个任意整数。

  Swarm 允许上传(upload)和消失(disappear),这意味着任何节点可以只上传内容给 Swarm,然后就可以下线。只要节点没有丢失或变得不可用,该内容将仍旧可以访问,这是因为有一个“同步”的过程,节点持续地在彼此之间传递可用数据。

  公共网关

  Swarm 提供本地 HTTP 代理 API,DApp 可以用来和 Swarm 进行交互。以太坊基金会在托管公共网关,该网关允许免费访问,因此,人们甚至无需运行自己的卖二手手游节点即可尝试 Swarm。

  Swarm 公共网关可以在 swarm-gateways.net上找到,上面一直都运行着*的 Swarm 稳定版。

  目前,该网关只接受限制大小的上传。将来,上传到该网关的功能很可能完全消失。

  上传和下载

  数据上传内容由这些步骤组成:“上传”内容到本地 Swarm 节点,接着本地 Swarm 节点用其在网络中的对等点“同步”所生成的数据块。同时,下载内容由这些步骤组成:本地 Swarm 节点查询在网络中的对等点以获取相关的数据块,然后在本地重组这些内容。

  内容解析器:ENS

  为了解析 ENS 名称,Swarm 节点必须连接到以太坊区块链(主网或测试网)。

  ENS 是个系统,Swarm 用它来实现以人类可读的名称(如 theswarm.eth)引用内容。它的操作类似于 DNS 系统,把人类可读的名称转换成机器标识符,在此,即你正在引用的内容的 Swarm 哈希。通过注册一个名称,并把它解析成网站的根清单的内容哈希值,用户可以通过 URL(如 bzz://theswarm.eth/)访问该网站。

  目前,主流的浏览器(如 Chrome、Firefox 或 Safari)不支持 bzz 协议。目前,如果要通过这些浏览器访问 bzz 协议,必须使用 HTTP 网关(如

  swarm-gateways/bzz:/theswarm.eth/)或者使用支持 bzz 协议的浏览器(如 Mist)。

  可变资源更新(Mutable Resource Updates)

  可变资源更新是 Swarm POC3 上的一项 高度实验性的功能 。它正在积极开发中,因此,有些东西可能会有变化。

  我们在这份指南中已经了解到,当我们在 Swarm 中改变数据时,我们上传的数据所返回的哈希值会以无法预料的方式变化。通过可变资源更新,Swarm 提供一种内置方式,可以对更改数据保持一个持久的标识符。

  为了保持与更改数据有相同的指针,常用的方法是利用以太坊命名服务 ENS。但是,ENS 是一个链上功能,它限制了其他地方的功能:

  每个 ENS 解析器的更新都需要 gas 才能进行。更改数据不可能比挖出新区块的速度更快。正确的 ENS 解析方案要求始终同步到区块链。

  可变资源更新允许我们用非变量标识符来更改数据,无需使用 ENS。利用在创建资源时获得的密钥,可以像普通 Swarm 对象一样引用可变资源。

  如果同时使用 ENS 解析器合约和可变资源更新,只需要一个初始事务来注册 MRU_MAINFEST_KEY。该密钥将解析到资源的最近版本上(更新该资源不会改变该密钥)。有 3 种和可变资源更新进行交互的方法:HTTP API、Golang API 和 Swarm CLI。

  注意事项:

  只有创建该资源的私钥(地址)可以更新它。在创建可变资源时,必须要提供的参数之一是预期的更新频率。这表明该资源多快(以秒计算)被更新一次。尽管你可以以其他的速率更新该资源,但这么做会减慢索引该资源的处理过程。

  Swarm 上的加密

  在 POC 0.3 中引入了对称加密技术,现在可以很容易随 Swarm up 上传命令一起使用对称加密了。该加密机制是用来保护信息,并使得在处理任何 Swarm 节点时都不可读分块数据。

  Swarm 使用 计数器模式加密技术 来加密和解密内容。当上传内容到 Swarm 时,该上传的数据被分为 4KB 大小的块。这些块都将用独立的随机生成的加密密钥来编码。这个加密过程在本地 Swarm 节点上发生,没被加密的数据不与其他节点共享。单个块(和整个内容)的引用将是编码数据哈希值和加密密钥的组合。这意味着引用将比标准无加密的 Swarm 引用长一些(不是 32 个字节,而是 64 个字节)。

  当你的节点将你的内容的加密块与其他节点同步时,它不与其他节点共享完整的引用(或任何方式的解密密钥)。这意味着其他节点无法访问你的原始数据,此外,它们也无法侦测到同步的块是否经过加密。

  检索数据时,只在本地 Swarm 节点上将它解密。在整个检索过程中,这些块以加密的形式遍历网络,参与的对等节点无法解密它们。它们只在用于下载的 Swarm 节点上进行解密和重组。

  注意事项:

  Swarm 支持加密。由于无法撤销上传,因此强烈建议不上传未加密的敏感和私密数据。用户应该避免上传非法的、有争议的或不道德的内容。Swarm 目前即支持加密也支持未加密的 swarm up 命令,通过使用 --encrypt 参数来标识。将来可能有变化。加密功能是非确定性的(因为每个上传请求生成的密钥是随机的),API 的用户不应该依赖结果的幂等性;这样,在启用加密的情况下,同样的内容两次上传到 Swarm 所产生的引用是不同的。

  作者:诺亚科技;来自链得得内容开放平台“得得号”,本文仅代表作者观点,不代表链得得官方立场凡“得得号”文章,原创性和内容的真实性由投稿人保证,如果稿件因抄袭、作假等行为导致的法律后果,由投稿人本人负责得得号平台发布文章,如有侵权、违规及其他不当言论内容,请广大读者监督,一经证实,平台会立即下线。如遇文章内容问题,请联系微信:chaindd123

目录
相关文章
|
5月前
|
jenkins 网络安全 持续交付
漫谈容器化技术(swarm篇)
漫谈容器化技术(swarm篇)
66 0
|
9月前
|
存储 缓存 Kubernetes
kubernetes组件再认知
之前学习k8s的各组件还是感觉不深入, 只停留在名字解释上面。总是不能深入理解,例如应用部署后kuber-proxy会在master 和node上添加什么样的iptables规则、部署一个应用的完整流程( 手画各组件功能并介绍10分钟以上 )、schedule具体是怎么调度的、limit request 是如何限制资源的…
165 0
|
12月前
|
Prometheus Kubernetes Cloud Native
为Kubernetes集群部署一个ChatGPT机器人 上
为Kubernetes集群部署一个ChatGPT机器人 上
|
运维 Kubernetes 监控
Kubesphere 和 Rancher 如何做抉择?
目前主流的**Kubernetes**集群管理平台就是**Kubesphere**和**Rancher**,那么我们该如何在他们之间进行抉择呢?本文我们就来一起探究一下这两个平台的优劣。
3562 0
|
Kubernetes Cloud Native Serverless
2021 年 CNCF 调查:Kubernetes 跨越鸿沟的一年
大家都知道我喜欢好的调查,那么让我们来看看云原生计算基金会(Cloud Native Computing Foundation,CNCF)2021年的年度调查。 他们询问了 2302 名受访者是如何使用 Kubernetes 以及其他更通用的云原生工具的。 报告的主要结论是:Kubernetes 的使用已经成为主流,因为报告的副标题是 2021 年:“Kubernetes 跨越鸿沟的一年”。
127 0
2021 年 CNCF 调查:Kubernetes 跨越鸿沟的一年
|
弹性计算 运维 Kubernetes
故事,从 Docker 讲起 | 深度揭秘阿里云 Serverless Kubernetes(1)
伴随着云原生的发展,从早先的单机版 Docker 到 Kubernetes 的编排领域的一统江湖,再到云上托管 Kubernetes,技术风雨变化。
故事,从 Docker 讲起 | 深度揭秘阿里云 Serverless Kubernetes(1)
|
2天前
|
运维 Kubernetes Cloud Native
无处不在的 Kubernetes ,难用的问题解决了吗?
容器和 Kubernetes 已经成为云原生时代主流的选择,但实际落地的时候,却陷入了困境。在容器技术的演进过程中,我们发现了不少能够降低容器编排门槛的开源项目和商业化产品,本文将为您介绍。
14 0
|
Kubernetes Cloud Native 关系型数据库
云原生时代必须具备的核心技能之Docker高级篇(Swarm)
云原生时代必须具备的核心技能之Docker高级篇(Swarm)
云原生时代必须具备的核心技能之Docker高级篇(Swarm)
|
运维 Kubernetes Cloud Native
无处不在的 Kubernetes,难用的问题解决了吗?
从第三方的调研数据看,容器和 Kubernetes 已经成为云原生时代主流的选择,但实际落地的时候,却陷入了困境。我们尝试去总结了一些共通点,以及应对方案,也许能为正在落地容器技术的企业提供一些参考。
|
Kubernetes Cloud Native API
Kubernetes何时才会消于无形却又无处不在
一项技术成熟的标志不仅仅在于它有多流行,还在于它有多不起眼并且易于使用。比如,没有人会去思考墙上的插座,除非你恰好需要给你的手机充电但又一个都找不到,这只是我们日常生活中所用到的大量技术的一个例子而已。
1245 0