Skip to content

Instantly share code, notes, and snippets.

@s-ben
Created June 11, 2020 03:53
Show Gist options
  • Save s-ben/5a41f331cf4bed706f0f9697cfb09802 to your computer and use it in GitHub Desktop.
Save s-ben/5a41f331cf4bed706f0f9697cfb09802 to your computer and use it in GitHub Desktop.
Great questions @MakerMan. It's nice to have community members that can understand some of this stuff on deeper levels. My knowledge of the algorithm is more high-level, but hopefully I can point you in the right direction.
[quote="MakerMan, post:7, topic:2700"]
Do you have a link to a more advanced paper that shows in detail the math being used?
[/quote]
No more advanced paper yet, in part because we're undergoing a rewrite of the algorithm, called CredRank. The basic functionality and scores will be the same, but it will allow us to improve performance (faster calculation and smaller output), better interpretability (i.e. we can answer more questions of the types you propose) and flexibility (i.e. we can create features that enable more cryptoeconomic models). You can find more about CredRank here,
https://discourse.sourcecred.io/t/credrank-scalable-interpretable-flexible-attribution/654
[quote="MakerMan, post:7, topic:2700"]
I’m a bit curious how you guys handled the epoch’s. I guess it is similar to doing something like a blockchain state save rather than having to back calculate everything to determine the state at some point.
[/quote]
How epochs work is beyond me... Will ask the algo designers for input.
As for state changes, we currently do just re-download all the data and recalculate the graph from scratch each time we generate new scores (state). The algorithm is fairly computationally intensive, so not something you could calculate on the Ethereum blockchain for instance (not 1.0 anyway). One nice property of the Page Rank algorithm however, is that while it is expensive to calculate, it's very cheap to validate. And, CredRank once merged will significantly decrease runtime and output size.
SourceCred does plan to launch Grain as an ERC-20 token, and is working on a Grain ledger that does a better job of automating accounting that is currently done in a more manual, messy way.
[quote="MakerMan, post:7, topic:2700"]
There is a lot here that is interesting but I find the concept of managing past cred states (and ofc grain payouts etc.) against current cred with the condition that cred or grain doesn’t decrease is interesting. How is grain used against cred to maintain this condition and what kinds of deficits are managed. Also given that you are using something like a matrix formulation with eigenvalues to manage the cred you just renomalize the cred sum to be what you need for the cred growth you want? It is not entirely clear to me the connection between cred and grain from this article.
[/quote]
As for Cred and Grain, I would think of them as separate things (for now anyway). When we implement [Boosting](https://discourse.sourcecred.io/t/boosting-a-prediction-market-on-ideas/306), Cred and Grain will interact and affect each other. But for now, in SourceCred and the Maker trial, Grain (or DAI in Maker's case) is just distributed weekly based on Cred scores. You can think of Grain as immutable, which it will literally be once DAI payments go out on-chain. While Cred scores can change based on new data, re-evaluation of old data, and changes to the algorithm. How Cred and Grain interact depends on the cryptoeconomic model the project uses, and the design space there is large and relatively unexplored in practice. We have some really smart people exploring the theoretical possibilities though, for SourceCred and generally spearking. SourceCred has a #cryptoeconomics channel on our [Discord](https://discord.gg/DdQhMx) you might find interesting. We're also interacting with the Token Engineering (TE) community ([Discord](https://discord.gg/NyM4hQ)), as well as with other researchers in the cryptoeconomics and governance realms.
Back to the core algorithm, below is a "paper" that explores how PageRank is used generally. This will help you understand, for instance, the alpha parameter, one of the main "knobs" you can use to steer the behavior of SourceCred.
https://medium.com/sourcecred/exploring-subjectivity-in-algorithms-5d8bf1c91714
This paper goes into some of the social science and game theory involved,
https://medium.com/sourcecred/network-formation-games-7a74491abf0e
And here is a quite out of date, but thorough and perhaps useful description of the SourceCred algorithm.
https://github.com/sourcecred/research/blob/master/algorithm.md
[quote="MakerMan, post:7, topic:2700"]
One thing in my thoughts on this topic that comes up is the idea of relative age of contributions or their relevance. There is two ways to deal with this that I think generally work:
1. Have cred have a decay rate - using the epoch slowly decay cred.
2. Have contributors themselves put a cap on the amount of cred or grain they require before a contribution is considered ‘paid’. This is a nice mechanism for contributions to formally enter the community with a previous value that disassociates from future value creation.
Conceptually while people would desire to make money off of contributions in perpetuity practically this doesn’t work well. examples are patents where at some point it is more beneficial to society for these patents to enter the ‘public domain’ vs. to keep someone paying a royalty etc to use them. Timeframes on these things are important in relation to revenue generation against potential use and litigation processes. One has to have potential to create enough compensation for the creation of something during the time frame the contribution is active for revenue generation.
[/quote]
This is another deep area of thought. There are many different "employment"/economic models one could implement here. SourceCred is exploring a [Sponsorship](https://discourse.sourcecred.io/t/sponsorship/684) model, where a sponsor (e.g. Protocol Labs) agrees to pay a set dollar amount per month, in return for a share of the contributor's Cred, de-risking their income. Other models are being discussed. Which one is appropriate for a given project will likely depend on the needs and culture of the project. I agree that balancing rewards over time (temporal dynamcis), is one of the more important, trickier aspects.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment