Você está na página 1de 23

The IOP

Community System
From the beginning, IOP was a project built on the idea of community participation.
There are people with something to contribute all around the globe. Most of them
might never speak up or be known in the corporate world. We always asked our-
selves how we could reward great ideas without pressuring people into being part
of a corporation. For this reason the system of IOP chapters came into existence.
Every member of the community can create a chapter and present their projects
on our community Discord server, where every member of the community can
cast their vote. Over the next weeks we will start moving the voting process from
Discord onto the IOP blockchain. This document presents our ideas and the mech-
anisms by which we hope to create a reliable system in which everyone can follow
their vision of what a decentralized economy looks like.

Discord Shortcomings
As a non-persistent chat protocol with no sybil attack prevention mechanisms Dis-
cord is not the best platform for hosting a voting system. Votes can be cast without
cost and withdrawn at any time, making voting results unpredictable and easily
forged. Sybil attacks have been mitigated so far by requiring a minimum amount
of participation from new members before they are eligible to vote, but this mech-
anism does not scale to arbitrary community sizes. Furthermore, Discord and any
other chat platform is a centralized system which runs contrary to the ideas of
blockchain and cryptocurrencies. Because of this, the voting system should be
attached to a persistent, decentralized system, i.e. the blockchain. This allows trus-
tless participation for both voters and proposers.
General Overview

In this short summary, we will try to give a brief overview about the processes
involved, both from the perspective of someone who presents a proposal to the
community and someone who simply wants to take part in the voting.

Projects that earn the favor of the community will be rewarded two-fold:
They will directly receive an amount of IOP coins calculated according to the Pare-
to Principle (detailed below).
They will be awarded a license that allows them to mine IOP coins on their own.

Before you start: While reading, you can take a quick look at a very basic mockup
of the app functionality and follow along here:

https://xd.adobe.com/view/8f185bf3-71fd-421a-5b31-d42cd7b7bdcd-f929/

DISCLAIMER
This system is chain-assisted instead of chain-based, to remove the need for a
hard-fork. The calculation of votes and rewards will be done by a special block-
chain client, that will also generate a list of transactions necessary to apply the
calculated results (sending rewards, awarding licenses, etc.)
The source code of this software will be openly available to anyone wishing to ver-
ify the results of the voting and their proper application.

If you have any more ideas for nice features, on-chain or off-chain, please contact
us at info@iop.global. We will enhance the voting app continuously.
User Account

As a user of the voting app, you will have an user account supported by an IOP
mobile wallet behind the scenes. This wallet is used for authentication with the
backend and for funding all transactions related to the voting system. Though it
can in principle be used for payments, only deposit and withdrawal features will be
available to the user in the foreseeable future.
Creating a Proposal
and Reports
When you have a project that you feel will benefit
the IoP community and should be supported, you
can create a proposal. Each user can create as many
proposals as they want, unrelated projects should
be created as independent proposals. We want to
facilitate networking and small task-forces that fo-
cus on the issue at hand, then reorganize and form
new structures, always combining their strengths.

For the initial creation of a proposal, you must pres-


ent a title and a short description. All in-depth pre-
sentation is deferred to your first report. To disin-
centivize spam, a fee of the order of 500 IOP needs
to be burned after creating a proposal to lock it
onto the blockchain1. A proposal that is not locked
on to the chain will eventually be deleted from the
system and cannot receive votes. The information
about the proposal cannot be changed after lock-
ing it onto the chain.

After your proposal has been locked onto the chain,


you can create your first report. Like a proposal, the
report is locked to the chain using a transaction. Re-
ports are free2, but are always bound to their pro-
posal and you can only create one report per vot-
ing period. The contents of a report can also not be
altered after locking them to the chain. We will limit
the contents of a report to Markdown-style format-
ted text in the beginning, while we aim to allow im-
age upload in the future. Please be aware that we
will not be able to completely prevent users from
including URLs in the report texts, but all content
not presented directly inside the voting app is open
to manipulation by its respective creator, even after
voting is completed. This fact will be made explicit
to the user whenever applicable.
1
This fee will be adjusted in relation to the purchasing power
of the IOP currency.
2
Excluding transaction fees.
Creating a Proposal
and Report
Together with the contents of your first report, you will need to supply an address
that you want to use for mining if you are awarded a license in the next voting
phase. You will receive the voting rewards on an address automatically generated
by your voting app.

Each round of the voting system will run for exactly one month. During this period,
reports can be uploaded and votes can be cast simultaneously. Presenting your
report at the beginning of a voting phase will allow your report to be seen more of-
ten, but if you have important events you want to present in your report, you may
choose to upload it at a later point. The report deadline and the voting deadline
coincide, so uploading your report close to the deadline will most probably entail
a voting balance of zero.

