As we prepare for the launch of Discover, our new way of showcasing the vibrant DApp ecosystem developing on Ethereum, we thought we’d let you in on some of the ongoing technical developments behind it’s slick new interface.
Discover is designed to introduce SNT based curation in a way that removes the centralized curation methods in App Stores today. Through the use of the Status Network Token, DApp developers and end users alike will be able to partake in an economic curation mechanism to list, downvote, upvote, and browse an up to date list of DApps.
- Deliver SNT based curation mechanisms in accordance with the white paper
- Build Discover as a web DApp and design it in such a way that enables users to navigate the store easily, discover new DApps, and have an up-to-date list of DApps that are currently popular/being used
- Write the smart contracts that will control the economic mechanism in as general a way as possible so that they can be used for the curation of any arbitrary data type, (i.e. a DApp, a sticker pack, or anything else which we might want to open up to community curation, rather than Status centralization)
Latest V1 Design: https://dap.ps/
Current Status: V1 Design complete and avialable in next release
Team: Andy, Ricardo, Andrei, Julien
Status Channel: #317-dapps-store
In order to ensure that we do not need to include any DApps in the native code that Status ships through either the App or the Play Stores, we have developed Discover as a standalone React web app. Development of the voting screens and components, the ability for anyone to submit a DApp, and the full Desktop screens is going on in this repo, so please join us if you have a passion for React and want to build the future of curating information on web3.
The designs we are working off are looking genuinely awesome. And, as you can tell from all the links, the entire project from start to finish is open source.
We’ve known for some time what shape we wanted the Discover curve to have, showcased with live code in this Observable Notebook.
However, the majority of our research time has been spent on figuring out how to do exact mathematical calculations involving exponents using Ethereum. We know that we have one simple condition to meet: the more SNT that is staked, the more votes need to be minted, so that each vote is cheaper for a given user to buy.
We achieve this simply, by thinking of the whole thing as a boundary value problem:
- take some percentage of the total SNT in circulation (our unique and useful boundary) and set it as the absolute maximum any one DApp can stake, i.e. the ceiling.
- set the rate votes will be minted at to some number between 0 and 1, which we do by taking what is staked, dividing by the maximum ceiling, and subtracting from 1.
- multiply what was staked by the rate to get how much SNT is available to be withdrawn. Importantly, the amount available is also exactly equal to the total cost of all downvotes.
- take the amount SNT available to vote with and put it to the exponent of (1 / rate). Because 0 < rate < 1, this always gives us an exponent bigger than 1.
- So, we get our exponential relationship, and because everything except the ceiling can be expressed in terms of something else, it is only the ceiling - the percentage of SNT in circulation we choose as the max - that really affects the shape of the curve. This makes things significantly easier to reason about.
In the above setup, the decimal value of the exponent really matters. However, doing exact arithmetic calculations on the EVM (normally called “floating point”) is really hard. Solidity especially only supports ints or uints, which makes exact exponential calculations hard to get right.
Luckily though, the fantastic people at Bancor have faced and conquered such challenges before in their own work, and so have just the kind of contract we’re looking for: one capable of handling exact power calculations using a mixture of Taylor and Maclaurin series approximations and iterations. It’s really impressive stuff.
What’s even more impressive though, is their test suites. Seriously, these tests make us want to be a better people. We mean that literally.
So, we have implemented the part of the BancorFormula contract that has to do with handling exact power calculations, and adapted their awesome tests to work with Embark. There are also a bunch of tests now written for the Discover contract itself, and it has passed the latest and greatest static analysis tools, so it’s time to get it audited. Thanks TrailofBits!
All The Rest
We’ve also done a bunch of work with the wonderful people from LimeChain on a Vyper contract. There are still some issues that we face there, but if we are able to solve them, then we could put the contracts side-by-side and choose the most optimal one in terms of gas use, and look at whether we could get more accuracy than the BancorFormula provides using Vyper.
There’s also the macroeconomics to figure out. Having solved some technical limitations, what sort of ceiling is it actually reasonable to choose?
We’ve run some informal twitter polls and Discuss surveys as a tentative means of trying to figure out what the best ceiling to choose is. Given the responses, we think that it’s unlikely people would be willing to spend more than 1M SNT to ever rank a DApp, and so have set the curves up so that the incentives to stake more than 1M are doubly stacked against you: you stand to earn less and less back, and it’s becoming increasingly cheap for the community to downvote you.
You can read the full contract specification here, which details both the exact shape of the contract, as well as some potential attacks we’ve taken into consideration in its design and research phase.
We look forward to offering a leap forward in the decentralized curation of relevant information in ways which benefits both builders, and the communities of which they are inextricably a part.