Decrease reward from swarm redistribution with distance from pulse origin

in res-currency •  6 years ago  (edited)

With a curve like ratio = 1 − (distance/maximum_propagation_distance)^2,

where distance is in number of people, along a radius from the origin point of the swarm redistribution pulse (horizontally at any given distance people get the same ratio, only decreases with distance), maximum_propagation_distance is how far the pulse travels, an example being maximum_propagation_distance = 10.

The swarm redistribution pulse itself can be separated into segments, and employees can be used similar to miners, who are rewarded with a tiny bit of the universal basic income reward (has to be higher than gas cost, but as low as possible after that based on market price. ) Any miner can choose to process as big a segment as they wish, using uint _iterate, and continue on what others have processed, using _tip (latest node at some point in a pulse), and can pre-compute the pulse off-state to know how many iterations is profitable.

function processSegment(bytes32 _taxID, uint _tip, uint _iterate) {     
    address root = taxRecord[_taxID].tips[_tip].node;
    uint timestamp = taxRecord[_taxID].tips[_tip].timestamp;
    uint rootHuman = taxRecord[_taxID].tips[_tip].rootHuman;
    uint distance = taxRecord[_taxID].distance[rootHuman];
    computeSwarm(root, timestamp, distance, _iterate, _taxID); 
    delete iterateCount;
}


That the swarm redistribution "pulse" can be done in segments is a way to manage GAS costs and potential transaction size limitations (with that, block size limitations on Ethereum are no problem. )

The computeSwarm() function then looks something like this:

function computeSwarm
(
    address _node, 
    uint _timeStamp, 
    uint _distance,
    uint _iterate,
    bytes32 _taxID
)
    internal 
{

for (uint i = 0; i < dividendPathways[_node].length; i++) {

  address node = dividendPathways[_node][i].from;
  uint timeStamp = dividendPathways[_node][i].timeStamp;

  if (timeStamp <= _timeStamp && taxRecord[_taxID].distance[node] == 0) {
    if (verifyPoP[node] == true) {
      _distance++;
      taxRecord[_taxID].distance[node] = _distance;

      // Get values for capping the amount of basic income using auto-regulation from a bell curve
      taxRecord[_taxID].bellcurve.basicincome[node] = basicIncome[node];
      taxRecord[_taxID].bellcurve.total += basicIncome[node];

      if(_distance < 10) {
          uint ratio = 1 − (_distance/10)^2;
          taxRecord[_taxID].ratio[node] = ratio;
          taxRecord[_taxID].sum += ratio;
      }
    }
    if(iterateCount <= _iterate) {
      iterateCount++;
      computeSwarm(node, timeStamp, _distance, _iterate, _taxID);
    }
  }

}
}
Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

"That the swarm redistribution "pulse" can be done in segments is a way to manage GAS costs and potential transaction size limitations (with that, block size limitations on Ethereum are no problem. )"what is the case with bitcoin?I need to get this clear@johan-nyren.

Bitcoin is an older technology, Ethereum was a 2.0 which added smart contracts, an idea from 1997 and Nick Szabo. It had not been possible to develop Nick Szabo's idea before Craig Wright invented mining (proof-of-work) for global consensus, which provided a medium where smart contracts could live. Both Bitcoin and Ethereum are quite outdated at this point, have a look at BitLattice if you are interested in the next generation,
https://steemit.com/informo/@johan-nygren/bitlattice-as-ethereum-2-0-and-how-sharding-required-a-new-state-topology

interesting content you have shared thanks for sharing it ...this will benefit all :)