The beauty of Ethereum to me, can be summed up simply:
By deploying immutable contracts to a shared, public computational surface - contracts whose data can be read deterministically by anyone with access to the internet - we can encode idealism into the way we run society.
What's more, what's different this time, is that the idealism exists independently of the people who encoded it, who inevitably become corrupted, because we are all human. And to be human is to be corruptible, in some very real and simple way.
My idealism arises out of cryptoeconomics, which is not about egalitarianism, but about designing systems with no central point of control. Decentralisation is the goal, egalitarianism is a great success metric. But not the other way around, because egalitarianism is not something for which we can reasonably optimise.
Watch the tech talk for a high-level overview here (now a bit outdated).
Play with a live ObservableHQ notebook here.
Read the contract in this repo.
Look at the evolving designs.
In order to fulfill one of our whitepaper promises, we need a mechanism in the Status DApp Store that uses SNT to curate DApps. While this is not the only mechanism we will make available to users to find interesting and relevant DApps, it is one of the most important, both for SNT utility and because economic mechanisms are at the heart of how we buidl sustainable peer-to-peer networks.
We propose using an exponential bonded curve, which operates only on downvotes, to implement a simple ranking game. It is the most radical market feasible: the more SNT a DApp stakes, the higher it ranks, with one caveat. The more SNT staked, the cheaper it is for the community to move that DApp down the rankings.
Token Curated Registries, and other bonded curve implementations try to incentivise the user with some kind of fungible reward token (often with governance rights/requirements attached to it) in order to decentralise the curation of interesting information. However, this creates mental overhead for users (who must manage multiple tokens, all with different on-chain transactions required) and is unlikely to see high adoption.
Making the ranking algorithm transparent - and giving users an ability to affect it at a small cost to them should they feel very strongly - is potentially a more effective way to achieve decentralised curation.
An effective economic ranking mechanism, selected with the option Ranked by SNT (one of many filters), answers the following user stories from our swarm doc.
balance.upvote and adding SNT to its balance.Designs being worked on here.
+ button on the home screen) is not included either. We need to figure out if any additional metadata is required before we can design that screen.Instantiates the MiniMe (or EIP20) interface so that the contract can receive and send tokens as necessary.
uint total == 3470483788 - total SNT in circulation.uint ceiling - most influential parameter for shape of curves (votes minted per DApp and cost to effect a DApp by some set percent for users). Potentially controlled dynamically by governance mechanism.uint max = (total * ceiling)/10000 - max SNT that any one DApp can stake.address developer - the developer of the DApp, used to send SNT to when downvote or withdraw is called. bytes32 id - a unique identifier for each DApp, potentially with other metadata associated with it, hence the bytes32.uint balance - keep track of the total staked on each DApp.uint rate = 1 - (balance/max) - used to calculate available and v_minted.uint available = balance * rate - amount of SNT staked a developer can earn back. NB: this is equivalent to the cost of all downvotes.uint v_minted = available ** (1/rate) - total downvotes that are "minted".uint v_cast - keep track of the downvotes already cast.uint e_balance = balance - ((v_cast/(1/rate))*(available/v_minted))- the Effective Balance each DApp is actually ranked by in the UI.(bytes32 _id, uint _amount)Accepts some nominal amount of tokens (> 0) and creates a new Data struct with the _id passed to it, setting the new struct's balance and using that to calculate balance, rate, available, v_minted_ and e_balance (which is == balance at first).
Emit event containing new e_balance.
(bytes32 _id, uint _amount)Mock add _amount to balance, calculate mRate, mAvailable, mVMinted, and mEBalance. Subtract this from the actual e_balance and return the difference to be displayed in the UI to show the user what effect their "donation" will have when upvoting.
(bytes32 _id, uint _amount)Transfer SNT directly to the contract, which means donating directly to the DApp's balance, no curve used, no money to the developer. Then recalculate rate, available, v_minted and e_balance.
Emit event containing new e_balance.
(bytes32 _id, uint _percent_down) Specifying the _percent_down allows us to calculate the cost without integrating anything. Calculate the v_required to effect the DApp by the specified % and the return cost for use in the UI.
NOTE: it's likely best to poll this method fairly often from Status and store the approx cost locally for a quicker, smoother UI and then double check that it's correct before the user confirms the transaction.
(bytes32 _id, uint _percent_down) Send SNT from user directly to developer in order to downvote. Call downvoteCost to get balance_down_by, votes_required and cost.
Add v_required to v_cast, recalculate e_balance, and subtract cost from available so that withdraw works correctly.
Emit event containing new e_balance.
(bytes32 _id, uint _amount) Allow developers to reduce thier stake/exit the store provided that _amount <= available. Recalculate balance, rate, available and v_minted. If v_cast > v_minted, then set them equal so the maths is future-proof, and recalculate e_balance.
Emit event containing new e_balance.
(uint _newCeiling)Potentially a simple multisig governance mechanism to change the ceiling dynamically in response to demand? It's not trivial to add though, because you would need to update most of the fields in each Data struct in storage, which could exceed the gas limit if there are large numbers of DApps in the store...
(address _from, uint256 _amount, address _token, bytes _data)Included so that users need only sign one transaction when creating a DApp, upvoting or downvoting. Checks that the token (SNT), sender, and data are correct. Decodes the _data using abiDecodeRegister, checks the amount is correct and figures out which of the three "payable" functions (createDApp, upvote, and downvote) is being called by looking at the signature.
(bytes _data)Helps decode the data passed to receiveApproval using assembly magic.
What metadata we need to identify each DApp uniquely is still a topic for research and discussion. Ideally, we want these contracts to be used for curation in general, not necessarily just for DApps, so it needs to be as general as possible. For now, only an id in Data is included.
Creating many accounts for one DApp is not possible - each DApp is uniquely identified and by its id and ranked only by the amount of SNT staked on it. In the same way, there is no quadratic effect in this set up, so staking for a DApp from lots of different accounts in small amounts has no greater/lesser effect on its ranking than staking 1 large amount from a single account.
Remember, you never get back more SNT than you stake, so this is also economically sub-optimal. In addition, there will be a free "complaint" feature as part of the "downvote" screen. There is an important difference between "contractual" and "social" (i.e. the Status UI) reality. Status reserves the right to remove from our UI any DApp that actively violates our principles, though anyone else is free to fork the software and implement different social/UI rules for the same contractual reality. This protects even further against any incentive to submit bad/damaging DApps.
However, at the beginning of the Store, this is an attack vector: ranking highly requires but a small stake, and this could conceivably result in a successful, cheap hype campaign. The "complain" feature is meant as social protection against this (though it depends on the responsiveness of the Status team, which is not optimal).
You can still never earn back quite as much as you initially staked, enforced by the condition in the withdraw function: require(_amount <= available).
Simply balance - available, i.e. some small amount of SNT not available to be withdrawn.
Yeah, and I'm not sure that playing with the curve will mitigate this. However, another (implemented) solution would be just to lower the second bound in the require to - say 5/100 - i.e. you can only affect a ranking by between 1 and 5% with any given vote. More research needs to be done on exactly what the optimal bound there really is (though I'm not sure how to even define "optimal" for this).
v_cast - things get very expensive.This is a result of how the data and sliders are structured. If you mock a high v_cast, then the graph, trying to show the effect of that on DApps with lower balances naturally spikes for balance < v_cast, which I have tried to exclude as best as possible.
This is a simple economic mechanism that
Moreover, having SNT is not required to see (and benefit from) a well-curated list of DApps; only if you want to effect the rankings on that list do you require tokens, which also makes the UX considerably easier for non-technical users.
From the perspective of DApp Developers - they must still spend some capital to rank well, just as they currently do with SEO and AdWords etc., but they stand to earn most of that back if the community votes on their product/service, and they can withdraw their stake at any time. The algorithm is entirely transparent and they know where they stand and why at all times.
Copyright and related rights for this specification waived via CC0.