Closed PomeloBounties closed 7 months ago
Bounty application submitted by @andrewrec with a message:
I want to do this!
Waiting for your approval @drewbop
Bounty application submitted by @andrewrec with a message:
I want to do it!
Waiting for your approval @drewbop
Bounty application submitted by @drew-bop with a message:
I can accomplish this task!
Waiting for your approval @drewbop
Bounty application denied for @drew-bop with a message:
I don't like the look of you
Bounty application approved. Good luck @andrewrec!
Bounty work submitted by @andrewrec with a message:
Waiting for your approval @drewbop!
Bounty work denied for @andrewrec with a message:
That's just google
Bounty work submitted by @andrewrec with a message:
I'm done!
Waiting for your approval @drewbop!
Bounty forfeited by @andrewrec with a message:
Over it
Bounty application submitted by @andrewrec with a message:
I've done it already!
Waiting for your approval @drewbop
Bounty application approved. Good luck @andrewrec!
Bounty work submitted by @andrewrec with a message:
How about now!
Waiting for your approval @drewbop!
Bounty funds released and ready to be claimed @andrewrec!
Bounty 0.0500 USDT successfully claimed
Bounty
Review Music Encyclopedia Smart Contract Design created by @drewbop on Pomelo Bounties
Summary
Job Description: Review the design of the Music Encyclopedia Smart Contract, including logic and flows, economic system, computing efficiency, contract/back-end/front-end design, and potential vulnerabilities. Identify potential contract vulnerabilities, consider economic and game theoretical vulnerabilities, explore Sybil and DDOS vulnerability, and describe mitigation techniques.
Apply
https://bounties.pomelo.io/bc2acb421413
Original Issue
https://github.com/ursapolarisrecords/polaris/issues/12
Title
Review Music Encyclopedia Smart Contract Design
Body
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.
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. It is a nice-to-have on the smart contract, though, unlike the other items listed.
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.
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
Base Reward
0.0500 USDT
Note
For technical discussion use the original issue. This issue is for tracking the bounty application and implementation progress.