Because voting involves burning IOP, voters need to be incentivized for taking part
in the voting. For this, we will introduce a mechanism we call voter payback. If the
creator of a report chooses to offer a certain percentage of voter payback and
wins IOP at the end of a voting round, the given percentage will automatically be
distributed among all positive votes on payout.

Of course, we will allow for comments on reports


(and on proposals), to allow for lively discussion,
but again, this content is not stored on chain, so
must be taken with care.
Voting for
a Report
To cast a vote, you will need to deposit a few IOP into your voting app.

As a user you will be presented with a list of proposals that have already uploaded
a report in the current voting round. In the future you will be able to rank the re-
ports by Vote Balance, Trending, Date, and so forth.
Voting for
a Report
When you open a proposal you will be presented with a short description and a list
of the reports for this proposal, including the results for completed voting periods.

When you open a report, you will see a voting balance, which describes how many
votes the current report has received. If you choose to vote, you will be presented
with an amount field. 1 IOP satoshi equals 1 vote. However, because there is always
a fee involved in sending a transaction, voting in the order of 1000 IOP satoshi or
more is encouraged.
Voting for
a Report
The amount you choose to spend will be burned in
a voting transaction. You have the option to upvote
or to downvote. If you choose to downvote, the
amount you enter will decrease the voting balance
of the given report. All votes will be pseudonymous
(the level of anonymity every blockchain like bitcoin
provides). The voting transactions are visible on
chain, but the relation of addresses to accounts is
not publicly known.

At the end of each voting round, all proposals


that have locked a report to the chain will be or-
dered by their voting balance. All reports that have
positive voting balance (possibly limited by rank)
will receive voting rewards (~14000 IOP in total
per month) according to the Pareto distribution
presented below, minus the amount promised to
the voters. This voter payback will be distribut-
ed among all upvoters according to their voting
weight. Downvotes will receive no compensation. It
is thus possible for voters to “win” more coins than
they spent voting. Also, it is far more expensive to
“fight” by downvoting instead of “cooperating” by
upvoting.

All reports that rank 31 or better will also receive a


mining license until the next voting phase ends.
Pareto Principle

The distribution of rewards will follow the pareto principle, a principle found in all
of nature, governing the population size of cities or animal colonies, the yield of
crop and of course income distribution. This principle is also known as the 80/20
law, where you get 80 percent of the work done with 20 percent of the effort or
where 20 percent of the population gain 80 percent of the income. Furthermore,
you get 80% of these 80% (64%) done with 20% of those 20% (4%) and so forth.
Our distribution will be a bit softer on everyone, distributing 75% of the reward to
the best 25% of chapters et cetera.

The pareto distribution is described by f(x) = k * xmin / x ^ ( k - 1 ), leading to the


following mathematical formula for the amount gained of the top x percent of the
chapters:

a(x) = ( 1 - x ) ^ ( ( k - 1 ) / k )
with k = ln( 1 - 0.75 ) / ( ln( 1 - 0.75 ) - ln( 0.75 ) )

Distributed over the 31 chapters of the new system, the rewards will then be as
follows:

If some ranks remain vacant at the end of a voting round, the respective coins will
be burned. If two or more reports reach exactly the same voting balance (highly
unlikely), the rewards will be averaged.
Effects of
Burning Coins
Burning coins decreases the maximum supply and has a deflationary effect. Any
decrease in supply makes a resource more scarce. Given that demand for the re-
source is constant, economic theory suggests an increase in market value of the
resource in question.

Users of the voting app, however, do not strictly lose coins by burning. Instead,
they have the chance to be disproportionately rewarded and are thus incentivized
to engage in the system.

Our new block explorer will be able to represent the total and maximum supply
accurately.
Technical Details

These paragraphs are meant for people who want to gain a deeper understanding
about how the app actually achieves security using the blockchain.

In the diagram below you will see use cases for the user of the voting app and the
voting backend itself. Each use will be described in-depth.
Submitting
a Proposal
The user creates a proposal using the app interface. When he is done, the app
forwards all the data inside of the proposal to the voting backend, which verifies
the proposal data. It adds a timestamp and some hashing salt to the data. After the
backend has calculated the hash, it returns the hash, together with the timestamp
and the salt to the voting app, which in turn verifies that the data in the proposal
combines with the timestamp and salt hash to the given value. This mechanism
makes it infeasible for a user to engineer the hash of a proposal and makes sure
that two identical proposals at different times hash to different values.

The Voting app then creates a proofing tx, in which he sends the price of a propos-
al (TBD) to a script of the form (subject to change)
OP_RETURN MSG_TYPE_PROPOSAL FEED_X_BYTES PROPOSAL_HASH

The sent IOP are unrecoverable and thus burned.


This transaction is sent into the IOP network, where it will be written to the chain in
the near future. It is the responsibility of the voting app (or the user) to verify that
the transaction has reached the network.
Submitting
a Report
The user creates a report using the app interface. When he is done, the app for-
wards all the data inside of the report to the voting backend, which verifies the
report data, including but not limited to making sure that the referenced proposal
exists and is already proofed on the chain. The backend then adds a timestamp
and some hashing salt to the data.

