district0x Dev Update - January 21st, 2020

Development progress and product changes from district0x

In our last update, we detailed the progress we’d been making towards constructing and testing our new Infura node in order to host our dapps in a more stable environment, and prevent some of the ongoing issues we’ve seen with hosting multiple dapps on our fragile Parity instance. This was a way to restore Meme Factory to immediate working order, and also pave the way not just for the launch of the District Registry, but also all future apps we plan to launch to our nodes.

Over the course of the past two weeks, however, we’ve hit insurmountable walls in our Infura implementation. To simplify the issue greatly, essentially we were bound by the request restraints that Infura enforces in a way that prevented complete synchronous behavior. We sunk several days trying to refactor our environment to operate with only partially synced data, but ultimately it was impossible without rather drastic revisions to the logic of *all* of our dapps.

We were left with few good options, the most straightforward of which was to look past both Infura and Parity and begin running a Geth node. In the past, back in 2017, we decided as a team to avoid Geth in favor of Parity due to a variety of concerns ranging from compatibility, to ease of use, to projected developer support. Given the problems we detailed above, we thought it high time to re-approach Geth and see if it can offer a solution to these continued woes.

Much of our last two weeks has been spent completing this migration on our extant dapps, with Meme Factory getting the first treatment of our new Geth and websocket implementation. We initially had trouble syncing a full history for our applications, but after closing down some outside requests that were busying it, performance has improved. Alongside this, we’re continuing to leverage Metamask on the client side to pass user transactions along through Infura.

Alongside this, more work has been put directly into the District Registry and Ethlance applications themselves. Ethlance has had its syncer and resolver completed, finally built to the new logic. More work is happening on the front end to get animations and ERC20 payment support the most user-friendly polish possible. We are rapidly approaching the end of the primary development cycle for Ethlance’s relaunch.

The District Registry has faced some setbacks amidst all the turmoil with our nodes however. While testing staking on our mainnet instance of the Registry with real amounts of DNT, we noticed the bonding curves were not always yielding the expected results our intended formulas would predict. Anyone familiar with Bancor’s use of bonding curves knows that while the mathematics behind the curves is quite simple, it requires several workarounds in other languages to implement on the EVM, all of which function to circumvent the lack of floating point operations.

Essentially, this results in a necessary estimation of the curve given a variable input (amount of DNT staked) by the user. The parameters we used to enforce these estimations were not sensitive enough to handle the wide variation in staking/unstaking sizes when we began throwing simulations of all kinds at our live instance, especially for the first few stakes on a district, before the curve can “balance” itself out.

We’ve been approaching a variety of different solutions to this problem, and implementing a few back into our smart contract logic in order to prepare for another mainnet deployment which much more smoothly tracks our intended staking/bonding curves. Several of these fixes are already deployed and are undergoing final testing and revision today. With any luck, we’ll have the District Registry out once the newest instance is confirmed stable and is loaded with data.