Here is our first dev update, it might be a little long and I apologize for this, there is a couple of things I wanted to say.

Foundations

First point is about our philosophy even if we think most people here share the same. We believe in open sourcing, we think what happened following the release of Bitcoin and all the forks was a good thing which allows the ecosystem as a whole to grow faster and better. In that sense, we will publish most of our work as soon as it can help others.

We are also using a lot of code provided by other projects and would like to thank them, including 0x, Kyber, Gnosis, Open Zeppelin and Civic. We are still amazed by how available are the devs from other projects and how good the collaboration can be.

State of the art: Where we are

We have specified and developed the architecture of the Request Network.

Here is what it looks like.

High level view of the smart contracts. The core is registering all the Requests, and is administrable which allows update and pause. There is only one core, the core can allow subcontracts to manage each currency. Each subcontract manages the creation and interaction with the request for a specific currency. Some subcontracts are synchronous, while other interact with an oracle (for Fiat currencies for example)

Here are the details of a currency subcontract. The subcontract interacts with different extensions that can be chosen by the creator of the request.

The Core smart contract, the Ethereum smart contract and the Escrow extension are ready (not audited yet) and here is a view of the code: https://github.com/RequestNetwork/Request_SmartContracts

Also we released our interface for extensions so developers will soon be able to add their own (the documentation will soon be released)

Optimizations

One of the interesting point we have been facing like many other projects on Ethereum is how to optimise gas cost, speed and privacy.

When dealing with B2B invoices, you especially need to broadcast your transaction on the blockchain so that your client can detect it automatically. But when you are at a Point of Sale or online, the vendor doesn’t need to broadcast the invoice on the blockchain. If he would do so, he would have to wait for blockchain confirmation and it would add a gas cost. The solution was to work on an ECDSA optimization where the seller encrypts his transaction, provides it to the client who accepts the invoice, pays it and broadcasts it in a single transaction.

Most blockchain systems (including Ethereum & Bitcoin) use the Elliptic Curve Digital Signature Algorithm (ECDSA) for cryptographically signing transactions. We use it to prove that the sender of the transaction had access to a private key and that the transaction has not been changed since it was signed.

Here is what the signature of a request looks like (parameters are not exhaustive)

You can have a view on how to create the signature in the function CreateQuickRequest on the code of this contract and on the tests: https://github.com/RequestNetwork/Request_SmartContracts/blob/master/contracts/RequestEthereum.sol

https://github.com/RequestNetwork/Request_SmartContracts/blob/master/test/requestEthereumCreateQuickRequest.js

Now we can go further in the optimization and reduce the cost to almost 0, with another type of Request that we are developing and which we refer to as “simple invoices”. These types of Invoices can be batched in a hash on the blockchain which make them almost free, and stored on IPFS. What happens in that case is that the vendor encrypts the information of a request and publishes them on the blockchain so that everyone with the key can verify it. The buyer verifies the invoice with the hash stored on the blockchain and can pay in a secure way.

This type of invoices are perfect when paying for a coffee or small amount transactions, however we lose some features as other smarts contracts can’t access it such as extensions or factoring.

Some things that are coming soon: