Smart Contracts permissioned deployment voting

[Orbit Lens]

There's an idea I've been thinking a lot of since the announcement of the smart contracts platform on Stellar network. I'm still not 100% sure about it, but I'd like to kick off the discussion on this matter since it may be tremendously important for the future success of the technology.

All the freedom provided by Soroban looks awesome, yet that's a double-edged sword. The quality of the smart contracts and inherent complexity of their interaction became a huge problem for dozens of existing Turing-complete networks. Almost everyday we see news about loud exploits of buggy smart contracts or shady schemes resulting in huge amounts of money being stolen. Statistics of various DeFi and GameFi projects loosing/stealing billions looks staggering (here are some numbers for the context: https://blog.chainalysis.com/reports/2022-defi-hacks/). 

Aside from the reputational loses (users are often afraid to utilize Turing-complete chains for anything more complex than sending money to/from exchanges), this also brings to the light some legal concerns. Recent OFAC vs TornadoCash case is a good example of government imposing pressure directly on ecosystem in response to a single "bad actor" behavior, although the ethic side of this topic is highly debatable. If we take a look at other blockchain ecosystems, the situation there looks even more ominous. Up to the point that nobody takes some some of them seriously anymore because of hundreds hacked and rug-pulled projects.

Assuming that we follow the same path, in the long run such a decision may inflict quite a lot of problems and damage the hard-earned Stellar reputation as a safe remittance network.

But what if we implement some voting mechanism to make the contract deployment semi-permissioned? Something like on-chain voting on Polkadot. Or deployment accepted by the majority of validators. Only those smart contracts which have a bulletproof design and are widely supported by the community deserve to be deployed.

For example, if we are talking about a stake-based voting model, every two weeks (or maybe weekly/monthly/quarterly?) our community can vote on-chain with their XLM balances for the projects that have a decent documentation, solid team, and verified smart contracts. Employing the approach similar to the SCF community fund (with the ability to vote for and against the project) may prevent clearly malicious or poor-quality smart contracts from getting onto the chain even if somehow they gain enough XLM for the self-voting.

It's just one of the possible mechanisms. There are more options:  SCP voting by validators, allowing only "approved" contracts on the Horizon side, maintaining the registry of approved contracts and blocking all other contracts in the wallet interface, etc. I'm personally more in favor of strict ledger-enforced deployment rules (on-chain XLM stakes voting or validators collegial decision) since other "softer" or indirect constraints can be circumvented.

Pros:
- Voting automatically implies a multi-step refining procedure that rewards more comprehensive and high-quality solutions
- All contracts that make it to the chain will be thoroughly audited
- Bad actors can be stopped before they make any harm
- Firmer stance for SDF, ecosystem projects, wallets, exchanges in legal questions
- There will be a not so many active contracts in the system, which in turn provides some other benefits:
    - concentrated DeFi liquidity -- a dozen of various proven designs instead of an army of Uniswap/Curve/Balancer clones
    - great interoperability between contracts -- building blocks instead of thousands incompatible pieces
    - better support from the wallets side
    - safer and more friendly landscape for the users

    - less restrictions for smart contract developers -- Soroban devs may ease or completely lift some memory/execution restrictions and automatically precompile code for all deployed smart contracts, massively improving their performance

Cons:

- Higher centralization and censorship concerns -- an extremely controversial subject that largely depends on the exact voting method and procedures

- There's a nonzero chance that some potentially great idea may be buried in oblivion due to the lack of community traction 

Any thoughts on this? Maybe having a hundred of well-audited and interoperable smart contracts built by reputable teams will be much more beneficial in the long run than going the anarchy mode with a full open smart contracts platform?

Regards,

OL

[Tomer Weller]

Orbit, Thanks for kicking off this discussion - it's super important and I'd love to hear what others think. 

Some comments in no particular order: 

1. This might be obvious but I want to emphasize that voting doesn't make projects bullet proof. Even with plenty of scrutiny and audits projects still get hacked. For example, the nomad project, which was recently hacked, was audited and have some of the most talented smart contract engineers in the industry

