Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add predictoor template #749

Merged
merged 136 commits into from Jul 4, 2023
Merged

add predictoor template #749

merged 136 commits into from Jul 4, 2023

Conversation

alexcos20
Copy link
Member

@alexcos20 alexcos20 commented May 4, 2023

For this epic "[Predictoor BE] Ship MVP" -- Add DT3 to contracts repo

Discussion on whether to merge to main: predictoor-pm#18

@alexcos20 alexcos20 self-assigned this May 4, 2023
@alexcos20 alexcos20 added Status: DoNotMerge Don't merge this PR Status: InProgress Work in progress, don't merge labels May 4, 2023
Copy link

@github-advanced-security github-advanced-security bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Slither found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.

Changes:
- rail every blockNum function args to slot, instead of revert
- payout function never reverts
- renamed to ERC20Template3
- events are storing slot, it will be easier to group it in subgraph
- truval_submitted it's an enum now, instead of bool
- removed external addMinter function
- refactor soonest_block_to_predict  (there is blockNo diff between get and actual prediction block)
 - added SettingChanged event
Copy link
Member

@trentmc trentmc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More comments. More to come (on Mon:)

return (subscription_revenue_at_block[slot]);
}

function get_prediction(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename to get_predval()

Why: to disambiguate from each predictoor's predval, versus the top-level aggregated predval agg_predval.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This returns entire prediction (predval,stake,predictoor,paid) and not just the predval

Paying,
Canceled
}
event PredictionSubmitted(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename to PredvalSubmitted

Why: disambiguate from each predictoor's predval, versus the top-level aggregated predval agg_predval.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't have the predval in the event (would be easy for somebody else to see it), we only have the information that a prediction for slot X has been submited by predictoor Y and he/she staked Z

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename to SingPredictionSubmitted.

uint256 indexed slot,
uint256 stake
);
event PredictionPayout(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename to PredictoorPayout

Why: more specific / clearer

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A Predictoor can have multiple payouts. It's more clear "Prediction" because then we know that it refers to a certain prediction

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

Then, in line with above, I recommend rename to SingPredictionPayout

contracts/templates/ERC20Template3.sol Outdated Show resolved Hide resolved
contracts/templates/ERC20Template3.sol Outdated Show resolved Hide resolved
contracts/templates/ERC20Template3.sol Outdated Show resolved Hide resolved
contracts/templates/ERC20Template3.sol Outdated Show resolved Hide resolved
bool trueval,
Status status
);
struct Prediction {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should rename this to PredictionStruct? Will help to disambiguate from predval which it holds.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a prediction.
A prediction is formed of :

  • predictoor address
  • predval
  • stake
  • paid (if it was paid or not)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename to SingPrediction

contracts/templates/ERC20Template3.sol Show resolved Hide resolved
contracts/templates/ERC20Template3.sol Show resolved Hide resolved
@alexcos20
Copy link
Member Author

alexcos20 commented May 14, 2023

TODO: use mixedCase, according to Solidity naming convention

@@ -0,0 +1,1150 @@
pragma solidity 0.8.12;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's use the labels sing_predval, agg_predval and trueval everywhere.

  • And camelcase equivalents when appropriate.
  • And "prediction" for a group of data around a "predval" (eg predval, stake, predictoor address)

Details...

Over the weekend I had an idea: to further disambiguate singular predvals from aggregated predvals, add "sing" in front of each predval label. Eg "sing_predval", side-by-side with "agg_predval".

Note how I use "predval" and "trueval" without spaces, underscore, or camelcase. That's on purpose, it's just one word. Just like we use "datatoken" not "data token". It reinforces the mental model of predicted vs true, and reduces chance of error.

I thought about doing the same with "sing" vs "agg" too, ie "singpredval", "aggpredval", "trueval". But it's too hard cognitively. So let's just stick with "predval" (having two variants "sing_predval" and "agg_predval") and "trueval".

All the variable labels should reflect this: sol, py, js, and GDoc.

We should rename variables everywhere accordingly. It might be annoying to have to do right now, but it will save us a lot of grief going forward.

I won't give individual comments on this below, it'd be annoying to track. Just make the changes. When done, ping me, I'll double-check.

Paying,
Canceled
}
event PredictionSubmitted(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename to SingPredictionSubmitted.

uint256 indexed slot,
uint256 stake
);
event PredictionPayout(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

Then, in line with above, I recommend rename to SingPredictionPayout

bool trueval,
Status status
);
struct Prediction {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename to SingPrediction

@alexcos20 alexcos20 marked this pull request as ready for review July 4, 2023 05:51
@alexcos20 alexcos20 merged commit e3980dc into v2.0 Jul 4, 2023
9 checks passed
@alexcos20 alexcos20 deleted the test/dt3 branch July 4, 2023 06:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: DoNotMerge Don't merge this PR Status: InProgress Work in progress, don't merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants