APIs for the future: decentralized, trustless, secure
With the advent of cloud computing, everyone is trying to create some sort of online service that you can access and interact with via an online API. As the popular iOS slogan goes "there's an app for that", in the API world it's a similar mantra: "there's an API for that", irrelevant what you're trying to build: machine translation, mapping service, email sending, video rendering and streaming, etc., you'll find a large or small company that does exactly that, and the only thing you need to do is to hook into their system.
However, the online service and API ecosystem has a less attractive side, a problem yet unsolved, which leads to a high barrier of entry for small projects: trust. New and geographically remote projects are inherently untrusted, which makes payment for said services very problematic.
There are two main types of API providers: large corporations and small to medium scale projects, the two of which have very different offers when it comes to paid APIs.
A prominent solution currently available is offered by mashape: an API marketplace, broker and payment gateway acting as an escrow service between providers and consumers. Providers register their API endpoints into mashape's centralized brokerage service (configuring an associated pricing model), which on the other hand exposes those hidden APIs to the general public via their own servers. As all API invocations pass through them, those can be individually authorized, accounted for and charged at the end of the payment cycle. The value mashape brings to the API ecosystem is a payment escrow service, where API providers and consumers don't have to trust each other, but rather they all trust mashape itself to do the right thing. In exchange, mashape charges a 20% flat fee on all transactions that go through its brokarage service.
The problem with the current API ecosystem is that it requires blind trust in one or both of the API participants and true pay-per-use can only be achieved by the big players in the industry. All the existing solutions to these problems take the shape of centralization, which again requires a mutually trusted party, but also introduce a potential point of failure, a potential bottleneck and last but not least, significant privacy concerns.
The proposed solution that we're pushing for is the re-decentralization of online services and APIs (like they originally were meant to be), but in a fully trustless way, where neither of the API participants has to know the other party or even trust it with funds (pre-lent or pre-paid).
By binding the financial contracts to the Ethereum blockchain, the API consumer and provider can remain in charge or their communication and the payment execution is enforced and secured by the censorship resistant Ethereum blockchain. Payment is made on a per-call basis, resurrecting the dream of a "pay for what you use": an API consumer only pays for what he actually uses, at the exact moment when he uses it; whereas an API provider can at any point redeem the payments made to his service, without the consumer being able to refuse the already authorized payments.
Payments are done over a secure, on the Ethereum blockchain, payment channel. The payment channel work in such a way that you won't burden the network with micro payments or yourself with unecassary fees. Signing of micropayments happen client side, off chain, by the consumer and are included in the authorisation header of each API call. The signed transaction can then be verified using the Ethereum state by the service provider (off chain). Once a micropayment has been signed by the consumer it can no longer be undone, this is great since both parties can't hold one another for ransom or extort the other party by not holding up their end. Payments can be verified using the following algorithm. Given that
His the hashed output of
(consumer || provider || nonce || amount)and
Sbeing the signature of
Husing standard ECDSA with the secp256k1 curve, one can derive the sender (and therefor the proof) and verify that a payment channel is 1. owned by said signer; and 2. contains enough funds. Using
Sone can redeem a cheque and collect their reward for their provided service. This works great since we don't have to burden the network with useless transaction as we can make use a sliding window technique where we keep increasing
H. Once a cheque has been collected we increase the nonce invalidating any other transaction with the given nonce provided in
H, this is to say that a particular signed cheque can only be claimed once, ever; it is therefore wise to obviously redeem the cheque with the highest possible
So, what could this decentralized and trustless API ecosystem support:
So why is this project better that anything out there?
How much does such a setup cost?