智能合同中的密码签名->验证智能合同的身份

Question

简而言之，我的问题是：

->是否有可能通过智能合同(例如用合同的秘密密钥)对某些数据进行数字签名，从而确认正是这个智能合同签署了这些数据?我已经知道，它可能不会那样工作，因为合同的数据和代码是完全公开的，因此它不能保密。那么，有什么聪明的链上的解决办法，还是我必须使用链外的步骤与这个..？

现在有一些背景：

我正在尝试创建一个dapp，其中创建者可以对一个文档进行签名，并在Blockchain上加盖时间戳，这样任何人都可以验证文档是否在某个时间点出现问题。

到目前为止，我的概念是：

1. 文档得到散列，然后由创建者的私钥(客户端，离链) ->签名，从而创建文档的数字签名
2. 然后，签名被发送到一个智能契约，该契约将时间戳附加到签名中，将两者混合在一起，然后契约将哈希签名)(时间戳表示当前块的时间)
3. 契约存储一个映射，其中每一行(每个文档或其版本的一行)都使用文档的散列进行访问，指向一个带有:时间戳、创建者签名和契约本身签名的结构。
4. 现在，任何访问文档、创建者公钥和契约公钥的人都可以验证(在映射中使用签名的散列)，

( a)文档由创建者签名

( b)该文件已加盖时间戳，并由smart合同签署

->我最初的目标是避免将可信的第三方包括在流程中(既不用于时间戳，也不用于签名)。

所以问题似乎是：

->，因为智能契约不能在链上存储秘密(据我所知)，所以我无法在合同中安全地存储私钥，它可以用它来签署数据。

->还说，如果我将一个秘密密钥存储在链外的某个地方，那么如何授权智能契约访问它呢？(因为它没有可识别的私钥)

如果你能帮我，那就太棒了！谢谢!

Answer 1

是否可以通过智能合同(例如，使用合同的秘密密钥)对某些数据进行数字签名？

不是的。契约没有签名密钥，无法启动操作(它总是以外部拥有的帐户签署的事务开始)，并且不能与外部世界交互，除非将事件发送到日志中。

我正在尝试创建一个dapp，其中创建者可以对一个文档进行签名，并在Blockchain上加盖时间戳，这样任何人都可以验证文档是否在某个时间点出现问题。

这并不特别难..。

文档得到散列，然后由创建者的私钥(客户端，离链) ->签名，从而创建文档的数字签名

是的

然后将签名发送到智能契约，该契约在签名后附加时间戳，将两者合并在一起。

当事务包含在块中时，您将得到“免费”的时间戳。额外的步骤似乎使情况更糟。您希望观察者能够确认文档(在将来)，并且不应该要求他们知道时间戳才能这样做。只需记录内容的散列即可。

mapping(bytes32 => bool) public exists;

function recordExistence(bytes32 docHash) public returns(bool success) {
  require(!exists[docHash]);
  exists[docHash] = true;
  // should emit an event, omitted for brevity
}

然后契约签署哈希)(时间戳表示当前块的时间)

合同本身没有签字步骤。如果合同允许的话，就是这样。除非合同批准，否则任何状态转换都不可能发生。

契约存储一个映射，其中每一行(每个文档或其版本的一行)都使用文档的散列进行访问，指向一个带有:时间戳、创建者签名和契约本身签名的结构。

您可以使用创建者的普通地址，因为创建者将是发送事务的签名者。我会花时间做这件事，但可能不需要。

struct DocStruct {
  address creator;
  uint timestamp;
}

mapping(bytes32 => DocStruct) public docStructs;

function docExists(bytes32 docId) public view returns(bool doesIndeed) {
  return docStructs[docId].timestamp > 0;
}

function recordDocCreated(bytes32 docHash) public view returns(bool success) {
  require(!docExists[docHash]);
  docStructs[docId].creator = msg.sender;
  docStructs[docId].timestamp = now;
  // emit ... 
  return true;
}

现在，任何访问文档、创建者公钥和契约公钥的人都可以验证(映射中有签名的散列)，( a)文档是由创建者b签名的)，文档是经过时间戳并由智能契约签名的。

是。msg.sender不说谎，now也不说谎。覆盖是不可能的。

我最初的目标是避免在流程中包含可信的第三方(既不用于时间戳，也不用于签名)，因此问题似乎是：->，因为智能合同不能在链上存储一个秘密(据我所知)，我无法在合同中安全地存储一个私钥，它可以用它来签署数据。

一起踩你的脚后跟，你已经回家了。AFAIK，文档的散列并不意味着是秘密。除了它存在之外，它没有任何关于文档的有用信息。你有证据证明造物主在某一时刻签署了一条信息，展示了这个秘密的知识。

签名者(创建者)发送的事务被挖掘成一个具有明确timeStamp的块。当有人用有问题的public docStructs检查docHash时，返回的值是值得信任的。

已知唯一可行的解释(Alice没有时间机器)是创建者在历史上的一个可证明点签署了一个具有文档知识(并计算其散列)的事务。除非她有那份文件，否则她不可能猜到那个哈希。

这是一种常见的做法。如果您需要对文档中的内容进行更细粒度的证明，同时又将相邻的信息保密：https://medium.com/@robhitchens/selective-disclosure-with-proof-f6a1ac7be978

希望能帮上忙。