Closed PomeloBounties closed 2 weeks ago
Bounty application submitted by @BenjaminBaani with a message:
I have been a reviewer of projects/proposals in cardano’s project catalyst, and reviewing this music encyclopedia smart contract design is what I can do. The review must follow three standard criteria namely: impact, feasibility and value for money.
Waiting for your approval @UrsaPolarisRecords
Bounty application submitted by @nadiaalicante1 with a message:
N/A
Waiting for your approval @UrsaPolarisRecords
Bounty application submitted by @Adi12113 with a message:
Git
Waiting for your approval @UrsaPolarisRecords
Bounty application submitted by @Adi12113 with a message:
N/A
Waiting for your approval @UrsaPolarisRecords
Bounty application submitted by @Daddie-b with a message:
I can handle this task
Waiting for your approval @UrsaPolarisRecords
Bounty application submitted by @rafaelmarquesxbox with a message:
https://github.com/pomelodrew/promo/issues/3#issue-2214341078
Waiting for your approval @UrsaPolarisRecords
Bounty closed by the funder
Bounty funds withdrawn by the funder
Bounty
Review Music Encyclopedia Smart Contract Design created by @UrsaPolarisRecords on Pomelo Bounties
Summary
*Job Description: Review the design of the Polaris Music Encyclopedia smart contract and provide feedback on its architecture, logic and flows, economic system, computing efficiency, contract/back-end/front-end design, and potential vulnerabilities. Work consists of reviewing the relevant design documents and attending a ~1 hour video meeting to review findings, recorded for internal reference.
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.
This contract will allow any person to stake tokens and publish a proposed addition to the Polaris Music Encyclopedia. The submission enters a queue until other users verify the submission as good or bad data.
Bad data or verifiers are punished by having their stake slashed.
Good data is rewarded with new tokens to be shared between the submitter and the verifiers.
More details available on GitHub.*
Apply
https://bounties.pomelo.io/2cbb3214abea
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
150.0000 USDT
Note
For technical discussion use the original issue. This issue is for tracking the bounty application and implementation progress.