2. Voting is hard. If we go down the route of stake-weighted voting then we allocate trust to capital holders - which contradicts SCP's approach to reputation based trust. If we go down the route of SCP votes (Geoff suggested something similar for speedex in CAP44) then we need to have very engaged validators and probably a story for abstaining (regulated entities might not be able to vote for inclusion of various financial instruments).

3. Regardless of the voting method, we would need to setup a social contract and guidelines to help voters make decisions. 

4. We would need to setup governance tooling and forums. For reference, here's Osmosis' process and governance portal.  

5. An additional Pro is that we might be able to JIT vetted contracts, which has significant performance gains over interpreting.   

Personally, I'm on the fence about this. Given that Stellar is a network built on reputation based trust, having governance around smart contracts makes sense to me. But I'm also concerned that it might stifle innovation and generate more work to get soroban out the door. 

Again, I would love to hear what others think. 

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/76158fe6-d32e-44bd-a884-32fabfafc0c0n%40googlegroups.com.

[David Mazieres]

Having some kind of reputation system for smart-contracts might be a
good idea, so long as it is not enforced by stellar-core. I could see
having a SEP on smart-contract endorsement. Wallets implementing the
SEP would support a "developer mode" that, if disabled, prevents users
from interacting with non-endorsed contracts.

That said, I don't like the idea of relying on validators to evaluate
smart contracts. The role of validators is to ensure people play by the
rules, not to judge what people do within those rules. Just as we don't
ask validators to determine which token issuers are solvent, we
shouldn't task them judging the quality of smart contracts. That's a
different role best filled by a different set of actors.

David

[Tommaso De Ponti]

Imho, I don't particularly like the idea of permissioned smart contracts but I might be biased on the subject. Anyways, here are some of the first thoughts that I thought of while reading orbitlens's proposal: 

1. it doesn't attract developers, the idea of having your contract voted before it can be used by a public network is not ideal 

2. as tomer commented, voting has to be thought through: what degree of participation will be required by the voters, a contract being voted on does not mean it's actually safe. 3. it might backfire leaning into trusting Stellar less: if a contract that was supposedly audited and voted were to reveal a bug, can we really trust those audits and votes? Having the user decide which contracts to trust is very different than trusting it for them without being 110% sure (even if it's the community voting) 

4. having to set up governance, forums, and additional reference portals leave much more room for security vulnerabilities in one of these features on their own. While the current approach only requires making the VM secure to avoid for example VM escapes. (?) 

Ultimately, since auditing a contract can't be done by a machine but requires human knowledge, I would oppose to a potentially non-liable party without any form of collateral having to determine that it can be run since it's safe. If this process can't tell for sure if a contract is secure, why make it mandatory and make it more difficult for soroban to emerge? imo, there could be a similar alternative that makes this optional, a selection of (community?)-voted contracts, without permissioning the whole network. I should also say that I'm not familiar with how chains with permissioned contracts work so feel free to correct me if some claims are incorrect 

[Tomer Weller]

> The role of validators is to ensure people play by the rules, not to judge what people do within those rules

Validators also get to decide what these rules are. Currently, they do it by voting on protocol changes. What Orbit proposes is effectively allowing developers to propose new rules without vendoring these into stellar-core as part of a protocol change. If we trust validators to vote on new functionality via protocol upgrades - why not via smart contracts as well? 

   

--
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/8735dledel.fsf%40ta.scs.stanford.edu.

[Paul Bellamy]

Personally, if this were implemented, I don't see why ecosystem devs would want to beg and campaign to get their contracts approved and deployed on Stellar when there are other chains without that restriction.

Also, having validators "approving" of specific smart contracts seems like it might open them up to liability, but I am not a lawyer.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/CALTyOpGOaHkfuMDjuYoVDeEC2mFS6CXQ3dWwHkKWXGtMyrKgKg%40mail.gmail.com.

[Markus Paulson-Luna]

Thanks for kicking off this discussion!

Couple of thoughts on this

