FAIRDROP, Airdropping ninja-mined-free self-vote-attenuated toy coins (concepts only).

in HiveDevs4 years ago (edited)

I'm feeling a bit weird writing about an on-hold project. I've prioritized my dev projects and decided to work on only one at a time, and the top of my list is hivequeue, not FAIRDROP.

I am writing this post because in a recent discussion on discord I mentioned the on-hold project, and for the discussion to proceed, I'dd like to make this blog post a place to share some of my ideas, insights and unsolved problems regarding this little pet project.

FAIRDROP is a working title for a little toy hive-engine token project I want to some day run. The name FAIRDROP is meant to be short for Fair Airdrop.

HIVE is the first fork-off of the STEEM blockchain, and in less than two weeks we will see a second fork-off chain from STEEM named BLURT. It seems the main reason for BLURT to exist is the fact that, despite efforts to fork-out illegitimate (ninja-mined) stake, many people believe the way the HIVE fork-out of ninja-mined stake, targeting accounts rather than the stake itself, wasn't exactly impartial or fair.

So what is the idea behind FAIRDROP. The idea had started long before the whole 孙宇晨 incident. I had been playing about a bit with the streaming the STEEM blocks into an ArangoDB database before the whole EIP hardfork was proposed, and had been looking into the possibility of simulating a later genesis block for STEEM. That is, the idea I had been looking at was the idea to:

  1. Find a new appropriate genesis block. I picked block 3141593 (a million times pi) arbitrarily, this likely isn't an appropriate new genesis block. We basically want the oldest block that is young enough to avoid any air of ninja mining from there on.
  2. All STEEM that came to life before block 3141593 is assigned to a virtual non existent account and a delegation evenly in the new virtual genesis block to all then existing accounts.
  3. Keep track of virtual SP.
  4. All transactions are tried and can fail. A transfer with insuficient funds simply fails.
  5. At block 31415927 (10 milion times pi), all virtual delegations end.

The import took long (weeks) and the simulation after that took even longer. Together a number of months, and this was before Steemit INC had decided to rate-limit their JSON-RPC API in the most unprofessional way possible. A subject I won't go into now. I learned a few things, amongst others that replaying with a failure model like this leads to failure and success of transactions that appears quite arbitrary. Two other thing I learned that I didn't know was that the reward curve had changed before (I naively but fairly used the lineair curve in effect at that time), the old curve had made the ninja mined stake even more unfair, and that ninja mined stake had played a huge role in how witness rewards were distributed.

I never got to completing the simulation model for making the witness rewards fair or the transfers of funds less arbitrary.
This did however give me the first set of specs for what I would later want in my FAIRDROP toy project, show how the STEEM/HIVE/BLURT world would have looked if different sources of unfairness could be erased from the blockchains history by re-running that history with a fairer set of rules.

  1. It is essential to pick a proper new genesis block, not to old, not to young, to get rid of all ninja mined stake.
  2. We need a two pass simulation to make transfer of fund simulation less arbitrary, details need to be figured out, but neither a hard fail nor a whatever IS available approach lead to a desirable result.
  3. Forget about SBD, too complicated, ignore it existed.
  4. Witness votes and rewards need special attention. They would have been much different without the ninja mined stake, but hard to moddel with a replay only simulation.

With the graph DB at my disposal, I then ran a number of only sideways related simulations to test a number of other fairness issues. I had found that bid bots, self votes, votes from and between related (self created, etc) accounts, voting circles, etc made up a huge portion of the reward pool distribution. So the next part of the fairness simulation looked at modeling the closeness of accounts over time and used this closeness to adjust the RSHARE values for votes. I defined a relatedness metric between any pair of accounts with a value between 0.0 and 1.0, and tried to use the transitive connectedness to adjust vote RVALUE numbers. Transitive modeling is quite a challenge, so I took some shortcuts there. Some ideas on connectedness influencing events:

  • Transfer of funds (strong, short lived, directional)
  • Votes (weak, short lived, directional)
  • Account creation (strong, bidirectional)
  • Delegation (strong, bidirectional)
  • Voting proxy (strong, bidirectional)

Now when the EIP ideas started gaining traction, stopped playing with my experiments and moved to using my graph db for other simulations. Looking at some what if simulations with the EIP in place. This strategy showed, to me, unfortunately not to the witnesses responsible for voting in the EIP, that the EIP would very likely backfire (as it did, though not in all the ways my simulations predicted).

After the EIP was adopted in a hard fork, I became much less active on STEEM and, now I feel, unfortunately, dropped the database from my then rather constrained storage to make room for other data. Unfortunately, because this means I'll have to re-fetch the whole history of blocks into a graph database when I'm starting up my FAIRDROP toy project. Unfortunate also, because as I was unable to use my database and simulations to show the potential of a fork-out of unfair stake, I'm unable to demonstrate now for the BLURT crew as well.

So for now, FAIRDROP is just a project on my list of future projects, a toy project aimed to show HIVE and BLURT what could have been. The idea is to combine the two simulation scenarios and their lessons learned into a new inclusive what-if simulation and to a hive-engine airdrop based on that simulation. It will be a zero utility hive-engine token, just a proof of concept if you will, and as such I'll be happy with a non-perfect implementation, but maybe one that can inspire future forks and/or airdrops with the possibility of rewriting history in a non arbitrary way free of any politics.