district0x Dev Update - January 8th, 2019

Development progress and product changes from district0x

The last two weeks of development have been spread across several different lines of work, mediated by the holiday season that afforded our service providers with a much needed break from work. Despite this, we’ve been making progress in our first week of development in 2019, and we’re excited to share where we’re at with all applications currently being worked on.

Meme Factory

In our last update, we relayed the issues we were facing getting Meme Factory deployed to the Ropsten testnet due to an inability to sync through our containerized pipeline. We ultimately had to abandon the containerized environment for now, and doing so allowed us to rapidly work towards deploying a testnet instance of Meme Factory for the various stages of QA needed.

We also refactored large parts of our asynchronous code in the district server smart contracts library, with most server calls of all kinds now being contained in smart contracts. This came coupled with changes to the way we listen to events, and will help us much more simply track the lifecycle of a Meme throughout the entire application. This refactoring did introduce a few new bugs and oddities in meme generation and also generating parameters for the Dank registry, which needed to be addressed before proceeding.

The major parts of development time since then have been spent bug-bashing and ironing out the kinks from several late stage changes we’ve made to architecture. We’ve also made several important first-load optimizations by bundling the way we pull contract ABIs through a JSON bundle. These efforts will continue through the coming weeks until Meme Factory and the DANK faucet are ready to go live.

District Registry

The District Registry has it’s own set of challenges to bear down before completion. Our current design pattern continues to run into issues with contract size limits, and this has required a series of ever-more delicate redesigns in order to minimize these contract sizes.

The current methodology involves taking the stake bank, challenge libraries, and each challenge themselves and taking out of their original contract state and breaking them into their own library where possible, and a separate contract wherever else necessary. This has been coupled with research into the recently developed ERC-1538, which offers a potential solution to the size limit issues that have plagued development thus far.

Ethlance

Ethlance development continues along taking heavy cues from the problems we’re addressing in other applications and using our new solutions to avoid these later in the development cycle. This involves creating a data generator and syncer using core async, and multiplexing all contract events into a single channel. We’ve also made a point to pre-emptively break off any functionality that makes sense as its own contract, where we may have left it whole had it not been for our experience building the District Registry.

With initial drafts of the syncer and generator under review, time was also taken to get Ethlance up and running in our Travis CI instance, and make sure all tests are currently running. There has been quite a bit of work done on the backend of Ethlance up until this point, and though there will be more modifications as we incorporate feedback, future development is likely to turn towards the front end for now.

While progress has been slow going over the holidays, we’ve returned to work with spirits renewed and energies high. The entirety of the development squad is excited to be wrapping several months-long projects to a head and show them off to the public. We can’t wait to see what new obstacles we will clear in 2019!