I definitely get the sentiment; watching users lose funds due to smart contracts that were clearly not trustworthy in the first place sucks. That being said, I see a few large issues with implementing this at a protocol level:

1. Voting on a contract deployments will probably lead to a large amount of bureaucracy and politics. This is a fairly big issue in the Cosmos ecosystems where deployment whitelists are used. I'm very worried that adding political hurdles to developing Stellar smart contracts will drive away most new developers and significantly slow innovation.

2. Also not a lawyer, but I agree with what Paul said regarding validator liability. Approving contract deployments could be seen as taking some level of responsibility for what gets deployed on-chain. Running a Stellar validator is a fairly charitable thing to do as there is no economic incentive. Asking validators to also take on potential legal risk is probably a really hard sell.

3. I don't think this will accomplish much in the way of protecting user funds. As Tomer said, bugs will inevitably slip through. Furthermore, the majority of large exploits in DeFi/GameFi are the result of well-known contracts getting exploited. These contracts would probably have been whitelisted if they applied. Furthermore, there are already plenty of opportunities to scam users without needing smart contracts. We see constant phishing hacks, and plenty of sketchy liquidity pools have taken users' money by utilizing Aqua bribes. I have difficulty believing that smart contracts are significantly better tools for stealing from users' funds than the tools already available to bad actors.

So overall, pretty against deployment whitelists at the protocol level. I think it'd make more sense for individual horizon instances to decide to censor certain contracts. This wouldn't create the same political hurdles for new devs as they could always host their own Horizon instance (more horizon instances is good right?). It doesn't create any liability for validators. And it's probably almost as effective at protecting the average user as protocol-level censorship would be.

[Enrique Arrieta]

This is a subject I'm really interested since I'm always explaining others how to identify scams on internet so they can avoid them.

I also believe is important to think about how to avoid scams (otherwise we will never reach relevant adoption and respect) but in my opinion the help should be done at an application level and not at the core level, the Internet grew and evolved so fast because everybody can work on top of it easily and no one can stop an indie dev in creating a game and publishing it.

But because we know that's also dangerous we have created our own check tools: Email spam filters, browsers alerting about visiting a website where the SSL suddenly is not valid, private owned stores where only whitelisted apps are listed, etc... Why not doing the same in Soroban? IE it's open and easy to work with BUT we start having standards to apply checks on top of it.

I would prefer having a rating system at the core level (I know rating systems can easily be abused but we can minimize it by whitelisting reviewers and having collaterals from reviewers too so there is skin in the game) so wallets and services can consume data to alert (not block) users so they are aware of what is going on. For example as soon a wallet see that a contract has a rating with zero it can alert the user that there is a risk with those contracts and that it should be careful about it

This way tools can decide how to alert the user and at the same time the user is free to interact with what they want, blocking content can be stressful and for example I can't use my bank's phone app because my phone is in developer mode and they have decided that no developer phone can use their app because is dangerous for the user (could have installed an scam app)... that's not protecting me, it's actually keeping me out of the service.

Lastly with the liability from the validators, even if there is no legal risk they will also be gatekeepers and I think that could also create a situation where a kind of business that is not well accepted by the community could be left out just because of subjectives opinions from the validators

That being said, thanks for bringing the debate to the table and looking forward in reading more points of view

[David Mazieres]

Tomer Weller <to...@stellar.org> writes:

>> The role of validators is to ensure people play by the rules, not to
> judge what people do within those rules
>
> Validators also get to decide what these rules are. Currently, they do it
> by voting on protocol changes. What Orbit proposes is effectively allowing
> developers to propose new rules without vendoring these into stellar-core
> as part of a protocol change. If we trust validators to vote on new
> functionality via protocol upgrades - why not via smart contracts as well?

Rules are general constructs that apply to multiple tokens and
contracts. Smart-contract endorsement is all about opining on specific
pieces of code. We want validators to agree on useful functionality for
all tokens, which requires consensus on the rules. We don't want them
combing through financials and reading through source code to decide
which particular tokens are worthy of being traded on Stellar; that's a
subjective decision best left to ecosystem software like wallets, or to
individual users.

