Select Page
The Price of Permanence: Comparing Swarm and Arweave

The Price of Permanence: Comparing Swarm and Arweave

Storing data securely is essential for the decentralized internet. To meet this need, Arweave and Swarm both aim to provide a storage layer free from censorship, gatekeepers, and centralized control. Each system incentivizes node operators to store data reliably while keeping costs low enough to remain accessible, and high enough to keep the system self-sustaining. It’s a careful balancing act with different approaches. This article compares the basic economics, incentives, and long-term risks of both systems.

Let’s begin with a general comparison:

ArweaveSwarm
Payment modelOne-time, fixedTop-up balances via postage stamps
BlockchainArweave (native)Built on Ethereum (Gnosis Chain)
TokenARBZZ 
Token Atomic UnitWinstonPLUR
Risks/ AssumptionsKryder’s Law, AR token valueEthereum ecosystem, active nodes
Economics Proof-of-Work, Storage EndowmentRedistribution Game
Live Network HealthViewBlockSwarm Scan
Live Fees Arweave feesSwarm fees

Arweave offers a simple promise to users: “pay once, store forever.” The price paid when uploading a new piece of data guarantees storage for at least 200 years. There is only one transaction, and the time horizon is fixed for all users.

Swarm’s system is more flexible and adaptable. It allows users to choose how long their data stays available, based on how much they fund their storage. Uploaders purchase batches of postage stamps. A batch represents a quota (e.g. 20GB), which entitles the owner to issue and assign a postage stamp to a number of chunks needed to store that data. The batch also acts as a wallet from which the storage rent is automatically deducted. The balance decreases over time, and the data remains available until the funds run out.

Arweave’s Storage Endowment

“Arweave draws inspiration from Bitcoin’s proof-of-work structure for achieving consensus and adapts its implementation to incentivize the permanent storage of information within its network.” – Arweave lightpaper

Like Bitcoin, Arweave runs its own blockchain. Miners store and retrieve data for users as well as process transactions on the network. They are rewarded in native AR tokens, which are minted by network node operators and serve as block rewards. Also like Bitcoin, Arweave was designed with a hard cap on the total supply (66 million AR tokens).

When users upload data, they pay AR tokens into the storage endowment, a reserve that keeps miners incentivized even if block rewards fall short. To sustain this mechanism of permanent storage in exchange for a one-time transaction, Arweave relies on two key assumptions:

  1. Storage gets cheaper over time (Kryder’s Law)
  2. AR token value remains steady or increases
https://permaweb-journal.arweave.net/article/storage-endowment-explained.html

Assumption 1 is backed by an observation from the storage industry called Kryder’s Law. According to Kryder’s law, storage density tends to double —and cost per unit tends to halve—roughly every 18 months. Historically, this has translated to an average annual storage cost decline of around 38%. Uploading data locks AR into the endowment, effectively removing it from circulation, which puts pressure on the price of AR tokens to increase.
So far, thanks to both assumptions holding, Arweave’s tokenomics has worked out, and as a result “not a single token has left the endowment since launch nearly 7 years ago.” However, if AR’s value fell significantly or storage costs stopped declining, the endowment could struggle to maintain incentives, jeopardizing Arweave’s long-term promise.

Swarm’s Redistribution Game

“Swarm is a peer-to-peer network of nodes that collectively provide a decentralised storage and communication service. This system is economically self-sustaining due to a built-in incentive system which is enforced through smart contracts on the Ethereum blockchain and powered by the BZZ token.” –Swarm whitepaper

In Swarm, the batch balance functions similarly to Arweave’s storage reserve, while the redistribution game can be likened to Arweave’s block rewards, keeping storage providers incentivized. 

