From the beginning, one of the primary drivers of OpenRelay’s design decisions has been operational simplicity. We have a very small team, and spending lots of time maintaining services would mean not spending enough time on developing the platform. Out of the gate, we decided we wanted to use a storage engine for the order book that was a managed database. We believed at the time that DynamoDB would be an adequate storage engine with minimal operational overhead.
However, we soon found that the limitations of DynamoDB were going to limit what OpenRelay was capable of. DynamoDB only allows for five global secondary indexes, so if we wanted to support querying by:
- Maker Token
- Taker Token
- Maker Account
- Taker Account
- Exchange Address
- Fee Recipient
We were going to need additional global secondary indexes, and things were going to get complicated quickly.
Additionally, DynamoDB requires our code to specify what indexes to use, and does any additional filtering with a scan. Essentially, it lacks a query optimizer that uses statistics about the distribution of data to choose the most efficient index.
Another downside of using DynamoDB is that the Go drivers for DynamoDB left a lot to be desired. Enough so that we decided that any services interfacing with DynamoDB would be written in Python, to take advantage of the PynamoDB ORM. While we think Python is a great language, and OpenRelay’s Microservices API makes writing different services in different languages pretty trivial, adding a new language to our system was not a decision we took lightly. It has a number of operational implications, and also raises the bar for contributors, who now need another language under their belt to make contributions.
Finally, DynamoDB is an Amazon Service, meaning OpenRelay couldn’t run anywhere other than Amazon. This wasn’t an immediate concern for OpenRelay.xyz, which is indeed hosted in Amazon Web Services, but it certainly wasn’t something we considered a feature.
PostgreSQL solves most of the issues we had with DynamoDB. It gives us as many indexes as we need, it has a query optimizer, it plays nicely with Go, and since it’s open source you can run it anywhere. Amazon Web Services provides managed PostgreSQL via RDS, and advanced scaling via Aurora, so it should be relatively easy to manage for the foreseeable future. For those who want to run OpenRelay outside of Amazon, they can manage their own PostgreSQL server, or use any of a number of other managed PostgreSQL providers.
As the services that interact with the Order Book have been rewritten, we have built the search API to implement the 0x Standard Relayer API. The new spec compliant API will be found at https://api.openrelay.xyz/v0/, while the old version will continue to be available at https://api.openrelay.xyz/v0.0/. The /v0/ API will be served from the PostgreSQL version of the order book, while the /v0.0/ API will continue to be served from DynamoDB. Uploaded orders will be added to both versions of the order book as they are processed.
Despite implementing the Standard Relayer API, we still consider OpenRelay.js to be in preview while we implement some of the remaining APIs and, very importantly, get the documentation ready to go.
Ropsten Testnet Support
As of today, we have support for the Ropsten Testnet. Orders for the Ropsten
testnet can be submitted to https://api.openrelay.xyz/v0/order just like
transactions for mainnet. They are distinguished by the exchange address
specified in the order. Transactions for mainnet should specify the exchange as
0x12459c951127e0c374ff9105dda097662a027093, while transactions for Ropsten
should specify the exchange as
We have orders available to acquire Ropsten ZRX in exchange for Ropsten WETH. We will try to keep the exchange stocked with orders for more Ropsten ZRX, but would ask that you take only what you need so that Ropsten ZRX is available for those who need it.
We have no immediate plans to support Kovan or Rinkeby, but are open to doing so if there is significant interest.
Now that OpenRelay.xyz has stabilized a bit and fully implements the Standard Relayer API, our next focus will be on polishing off OpenRelay.js, and getting a portal site working to submit and explore orders on OpenRelay.xyz. Our portal site will be relatively unique, in that it will focus more on educating users and developers about the 0x Protocol and Tokens in general, rather than trying to build an exchange focused dapp.
A Call for Help
OpenRelay has a small team, and is stretched pretty thin. We would love to get some more community involvement, and invite people who are interested in participating to take a look at our list of open issues. If you’re interested in contributing, we’ll try to make the time to help you get up to speed if you’ll take on some of those listed issues.