Community Pool Spending

Secret Governance
1

Problem: Funding Projects Collectively

How might Enigma’s community of validators allocate resources? At the time of this post, there is 43,888 SCRT in the community pool, and that number is growing! How can those coins provide a reliable and sustainable way to drive progress toward valuable outcomes?

In the past, we offered Enigma Growth Grants (EGGs), which led to development of an explorer for the Discovery network. Also, several members of the Collective are working as independent contractors. Going forward, the community will decide to fund specific projects by voting on budget proposals.

Enigma’s network of validators recently passed an important proposal to raise our community_tax parameter from 2 to 75 percent of block rewards. This greatly increases the amount of SCRT available for various initiatives.

I’m organizing weekly discussions about Enigma’s governance system, and we’re developing a collaborative structure inspired by the Cosmos GWG. Our community has been referring to this group as “Secret DAO.” The main goal of this initiative is to help all kinds of stakeholders create and submit worthwhile proposals.

Thanks to Gavin Birch of Figment, we have this document explaining best practices for drafting and evaluating community spend proposals. Learn more by perusing this GitHub repository!

Format:

  1. Title - distinguishing name of the governance proposal
  2. Description - body of the proposal that further describes what is being proposed
  3. Recipient - Enigma (hex-based) address that will receive funding
  4. Amount - amount of SCRT that the recipient will receive (denominated in uscrt)
  5. Deposit - amount contributed to the deposit (uscrt) from the account submitting the proposal

Here is an example of a successful Cosmos Hub proposal with detailed milestones. Of course, Enigma is a different network, and our governance objectives are not the same. What kind of projects might deserve support from our community pool?

Example

Let’s imagine a community member has an idea for some kind of application built on Enigma. Their project may choose to submit a community spend proposal. First, they should post a summary on the forum, hopefully in this thread, requesting feedback. Next, they may draft a proposal for consideration by validators. If any help is needed, they can ask members of Enigma’s Governance Working Group.

After the proposal is ready, they should use this guide to actually submit their proposal. If they are not yet part of the network, ideally somebody else can submit on their behalf. There is a minimum deposit required for a proposal to enter the voting period, and anyone may contribute to this deposit within a 7-day period. If the minimum deposit isn’t reached before this time, the deposit amounts will be burned. Deposits will also be burned if quorum isn’t met in the vote or if the proposal is vetoed.

{
   "title": "Secret App",
   "description": "This is a summary of key information about this
   proposal. Include the URL to a PDF version of the full proposal.",
   "recipient": "enigma1vgqg9j4g64kv4f6tdmhxujpm4xjrwcnw0wzg3h",
   "amount": [
      {
         "denom": "uscrt",
         "amount": "888888888888"
      }
   ],
   "deposit": [
      {
         "denom": "uscrt",
         "amount": "1000000000"
      }
   ]
}

Got ideas?

Please don’t hesitate to share any thoughts or questions regarding this opportunity. Ultimately, our mission is to build privacy solutions for decentralized applications. We are looking forward to coordinating around interesting projects in our ecosystem!

Participate in the Governance Working Group

2020-03-20T18:00:00Z

1920×1080

Our next meeting will be in VR using a Mozilla Hubs room called the Chamber of Secrets, pictured above. Special equipment is not required; it works in every browser. You can join using a laptop, smartphone or headset. We will be discussing project updates and some ideas for impactful community pool spending. Looking forward to the conversation!

2 Likes
2

So, lots of dapps need randomness

and it turns out that randomness is actually hard to generate – you could have a whole bunch of people submit bits and then as long as at least one is independent they all are

but then you can’t build up a ‘store’ of random bits publically/verifiably
since then it would be predictable

with Enigma that’s no longer an issue

have a random ‘oracle’ that continuously accepts tx hashes plus internal state plus nist randomness plus , and here’s the important part, allows anyone to send in any data to add to the internal state of the PRG at any time

(data gets hashed and xored with the internal state at a given timestep)

that way you can have a continuously updating random oracle with internal state, with arbitrary public input

