A Blockchain API for DApps: Introducing the Oasis Gateway
Making DApps more usable with a simple API
We believe that blockchain is the future of cloud computation. It provides users with strong guarantees of integrity, and with the Oasis network — confidentiality in compute and storage. In order for the transition from centralized to decentralized cloud to succeed, we need to enable developers to build applications that are accessible for end-users.
Use the Oasis Gateway in your next DApp. To get started, use our secret ballot tutorial to walk through how to connect the Gateway to a front-end interface.
We started in August by releasing an entirely new WASI-based runtime and the new Oasis SDK. Together they make development on blockchain look and feel just like a traditional cloud environment. But to compete with centralized applications, decentralized apps — or DApps — must provide more than just the intrinsic properties of blockchain — they must meet the same usability standards of the popular mobile and web apps ubiquitous to today’s users.
Background
The infrastructure transition from self-hosted systems to cloud computing went unnoticed by end users. They didn’t have to change their behavior or download a new app — the user experience remained nearly identical. In contrast, the development experience drastically improved. Platforms were introduced that made it much easier to build, manage and scale applications — and slowly a new class of features emerged that leveraged the accessibility of the cloud to deliver higher-quality, reliable experiences to their users.
DApps similarly provide a new set of valuable benefits, but they are obfuscated by an interface too confusing and cumbersome for the average user. Specifically, when compared to a centralized app, a DApp’s usability is hindered by the following:
- Slower and less responsive
- Complex wallet management for transaction fees
- Disruptive notifications and transaction approvals
- Conceptual barriers to understanding blockchain and wallet functionality
The requirements around wallets are the most troublesome of the list. Suffice it to say, we do not live in a world where everyone has a wallet on a blockchain network. And rightly so — just think about the initial steps to use a DApp:
- Understand how wallets work
- Download a wallet application
- Put money in your wallet application
- Connect wallet application to a network
- Approve gas fees for every transaction
- Keep the wallet safe
Thus, to ensure a seamless transition to blockchain and promote user adoption, DApps must allow service providers to have their own billing relationships with end-users — avoiding the requirement for a user-owned wallet altogether. This relationship does not need to be defined by the system — we use plenty of services every day that charge us once a month or not at all — but it should offer developers the flexibility to provide wallets for their users or allow them to connect their own wallet if desired.
Our hope is that this shift will broaden the addressable market for DApps, while still retaining many of the valuable properties of blockchain.
We want to emphasize that this is an experiment. Our goal is to better understand what it takes for blockchain to be widely adopted in applications, and for decentralized apps to offer a delightful experience for any user.
The Oasis Gateway
To allow end-users to use DApps without setting up a wallet, and to improve the blockchain development experience as a whole, we started by looking at interfaces familiar to developers that use standard cloud services such as AWS or GCP.
As we discussed in our previous post, the serverless model used in cloud computing fits very well with the computing model provided by blockchains, and we intend to provide a similar abstraction on top of our own platform. We don’t want to talk about contracts — we want to talk about services. This is a new interface that we will make available to developers with Oasis Client and Oasis SDK.
The developer-gateway is a component of our infrastructure that is publicly available for other developers running services on the Oasis Network.
At its core, the developer-gateway owns a wallet, and acts as a wallet for client transactions. Clients send blobs of data, and the developer gateway generates and signs transactions out of these blobs, to be immediately submitted to an Oasis node. This means that the developer-gateway can pay transaction fees on behalf of the user.
In this model, if the owner of the developer-gateway expects to make money from the end user, they will have to use standard business model — just like centralized applications. This will provide a more familiar, comfortable experience to end-users that in turn will promote adoption.
APIs
The APIs in this section are shown in Go so that we can specifically expose all the structs and fields involved. There are two main APIs we want to show here, there are others, but these are relevant ones for our discussion.
ExecuteService
The main API provided by the developer-gateway — and which is central to its design — executes a service. This is akin to executing a transaction in which there is no transfer of tokens, and there’s no deployment of a contract. A contract already exists and a client wants to execute it.
It is important to mention that the Data field in the request is generated by the client, and the developer does not have access to it in the developer-gateway because of Deoxys-II. This makes this model privacy preserving.
In this model, there is no transaction receipt exposed, and none of the internals for the verification or execution of the transaction are exposed (EstimateGas, …).
// ExecuteServiceRequest is a request issued by the client to// trigger the execution of a service.type ExecuteServiceRequest struct {// Data is an authenticated blob of data that the client// intends to pass to the service as argumentData string // Address is the address where the service can be found Address string}// ExecuteServiceResponse is the response to an ExecuteServiceRequest.// It returns the output generated by the executiontype ExecuteServiceResponse struct { // Output generated by the execution of the service Output string}func ExecuteService(req ExecuteServiceRequest) ExecuteServiceResponse
Deploy Service
This API is the equivalent of a transaction with an amount of 0 tokens and deploys a contract.
// DeployServiceRequest is a request issued by the client to// trigger the execution of a service.type DeployServiceRequest struct { // Data is an authenticated blob of data to initialize the service Data string}// DeployServiceResponse is the response to an DeployServiceRequest.// It returns the address of the newly deployed servicetype DeployServiceResponse struct { // Address generated for the newly deployed service Address string}func DeployService(req DeployServiceRequest) DeployServiceResponse
Authentication and Authorization
With this model, the owner of the developer-gateway owns the wallet, not the client. So, it is important to be able to restrict who has access. The developer-gateway needs to give the owner some guarantees that it has control over what the developer-gateway executes. This is why we provide policies that define specific restrictions.
For instance, users of application A can call only service S, and users of application B can call only service Z. Plugins can be added to the developer-gateway to add the required authentication mechanisms for the owner of the gateway to make sure that an authenticated client intends to call an API for which it is authorized, to a service for which it is authorized.
Where is my wallet?
We talk a lot in this blog post, but the main point is that in this model users do not have access to a wallet. It looks like a small change, but the consequences are huge. It would seem that the user is at the mercy of the developer-gateway owner, since they are the one executing transactions.
However:
The developer-gateway service providers manages the wallet. This means that it will not execute transactions that it doesn’t need to. Actually, we foresee owners implementing restrictions to make sure that their users can only execute the minimum number of actions on services.
The user still receives guarantees of privacy because the user can only send authenticated blobs of data that are only accessible by the service. The developer-gateway can authenticate end users, so in that sense some confidentiality is lost, but not as much as with the standard cloud provider based applications. We still have a DApp.
It is up to the owner of the developer-gateway to decide how to define the business model that will work for them. There is no predefined model, what is going to be deterministic and immediate are the costs the owner has. In terms of revenue, it is up to the owner and their users.
Try it out!
Use the Oasis Gateway in your next DApp. To get started, use our secret ballot tutorial to walk through how to connect the Gateway to a front-end interface. Then, get hacking on your own project!