Users purchase postage stamps in bulk using BZZ (specifically, xBZZ on the Gnosis Chain). Individual stamps are attached to each data chunk uploaded to the DISC (Distributed Immutable Store of Chunks), Swarm’s underlying storage layer. 
The BZZ tokens collected from postage stamp sales are redistributed to groups of nodes called neighborhoods. In each round of the game, a random neighborhood is selected to receive the reward, incentivizing cooperation and agreement on stored content.

Interaction of smart contracts for swarm storage incentives. The figure shows with the dotted line the information flow between the four contracts comprising the storage incentive smart contract suite, as well as the public transaction types they accept (Source: The Book of Swarm)

The game is orchestrated by smart contracts. The batch also acts as a wallet, with storage rent deducted automatically based on the quota and the dynamic unit price set by the price oracle. The oracle adjusts the price of postage stamps based on supply and demand, specifically, how many nodes in the selected neighborhood are replicating chunks. If there are fewer than the target replication rate (of 4), the unit price increases; if more, it decreases. When exactly four attested replicas are present, the price remains stable. 

As rent increases, stamps expire faster and associated data is deleted; when rent decreases, data persists longer. For this storage incentive model to work, Swarm relies on key assumptions:

  1. The number of nodes in a neighbourhood that participate in the game correctly indicates the supply of storage (for the size of reserve, a particular fixed volume of chunks each node is supposed to store).
  2. Liquid supply of storage: node operators will respond to price signals in the sense that higher prices will attract more node operators to dedicate their disk space to the network, while decreasing price will discourage some operators to continue their service.

If storage prices fall over time (as assumed in Arweave’s model) or if BZZ value increases, a well-funded batch can effectively achieve “pay once, store forever”. However, Swarm doesn’t make this a formal guarantee—rather, it allows flexible configurations based on user preferences and market conditions.

Comparing Risks and Assumptions

Let’s review the risks and assumptions side by side:

  • Arweave depends on:
    • Kryder’s law continuing to drive down storage costs
    • A stable or rising AR token value

If both hold, the endowment can incentivize storage indefinitely.

  • Swarm relies on:
    • Accurate pricing via the price oracle and game participation
    • Elastic node supply reacting to incentives

The unit price of rent (denominated in BZZ per chunk per block) is determined by a price oracle at the time the rent is due, so users can’t pre-determine how long storage will last. 

But if the rent declines fast enough and the batch balance exceeds the finite sum of future rent, the balance will never deplete—effectively mimicking Arweave’s “store forever” outcome. Crucially, Swarm’s design allows users to set or adjust storage duration at any time. In this sense, Swarm’s economic model can subsume Arweave’s.

Conclusion

In essence, Arweave promises permanence via simplicity, locking in fixed assumptions at the protocol level. Swarm achieves resilience through adaptability, allowing price discovery and dynamic adjustments through market participation. For users, the choice boils down to:

  • Arweave: Set-it-and-forget-it storage, assuming macroeconomic stability. 
  • Swarm: Adjustable permanence through market-driven economics. 

Each has its strengths, and understanding their assumptions is key to deciding which is right for your data.

Introducing the Access Control Trie (ACT) in Swarm

Introducing the Access Control Trie (ACT) in Swarm

by András Arányi

The Access Control Trie (ACT) is an essential feature designed to manage access control in Swarm’s decentralized storage infrastructure. It enables publishers to grant or revoke access to specific content at the chunk level using encrypted session keys. This guide will walk you through the key concepts and practical aspects of using ACT to protect your data in Swarm.

If you’re a content publisher and looking for a way to share data but maintain full control and privacy, you might find that the below concept of a fully fledged access control mechanism covers all your needs.

Content Publishers

⚠️ TLDR: Publishers can control access to their data by encrypting access keys for each viewer and adding/removing them from the ACT lookup table. ⚠️

As a publisher, you have full control over who can view your content. Using ACT, you can upload your data and grant access to specific grantees (viewers) by referring to their Swarm node wallets’ public keys. Additionally, you can revoke access at any time, ensuring that only authorized viewers have the ability to access your data.

