If you’re not aware of the xDai blockchain, it’s a pretty cool concept. Users take DAI tokens from MakerDAO and lock them into a contract on the Ethereum blockchain. After a few blocks confirmations, that DAI becomes available to you on the xDai blockchain. From a contract developer’s perspective, the xDai blockchain is pretty much like the Ethereum blockchain. It runs the EVM, so contracts can be lifted and shifted to xDai. But instead of paying for gas with ETH, xDai transactions pay for gas with DAI. Instead of having to keep a volatile asset around for fees, you can just keep the relatively stable DAI. xDai is also a proof-of-stake chain, so no costly proof-of-work, and it can achieve lower block times pretty reliably. Lower block times mean cheaper transactions.

So with lower block times, cheaper transactions, and a stable underlying currency, it’s no wonder that many developers are moving projects to xDai as Ethereum’s gas prices soar. Many of these developers looking to move their projects to xDai use Rivet for connecting to Ethereum, so they turn to us wanting to know if we can support their application on xDai.

The answer, for now, is “not yet.”

The Problem With Supporting xDai

The problem with supporting xDai is that there is no Ethereum client with maintainers who even claim it to be production ready that supports xDai. Really.

The latest hard fork of xDai has dependencies that were adopted into Parity v2.7.2 — the last release of the Parity client. After that, Parity Technologies handed over the reins of the Parity Ethereum Client to OpenEthereum, and the name was changed. The OpenEthereum team made their v3.0.0 release based on v2.7.2. But some time later, the OpenEthereum developers said that v2.7.2 was not production ready, and said that basing v3.0.0 off of that version had been a mistake. At this time, they recommend using Parity v2.5.13 for stability. But remember that xDai has dependencies that weren’t introduced until v2.7.2, so v2.5.13 is not an option for running xDai today. Then, in September, OpenEthereum’s development lead stepped down, leaving questions around the future maintenance of the project.

Even before the latest string of support issues with OpenEthereum, our team has always had concerns about Parity’s production readiness standards. Users have lost millions of dollars in assets to hacked Parity Multisig wallets. They’ve caused chainsplits on Ethereum testnets prior to hard forks on at least two different occasions; before Constantinople due to poor adherence to the spec, and before Istanbul by releasing their hardfork support just before the Ropsten testnet was due to fork. With the Istanbul hardfork, they announced an emergency patch the day after the fork was supposed to go live on mainnet, but we were spared the pain of a chainsplit by the fact high block times pushed the fork back by a couple of days. More recently, OpenEthereum’s incomplete chain reorg support has caused chain splits on both Ethereum Classic and the Ropsten testnet during 51% attacks.

The Rivet teams prides ourselves on providing a high quality of service. We also have a pretty small team, and if we’re to have any hope of moving forward with general feature development, we have to have operationally stable services. If we’re trying to run chains on unstable Ethereum clients, our time evaporates into keeping the service up and feature development grinds to a halt. Even on a good day Parity never met our standards for production readiness; in its current dismal state there’s simply no way we can consider supporting xDai.

The issues with xDai client support tie into a point our team has been discussing at length lately; that DeFi needs to be extremely well prepared when mass adoption finally arrives. With many serious DeFi projects choosing to build dependencies on xDai, it’s extremely concerning to think they’re building dependencies on networks that have no production ready client available.

We could follow in the footsteps of YAM; launch a product based on some code we know isn’t really production ready with a big disclaimer not to rely on it for anything important. Then people would summarily ignore our big disclaimer, rely on it for something really important, and we would watch as lots of people get burned when our product does something completely wrong because it relied on software that we knew wasn’t production ready. That’s not our bag.

So… When’s Rivet Going to Support xDai?

Despite these issues, we actually have a plan for supporting xDai.

Rivet is based on a streaming replication architecture. We have a fork of Geth where we run “master nodes” that connect to the peer-to-peer network, participate in the network, validate data we get from peers, and as the masters write everything out to disk they send a copy off to our replica nodes. The replica servers are exact copies of the masters; they can answer all the same queries quickly, without the overhead of peer-to-peer connectivity.

Our current streaming replication architecture is based on low level change data capture. We capture the exact database disk writes, so our replication stream is only useful to a client that expects exactly the same database schema. Because both our masters and replicas are based on Geth, and Geth is nowhere close to supporting xDai, we can’t use our streaming replication system in its current form to support xDai.

But we’re working on a solution. We’re building a change-data-capture system that works at a higher level. Rather than copying low-level database entries, we’re starting to capture higher level information about the blockchain and the changes to it. This will allow us to pull xDai data from Parity or OpenEthereum nodes and stream the changes into the same production-ready replicas we use to support the Ethereum mainnet and its testnets. Our OpenEthereum master nodes may be less reliable than our Geth master nodes, but our streaming replication systems already allows for redundancy at that level, allowing us to handle master failures gracefully. xDai’s EVM and state trie implementations are functionally identical to the Ethereum mainnet’s, so our replicas should be able to support them with no problem. We’ll have to build in some special cases to deal with xDai’s different block headers, but that’s not a show stopper.

We’re moving towards this future as quickly as we can while still ensuring quality. Aside from enabling us to support xDai, it opens up a bunch of other possibilities that I’ll delve into in another post. While I’d like to be able to say we’re launching xDai support soon, the reality is that it will likely be a few months before we’re ready to even call it a beta.