一个智能契约所能支持的最大数据和程序复杂度是什么？

Question

我想为P2P交易订立一份明智的合同.我在徘徊，如果我必须为每一个投标和两个实体之间的协议建立单独的合同，或者我可以简单地创建一个包含所有出价和用户之间协议的单一合同？

只有一份合同将方便访问它，因为我只需要管理一个地址，但是，如果我将有多个合同，我如何管理他们？特别是如果我将使用oracle允许外部设备提供一些外部数据的合同。

谢谢。

Answer 1

在这种情况下，我通常使用的是一个“主”合同，其所有者是平台，并为每个“细节”合同部署一个单独的合同。在您的情况下，我的建议是将每个投标都放在单独的合同中，您可以在其中存储投标人地址，甚至可以设置一个不是平台的所有者，并将每个投标合同的地址存储在主合同中的映射中。

使用这种办法将使平台能够“控制”投标和投标人在不通过平台的情况下处理投标。根据我的经验，它也使代码更易于编写和维护。

Answer 2

复杂性或数据存储没有上限，但也存在需要注意的约束。

主要约束条件是最大交易气体成本(即a)。块gasLimit，这是一个由矿工投票表决的可变网络属性。这是单个原子事务计算复杂性的上限。隐式地，这是对可以一次部署的契约的最大大小的限制。

将大型合同分解为由较小的契约组成的系统是很有用的，这些系统可以相互作用，以确保任何单个组件都不会太大而无法部署。正如Marco指出的，您可以(而且应该)严格控制对每个组件的访问。

虽然在合同状态中存储的数据量没有上限，但是有两个因素在你的头脑中。

1. 避免迭代过程。你需要确保所有相互作用的气体成本是规模不变的。见此处：是否有妥善解决的和简单的存储模式的坚固性？和https://blog.b9lab.com/getting-loopy-with-solidity-1d51794622ad
2. 请记住，这个系统在财政上是有限的。数据集可以是您和您的用户愿意融资的大小。因此，虽然理论上可以用大量的数据填充映射和数组，但可负担性说明了另一个问题。

同样值得记住的是摊销工作的想法。我认为这句话是尼克·约翰逊首次提出的(在上文所链接的条款中有提及)。基本上，如果将状态转换建模为多个较小的原子事务，则状态转换的复杂性没有限制，但每个原子事务必须始终在气体限制范围内完成。

希望能帮上忙。