The RIF Storage team has been busy SWIPping, and if you have no idea what that means and you are curious to find out: please read along!
A SWIP is a Swarm Improvement Proposal. It essentially is a process through which anybody can propose new ideas to become part of the open-source Swarm project. The SWIP process is largely similar to the Ethereum Improvement Proposal (EIP) or the RSK Improvement Proposal (RSKIP) processes. Knowing this, you can probably figure out what SWIPping means… Indeed! We have been submitting proposals to improve Swarm!
Via this article, we love to share with you what these proposals are about and why they are important for RIF and Swarm, but first… a little background for those who have missed out:
RIF Labs (which recently changed its name to IOV Labs) previously explained why decentralized storage is so important and presented a high-level overview of Swarm. Why Swarm? As you might know, RIF Labs is building a decentralized storage protocol (RIF Storage), and to start we partnered up with Swarm.
Recently we submitted three SWIPs detailing the SWAP functionality and where the incentivization is heading. We will give you a brief explanation for every SWIP; why they are important and what motivated us to submit them. The SWIP process is completely open for everyone to participate, so we invite you to leave your feedback and contribute as well!
SWIP #22: MULTIPLE PAYMENTS PROCESSING SWIP
Content:
This SWIP proposes to make Swarm more modular, allowing peers to negotiate on how to settle their payments. A payment module contains a choice for a currency (e.g. RIF, Ether or Bitcoin) a payment method (e.g. via the chequebook smart contracts, Lumino, Lightning Network, or even good old postal service) and acs honey-to-money oracle. Peers will be able to list a preference for each payment module and if two peers prefer one module over the other, this module will be used from that point onwards.
Motivation:
Swarm is a decentralized storage and communications project and for this to be successful, we need an incentives layer. Nevertheless, how a payment is executed should not be a matter for the functioning of the rest of the Swarm. Allowing nodes to settle their payments via their preferred method is expected to increase the adoption and resilience of Swarm. Guess what will be the currency for the first 3rd party payment module? Exactly, RIF!
SWIP #21: MESSAGE TO HONEY ORACLE
Content:
Swarm messages (such as a chunk request or delivery) all have various loads on Swarm peers. This load is reflected in the relative price of each message versus the other messages. The Message To Honey Oracle SWIP proposes a mechanism which allows future atomic updates of the price for all nodes without requiring code changes in the software every time prices are updated. We propose to utilize smart-contracts from which the latest message prices can be read and where a simple and upgradable governance mechanism allows for updating the prices. What is Honey, you may ask? Honey is an internal accounting unit, used by Swarm nodes to do their accounting and converted to a currency upon payment (see Honey To Money SWIP).
Motivation:
In the ideal world, the price of a message should be relative to its computational load on the peers. In practice, achieving exactly this is very difficult, as there are multiple types of messages and they will be used for purposes which we can’t even imagine yet. The best thing to do is to come up with a sensible estimate and see how the network will behave when it is live (this is how it is done for the pricing of OPCODES in Gas in RSK or Ethereum as well). For this to work, however, there needs to be a way to update the price of messages. Importantly, a price update should be atomically applied by the nodes, or otherwise, accounting imbalances (leading eventually to disconnects) will start to appear.
SWIP #20: HONEY TO MONEY ORACLE
Content:
The concept of Honey was previously explained as “an internal accounting unit, used by Swarm nodes to do their accounting and converted to a currency upon payment”. This SWIP is about the conversion of honey to a currency in which the debt can be settled. Just as was the case in the Message To Honey Oracle, we propose for one endpoint to resolve the latest honey-price. This SWIP is somewhat more general: we don’t require this endpoint to be an on-chain smart contract, but we propose an initial implementation where the implementation of the endpoint will be very similar to that of the message to honey oracle.
Motivation:
The same reasoning for the need of atomic upgrades applies as was the case for pricing of messages. The choice for doing the accounting in a different currency than payment was made to reduce the computational overload on peers: if peers would have to find out what is the most current actual price for a message every time a message is sent, this would be a big burden. Agreeing on a neutral honey price and only converting this to a currency at a later point is more efficient. Furthermore, separating honey from currency is good for modularity: the accounting module is concerned with honey only, the payment module converts this to a currency and does the payment.
END NOTE
We invite you to read up about all SWIPs on Github (especially #20, #21 and #22). Currently, the SWIPs are in Draft stage, meaning that they are open for any feedback and they may be changed based on this. As RIF Storage will be utilized by you, and Swarm is an important component, we’d love to hear your feedback.