What makes ACT unique is that, as opposed to other solutions which only encrypt data, ACT ensures that only the intended viewers will have access to the data. Everyone else is blocked, even from discovering an encrypted version of it. This significantly increases the privacy and security of your content, preventing unauthorized users from knowing the data even exists.

How to manage access:

  1. Upload your content to Swarm as you normally would, but with ACT request headers included.
  2. Assign access rights by adding the grantee’s public key to the ACT.
  3. If needed, revoke access by removing the grantee from the ACT.

Keep in mind: Publishers can control the latest version of content that grantees are able to access. If you update your content, viewers might still have access to an older version if they were granted access to that earlier version before.

You can learn more about how to manage access using tools like swarm-cli by following the tutorial in the Swarm documentation. These features are also fully supported by the Bee API (starting from version 7.0+), enabling any application to interact with them directly.

Grantees (Content Viewers)

⚠️ TLDR: Grantees can access the specific version of content that the publisher has granted access to, but may lose access to future versions if revoked. ⚠️

As a grantee, your ability to view the content is based on the public key of your Swarm node’s wallet and depends on the permission granted by the publisher. The process for gaining access is simple and secure, thanks to ACT’s encryption mechanisms.

How it works:

  • Your Swarm node wallet’s public key is used as a session key, which is then used to create two additional keys:
    • A lookup key to find your entry in the ACT lookup table.
    • An access key decryption key, allowing you to decrypt the content access key specifically encrypted for you.

This ensures that only you can decrypt the content, and you can retrieve the version of the content you have (or have had) permission for.

How ACT Manages Grantee Access

ACT employs a sophisticated mechanism to manage grantee access using public-key cryptography and secure key derivation. At the heart of this system is the ACT lookup table, a key-value store that securely links each grantee’s Swarm node wallet’s public key to an encrypted access key. Here’s a breakdown of how it works:

  1. Session Key:
    Each grantee’s Swarm node’s public and private key pair serves as their unique session key. This session key is crucial because it forms the basis for all further encryption steps related to the grantee’s access.
  2. Key Derivation via Diffie-Hellman:
    Using Diffie-Hellman key derivation, the session key is used to derive two important keys:
    • Lookup Key: This key is used to identify the specific entry for a grantee in the ACT lookup table.
    • Access Key Decryption Key: This key is used to decrypt the access key, which in turn allows the grantee to unlock the protected content.
  3. Encrypted Access Keys:
    The content access key is encrypted specifically for each grantee using their derived decryption key. This ensures that only the intended grantee can decrypt the access key and thus view the content. This per-grantee encryption adds a layer of security, preventing unauthorized access even if someone else obtains the encrypted data.
  4. ACT Lookup Table:
    The lookup table itself is implemented as a key-value store within a Swarm manifest. Each grantee’s public key maps to an encrypted access key, ensuring that only authorized users with the correct session and decryption keys can retrieve the access key and, subsequently, the content. This table allows publishers to manage access dynamically, adding or removing grantees as needed without compromising the security of the stored content.
  5. Adding and Removing Grantees:
    Publishers have the flexibility to dynamically add or remove grantees from the lookup table. When a grantee is added, their public key and the corresponding encrypted access key are stored in the lookup table.

Version Control and Historical Access:
The ACT maintains a version history, which includes timestamps for each version of the access control list. If a grantee’s access is revoked for new versions of the content, they can still access older versions to which they had been granted permission, based on the relevant timestamps.

Encryption and Security in ACT

⚠️ TLDR: Every element in the ACT process is encrypted, ensuring complete security of content and access control. ⚠️

As demonstrated earlier, encryption is central to how ACT is implemented. Every component, from the grantee list to the content access keys, is encrypted using strong cryptographic methods. This ensures that only authorized users can access your data, and any tampering or unauthorized access is effectively prevented.

Here’s how encryption is applied:

  • Grantee List Encryption:
    The list of grantees is encrypted using the publisher’s lookup key, ensuring that unauthorized users cannot even detect the existence of the grantee list. This adds another layer of privacy, as only the publisher and authorized grantees are aware of who has access.
  • Access Key Encryption:
    Each grantee’s access key is individually encrypted using their specific decryption key derived through the Diffie-Hellman process. This ensures that only the intended grantee can decrypt the access key and gain access to the protected content.
  • Historical Version Encryption:
    All versions of the ACT, including older ones, are protected by encryption. This means that even if a grantee’s access is revoked, the historical data they had access to remains encrypted and secure.

Content Encryption:
Finally, the actual content itself is encrypted at the chunk level. Only those who possess the correct access key (which is encrypted for each grantee) can decrypt and retrieve the content.

Key Takeaways

  • Publishers: Maintain control over your data and manage grantee access with fine-grained control using ACT. You can easily add or remove access rights and ensure your data is always protected by encryption.
  • Grantees: Access specific versions of content securely, knowing that only you have the ability to decrypt the content you’ve been granted access to.

For anyone operating in the Swarm ecosystem, the Access Control Trie (ACT) represents a critical advancement in decentralized content management, offering robust security while maintaining flexibility in access control.

If you’re interested in learning more about how ACT works or how to implement it in your Swarm nodes, have a look at the Swarm documentation.

ACT opens up endless possibilities in new type of business applications on decentralised infrastructures. If you want to know how or you already have a concept in mind have a look at our article dedicated to this topic and register your interest in a consultation with us here

Optimized chunk production for compact usage of postage buckets: A Swarm Hack Week success

Optimized chunk production for compact usage of postage buckets: A Swarm Hack Week success

During the recent Swarm Hack Week, the Solar Punk team hosted a hackathon where Mirko from Etherna developed a project aimed at addressing the inefficiencies in postage batch consumption in Swarm’s data storage. Currently, storing data in Swarm requires purchasing postage batches with a depth much larger than necessary, leading to significant inefficiencies and increased costs. The project focused on optimizing this process to make the nominal space in postage batches truly usable.

Steps of development

Using Bee.Net, an open-source C# library, he introduced a “compaction level” ranging from 0 to 100. This compaction level controls the effort put into compacting chunks within buckets. At level 0, there is no effect on chunk compaction, while at level 100, the compaction is maximized. The compaction level sets a trigger limit on bucket collisions, prompting the system to mine a better chunk hash when collisions occur. To enhance precision at higher compaction levels, he implemented this using a parabolic function.

Mirko added a custom byte in front of each data chunk’s payload to enable the mining of different chunk hashes, resulting in data chunks containing 4095 bytes of actual information instead of the original 4096 bytes. To interpret these optimized chunks, the reader simply drops the first byte of each data chunk. This approach ensures that the optimization can be executed solely on the client side, though it would be more efficient if handled server-side.

The key advantages of this approach include making nominal space in postage batches usable, reducing postage batch costs, and not requiring additional resources for storing decryption keys. The algorithm works even if not all chunks within the postage batch are optimized, and different files can utilize different compaction settings, enhancing flexibility.

If you would like to take a closer look on the project’s code, you can reach it on the following link: https://github.com/Etherna/bee-net/tree/feature/BNET-99-swarm-hackathon-2024 

Future work

Future work will focus on developing a deterministic method for hash production to enhance consistency, refining the trigger level formula for better performance at lower levels, and investigating solutions for the potential impact of unoptimized chunks on lower depths due to the birthday paradox.

This Swarm Hack Week project has significantly advanced the optimization of Swarm’s storage. By implementing a compaction level and optimizing data chunks, he has made Swarm’s storage more efficient and cost-effective. This collaborative innovation exemplifies the potential for future improvements in decentralized data storage. Stay tuned for more updates as we continue to enhance Swarm’s capabilities!