Enigma Blockchain

Hi everyone!

I’m creating this topic for discussions about Enigma’s recent launch of a distributed network using the Cosmos SDK. It’s a new beginning for this community, and we’re looking forward to building more interoperable privacy solutions for the whole blockchain ecosystem.

One of the most significant changes that was made is the addition of on-chain governance to the protocol. Validators are considering proposals now, and we hope to support meaningful discussions here on the dev forum. If you have any ideas or questions, reply to this message or start a new topic in the Enigma Chain category.

Here is a place where you can ask questions, voice your opinions, and influence the direction of Enigma’s live network. Our team hopes to submit a governance proposal for integrating secret contract functionality in the coming months. This proposal would be voted on for inclusion by validators in the Enigma network.

Currently, there are 20 validators, selected based on their successful support of the Discovery testnet. More will be necessary to achieve greater decentralization. To this end, we have been exploring frameworks that enable decentralized autonomous organizations built on Ethereum. Recently, our team launched a “DAO” as an experiment at ETHDenver. Although it is not part of Enigma’s on-chain protocol governance, Secret DAO allows members to conduct reputation-weighted votes on proposals. Eventually, there might be funds allocated to specific projects through a combination of social and technical decision-making processes.

For now, share thoughts here on the dev forum. This open-source platform is best for coordinating stakeholders and other participants. We have some interesting decisions to make together. Our community invites anyone to help with development and ongoing research. All positive contributions are much appreciated!

5 Likes

How does on chain governance work specifically? Not in terms of voting but in terms of the success of a proposal. Specifically:

  1. At what point is a proposal considered successful?

  2. Does a successful proposal mean that the proposed implementation is added to a list of things the Enigma team will implement or is it up to the community to implement the change?

  3. If up to the community, how does this work? Can anyone make a PR and once tested and verified it is merged? Is another vote required to decide which code to merge? Be specific

  4. If possible to answer amidst all of what’s going on, apply these questions specifically to the proposal for a token swap. The latest update stated that for the time being, the Enigma team could not facilitate a token swap. What does this mean If the proposal is successful? Will anything even come of it?

  5. Will it be possible in the future to propose a movement of the main net from Cosmos to Ethereum 2.0 once it’s released and fully functional? Everyone knows that Ethereum has by far the most developers and as far as my limited understanding goes, interoperability among chains is not an easy problem to solve. Will this move delay the ability to run secret contracts on Ethereum as opposed to waiting for the release of Ethereum 2.0 for main net?

3 Likes

@ButlerAnd3rdTeam,

Here’s how on chain governance works. All staked SCRT (at validators) make up the total voting power. If there are coins that are not staked, they are not a part of voting power.

Anyone can make a proposal. I believe there’s a 1000 SCRT deposit requirement, this amount does not necessarily need to come from the ecosystem participant who has made the proposal.

Once the proposal is made, 33% of the voting power needs to participate in the voting (yes, no, abstain, no with veto), in order for the proposal to be considered a valid proposal.

Then once 33% participation is reached, the voting process is valid. Once it’s valid, there needs to be 50% yes in order for the proposal to be accepted

So, if 20% of all voting power votes, and everyone votes yes - this will not be a successful proposal.

Regarding the second question - successful proposal will be add in the development timeline of the development team and the community can also contribute to the code base

  1. Merging the code base requires a hard fork in the network. This means all validators need to upgrade their code. It’s not necessarily another vote

  2. Can’t comment on this. Technically speaking any major change to the network requires a vote and a hardfork. The hardfork is solely up to validators.

  3. Cosmos chain has made our product development much easier. If you look at the architecture we had in Discovery, there were features that caused issues for us. In other words we needed to introduce centralized operators with crypto-economic incentives to act honest. These features are:

  • identifying time (deadman switch) - we didn’t have a way to verify ethereum blocks in Enigma, now our network has it’s own blocks - thus we can determine time in a decentralized manner
  • ethereum balances (token weighted voting or any kind of auction) - we didn’t have a way to verify ethereum balances in Enigma, now our network has it’s own balances
  • Storing task records on Ethereum: Users needed to store tasks (hashes of inputs) on Ethereum. This made our collaboration discussions with 0x around Decentralized TEC obsolete.
  • TX fees - Salad uses an operator so that the users don’t pay twice (once on Ethereum, once on Enigma). Operator was used to obfuscate this choice.

