分散式多卖方销售平台的体系结构最佳实践

Question

我的问题围绕创建分包合同和创建合同的最佳实践。

故事:我正在创建一个工具来帮助人们购买小部件、小玩意和棘轮，所有这些都是通用商品。让我们把这个工具叫做ACME工业。现在，ACME并不提供这些产品--其他实体向ACME发送了乙醚的押金，以及每种产品的价格，并被列为卖家。一个买家来了，点击小部件，从卖家列表中选择，把乙醚放入合同中。一些逻辑发生，然后他得到物理的东西，卖方得到乙醚和审查与ACME。

问题

• ACME本身就是一份合同(我认为)--它具有像registerSeller{}这样的功能，需要分散和透明。它还需要保存像uint => address[]这样的映射。或者它可以仅仅是一个创建契约的JS框架(比如acmePurchase{})？
• 小部件、小部件和棘轮应该都有一个单独的地址来创建合同，还是应该将这些信息附加到订单数据中？

示例：

// Product type contained in message
{"value": 555, "sender": "0x0...", "data": {"seller": 23, "product": 2}}

// Product and seller defined by address ether is sent to
{"value": 555, "sender": "0x0..."}

我想我很难理解这里的体系结构(相对于集中式事务数据库)的根本差异。

Answer 1

数据结构是一个需要解决的挑战。数据实际上是以一种顽固不变的方式嵌入到程序中的。

最简单..。与结构、数组和映射的整体收缩。在实践中，我发现一个很好的模式是使用到struct (details)的映射、数组中的键(索引)以及返回数组长度的函数。这样，您的客户端就可以在键上迭代，并通过映射调用其他函数来处理结构。

中间..。使用集线器的集线器和辐式体系结构，在集线器内/由集线器生产的合同工厂中生产卖方合同。集线器跟踪它创建和“拥有”的卖方合同。互动就会发生。卖方合同只听取“所有者”的命令，后者是集线器。有些功能只听取卖方的意见，例如设定价格。

最好..。在契约中拥有数据(它总是如此)也意味着，如果没有一个空的数据存储，合同就不能升级或修复。呀！将存储和逻辑问题分离为单独的契约。让逻辑契约“拥有”数据契约，并使这种所有权安全地转移到升级的逻辑契约中。

更新:参见这里的一些示例模式：博客:实体中的简单存储模式