but without the worry about people reading the public input and predicting future randomness

you also get ZKPs for free – you can have the oracle periodically publish hashes of its internal state and then if someone wants proof of a random roll (once, say, a day has passed) they can get it

4 Likes
3

How does this solve the problem of users manipulating the randomness oracle? This is the problem we see so far, if the oracle is dependent on some user-submitted data (e.g., tx hash).

Regardless, I see a lot of value about adding randomness to the network. I believe even a manipulatable randomness oracle can be useful for something like Salad (I might be wrong), but definitely not okay for many other applications like games, poker, bidding, etc…

4

If any user can submit data that changes the state of the oracle at any time (the simplest version of this is any user can submit X and then the oracle’s state becomes H(X) XOR prior_state, for some secure hash H), then the oracle is secure as long as at least 1 user is independent of the others :slight_smile:

1 Like
5

(the proof of this follows e.g. the proof of secure coin-flip protocols, and is p much just ‘leftover hash lemma plus uniform XOR anything is uniform’)

6

Hi @Avret, thanks for taking the time to posr your idea. Can you explain how your solution overcomes the attack that @guy described here? Salad in Enigma blockchain · Issue #102 · scrtlabs/SecretNetwork · GitHub

7

Sure! The github issue relies on single-source randomness which is why it can be manipulated – I’m proposing an oracle that takes in a whole bunch of separate sources of randomness and uses them to build up state. (you could build a less secure version of this by just taking every txhash and using them to build up the oracle’s state via the same H(tx) XOR prior_state mechanism, but that’s vulnerable due to low network liquidity early on)

1 Like
8

The attack does not rely on the state of the entropy pool, so I’m still not sure how increasing the number of entropy sources helps here.

9

Being able to pick your randomness relies on knowing the state of the entropy pool – if that state is hidden, picking txhashes doesn’t help!

1 Like
10

Another thing – the random oracle as I’ve specced it out isn’t replayable, every call to get random bits pushes the state forward

1 Like
11

This is still susceptible to the attack @guy described because of the determinism Tendermint forces, and because an attacker with a full node can run txs locally on the same state until the desired output is received locally and only then broadcast it to the network. The attacker will have to be very fast, but it’s doable.

12

Oh, no, I’m not getting myself across clearly – the random oracle’s state is only accessible via ‘make a request for random bits, that request is granted and broadcast to the network, the state is moved forward a step’ – at no point does the request for random bits cause the oracle to take in new data. Breaking the secrecy of the entropy pool should only be possible iff you can pull arbitrary plaintext out of enclave secrets (in fact I’m pretty sure I can write a reduction proof over TEEs that shows that)

1 Like
13

So I guess I don’t understand the use case you’re describing because it’s not possible currently with CosmWasm or even with Tendermint

14

You cannot force an oracle tx in the middle of your tx, your tx must come after the oracle’s tx

15

You request random bits at some point and broadcast an event like ‘waiting for random bits’ to the chain, then the oracle publishes ‘sent random bits with hash H’ at which point you then use those bits

16

@Avret what prevents someone from probing the oracle repeatedly until the random bits they get look ‘good’ to them?

17

The oracle publishes the addresses of everyone requesting random bits from it at every transaction – if your poker game should need 10 bits of randomness and you ask for 500, people are gonna have some questions :stuck_out_tongue: (and yeah, this allows the sidechannel of seeing what random bits are requested and using that to read out codepaths, but that’s sidesteppable by ‘writing code that requests randomness regardless of codepaths’)

2 Likes
18

Talking to the oracle happens off-chain then?

19

No, it happens on chain, but in 2 stages: plaintext ‘address A requested B random bits, and the hash of the received bits is H(the bits )’ and the ciphertext where B random bits are sent encrypted to A

2 Likes
20

I don’t think you can prevent someone from running their own full node and locally bypassing this. Even if you can, which I don’t believe is fully possible, this is still a heuristic which makes it harder to manipulate the oracle - but it doesn’t solve it completely. There’s also a UX price (two step process which makes usability more cumbersome).

1 Like