Besides, if new APIs must be approved through consensus, it's not right
to call them them smart contracts--they are just protocol upgrades
(albeit in a safer and more modular stellar-core).

Anyway, if we build an external smart-contract endorsement system and it
turns out that today's validators are exactly the group that wants to
run it, then they can--no harm done. On the other hand, if we bake
endorsement into stellar-core such that it requires the participation of
validators, and that approach turns out not to work (which I'm convinced
will be the case), then you've killed the ecosystem. We'd be crazy to
take that kind of risk.

David

[Gleb Pitsevich]

Orbit and everyone, thanks for sharing your thoughts.

We are against whitelisting of smart contracts on the network level.

Having some kind of smart contract reputation informational system adopted by the ecosystem would be great though.

Few thoughts from our end.

- As a Stellar validator, I don't think us or other network validators are qualified to evaluate the security of smart contracts and the quality of their development teams. I don't see the incentives for validators to invest their time into research, read audit reports, etc. The above applies for an average XLM holder too - they don't have the expertise and lack incentives to do the research. It seems that the system would require some kind of vote delegation mechanism, which brings additional complexity.

- Many form of voting would be vulnerable to bribes (voting rewards offered by projects).

- I don't think there should be some kind of "Smart Contract Council" (validators, or delegates) that makes a decision whether a specific smart contract is allowed on the network. It raises so many complicated questions. UST had no bugs per se, it worked as designed in the code - should it be approved or not? 
- As mentioned by others, it seems that majority of funds are stolen from popular protocols. Together with the TVL growth, incentives are growing for bad actors. Hackers are motivated to find bugs in existing successful products, the ones that have already passed the whitelist filter.

- A team building a novel idea might decide to not go through the extra hoops of getting approved and convincing voters instead would just build their project on another chain.

- There's no whitelist for token issuance, why should there be one for smart contracts?

Gleb .

[Tyler van der Hoeven]

Not a whole lot to add to the conversation but wanted to jump in on the side of please let's not do this. Implementing this on any other chain wouldn't have stopped the majority of any hacks so the initial objective wouldn't be resolved. There may be something to be said for mission oriented audits based off current validator objectives but even here I'm opposed. The whole point of adding smart contracts is that our current use case scope is bigger than what we're currently doing and locking in or throttling what can be done and who can do it down to current validators would be a mistake in my opinion.

It does beg a much larger question though around incentives. Why allow more functionality at all? All the current validators are doing their own thing with the network, what's their incentive for allowing more varied usage? Why not just lock it down or at least require use case oriented network cloning? (Stellar NFT Network anyone?? What better network to bridge to than our own?) I see a pretty significant long term elephant in the room around whose paying for this network and why will they continue to foot that bill for businesses dissimilar, disassociated or even destructive to their own? Other business models don't have to be evil to be destructive to the tier 1 validator network. NFTs, micro payments, lotteries, shipping, arbitrary data storage, etc. all can be viable interesting use cases that could result in a net negative for tier 1 validators.
The noble, decentralized thing to do would be to let everyone in but there absolutely will come a point when the cost to do so will become prohibitive to doing business and alternative options will be sought out. Constraints, limitations and scope are essential for the longevity of an open network and you don't need the whole world's participation in order to reap the benefits of decentralization. Stellar tech provides great payment primitives however the use of these primitives are not all harmonious. This will 100x with the release of Soroban on the public network. Divergence of interest and mission alignment will happen eventually but baking it in early as a requirement is absolutely the wrong move. Innovation, freedom and inclusion will solve the problems it creates. Whitelisting, auditing and restrictions will just give us more of the same of what we've had for hundreds of years.

tl;dr don't solve problems we don't yet have with solutions that don't actually work. Err on the side of open innovation.

Tyler

[Orbit Lens]

Thanks for all the feedback on this topic. The majority of the arguments against the semi-permissioned contracts deployment also occurred to me, but there are many truly interesting points and totally justified questions.