This is a much better direction forward. We can accommodate more development in a shorter time period. We will provide more developers the ability to build on Enigma sooner.

This doesn’t mean we abandon our goal to provide privacy to the Ethereum ecosystem. We acknowledge that Ethereum has the most vibrant developer community. We plan to explore IBC interoperability efforts for the cosmos ecosystem, we will continue to work on the bridge mechanism we built for Discovery.

We will be transparent in our process to incorporate secret contracts to this network and in exploring interoperability with Ethereum

8 Likes

Thanks for the responses, @can, it’s great to hear more about the network.

As I’m sure you’re aware the current subject of interest for a lot of people regards the community run SCRT network and the ENG swap proposal. We are all eager to start using Enigma technology and be involved in a live network.

I understand there is a lot you cannot speak on yet (as much as you may like to) but I’ll still drop the questions and my thoughts here for the community to consider and discuss regardless.

Your answers to 1, 2 and 3 sound exactly as I expect given that SCRT is run by community validators and not under control of Enigma. Given that support for the swap proposal is virtually unanimous it seems mostly a matter of optics and logistics at this point.

I deeply respect the Enigma team, from the founders to the ambassadors and everyone in between, and wish I had total information.

One option is for community is to not wait for Enigma to make a determination on the swap but appeal to the validators directly and push through an unblessed swap, uniting everyone onto SCRT. This would be a pretty straightforward fork and does not even seem that contentious with regards to consensus right now, but puts Enigma into a weird place.

Concerns about this approach:

  • We absolutely cannot lose the contributions and input of the Enigma team. I am not on board with anything that causes a long-term divide. Hypothetically, If the community made a decision that went against Enigma’s guidance, could Enigma accept the outcome and continue contributing to the new project once the situation had settled? Or would this leave them in a long-term legal tension?

  • If a proposal succeeds that the Enigma team can not/will not support, would they still accept pull requests to the current Github repository, or would the hardfork need to be entirely managed by outside parties? If so, how about post hardfork success? Could the team even run a node on a fork they didn’t agree with once it succeeded at reaching consensus?

  • How would these things affect the finances and salaries of everyone involved? We want you all living well, happy, and successful. Could you all claim and spend SCRT from an unblessed swap?

  • Just to be clear, the DAOstack Secret Dao is not involved in this process at all, right? Is there any way for additional parties to become validators immediately? I would like to be involved with the proposals and voting.

Again, I understand if you can’t comment on any of this, but appreciate anything you can say or any thoughts the rest of the community has. I hope it’s clear that I’m trying to consider what’s best for all parties just the same as you are. Times of change are always hard but I see a really great future ahead if we can get through this united.

6 Likes

+1 for the questions and concerns raised by @uxt . Some additional questions based on your responses to mine:

  1. “Once the proposal is made, 33% of the voting power needs to participate in the voting (yes, no, abstain, no with veto), in order for the proposal to be considered a valid proposal.” – Unless abstaining happens by default, doesn’t this open up the possibility of frequent road blocks caused by holders of SCRT who have no interest in the governance portion of the network? Also can you clarify the difference between voting “no” and voting “no with veto”?

  2. “Regarding the second question - successful proposal will be add in the development timeline of the development team and the community can also contribute to the code base” – Will there be a public record of the team’s development timeline somewhere with these accepted proposals added? Perhaps a repo for each so that community members can contribute? If so when can we expect to see this?

  3. “Cosmos chain has made our product development much easier. If you look at the architecture we had in Discovery, there were features that caused issues for us. In other words we needed to introduce centralized operators with crypto-economic incentives to act honest… This doesn’t mean we abandon our goal to provide privacy to the Ethereum ecosystem. We acknowledge that Ethereum has the most vibrant developer community. We plan to explore IBC interoperability efforts for the cosmos ecosystem, we will continue to work on the bridge mechanism we built for Discovery.” – This is fine for now, but if this is the case I would hope that interoperability with Ethereum is very high up on the priority list, even if it comes in the form of strict interoperability between cosmos and Ethereum at the short term expense of general interoperability with a variety of other chains. Ethereum is by far the most important chain to cater to right now and for the forseeable future in my opinion.

