100 lines
3.0 KiB
Markdown
100 lines
3.0 KiB
Markdown
|
# Challenges
|
|||
|
|
|
|||
|
|
- Receiving payments
|
|||
|
|
- Distributing payments to participants
|
|||
|
|
- Computing updates to forum graph
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Receiving payments
|
|||
|
|
|
|||
|
|
Business SC will need to implement a financial model.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Excerpts from DeSciPubDAOArchit22July19PrintCut.pdf
|
|||
|
|
|
|||
|
|
> With today’s prices, however, we will begin by programming this all off-chain and simplify the reputation tokens to be less dynamic in their evaluation. Next iteration improves the decentralization commensurate with practical realities.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Validation pool termination
|
|||
|
|
|
|||
|
|
How do we want to handle this?
|
|||
|
|
The validation pool specifies a duration.
|
|||
|
|
We don't want to compute results until the end of this duration.
|
|||
|
|
We're currently supporting anonymous voting.
|
|||
|
|
With anonymous voting, we need to wait until the end of the vote duration,
|
|||
|
|
and then have a separate interval in which voters reveal their identities.
|
|||
|
|
For now, we can let anonymous voters reveal their identities at any time
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Bench.totalReputation is a very important quantity, isn't it? Basically determines inflation for reputation.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Should availability registration encumber reputation?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
- Is a particular availability stake amount required?
|
|||
|
|
|
|||
|
|
Currently we support updating the staked amount.
|
|||
|
|
Seems like a soft protocol thing.
|
|||
|
|
A given DAO can have a formula for deciding appropriate amounts.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
The following was a code comment on `Business.submitRequest(fee, ...)`:
|
|||
|
|
|
|||
|
|
> Fee should be held in escrow.
|
|||
|
|
> That means there should be specific conditions under which the fee will be refunded.
|
|||
|
|
> That means the submission should include some time value to indicate when it expires.
|
|||
|
|
> There could be separate thresholds to indicate the earliest that the job may be cancelled,
|
|||
|
|
> and the time at which the job will be automatically cancelled.
|
|||
|
|
|
|||
|
|
# Implementing forum
|
|||
|
|
|
|||
|
|
Does the following make sense?
|
|||
|
|
We will link the forum to the bench
|
|||
|
|
An author of a forum post /_ ? is always? can be? _/ a reputation holder.
|
|||
|
|
This is what we call a expert. Let's update that terminology to be `reputationHolder`.
|
|||
|
|
That's too long, though. Let's rename it to `expert`.
|
|||
|
|
So we want to aim for the situation where the author of a forum post is an expert.
|
|||
|
|
For now let's try thinking of them as experts no matter what;
|
|||
|
|
The strength of their expertise is meant to be represented by reputation tokens.
|
|||
|
|
So each reputation token must be a contract.
|
|||
|
|
Minting a reputation token means to construct an instance of such a contract.
|
|||
|
|
The reputation contract then has its own lifecycle.
|
|||
|
|
We can support dynamic reevaluation if the reputation contract
|
|||
|
|
|
|||
|
|
- has an interface that allows (securely) updating
|
|||
|
|
- Define secure :: passes validation pool
|
|||
|
|
- How shall it know the operation is occurring as part of an "official" validation pool?
|
|||
|
|
It can verify a signature...
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Tokens staked for and against a post.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Token loss ratio
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
parameter q_4 -- what is c_n?
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
what is reputation?
|
|||
|
|
valuable evidence that you're going to do what you say you'll do in the future
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
for now, combine c2 and c3
|
|||
|
|
|
|||
|
|
validation pool should compute rewards for author,
|
|||
|
|
then send that to the forum to distribute.
|