Request Network Protocol — Version 2

What it is

What we call “Protocol v2” is the second major iteration on the protocol. “v1” designates the protocol that exists today, based on Ethereum smart contracts. v2 introduces innovative features like high scalability and privacy options.

v2.0 will be publicly released once completed and successfully integrated with an app. We estimate the release to happen during Q1 2019.

How v2 helps Request Network meets its goals

The objective of Request Network is to provide a global open platform for payment requests. To reach this objective, the protocol needs to meet these criteria:

• Decentralized
• Fast
• Cheap
• Private
• Simple to use for the developers
• Fulfil the needs of the developers

Realizing this ambition requires a system on different bases. v2 enables:

• Scalability (faster and cheaper transactions)
• Privacy options
• More flexibility in currencies: more currencies will be available to the protocol, and they will be easier to implement
• Modularity and iterative development to gradually improve the solution

Main changes

High scalability and enablement of total encryption

In v2, all data is stored on a decentralized storage solution (IPFS) and the consensus is reached on an Ethereum smart contract through a hash of the IPFS data. Storing only hashes on Ethereum lowers costs while keeping a secure proof. Having no request data on Ethereum enables total encryption of the requests.

In the scheme above we see how it works:

• Transaction data, such as the content of a request, is stored encrypted on IPFS (InterPlanetary File System) to enable total encryption of requests.
• This encrypted data on IPFS is addressed by its IPFS hash; a way to direct to the encrypted data stored on IPFS.
• These IPFS hashes are recorded on the Ethereum main chain by a smart contract. This way transactions are recorded on the blockchain, while sensitive transaction data is fully encrypted and stored on IPFS.
• One hash can represent one or several transactions, reducing the gas fee to a minimum. Multiple requests can be made within the timeframe of Ethereum blocks, providing a way to scale.

Same burning, different network cost

Because the data about a request is encrypted and therefore unreadable, any bad actor or clever actor could abuse the network and add data that are either spam or unrelated to Request. The network will ignore this data, and the nodes will store them at a cost. To prevent these abuses, we continue using the burning system and the costs make it more expensive to store the random data on Request than other typical cloud storage solutions.

Because the smart contract does not have access to the amount, it cannot charge a fee relative to it. Therefore, the fees to pay for usage of the Request Network will now be relative to the size of the data. A minimum fee of 0.10 USD will be needed per network update, for up to 10kB (approximate size of a request) and 0.03 USD will be asked per additional 10kB. Pooling requests together will reduce the average cost of a request. Note that the fees will be adjusted to find the best compromise between spam protection and usage.

Simpler access to payment networks

Request Network is at its core, an open database of payment requests. In addition, it detects payments associated to an invoice using a built-in payment processor, which reads payment network data (such as the Bitcoin blockchain). Note that the payment processor module is open and developers can also attach their own, including existing payment service providers.

The new built-in payment processor is an off-chain open source module that allows users to pay without interacting with a smart contract, which makes it easier to pay from a wallet or even an exchange.

Simpler and more flexible logic

The protocol v1 natively handles multi-payee and multi-payer. We’ve noticed this feature is too infrequently used to justify having it in the core of the logic. In v2, it will be an extension, which will make the core logic lighter and easier to understand for the users of the protocol.

Strictly enforced rules hinder flexibility. Instead of strictly enforcing many rules, the core logic will have loose enforcement of rules, and provide the applications with ways to detect potential anomalies. For example, a refund coming from non-payee, and a payment after the request has been cancelled. These behaviours will be accepted but reported as warnings.

Modular design

The protocol is designed as modular blocks, that will enable easy upgradability. We are currently developing a basic implementation of each block, and will incrementally improve them with more advanced implementations by swapping a block, without touching the others. Continue to the next section for the details!

Architecture

Logical architecture

The architecture is designed in layers. A layered architecture has several advantages, the biggest in our case is changeability: swapping the implementation of a layer with another one without touching the others enable iterative development.

A: Storage

