Comments & suggestions re: how to subscribe to prediction feed and hide the predictions (ch 2.2)


having read the litepaper for Vanilla v2, I would like to make few comments regarding subscribing to prediction feed and how to hide the predictions and reveal them later on. I think the suggested mechanisms could potentially be improved.

The subscription mechanism described on the litepaper in chapter 2.2 is as such

“Subscribers pay the VanillaDAO for the signal as a monthly subscription. The DAO adjusts the subscription price based on multiple factors, e.g., the value of the signal to subscribers, the gas costs of subscribers, juicers, and the DAO, and the level of rewards paid out.”

I think a better way to handle this would be to run an auction at the end of every month, say, starting at T-7 days and ending before T-2 days (why T-2? Read ahead, this is due to key generation). One way would be to use dutch auction on e.g. Gnosis Auction, MISO, DutchX or on any other platform supporting decentralized auctions depending on the (side-)chain where Vanilla is going to be. Using a straightforward auction instead of some DAO-specific tuned price hack would also give a clear signal for the DAO itself on how well the system is doing as higher quality signal generation would inevitably translate to higher auction prices for subscriptions.

The amount of subscribers that would get access to signal for the forthcoming month could be set by the DAO governance as specced on the litepaper. Here is the second and IMO a much bigger flaw. Another excerpt from chapter 2.2:

“One central cost element is gas that is needed for juicers to reveal the predictions privately to subscribers. Each subscriber publishes a public key on-chain, which is then used by each juicer to encrypt their predictions for that subscriber. Since each juicer needs to publish each set of predictions as many times as there are subscribers, the juicer’s costs for making predictions go up with the number of subscribers.”

This doesn’t scale at all and is a very sub-optimal way to handle the distribution of shared encrypted content when the amount of subscribers will hopefully scale up. What I would propose is as follows:

1. Run dutch auction and determine the n top-paying (chosen) subscribers who will get access to the signal for the forthcoming month
2. Perform the key generation off-chain for the top-paying subscribers e.g. on Vanilla web site. This single key will be used to encrypt all predictions for the forthcoming month by the parties making predictions
2.1. Here in lies the core of the issue: How can a single key be generated that only the chosen subscribers have access to and no one else will know?
2.2. My proposal would be to use e.g. multiparty Diffie-Hellman (MP D-H) key exchange done off-chain. The chosen subscribers would each commit their own input to the key generation ceremony and in the end only them will be able to get their hands on the common private key. MP D-H is probably the most simple scheme, obviously there are more complex ones available as well
2.3. The subscribers would have at least two days time before end of the month to participate to the key generation ceremony. If someone paid for the subscription, but doesn’t participate to the ceremony then tough luck, they would not be able to decrypt the predictions.
3. From the common private key (any) one of the chosen subscribers would be able to generate the public key. First one to publish it on-chain would get a small reward and that would be the key to use for the following month
4. Now the predictors would use single key to encrypt their predictions and only the chosen subscribers would be able to decrypt them.
5. After the month has gone, first one to reveal the private key would also get a small reward and thus then enable everyone to get access to the predictions of the previous month

I think for simplicity’s sake the key generation could be done off-chain, but as such performing MP D-H can be done in public. In the end only the participants will be able to generate the shared private key. The only thing to limit is that the ceremony’s participants must be the chosen subscribers and that could be done by verifying the input for key generation comes from accounts that won the auction using e.g. digital signing.

Furthermore when VanillaDAO v2 launches (or is in “real-money beta”), I would suggest that DAO creates single public/private key pair and shares both keys to community to view all predictions. This would be the case for the first few months as hopefully the quality of predictions would be able to convince all on-lookers and potential subscribers that Vanilla is able to generate alpha. Only after the bootstrapping period the auctions would begin.

1 Like

Given the direction we’ve gone in for the initial implementation of Vanilla v2, I think we can pick up this discussion if and when it becomes timely!