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