The storage layer handles the consensus and the data availability. It can be managed by our blockchain or existing solutions (Ethereum, Tendermint, Plasma). In the case described above, it will be based on a combination of Ethereum and IPFS.

B: Data Access

It handles the encryption and data indexing

C: Logic

It is responsible for the business logic: properties and actions of requests.

D: Advanced Logic

It covers any number of extended uses of the Request logic:

• Payment connection: Handle the connection to payment networks (BTC, ETH, fiat currency payment networks) and the detection of payments
• Multipayee and multipayer
• Warnings: helps detect abnormal but accepted behaviours, such as refunds from non-payees
• Identity management
• Content Data: Standardized formats, already existing and publicly available on GitHub and as a npm package
• Smart requests: What is today called “extensions” (continuous payments, cross-currency, escrow, ICO, etc.). Smart requests, in addition to documenting transactions, have control over them

Physical architecture

Applications using the Request Network protocol can add formatted data on IPFS and track them on the smart contract. For convenience, HTTP gateways will be built. Such gateways serve several purposes:

• Simple use of the protocol: interact with the protocol through a simple HTTP interface, just like any existing web service API
• Abstraction of Ethereum gas: gateways will handle the Ethereum fees and charge their customers for the service
• Pooling service and cost optimization: the transactions will be pooled and added as 1 IPFS file and 1 hash on Ethereum. This will enable even lower costs
• Cache service: the gateways can have a cache of all data on IPFS that will enable fast access to the requests

In the scheme above we see how it works:

1. Apps have the ability to read, send & update requests through HTTP with one of the many Request Gateways.
2. Gateways add the encrypted request data to an IPFS node. The IPFS hash is computed from the data.
3. Gateways add the IPFS hash to the Request Hash Storage smart contract on the Ethereum main chain.
4. The Request Hash Storage smart contract sends the network usage fee, an amount based on the kB size of the data stored, towards the Request Burner smart contract.

Alternatively, apps can directly add the data on IPFS and put the IPFS hash on the smart contract.

The Request Network Foundation is developing such a gateway, and the source code will be publicly available and commercially exploitable by anyone who wishes to provide a gateway service.

What’s the roadmap

Initial release, v2.0

The initial release aims at being a scaffold on which we’ll incrementally add features. v2.0 includes:

• An implementation of the storage layer based on Ethereum, as described above
• A basic implementation of the data access with no encryption. Encryption will come later.
• Implementation of the logic layer
• A gateway with the essential feature for apps to use the protocol
• Detection of Bitcoin payments

v2.0 will be publicly released once completed and successfully integrated with an app. We estimate the release to happen during Q1 2019.

From this base, these features will be added:

• Encryption
• ETH requests
• ERC20 requests
• Declarative USD requests (no payment detection)
• Improvements on the gateways
• Improvements on Ethereum storage
• Improvements on encryption
• Consider alternative storages
• Smart requests on Ethereum
• Multipayee — Multipayer
• Identity
• Smart requests on other smart contract platforms
• More payment networks and currencies

Transition from v1 to v2

While developing v2, we’ll continue to maintain and support the v1. Information for the transition will be given to developers at a later date.

FAQ

What’s the plan for BTC?

There is nothing more to do for bitcoin support on the protocol in v1. We’ll integrate bitcoin rapidly in v2.

What’s the plan for cross-currency?

Cross-currency will be implemented in the Smart Request block of the v2. Work currently in progress on v1 will be reused for the Smart requests.

What happened to Plasma and Tendermint?

Plasma and Tendermint aren’t the best solutions for our use case at this point. The design in layers allows flexibility, we’ll change the storage layer for an implementation based on Tendermint or Plasma for example if it makes more sense in the future.

Work done on the Tendermint POC is reused for the implementation of the request logic and will be reused for the encryption.

Is the REQ token staying the same?

Yes, the REQ token is the same, and the fees will be used to burn REQ tokens.

Contact devs

Head to the request hub slack to chat with the protocol development team.

Join us

You are as excited as we are about what you just read, and you and you have the skills to help us build our vision? Join the team developing the Request Network protocol!