The current idea is to have a n-of-m (probably 2-of-3) multisig address that could broadcast a “disable EVM” and “reenable EVM” message to temporarily disable any contract execution in case anything funky happens.
This would be disabled a couple of months after the Metropolis (official stable production) release of Ethereum.
The holders of the keys would be a few of the devs (is the current plan), though other community / foundation members could also be considered.
I am in favor of this. I think a training wheels approach is wise in this situation.
There will will be those who don’t like the killswitch they can simple wait to use smart contracts until the training wheels come off 2 months after the Metropolis release.
Because stage 1 on testnet would not get enough testing. I’ve never used counterparty testnet. It just wouldn’t get tested at all.
Jumping from essentially no testing to mainnet with no safety net is too big of a jump. We need an intermediate stage.
And this killswitch does not directly control people’s funds. It just temporarily halts EVM execution until a patch can be distributed. If the community decides that the killswitch operators are doing something evil, then we create a fork that disables the killswitch and continue on.
How would that even play out? I don’t see the risk here of deploying on mainnet with no killswitch if people think it’s ready. That’s what Counterparty is. It’s an experiment and boundaries are pushed by putting things into the wild even if you’re not 100% sure it works. If it breaks, then fix it and everyone upgrades, the same way you’d fix it when someone submits a malformed transaction and Counterparty breaks down
A killswitch does control funds because it is a key to that stops execution of all contracts and a fork could destroy the equity Counterparty has built with its users. This software works because everyone chooses to run the same version. There is a real risk here that is just not worth it for the reward.
Why would Reuben or Robby even want that responsibility?
Agreed with Devon. I don’t think that neither Ruben or I especially want the responsibility of the EVM killswitch, but having the capability of shutting down the EVM in a worst case scenario (e.g. EVM-based DOS attacks, EVM security bug, etc) for the first six months or so outweighs the downsides, I think.
The “downsides” being not having this capability, and having to resort to more extreme measures such as a forced hotfix upgrade on a very short timeline – which is always incredibly disruptive. The EVM killswitch allows us to respond very quickly to any EVM issues, without having to specifically disrupt the functioning of the network in other regards.
As far as the EVM being “ready” or not, Devon’s points are valid. It’s not a binary 0 or 1 kind of thing. The EVM is a complex piece of software…we consider it “ready enough” for deployment on mainnet, with certain safety provisions and caps. We do have testnet, true, but time and time again, it’s been shown that virtually no one uses testnet…as Devon said, it would just not get used and tested (recall that the first iteration of the EVM was released on testnet only, and virtually no one did anything with it).
Occam’s razor for me here is that if no one uses smart contracts on the testnet, no one will use them on the mainnet. So, introducing something that’s likely to cause halting errors for the network, by your own admission, is a fairly irresponsible course of action.
Who will use Counterparty for smart contracts? Where are these people?
People don’t send tokens on testnet. People don’t use the DEX on testnet.
If we provide the technology on mainnet so people can use them, they might. Someone might create a smart contract to auction a SATOSHICARD for instance.
I’m not saying I know for sure that people will use contracts. But the fact that no one uses them on testnet is not a good indicator that they won’t.
The Counterparty project has a good history of moving fast and pushing the envelope with technology that actually works. Because of that, it has gotten more adoption than any other asset platform on Bitcoin (citation needed). We should continue doing that. It is, in my opinion, one of the strengths of the project.
The killswitch is a good compromise to that allows us to continue pushing the envelope with working technology while mitigating some of the platform risk.
No one using them on testnet when the EVM was first announced is probably a lack of awareness and documentation (as well as the fact that no one uses smart contracts :P)
Regarding Counterparty on testnet, what exactly is the barrier to testing it there? It’s really easy to use Counterwallet on testnet, burn BTC for XCP, and mess around with assets. You literally just click a different button on counterwallet.io. That’s why testnet exists; to test new features.
I agree that testnet is a very good resource for testing code. In that vein, the EVM announcement notes that the EVM will be tested well on testnet before any mainnet deployment.
Testnet is used to some extent, but you’ll notice that there’s only been a bit less than 3k sends on it, and 952 or so asset issuances …at least according to counterpartychain.io as I am reading it. So, it is nowhere near as used as mainnet. Now, I consider that unfortunate that not many people use testnet for anything, but it makes sense why that would be the case: testing in this sense is mostly a developer semantic…especially with non-developers there’s not much value for it, despite the ease that you may make it to use CW or any other tool. Moreover, the goal of any EVM deployment is deployment on mainnet, where it can be of actual use and value to the entire Counterparty community, besides simple testing of the software with dummy assets.
I wonder such a kill switch is a liability. I can’t see why you would want that and I can’t see suggestion of the basis that it would be used. As others above have suggested, it’s treading on other people’s money… you stop a contract at your risk… and for why. In what case would EVN on CP be a liability… contracts will run against XCP at a cost to the owner and if that cost doesn’t pay well enough for resources, then surely people will not see those scripts run and demand a higher pay. The worst case of EVM failing surely will just hit a brickwall backed by the real world value of XCP; some infinity script bug will just dry up the contract and buyer and owner of EVM contracts beware putting real world assets and their XCP into alpha technology. I don’t see the issue that requires adopting the risk of EVM failure into a kill switch for which those holding it might be legally liable.
Again, I wonder the OP is just putting obvious questions on record, which is fine but again simple answer to simple question… kill-switch is a bad idea.
I never stated that anything is “likely to cause halting errors for the network”, only that if we’re being fully realistic, we can’t guarantee that the EVM will flawlessly function (much like we can’t guarantee that any of the other code will flawlessly function). This is why sane hard caps, EVM safeguard, and so on are being proposed. At the level of issues around specific script executions, gas is the first level of defense here, hardcaps are the second, and things like EVM safeguard (if employed) are the third. The voting period for this gives us all the ability to collectively decide if these are good enough precautions for the prospect of smart contracts on CP mainnet.
Your question as to the value of the EVM is a good question, and it’s one you could have asked when Ethereum itself was being created. It will take several years for the full extent of use cases around smart contracts to really work itself out, but Ethereum is proving that people will build on top of the functionality, if it exists.
On a more immediate level, one of the biggest points of value I see with smart contract support is that we don’t have to hardcode logic to support new features of Counterparty. For instance, the protocol has binary options and contracts for difference support, which was added very early on in its development. These are hardcoded into the python implementation and add a considerable amount of consensus-sensitive surface area for some rather specific features (that in retrospect were not used much).
Without something like smart contracts, any new additional features like this would have to be added into the core protocol itself. Assuming that the EVM tests well on testnet, and we have the appropriate level of safeguards, allowing arbitrary functionality to be coded in without modifying the core protocol itself I would see as a huge plus. It affords much more capabilities to Counterparty, and allows individuals to add functionality without having to essentially petition to get it added to the core protocol.
My inclination is that the kill switch SHOULD for a limited time. During this period users should be warned that smart contracts functionality is in a test phase and they should “use at their own risk.” Once stability has been demonstrated it can (and SHOULD) be removed.
It might help move the discussion further if we discuss WHO will be the key holders if the kill switch is adopted.
Also, we need more details on what it would do. Does it pause contracts? Does it quit the contracts? If so, what happens to the balances?
Why would someone spend real value in XCP when the use of a kill switch hangs over them?
If you’re not confident of the risk, then put it on the testnet with a kill switch that can snapshot what’s going wrong.
The only exception to this is the if Ethereum itself has a kill switch, then perhaps that comes as part and parcel of an EVM and it will not be a limiting factor for users.
In the following thread, Vitalik mentioned kill switches in Ethereum frontier that would be removed in homestead. Don’t know what happened to this issue.
I’m not even getting into killswitch vs. no killswitch: The idea that we should add a killswitch to the live mainchain without testing it first on testnet is fundamentally flawed. It’s flawed for the very same reason you don’t make critical data backups without also restoring from those critical backups! Untested backups and untested killswitches are closely related and both are completely awful ideas.
If you want to have a kill switch, please at least demonstrate its real world usage first and not on a live production system.
The solution is to run testnet, regardless. If testnet doesn’t have meaningful data, that’s an issue with an obvious fix, and the fix definitely isn’t cowboy coding on a live production system.