Unfortunately, I don't have a finalized vision of a flawless voting method. Yes, each one of the discussed mechanisms has its own weak spots. And yes, I definitely agree that employing an intrinsically flawed procedure of contracts deployment will do more harm than good. Thus I don't really have a strong stance on this. But let me ask a few honest questions before we rule out this proposal entirely. 

First and foremost question is how we all see the primary focus of Stellar network? If you ask me, I'd say that the original "move money like email" moto gradually evolved to "move money through compliant international remittance network". The lion's part of all CAPs and SEPs (not to mention documentation) are that way or another focused on compliance and remittance interoperability. Not to mention recent strategical partnerships and active Denelle's work on blockchain regulation. This is quite cool because it provides a huge competitive advantage over other blockchains, addresses real-world use cases, and provides the clear strategical direction. I think we all can agree on this.

Can we build other types of blockchain application on top of this technology? Absolutely! At least until it doesn't contradict the main vision.

So is it possible for Stellar to beat competitors in other fields? Like NFT, DeFi, GameFi, Data Storage, Supply Chains Tracking, or a general "Distributed Computer" Ethereum thing? Well, yes, but the chances are quite small because of the well-known network effect. To do so we need to focus resources and elbow our way through a tightly packed crowd. Let's take NFTs for example. LiteMint built a great platform for NFT creators. People enthusiastically create NFTs and trade them. The number of Stellar-minted NFTs is growing super fast. Yet if we try to check the overall trading volumes for this segment, it wouldn't be so impressive. Frederic built a very cool Stellar->Ethereum NFT bridge. These efforts along with SEP standardization definitely push the evolution of Stellar NFT space. On the other hand, we have to admit that putting your NFT as Twitter logo or selling it on large marketplaces like OpenSea requires Ethereum bridging. The network effect and the head-start of other chains in this direction make it really hard to compete in this market. We had a good chance to become a leading NFT blockchain (or at least secure the second place) back in 2017-2018. Back then I advocated for Stellar-based NFTs, even proposed minor protocol changes to address NFT trading issues. However, all these initiatives were discarded by the committee because they were not aligned with the primary focus. And now talented artists creating NFTs on Stellar don't receive the well-deserved attention and traction despite the very convenient LiteMint platform and the buzz around it. Simply because of the network effect and the head start of other chains.

Now, do we anticipate that once Soroban hits the mainnet, developers from other of EVM-like chains will start to massively migrate to Stellar? Do we have some killer feature? Will it be significantly better/faster than Solana, Avalanche, BSC, and hundreds of other EVM-like chains? The network effect plays against us here as well. Introducing a general-purpose Turing-complete chain might attract the attention of all blockchain world somewhere in 2017, but not today. 

Up next, what kind of smart contracts we can expect to see on Stellar mainnet? We have several strong teams and a bunch of talented indi developers in Stellar community who can create some novel projects or creatively re-tinker existing ideas. The next, larger, portion of smart contracts will be simply copy-cat clones of Ethereum/Solana/BSC/{name_your_chain} projects, with their security entirely depending on how good the code will be adopted to Soroban execution specifics and pitfalls by developers who never coded anything on Stellar before. And the majority of remaining contracts will fall under category of rug-pull projects. Regular people will lose millions of dollars because of the careless or straight malicious developers. Not very bright perspective, isn't it?

Ok, what are the benefits of having a chain with limited number of "permissioned" smart contracts? Why would users choose Stellar over other networks? What's the selling point in this case? And how it aligns with Stellar mission? The answer is simple -- we can try to make a "safe place" for people. Those who utilizes Stellar for remittance, can also use its smart contract capabilities. The same users from Argentina, Mexico, Africa, or any other part of the world who open a remittance account on Stellar can benefit from cheap loan, or make some money depositing to the liquidity pool, or gain direct access to advanced financial tools like options and derivatives. And safety is probably a key requirement here. Today, in 2022, there's absolutely nothing unique in smart contract chains, we saw plenty of them. Yet that's a Wild West landscape -- one can make a fortune (rarely) or lose everything (much more often) in a matter of days. The niche of a "safe haven chain" is vacant at the moment. Without any doubts, Stellar is a perfect fit here. So maybe we are ready to claim it?

