令牌&智能合同“升级”

Question

我不是很专业，但我有个问题。

假设智能合同正在升级为新合同，那么新合同中是否有可能不向某些钱包发送新的令牌？

因此，例如，如果钱包XXXXX是一个已知的黑客基金的稳定者，那么钱包XXXXX不可以从新合同中得到代币吗？

Answer 1

是。您可以在契约中实现一个简单的逻辑：

例如：

 mapping(address => bool) public hacker;   
     function doSomething() public {
         require(!hacker[ADDRESS_TO_CHECK]);
        //continue
    }

Answer 2

假设智能合同正在升级

让我们把它拆开。首先，我认为这取决于你所说的“升级”是什么意思。

显式行政特权

合同可以写成黑名单。因此，它只需要输入一个特殊的用户谁决定谁列入黑名单，每个人都会看到的程序，以黑名单，或决定参加或不。这两种情况都有很好的论据，这取决于您想要证明什么。

function blacklistUser(address badguy) public onlyAdmin {
  badguys[badguy] = true;
}

在其他地方，确保这不是个坏人：

require(!badguys[msg.sender], "You are a badguy. Go away.");

诚然，这一概念过于简化，只是说明了这一概念。

在这种情况下，契约本身不需要升级，因为它清楚地说明了管理员在当前合同上下文中拥有的特殊特权。

可变逻辑

有几种模式用于启用对契约逻辑本身的更改。也就是说，一种使旧规则不再适用的方法，现在就开始新的规则。

开发人员将把这些可升级的合同称为。当它存在时，可升级性是显而易见的，这在很大程度上是因为它的实现并不简单。让这一切发生的代码真的很突出。我无法想象有一种方法可以对代码评审人员隐藏它，因为有这么多额外的东西。

我不想做一个例子，因为这是一个很大的话题，只是说这个想法是从一开始就把逻辑委托给可互换的部分，然后实现一种交换组件的方法。这些委托和交换逻辑的方法是非常明显的。

在大多数情况下，可升级的合同挫败了不可变软件的保证。任何事情都是可能的，因为我们不能确定这件事将来会做什么。

不可升级的合同不能转换为可升级的合同。也就是说，如果没有升级能力的迹象，那么你可以放心，规则不会改变。

如果您对此主题感兴趣，可以通过链接查看此概述：https://medium.com/hackernoon/trustless-upgrades-in-solidity-bf0bd4047d28。

希望能帮上忙。