After the backend has calculated the hash, it returns the hash, together with the
timestamp and the salt to the voting app, which in turn verifies that the data in the
report combines with the timestamp and salt hash to the given value. This mecha-
nism makes it infeasible for a user to engineer the hash of a report and makes sure
that two identical reports at different times hash to different values.

The Voting app then creates a proofing tx, sending a bit of IOP to itself, with an
additional txout, which has a value of 0 and a script of the form (subject to change)
OP_RETURN MSG_TYPE_REPORT FEED_X_BYTES REPORT_HASH

The IOP spent are available for use again shortly after sending the transaction. A
separate change address might be dedicated to the purpose of report locking.

This transaction is sent into the IOP network, where it will be written to the chain in
the near future. It is the responsibility of the voting app (or the user) to verify that
the transaction has reached the network.
Voting on
a Report
When a user decides to vote on a report, the app creates a transaction sending
the IOP amount (voting weight) chosen by the user to a script of the following form
(subject to change)
OP_RETURN MSG_TYPE_VOTE IS_NEGATIVE FEED_X_BYTES REPORT_HASH

The sent IOP are unrecoverable and thus burned.


This transaction is sent into the IOP network, where it will be written to the chain in
the near future. It is the responsibility of the voting app (or the user) to verify that
the transaction has reached the network.
Commenting &
Viewing Results
Creating a comment
When a user creates a comment, it is forwarded by the voting app to the backend,
which verifies the comment, including but not limited to ensuring that the refer-
enced report or proposal exists. The comment is then inserted into the database.

Viewing Results
When a user wants to view results, the app forwards a corresponding request (e.g.
organized by proposal ID or by round number) to the backend which retrieves the
reports in question from the database and returns them to the app, which presents
them to the user.
Processing
the Blockchain
The voting backend monitors the blockchain for new blocks. It retrieves from the
DB all txids that stem from pending results (payments and license transactions).
For every new block the transactions are compared and handled in one of 4 ways:

If the txid matches a pending result, the corresponding result is updated with the
txid and blocktime. (this can be either a payment or a license txns)

If we see a tx to OP_RETURN MSG_TYPE_PROPOSAL and can successfully parse it


to a proposal inside the DB, we update the proposal with txid and blocktime

If we see a tx to OP_RETURN MSG_TYPE_REPORT and can successfully parse it to


a report inside the DB, we update the report with txid and blocktime

If we see a tx to OP_RETURN MSG_TYPE_VOTE and can successfully parse it to a


report inside the DB, we insert a vote with the txid and blocktime into the DB.

If we receive information about a rollback of the chain, we revert the above actions,
setting txid and blocktime to NULL if applicable or deleting a vote from the DB.
Processing
The Blockchain
Calculating Results

Once a report window closes (00:00:01 UTC at the first of every month), we select
from the database all reports that have a blocktime inside the last window and sort
the reports by voting balance. For each report we then create a result including the
rank and the voting balance of the report.

Reports with a positive voting balance and ranked inside the limit (currently 31)
will receive a license for mining during the next report window and the rewards
calculated using the pareto distribution. Reports with negative voting balance will
be considered as vacant ranks and will receive no reward. Rewards intended for
vacant ranks will be awarded to OP_RETURN instead (and thus burned).

The calculated result data will be inserted into the database. In principle it should
be feasible to create the result at the same time as the report and update voting
balance and rank with every block processed.
Preparing Licensing
Transactions
The backend queries from the DB a list of all results for a given round.

For each result, we query the corresponding license address from the DB, and the
current status of the license from the IOP Blockchain.

If the address is not whitelisted, but won a license, add the address to the “addlist”,
If the address is whitelisted, but did not win a license, add the address to the “re-
movelist”

After all results have been processed, compile two transactions, one for removing
licenses, one for adding licenses. Store the contents of these to the DB. In v1, this
will just be a list of addresses to add and to remove. Transactions will be sent man-
ually. In v2, we will automate this process.
Preparing Payment
Transactions
The backend queries from the DB a list of all results for a given round.

For each result, we query the corresponding reward address and all votes for the
corresponding report from the DB.

The amountAwarded is distributed among the owner of the report and its voters
according to the voterPayback percentage and each voters voting weight (only
positive votes are considered)

This data is compiled into a tx and stored in the DB. In v1, this will just be a list of
addresses and amount. Transactions will be sent manually. In v2, we will automate
this process.
Send Transactions

After preparing the transactions they will be sent out by our voting backend asyn-
chronously.
Database Model

We created a database model for the Voting-Backend. This database is made ac-
cessible via a JSON API interface for the app. Below you will see the tables and
their relations. This schema is also available as SQL file.