Another point mentioned in responses: we didn't put any restrictions on asset issuers which in turn stimulates devs to create new assets and experiment. Is this bad? Yes, at this stage. Our ledger is clogged with garbage coins. Probably 95% of all newly issued assets (if we don't take into account thousands of garbage NTFs that pose another problem by themselves) are currently created by scammers. Users lose money daily. I lost count to support request emails from people who ask why the coin X went to zero or why a trustline was suddenly deauthorized. Don't have a fresh statistic, but we are probably talking about millions of dollars stolen. We, as developers community, don't invest enough effort to deal with this problem. Moreover, right now there's no straightforward solution aside from asset whitelisting on the wallet side, as we can only react retrospectively on malicious assets after some users have been already scammed. It's easy to forget that almost every day some unlucky and not-so-tech-savy users next to us lose their life savings. 

What about the innovations? If we don't allow unrestricted smart contracts deployment, will we lose the innovation edge? I don't think so. If you want to test your new super-bizzare idea in the real world, you can choose any of the 100+ existing turing-complete blockchains. And if the idea worked -- backport it to Stellar. High-quality projects will make it to the mainnet despite all the obstacles, we can see how this works with SCF contest. Again, clones of successful smart contracts from other chains will receive more attention to their code quality (I know that's not a panacea from hacking, but better than nothing). As I mentioned in the previous paragraph, we need to remember we have unrestricted innovations vs peoples money on the scales. It's crucial to find the correct balance.

Maybe we can delegate dealing with the problem of bad contracts to the wallets? We can. And I know in advance which wallet developers from our community will take this seriously and try to protect their users. However, judging from the success of other initiatives, we can't expect the ubiquitous protection. If you want an example, let's recollect the muxed accounts story. How many wallets and exchanges support the muxed accounts functionality introduced awhile ago? Or how many wallets block transfers to accounts tagged as malicious?

Regarding the legal implications. Do you really think that blindly allowing to execute arbitrary contracts on your validator node is safer from the legal perspective than participate in a more or less formal group audit of the smart contracts? What if the governments decide that you are liable by default for letting scammer to steal money from someone's account only because your node signed the block. Fortunately, we haven't seen such precedents yet, but the crippling blockhain regulation definitely heads in this direction. So this remains an open question.

Lastly, I have to admit that I didn't put enough time into thinking over all these profound problems. But since the release of Soroban is inching closer, it seems important to me to share my half-baked thoughts on possible implications. If there's another way to achieve the aforementioned "safe haven chain" status without sacrificing anything, I will be really glad to avoid the contract deployment restrictions.

OL 

[Frederic Kyung-Jin Rezeau]

Thanks for the shoutout.

> If there's another way to achieve the aforementioned "safe haven chain" status without sacrificing anything

Besides affecting the permissionless nature of Stellar, this voting solution would not be scalable if we look at the latest developments in this space, where smart contracts are evolving from basic, immutable blocks of code to proxied, upgradeable and governable entities (smart contract governance). In fact, smart contract governance frameworks are huge part of the solution and can address a much wider range of issues for building safeguards, mitigate risks and provide guarantees for smart contract users, without affecting permissionless blockchains.

All the best,
Fred

[Jake Urban]

Hey Orbit, I really appreciate your honest assessment of where Stellar is relative to others in the space. We need more of these open conversations to make sure we're making the right decisions.

While I completely agree that we should be increasing our focus on keeping the ecosystem safe for the "mainstream" user, I don't believe validators are the right group to take on this task. Applications are ultimately the ones responsible for protecting their users and have the incentives to do so.

I also don't believe Stellar would develop a significant advantage because we have a semi-permissioned network. Users are't impressed with safety, they expect it. To gain a significant advantage, like you said, we need an ecosystem that is objectively more useful or better in some way (if not many ways). Creating a semi-permissioned network would only insert a bottleneck in our ability to develop those advantages. When we are an undeniable leader in the space, thats when we can afford to sacrifice innovation for safety at the network layer.

[Clément Hallet]

Hello,

Jumping in the conversation with my 2 cents : what about a community code-review and insurance feature at the network level ? Something like a locked fund pool associated with each smart-contract, progressively funded by individual accounts after the deployment.

That is of course a whole new set of governance questions (for instance : how are the insurance contract terms decided and then evaluated ?).

That would still have the benefit to remove the upstream bottleneck told before and to replace it for an « not all-or-nothing, decentralised » protection. 

-- 
Clément

-- 
You received this message because you are subscribed to the Google Groups "Stellar Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stellar-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/stellar-dev/2f826734-fbca-4433-a850-6e2389774044n%40googlegroups.com.

[Nick Gilbert]

Hello, 

This is both an interesting and important discussion about what we want the future of Soroban and Stellar as a whole to look like, and as Orbit rightly points out, what we can learn from the successes and failures of other chains to make soroban something unique for the world. 

I'll start out by laying out how I think about this problem, I don't think there is a right answer to this question there are only trade-offs along a continuum between fully permissioned and fully open and we are trying to figure out an optimal point on that continuum which maximizes open access while minimizing "bad" behavior. But it is worth remembering If our mission is open and equitable access to the financial system, and we believe that the future financial system will be underpinned by decentralized smart contracting platforms like Soroban, its critically important that we don't repeat the mistakes of the existing system and put in place systems for exclusion which limit access unfairly or in-equitably. Which is to say we shouldn't set up a system which can be used by a small set of early adopters or powerful participants to block access to new entrants by imposing arbitrary barriers. 

Because of the risk of potentially blocking access and undermining the mission my default safety position is permissionless access, this protects equitable access in the short term but as pointed out by many in this discussion it will be equitable access to rug pulls and scams alongside innovative products in the near term. Followed by diminishing access in the longer terms as state and block contention increase and costs eventually crowd out the users with the fewest resources. 

I don't have a concrete proposal yet, but as Fredrick mentioned there is a lot of really interesting work being done in the governance space and I think we can look to that work to inspire some of our thinking. One that I recently came across was Colony.io. They build generic tooling for running DAOs, the overall system design is interesting. but the part I think is most relevant to this discussion is what they call lazy consensus. Their overall view is that voting is a huge waste of time, and should only be necessary in case of a dispute. So they designed a staking and slashing system with both a fee and a reputation component which only invokes a vote if someone is willing to challenge a change and put at risk sufficient reputation and financial stake. The entire white paper is interesting if designing governance systems is something you are interested in. 

What an approach like this gives you: 

• Contract submitters need to put up a bond to publish which is at risk during the challenge period acting as a barrier to spam.
• Votes only happen if someone is willing to put up stake to challenge, it incentivizes enforcement by rewarding participants who identify submissions which go against community wishes, because it's a bet on whether the vote will succeed if called.
• Loser of the challenge has their stake slashed based on how uneven the vote outcome, i.e if 90-10 vote you lose a lot, if 60-40 you lose very little. So obvious bad actors are severely punished, contentious disagreements between good actors are minimally penalized. 

What this doesn't answer:

• They have a domain and reputation system which signals who should have a say in the decision, in the context of a DAO that is modeling a traditional organization, i.e marketing domain, frontend dev, back end dev, when layered with reputation allows the system to identify who should weigh in. The question is who should way in on whether a contract should be deployed? Is it validators who provide the underlying compute, is it the developers who deploy contracts to soroban, applications developers who act as representatives of user interest..etc. 
• Would only gate deploy so you could block a new contract but not takedown an already approved one.
• What type of contracts are in scope, is it every contract deploy can be challenged, just new ones, as noted above what does that mean if there are multiple interacting contracts. 
  
• What new attack vectors does this open up, could an attacker could delay a fix by challenging it to a vote while an exploit is on-going for example.

I think the above possibilities are interesting and it would differentiate Soroban and Stellar in interesting ways, but it also opens a number of complicated questions that need to be answered in order to execute it well. 

-Nick