Editing Permissioned resource coins (section)

== Permissioned resource coins ==

After thinking about some of these problems I believe there is room for a new kind of resource coin based on permissions instead of open markets. The idea behind a permissioned resource coin is that instead of listing resource contracts on an open market, you would alternatively program the coin to decide the conditions for who can sell storage space for coins.

<span id="generating-an-initial-white-list"></span>
=== Generating an initial white list ===

To setup the resource coin, one must generate an initial list of hosts who will provide storage space on the network. These hosts, called “farmers” will consist of individuals who have verified identities via Civic and who have deposited a certain amount of resource coins to use as collateral.

This helps to prevent wealthy people from compromising the system and improves decentralization, but any other algorithm can also be used [insert your favorite proof-of-stake algorithm here] to generate the initial list.

<pre>bonds = {}
farmers = [
    {&quot;pub&quot;: &quot;alice&quot;, &quot;gb&quot;: 10},
    {&quot;pub&quot;: &quot;bob&quot;, &quot;gb&quot;: 10},
    {&quot;pub&quot;: &quot;eve&quot;, &quot;gb&quot;: 10}, 
    {&quot;pub&quot;: &quot;malory&quot;, &quot;gb&quot;: 10}
]

# Todo: allocate this to a pending pool and
# when pool is large enough -- shuffle it randomly
# before adding to farmers to prevent Google attacks
def add_new_farmer(pub, gb):
    if bonds[pub] &lt; 100:
        return

    info = {
        &quot;pub&quot;: pub,
        &quot;gb&quot;: gb
    }
    
    farmers.append(info)</pre>
The registration algorithm can be as simple or as complex as needed. Here, the code is checking to see that a new farmer has made a large enough collateral deposit to impose higher costs on Sybil attacks. A more complicated function would allow farmers to increase the amount of storage space they can advertise based on reputation and other factors.

<span id="allocating-storage-space"></span>
=== Allocating storage space ===

Consider a simple example with four parties, each with 10 GB of storage space. To buy storage space in this system, a person must purchase resource coins and make a request to the coin for storage space. The coin would then use available storage space in the order defined in the farmer set, and reserve payments between them.

<pre>price_per_gb = 0.01
swarms = {}
pending = {}
balances = {
    &quot;client&quot;: 100
}

# Unbound for loops don't work well on blockchains.
# This will need to be optimised.
def allocate_storage(gb_amount, client, id):
    id = random()
    swarm = []
    for farmer in farmers:
        # How much space can we get from this farmer?
        if farmer[&quot;gb&quot;] &gt; gb_amount:
            change = gb_amount
        else:
            change = farmer[&quot;gb&quot;]
            
        # Check the client has enough to buy this.
        total_cost = change * price_per_gb
        if balances[client] &lt; total_cost:
            break
            
        # Don't continue if there was no change.
        # We're done here.
        if not change:
            break        
        
        # Apply changes.
        farmer[&quot;gb&quot;] -= change
        gb_amount -= change
        balances[client] -= total_cost
        pending[id][farmer] += total_cost
        
        # Record farmer in this resource set.
        swarm.append(farmer)
            
    swarms[id] = swarm</pre>
What I have described above is a simple proof-of-stake system. It is a system that awards storage based on the order in which people join. In a real system, there are other variations that could be used. For example, you could program the allocate_storage function to distribute 75% of the storage space based on join order and the remaining 25% randomly.

<span id="paying-for-storage-space"></span>
=== Paying for storage space ===

In our sample coin pseudo-code I introduced an algorithm for allocating storage space, but what is missing from this is a protocol for the clients to use for making payments. In practice, all existing storage-based resource coins start by proving custody of a large amount of data.

The way they do this is to generate a large random number to use as a challenge and then prepend it to a piece of content to hash for an answer. To prove that a host still has the content they must be able to reproduce the same answer hash after given the random number.

While this challenge-response game works well for large amounts of content, for smaller pieces of content it is over-kill. What would be interesting is a storage system for smaller pieces of information such as those produced by sensors and other IoT devices.

Because the data is small, my protocol for this is to randomly sample data and check what farmers still have. The client would sign data under the same pub key and record an ID to identify it. That way they only have to maintain an index of metadata to verify bulk data sent over a unique period.

If you wanted to, you could also set a percentage ratio here to adjust how vital the data is to make it more like UDP. It might be okay if you lose one or two sensor readings along the way but not if you lose all of them!

<pre>audits = []
priv_key = &quot;private&quot;
pub_key = &quot;pub&quot;
swarm = coin.allocate_storage(20, pub_key)

def random_audit(swarm, pub_key):
    # An hour ago.
    start_time = time() - (60 * 60)
    end_time = start_time + ((60 + 60) * 2)
    
    # Get a list of data signatures for all data sent over the last
    # hour or so. Yes, I'm getting lazy here.
    offset = audits.get_offset_closet_to_start_time(start_time)
    challenges = []
    while 1:
        audit = audits[offset]
        if audit[&quot;timestamp&quot;] &gt; end_time:
            break
            
        challenges.append(audit)
        
    # Audit swarm nodes for data pieces.
    for farmer in swarm:
        responses = farmer.retrieve(start_time, end_time)
        if len(responses) &lt; len(challenges) * 0.8:
            farmer.micro_payment = &quot;break&quot;
        else:
            total_correct = 0
            for response in responses:
                if response not in challenges:
                    continue
                
                if not valid_sig(response, pub_key):
                    continue
                    
            if total_correct &lt;= len(challenges) * 0.8:
                farmer.micro_payment = &quot;break&quot;
    
