[ ] Logic and flows verified, potential edge cases identified
[ ] Economic system reviewed, incentives and dis-incentives explored
[ ] Computing efficiency and contract/back-end/front-end design streamlined
[ ] Vulnerabilities considered
[ ] Identify potential contract vulnerabilities
[ ] Consider economic and game theoretical vulnerabilities
[ ] Explore Sybil and DDOS vulnerability
[ ] Describe mitigation techniques
Background:
Base operation:
The smart contract is used as an event source for the music encyclopedia database. The database should be able to be reconstructed by replaying each blockchain action, including additions, deletions, and edits, in sequence.
The contract will create a token, maybe called POL or PLR or POLR. In the future, we hope to expand the scope to include another token, to be used to reward artists based on their representation on the graph. However, this is not part of the current scope and is mentioned only to share the north star of the project.
Upon signup, the user stakes a number of EOS sufficient to cover their resource usage.
This contract will allow any person to stake a number of tokens (either native POL or EOS/USDT/?) and then publish a proposed addition to the Polaris Music Encyclopedia. The submission will then enter the queue that waits for other users to stake their own tokens to verify the submission as good or bad data. Each subsequent submission by the user will result in an increase in the required stake.
Bad data is punished by having the submission user's stake slashed, as are verifiers who vote against the consensus result. Original stake and a portion of slashed funds are returned to those verifiers who reached consensus.
Good data is rewarded with the minting of new tokens to be shared between the submitter and the verifiers. Potentially 70% to submitter, 20% to verifiers, and 10% to the team.
Each subsequent token reward diminishes the amount of the next reward, such that if this reward is "R" and the number of previous transactions is "t", R = log(t) / t .
This formula is based on Metcalfe's law of network growth (n)(log(n)) combined with the inverse square law 1/n^2.
Front-end interaction:
Front end consists of a graph visualization displaying nodes and edges representing the relationships between musical artists, as well as a text sidebar that displays information about the selected node. It also includes a submission form for adding new data.
Upon submission, the front end provides a JSON structure, which will be packaged into a transaction and sent to the chain. The JSON structure will be of arbitrary length, but If a maximum is requred, >2000 characters will likely be needed.
The Front end will track the path a user is taking through the graph visualization, and if they find an node they "like", the "like" transaction publishes the path taken by the user to get to the artist they just "like"d. This data can be scrapped if the user "un-like"s the node
Users can stake their tokens to a node (such as an artist, album, or group) if they want others to see that node. This is accomplished as follows:
When a user first visits the site in a given session, the data visualization does not have an existing central point to start at, which it needs in order to function.
The current "central point" is stored on the blockchain.
Each time the contract executes a transaction, the central point changes
The central point is selected by weighting each node by the number of tokens staked to it, and then randomly selecting by lottery based on the nodes' token stake weight.
The blockchain will only be aware of node IDs that have token stake weight attached to them. The contract will not need awareness of the graph, as each stake transaction includes the node ID.
This presents potential edge cases of manually submitting nonexistent node IDs to the contract,
as well staking to a Node ID that is then removed,
as well as the case where nobody has staked tokens to any Node IDs.
The front end will also allow users to upvote/downvote data. They must include a stake for this verification transaction.
Users should be able to edit data that is already there. This will be done with the same event sourcing method as adding data.
(optional) Users should be able to comment, as well as like/dislike a comment, on a piece of data within a node or edge. If this is feasible to keep in the smart contract, it should be.
(optional) If feasible, the smart contract should keep track when a song is played, or when the "play" button is pressed on a song. Alternately, some setup that keeps track of every 5 seconds or so of music playback could be implemented, to replicate the approach taken by Emanate.
State Needs
The contract must keep the following in its global state:
TransactionCounter
TokenEmissionFormula
CurrentCentralNode
The contract must keep the following data in state for each account:
Accounts & Token values
24hr transaction counter (require a stake of more tokens on each subsequent transaction, transaction counter decays over 24 hours)
number of up and down votes on data supplied by the account(for data input reputation)
number of up and down votes where account staked tokens to verify data, in which the account voted with the consensus (for curator reputation)
The contract must keep the following data in state for each submitted data item, temporarily, until the data is verified by a supermajority after 10 days:
account of the submission contributor & the stake of the submission contributor
accounts upvoting data & the stake of each account.
accounts downvoting data & the stake of each account.
time remaining until data is ruled valid or invalid (resets after 10 days if 10-vote threshold is not reached).
Acceptance Criteria:
Background:
Base operation:
The smart contract is used as an event source for the music encyclopedia database. The database should be able to be reconstructed by replaying each blockchain action, including additions, deletions, and edits, in sequence.
The contract will create a token, maybe called POL or PLR or POLR. In the future, we hope to expand the scope to include another token, to be used to reward artists based on their representation on the graph. However, this is not part of the current scope and is mentioned only to share the north star of the project.
Upon signup, the user stakes a number of EOS sufficient to cover their resource usage.
This contract will allow any person to stake a number of tokens (either native POL or EOS/USDT/?) and then publish a proposed addition to the Polaris Music Encyclopedia. The submission will then enter the queue that waits for other users to stake their own tokens to verify the submission as good or bad data. Each subsequent submission by the user will result in an increase in the required stake.
Bad data is punished by having the submission user's stake slashed, as are verifiers who vote against the consensus result. Original stake and a portion of slashed funds are returned to those verifiers who reached consensus.
Good data is rewarded with the minting of new tokens to be shared between the submitter and the verifiers. Potentially 70% to submitter, 20% to verifiers, and 10% to the team.
Each subsequent token reward diminishes the amount of the next reward, such that if this reward is "R" and the number of previous transactions is "t", R = log(t) / t . This formula is based on Metcalfe's law of network growth
(n)(log(n))combined with the inverse square law1/n^2.Front-end interaction:
Front end consists of a graph visualization displaying nodes and edges representing the relationships between musical artists, as well as a text sidebar that displays information about the selected node. It also includes a submission form for adding new data.
Upon submission, the front end provides a JSON structure, which will be packaged into a transaction and sent to the chain. The JSON structure will be of arbitrary length, but If a maximum is requred, >2000 characters will likely be needed.
The Front end will track the path a user is taking through the graph visualization, and if they find an node they "like", the "like" transaction publishes the path taken by the user to get to the artist they just "like"d. This data can be scrapped if the user "un-like"s the node
Users can stake their tokens to a node (such as an artist, album, or group) if they want others to see that node. This is accomplished as follows:
The front end will also allow users to upvote/downvote data. They must include a stake for this verification transaction.
Users should be able to edit data that is already there. This will be done with the same event sourcing method as adding data.
(optional) Users should be able to comment, as well as like/dislike a comment, on a piece of data within a node or edge. If this is feasible to keep in the smart contract, it should be.
(optional) If feasible, the smart contract should keep track when a song is played, or when the "play" button is pressed on a song. Alternately, some setup that keeps track of every 5 seconds or so of music playback could be implemented, to replicate the approach taken by Emanate.
State Needs
The contract must keep the following in its global state:
The contract must keep the following data in state for each account:
The contract must keep the following data in state for each submitted data item, temporarily, until the data is verified by a supermajority after 10 days:
More detailed explorations and explanations are in the pseudocode for the smart contract https://github.com/UrsaPolarisRecords/Polaris/blob/main/eosSmartContractPSEUDO.md as well as in the rudimentary initial smart contract https://github.com/UrsaPolarisRecords/Polaris/blob/main/ursa.cpp