2 Likes

@uxt

Thanks for the thoughtful questions. I’ll respond to what I can and know below.

We absolutely cannot lose the contributions and input of the Enigma team. I am not on board with anything that causes a long-term divide. Hypothetically, If the community made a decision that went against Enigma’s guidance, could Enigma accept the outcome and continue contributing to the new project once the situation had settled? Or would this leave them in a long-term legal tension?

If a proposal succeeds that the Enigma team can not/will not support, would they still accept pull requests to the current Github repository, or would the hardfork need to be entirely managed by outside parties? If so, how about post hardfork success? Could the team even run a node on a fork they didn’t agree with once it succeeded at reaching consensus?

Our main consideration is ensuring that the network can run independently, which is the situation now given that there are 20+ validators (and which we hope to see grow over time). The community now owns the network - not us, and that was a strict decision we made to move forward.

With that in mind, I don’t expect Enigma to have any say in decisions that the community takes, nor do I believe we can be held liable for it. Going forward, our role is limited to development - we’re writing code, and proposing changes for the network to vote on.

Just to be clear, the DAOstack Secret Dao is not involved in this process at all, right? Is there any way for additional parties to become validators immediately? I would like to be involved with the proposals and voting.

Nope, it’s unrelated.

2 Likes

“Once the proposal is made, 33% of the voting power needs to participate in the voting (yes, no, abstain, no with veto), in order for the proposal to be considered a valid proposal.” – Unless abstaining happens by default, doesn’t this open up the possibility of frequent road blocks caused by holders of SCRT who have no interest in the governance portion of the network? Also can you clarify the difference between voting “no” and voting “no with veto”?

I can’t speak for how the network votes. No is simply a ‘No’ - between a ‘Yes’ and ‘No’, a simple majority wins. ‘No with veto’ is a stronger ‘No’ - if 33%+ use this option, then the vote fails, and the proposer loses their deposit.

  1. “Regarding the second question - successful proposal will be add in the development timeline of the development team and the community can also contribute to the code base” – Will there be a public record of the team’s development timeline somewhere with these accepted proposals added? Perhaps a repo for each so that community members can contribute? If so when can we expect to see this?

We’re planning to involve the community much more in our development and thought process. We’ve had a lot of discussions around this internally, and we feel that in a project that involves so many moving pieces, it’s the best way to share and gather feedback. This means that we want to share with everyone our thinking and priorities and get the community’s thoughts in real-time. After all, since all dev updates will be proposed to the network (often as hard forks), people need to have a clear understanding what they’ll be voting on.

“Cosmos chain has made our product development much easier. If you look at the architecture we had in Discovery, there were features that caused issues for us. In other words we needed to introduce centralized operators with crypto-economic incentives to act honest… This doesn’t mean we abandon our goal to provide privacy to the Ethereum ecosystem. We acknowledge that Ethereum has the most vibrant developer community. We plan to explore IBC interoperability efforts for the cosmos ecosystem, we will continue to work on the bridge mechanism we built for Discovery.” – This is fine for now, but if this is the case I would hope that interoperability with Ethereum is very high up on the priority list, even if it comes in the form of strict interoperability between cosmos and Ethereum at the short term expense of general interoperability with a variety of other chains. Ethereum is by far the most important chain to cater to right now and for the forseeable future in my opinion.