def store_content(content, priv_key, swarm):
    for farmer in swarm:
        # Skip this farmer.
        if farmer.micro_payment == &quot;broken&quot;:
            continue
    
        # Sign the data chunk
        nonce = random()
        sig = sign(chunk, nonce, priv_key)
        
        # Pay the farmer for this 
        farmer.store(chunk, sig)
        
        # Record meta data
        timestamp = time()
        audits.append({&quot;timestamp&quot;: timestamp, &quot;nonce&quot;: nonce, &quot;sig&quot;: sig})</pre>
The payment protocol then follows a basic micropayment channel: if a farmer fails an audit, the client closes their channel. Likewise, if a client fails to make payment, the farmer drops storing data for that client. Either side can close the channel at any time to unlock their pending balances (storage space or reserved payment in micropayment channels.)

<span id="optimising-data-usage"></span>
=== Optimising data usage ===

To avoid having many transactions for every storage request, it is recommended that storage be reserved in bulk. To help prevent malicious clients from reserving large amounts of storage space - the coin can optimize its code to distribute smaller amounts of space between farmers in the defined order or limit the amount based on a users reputation.

It is possible to optimise payment channels and storage requests too. Instead of multiple payment channels to individual farmers, payments can be made to a swarm identifier, where settlement would allocate the payments between farmers in a given swarm. Replication is slightly tricky though and more thought needs to be put into how to do this efficiently.

<span id="adjusting-for-price-fluctuations"></span>
=== Adjusting for price fluctuations ===

By allocating storage space between farmers in a programmable resource coin, it solves the supply problem. But that is still only half of the solution. What good is it to control the supply if you still have a coin whose value fluctuates in price for storage space? A complete solution would therefore need to use a USD-peg… here’s how that might work:

# An oracle signs a USD quote for 1 resource coins every N blocks.
# A payment channel is initialized using the most recent quote as reference.
# Every update to the micropayment channel must use the most recent quote, if it falls behind the payment channel must be closed.

The way to accomplish this is to use bidirectional micropayment channels. What will happen is the amount sent in channels will be adjusted based on fluctuations to the USD quote price, to maintain a stable USD ratio for storage space cost. Thus, the debt that a side owes may be increased or decreased based on changes to the price of the underlying coin.

<span id="supply-need-not-equal-demand"></span>
=== Supply need not equal demand ===

Currently, all of our farmers have to keep their infrastructure online the entire time even when there’s no one using their services; Infrastructure needs electricity to run, and electricity costs money. A more efficient algorithm would be to periodically calculate a set of farmers who should keep their equipment online to meet future demand.

Instead of distributing contracts to farmers in order, we might instead use an algorithm to keep track of the current demand for storage space and double our expected supply. Supply would then come from farmers in order, but it would be allocated randomly in allocate_storage. Farmers who are chosen would then have an incentive to stay online which should also create enough leeway to meet any future surges in demand.

Thus, the full algorithm would resemble difficulty adjustments made in a regular blockchain. A small tweak is to have auctions, but only between farmers who were chosen for a given period. That way, there would still be some price competition, but not enough to drive prices into the ground.

<span id="fixing-the-price-of-storage-space"></span>
=== Fixing the price of storage space ===

One interesting possibility for a permissioned resource coin is to simulate the operations of a normal business on top of a completely decentralized structure. Currently, market-based resource coins cannot do this because every participant in the market independently acts in their own best interests instead of with respect to the needs of the whole.

A permissioned resource coin could be run by a group of shareholders who make decisions on how to set prices. The effect is a structure that much more closely resembles how businesses are run in the real world. That is - it is far easier to control and align incentives when this is built directly into the currency than with relying on an unpredictable market to organise itself.

<span id="stagnant-farmers-quitting"></span>
=== Stagnant farmers quitting ===

Overtime, it is likely that people are going to stop being farmers leading to offline farmers being allocated the right to store content. If too many of these farmers fill up the supply pool the service will become unusable.

To prevent this: if a farmer doesn’t commit a heat beat every so often it be removed from the supply set in the future. Obviously this doesn’t stop malicious nodes from trying to pull off DDoS attacks but the allocated swarm should be structured around trying to prevent this as much as possible.

E.g. a hybrid approach that consists of storage allocated from a set of authoritative nodes + storage from a set of sequential farmers + a randomly allocated set from the total supply could be more secure than storing everything on one type of farmer - with or without redundancy.

<span id="private-permissioned-resource-coins"></span>
=== Private permissioned resource coins ===

Potentially an organisation could have an access list in place for users making payments to farmers on the network. This would give the public the ability to contribute resources towards creating a decentralised storage system while ensuring that only certain users can store content.

In the future, this may be a better way to do an ICO as the organisation building software that runs on a permissioned resource coin would have to depend on its users for operation. [http://roberts.pm/survivability This is in contrast] to existing coins that have no other purpose than to serve [http://roberts.pm/ico_crapcoin_checklist as economic hacks] to raise money and keep value artificially locked in an ecosystem.

<span id="how-does-this-compare-to-existing-systems"></span>