英文:
What happens when you write an erroneous smart contract that is pushed onto the blockchain?
问题
"Since it's the blockchain you can't remove it. What if the erroneous code isn't some benign, what if it can cause damage to the company's business. So for example flooding the company's own API with requests effectively DDoSing itself. That's probably a bad example but my question is what can you do if a smart contract with erroneous code is pushed, what are the steps you can take to stop the smart contract from function?"
"如果它是在区块链上，你无法移除它。如果错误的代码不是无害的，而是可能对公司业务造成损害的话，怎么办呢？例如，用请求来淹没公司自己的API，实际上是在对自己进行DDoS攻击。这可能是一个不好的例子，但我的问题是，如果部署了有错误代码的智能合约，你可以采取哪些步骤来停止智能合约的运行？"
"If the question doesn't belong here, I'll move it elsewhere. As long as I am directed to the right place to ask the question."
"如果这个问题不适合在这里提问，我可以将它移到其他地方。只要我被引导到合适的地方提问问题即可。"
英文:
Since it's the blockchain you can't remove it. What if the erroneous code isn't some benign, what if it can cause damage to the company's business. So for example flooding the company's own API with requests effectively DDoSing itself. That's probably a bad example but my question is what can you do if a smart contract with erroneous code is pushed, what are the steps you can take to stop the smart contract from function?
If the question doesn't belong here, I'll move it elsewhere. As long as I am directed to the right place to ask the question.
答案1
得分: 1
尽管智能合约的字节码是不可变的，但升级智能合约有两种基本方法：
- 部署新版本到不同的地址。
- 使用可升级代理模式。代理合约保存状态（例如存储值）并指向可变的实现合约。
第一种方法的示例是Uniswap。他们目前使用大多数用户正在使用的v3版本，与他们的用户界面连接在一起，但之前的合同（v1和v2）仍然可用，并在某种程度上使用（我猜主要由交易机器人使用）。
其中一个缺点是需要将数据迁移到更新版本的合同。因此，在这种特定情况下，Uniswap还发布了半自动工具，供提供流动性的提供商（他们的用户类型之一）将其流动性从v2迁移到v3。
使用第二种方法，数据仍然存储在同一个代理合约中，而实现（实际代码）合约可以更改。这涉及到一组不同的挑战，例如实现合约之间可能发生的存储冲突。
已部署合同的销毁取决于网络。
在以太坊虚拟机（EVM）网络上，有一个已弃用的本机函数selfdestruct，它将在未来版本中禁用，它允许调用者（在大多数情况下，它被授权机制包装）销毁合同。在它被禁用之后，将没有任何方法来删除已部署的代码，但增加区块链的大小可能会在以后再次引发讨论。
在一些其他网络上（例如Solana），您有选项租用存储槽，而不是不可变的状态更改。因此，如果您在一定时间内不续租，它会禁用合同功能，这也可以作为一种保险机制。
英文:
Even though smart contract bytecode is immutable, there are two basic approaches to upgrading smart contracts:
- Deploy a new version to a separate address.
- Use an upgradable proxy pattern. The proxy contract holds the state (e.g. storage values) and points to a variable implementation contract.
Example of the first approach is Uniswap. They're currently on v3 that is being used by most users and is connected to their UI, but the previous contracts (v1 and v2) are still available and being used to some extent (my guess is mostly by trading bots).
One of the downsides is a need to migrate data to the newer version contracts. So in this specific case, Uniswap also released semi-automated tools for liquidity providers (one of the types of their users) to migrate their liquidity from v2 to v3.
With the second approach, the data is still stored in the same proxy contract - while the implementation (the actual code) contract can change. There's a different set of challenges, for example possible storage collisions between the implementation contracts.
Destruction of an already deployed contract depends on the network.
On EVM networks, there's a deprecated native function selfdestruct that will be disabled in future versions, and it enables the caller (in most cases it's wrapped by an authorization mechanism) to destruct the contract. After it's disabled, there won't be any way to remove an already deployed code but it's possible that increasing size of the blockchain will open this discussion again later.
On some of the other networks (e.g. Solana), you have an option to rent storage slots instead of the immutable state changes. So that could also serve as a failsafe mechanism if you don't prolong the rent in X amount of time, it disables the contract functionality.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论