100% agree. IBC is one form of exploration. In general, we need a limited type of bridge for now that is much more limited than what IBC aims for -> chaining outputs from our network to Ethereum (and later on other chains).

3 Likes

Thanks @guy and @can for the explanation, @jlwaugh for kicking off the thread and everyone else for laying out your questions. It seems like a document describing the voting process in detail would be useful. I’ll get it on our to-dos. cc @can and @tor

3 Likes

Another couple of questions:

  1. Regarding the proposal to swap tokens: since the team said that for the time being they can’t facilitate a swap, will the community be able to do so if/when the proposal is successful? If so how can this be accomplished? Perhaps a discussion on the legal ramifications to take into account so that a method of doing so could be voted on. Even if Enigma can’t directly be involved

  2. Since according to the blog post people that hold SCRT that aren’t one of the 20 validators will be able to delegate their stake to other validators, are they able to do so on specific proposals after seeing how the validator votes?

1 Like

@ButlerAnd3rdTeam regarding your second questions,

You can choose to bond / unbond your delegated tokens from a validator at any time. I think it’s a good recommendation to have a platform where validators and their SCRT holders working with them can discuss these matters

2 Likes

Hello,

It appears that roughly 48m SCRT tokens are controlled by the team. What is their intended use?

Even if a swap happens where new SCRT is minted to replace ENG holdings, if it’s 1:1 (no dilution), the team will still control at minimum ~35% of total tokens. This is not meaningfully decentralized governance, especially considering anything can be vetoed with >33%.

1 Like

Just saw this tool that Chorus - a validator service, offers to its delegatees to vote on proposals. This means even if you are delegating to a service provider, it’s possible to vote independently
https://chorus.one/networks/cosmos/

1 Like

@luigi1111

We cannot comment about a token swap. Regarding your concerns, voting power depends on the amount of staked Coins. Coins that are not staked do not count towards voting / decentralized governance.

In the past we have considered staking a up to a certain portion of the network. This would be a way to make sure Enigma development team alone cannot veto proposals

Decentralization must not rely on a single party’s “won’t”, but on “can’t”. The team agreeing to stake only a certain percentage is still a hidden veto, unless possibly some mitigation could be added (not sure how off-hand).

Also, if the team is going to stake a % target of total supply, their holdings will be diluted relatively quickly toward that % as inflation occurs, leading one to wonder why they wouldn’t just target that % to start with. It could be a way to decentralize more meaningfully over time, which might be attractive.

Finally:
I know the team can’t comment on a swap, but the community and validators are definitely talking about it. I want to urge everyone to seriously consider what makes a decentralized (enough) system; these are very material considerations that shouldn’t just be glossed over as something to fix later (or maybe not at all).

1 Like

@luigi1111 - great points

The problem is, if you force the Enigma team to reduce their ENG/SCRT holdings to a non-veto threshold, you still cannot be sure the veto is off the table. They could split the holdings into 10 new addresses and claim they sold them to another party. There’s no way to verify that. Taking it a step further, you can write a program to split the holdings into thousands of new addresses with a varying amount of tokens and still retain ultimate (and secret) voting power.

Even if you split tokens evenly across all active addresses, you could still have a secret hostile takeover if someone has the money and time to buy 33% of the tokens.

The 50% approval threshold seems reasonable because if a single entity owns half the tokens, then they surely have the token’s best interest in mind. The veto threshold is similar but easier to attain, and it comes with a sting.

I can’t think of any good examples where “No with veto” solves anything that a “No” does not. Even in cases where someone is spamming hundreds of proposals, the validators can either just ignore the proposal (assuming it won’t pass) or vote “No”. The “No with veto” option seems dangerous and should be much higher (e.g., 75%) if we want to keep it.

1 Like