Ethereum合同可伸缩性(单个合同与多个合同)

Question

我正在上编写一个令牌交换合同，以便在交换中管理ERC 20令牌交换。

问题是，在可伸缩性方面，考虑到exchange将处理多达100万用户，以下两个选项中哪一个会更好。

选项1创建多个合同，每个合同负责交换单个对。这可以在单个合同上分配工作负载。

选项2创建一个单独的契约来管理所有令牌的交换。考虑到区块链可以以分散的方式处理处理，并且智能契约能够并行调用多个方法而不影响性能，则可以使用此选项。

那么，哪一个选项将是正确的，并更适合于有最多100万用户的Exchange

Answer 1

这是一个有许多不同因素的大设计问题，因此没有一个简单的答案(例如，任何分散的交换，如雷达中继或流动性的空中交换，都必须解决类似的问题，而且他们可能还没有一百万用户:)

你在讨论连锁订单的实现问题。与选项2中的所有对共享一个订单簿相比，每个交易对拥有不同的订单簿确实更具有可伸缩性，因为每个新的块需要15秒。你不希望volume的限制影响你的交易量。

然而，在我看来，将订单保持在链上并不是一个可行的解决方案。

像Loopring这样的系统试图使用零知识证明将交易规模扩大到每秒大约2000次交易，所有的交易都是分批在一起的，当达到足够的阈值时，只有在链上提交最后的状态来更新订单。