# Dedicated IPFS Networks - Pinata - Medium **Published by:** [Feng](https://paragraph.com/@feng/) **Published on:** 2022-02-11 **URL:** https://paragraph.com/@feng/dedicated-ipfs-networks-pinata-medium ## Content 通过网络专业化扩展 可扩展性。这是我们在Pinata不断思考的问题。随着 IPFS 的大规模增长和采用,我们需要越来越多的方法来通过IPFS 的 DHT(分布式哈希表)来优化内容的可发现性。在这篇文章中,我们将看看 IPFS 面临的几个挑战以及目前面临性能问题的项目的潜在解决方案。 很多节点 内容可发现性的第一个可扩展性挑战与 IPFS 网络中的节点数量有关。单个 IPFS 节点经常向网络中的其他节点发布内容。如果有人询问,这允许其他节点指向托管该内容的节点,如下所示: 来自:“通过 Swarm 连接加速 IPFS ” 当 IPFS 网络中有合理数量的节点时,这非常有用。然而,随着网络中节点数量的增加,网络趋于变慢。这是因为所有 IPFS 节点都使用相同的 DHT 来定位数据。随着公共网络上 IPFS 节点的增长,内容发现开始看起来更像下图而不是上图: 这种节点拥塞减慢了 DHT 找到具有该内容的节点的能力。此外,并非所有节点都同样稳定。许多加入网络的节点可能经常脱机或无响应。这会在尝试通过 IPFS 网络路由信息时产生额外的延迟。然而,网络中节点的数量并不是唯一的可扩展性挑战。这些节点上的内容量也是一个挑战。 很多内容 The second reason IPFS can struggle with efficient content discoverability is the amount of content being announced by nodes in the network. The act of announcing content takes a little bit of time for IPFS nodes. Additionally, these nodes want to announce all of the content they have. However, as nodes start storing more and more content, the DHT records for that content start to expire before the node is able to re-announce that content. As shown below, this backs up the content announcement queue and can lead to a situation where a node can only keep the network aware of a fraction of its content at any given time. So, how does the network scale with an increasing amount of nodes and content? Private Networks Protocol Labs is already putting considerable efforts into scaling the public DHT. But, there is a way for applications to scale their IPFS usage right now. Consider private IPFS networks. Private IPFS networks are fairly simple in nature. Instead of connecting to the main IPFS network, participants in a private IPFS network will only connect to the nodes in that network. Access to these networks is controlled by a private “swarm key” that each member in the network must possess in order to take part. To learn more about setting up a private IPFS network, visit these instructions on github. To this point, most private networks have been thought of as a way to add privacy to content. However, they become much more powerful when thought about in the context of network scalability. Dedicated Networks Most applications using the public IPFS network don’t actually care about content hosted by nodes other than their own. And, likewise, most other nodes don’t care about their content. By using IPFS’s ability to set up private networks, we can set up “dedicated” networks that consist only of nodes for a specific application’s data. These networks can be private through safeguarding the private access key that allows other nodes to join the network. Or, they can be “public” dedicated networks. A “public” dedicated network is a private IPFS network with a publicly known access key. These public, private IPFS networks allow anybody to join them. The difference being that these networks are separated from the main IPFS network to specialize themselves. Nodes who don’t care about the data on these networks have no reason to join them because doing so would be a waste of resources. Scaling Benefits By separating themselves from the main IPFS network, a dedicated IPFS network can realize significant performance gains. The main reason for these performance gains is that nodes in the network will be connected to most, if not all, the other nodes in the network at all times. How does this help with performance? In a previous post, Speeding Up IPFS Through Swarm Connections, we talk about how being directly connected to a host node allows a requested node to instantly locate content. This essentially bypasses the DHT lookup process. From: “Speeding Up IPFS Through Swarm Connections” This same functionality applies with dedicated IPFS networks. Since most nodes are going to be connected to each other at all times, content discovery happens near instantaneously throughout the entire network. This means no more lengthy lookup times. This also solves the issue of too much content being announced from a single node. When directly connected to a host node, it doesn’t matter whether or not that node has had the time to announce that content to the DHT. By being directly connected to the host node, any requesting nodes are still able to instantly discover the content. But, how do we serve the content to the end user if they don’t have an IPFS node? Gateways IPFS gateways can be run on dedicated IPFS networks just like they are on the public network. In fact, gateways work exactly the same with dedicated networks as they do with the main public IPFS network. The only difference is that instead of searching the public IPFS network for data, a gateway on a dedicated network will only search for content on nodes in the dedicated network. This becomes a huge selling point for applications that rely heavily on gateways to retrieve content. Instead of a user waiting through a lengthy content discovery progress each time they want to consume data, they can find it near instantly from a dedicated network gateway. Real World Examples Let’s say that we have three decentralized networks, as detailed below: A Decentralized Autonomous Organization that stores and shares all of its files through IPFS A network for sharing scientific data over IPFS A decentralized exchange that uses IPFS for its order books With dedicated IPFS networks, each of these examples can make sure that their data flows as efficiently as possible through their networks without dealing with the outside network noise that they don’t care about. But, what if you want to switch between dedicated networks? Switching Between Networks Another advantage of using a dedicated IPFS network is the ability to transition to the public network at any time. If, at any point, a node or network of nodes decides that its data wants to become part of the public IPFS network, all that’s required is a few small configuration changes and a node restart. When switching back to the public IPFS network, all of a node’s data will remain safe and unchanged. The only change is that the node will now be participating in the public IPFS DHT again. This allows for a relatively easy transition path for applications that may choose the dedicated network approach for performance in the near future, but ultimately would like to participate in the public network as it becomes more performant. The same concept works for switching to a different dedicated network. If a node wants to join a different dedicated network, it can simply change its node configuration to point to the new dedicated network. Important Considerations Dedicated IPFS networks provide a lot of power for scaling an application’s usage of IPFS. But, that doesn’t make them right for every project. These are important things to keep in mind when considering a dedicated network. Node Configuration Every node that wants to participate in a dedicated network needs to be properly configured to do so. This can become a user experience problem if not properly accounted for. Bootstrapping By default, IPFS nodes are configured to bootstrap themselves to public IPFS bootstrapping nodes run by Protocol Labs. To successfully run a dedicated IPFS network, dedicated bootstrapping nodes will need to be run and nodes will need to be configured to connect to them on startup. Public Data Access Nodes participating in a dedicated IPFS network won’t be able to access any data on the public IPFS network. If a network relies on data from the public network that won’t be hosted by users on their dedicated network, this could pose a problem. 同样,公共网络上的节点(例如公共网关)将无法访问托管在专用 IPFS 网络上的数据。 网络规模/对等点数 专用网络最大的性能提升之一来自每个对等点保持与其他对等点的连接的能力。如果专用网络变得太大,或者如果参与专用网络的节点没有足够强大的硬件来连接到大量节点,则性能提升可能很小。 结论 当应用程序不需要参与公共 IPFS 网络时,专用 IPFS 网络提供了强大的扩展工具。利用专用 IPFS 网络可以为专用网络节点提供更快的内容发现时间。这会带来更好、更稳定的用户体验。 虽然专用 IPFS 网络提供了许多优势,但它们并不是每个项目的好解决方案。在将项目过渡到使用专用 IPFS 网络之前,应该考虑一些事情。如果您对设置专用 IPFS 网络有任何疑问,请务必在我们的社区 slack中提问。 ## Publication Information - [Feng](https://paragraph.com/@feng/): Publication homepage - [All Posts](https://paragraph.com/@feng/): More posts from this publication - [RSS Feed](https://api.paragraph.com/blogs/rss/@feng): Subscribe to updates - [Twitter](https://twitter.com/singnightY): Follow on Twitter