(一系列文章中的第二篇，对代币销售模式的实施进行了高层次的概述)

在我的上一篇文章中，我讨论了一般的代币销售，并谈到了我们如何在所有的销售中找到共同点，以帮助我们创建标准模型。我还讨论了基本的直接代币销售模式，即贡献者向合约发送以太币，并获得相应数量的代币作为回报。正如我在那篇文章中所探讨的，这种代币销售模式存在固有的问题，尤其是对于对代币有高需求的销售。

你可以参考那篇文章，对这种模式的利弊进行更深入的探讨，但简单地说，虽然这种模式实施起来很简单，也很容易推销，但如果你的组织期望获得任何重大利益和筹款，它是一个糟糕的选择。太多的交易会堵塞网络，富裕的投资者用滑稽的高油价把普通的贡献者挤出去，而且代币不能被广泛分发，这应该是任何ICO的最优先事项之一。

很明显，需要不同的模式，这让我开始讨论另一种著名的代币销售模式。

平均分配的众筹模式

均匀分配，或地址上限，众筹模式是一种试图确保每个想为销售做出贡献的人都有平等的机会。这是通过对一个地址可以购买的代币数量设置上限来确保的。

在这种模式下，所有者还可以选择是否对销售中的ETH总筹集量设置上限。如果有一个募集上限，它可以让参与者了解他们得到的代币的百分比。如果没有募集上限，市场就会根据有多少买家参与，来决定项目的总估值。

你可能可以看到，这两种模式都有一些问题。有了上限，当有足够多的地址参与到销售中来时，它就把任何可能迟到的买家拒之门外，超过了上限。在没有上限的情况下，贡献者不知道销售的总估价是多少，因此造成购买多少代币的不确定性。

幸运的是，0x的伟大团队设计了这种销售模式的一个版本，有助于解决其中的一些问题。当代币销售有大量需求时，在代币销售开始前知道有多少人有兴趣购买代币是件好事，这样你就可以根据需求来迎合销售。因此，在这个模式中。

1. 出售的主人为出售设定了一个最高加价上限。
2. 有兴趣的人在销售开始前有几天时间通过在线门户注册，将他们的地址与用户联系起来，并将他们的地址加入到注册人库中。
3. 当销售开始时， 销售的最大筹款上限除以注册人数，得到个人地址上限。
4. 每个地址被允许在销售中贡献不超过计算的上限。
5. 不可避免的是，一些地址会忘记购买代币或决定不参与，因此在规定的时间间隔后，地址上限会增加，以允许想要更多的代币的地址购买其余的代币。

在深入研究实施之前，我先看看这种模式的一些优点和缺点。

优点。

• 每个想要参与的地址最初都会得到平等的机会来购买代币。高油价在这里没有什么帮助，因为每个人都有权利获得他们分配的代币，无论他们的购买何时通过，只要是在地址上限增加之前的初始时间段内。
• 在销售的第一个时期，没有成为第一个购买者的动机，所以网络拥堵和高油价的可能性较低。
• 如果有足够的需求，确保代币有广泛而均匀的分配。 代币销售的主要目标之一是为其平台创造一个庞大的潜在用户网络，因此允许代币均匀分配对这一点很有帮助。

弊端。

• 只有提前注册的地址才有机会参与，所以如果你是在销售期间发现的，你就没戏了。
• 当最初的购买期过后，地址上限上升时，就会有先到先得的激励，这可能会导致轻微的网络拥堵和高油价。
• 大型买家仍然可以通过创建多个地址来购买大量的代币，这在某种程度上违背了目的，但这更难做到，而且向资金池添加更多的地址会降低每个地址的代币数量，所以有一个权衡的结果。

有一个伟大的分析是由

威尔-沃伦

关于0x代币销售如何使用各种指标的表现。一个有趣的收获是，几乎所有注册的人都是在注册窗口的第一天注册的。他们能够注意到后来几天发生的Sybil攻击，然后决定缩短注册时间。

另一个观察结果是，即使注册者通过整个第一阶段的时间来购买他们的代币，仍然有很高比例的人试图在第一天快速购买，造成一些网络问题。由于这个原因，保持上限变化之间的时间段相对较短，如1-2天，取决于销售的需求，这可能是一个不错的选择。

实施

现在，我们将开始简要讨论图书馆如何实现这种众筹，探讨除了我在 上一篇文章中讨论的所有众筹共享的指标外，所有这种类型的众筹应该有哪些指标。

• 允许用户注册和取消注册的机制。大多数销售只允许用户在销售前短时间内注册，但如果每个地址有一个静态上限，注册可以在整个销售中使用。用户将在业主提供的网站上注册，业主将注册信息提交给智能合约。

• Mechanism to calculate the address cap based on how many users registered pre-sale.

• Mechanism for users to submit purchases. Since the contract lies dormat when nobody is interacting with it, this function also handles increasing the price of the token, if needed, and increasing the purchase cap per addres.

And that is about it! You can see how we implemented it here. We have done extensive testing on the model and feel very confident in its security and functionality, but still welcome any feedback on how to make it better.

At Modular, we are working on creating open source, community audited, deployed libraries for Ethereum, and we are including this style of customizeable crowdsale in our libraries. In accordance with the rules I laid out in the first article, we have created a base crowdsale library that specific crowdsale implementations “inherit”. It includes all the common variables and functions mentioned last time. We also created an implementation of the crowdsale library described in this article for even distribution crowdsales which utilizes the base library to give developers a tested resource in creating their own crowd sale contracts.

You can see our libraries on our Github. We already have libraries for a large variety of applications and are actively working on building out libraries for different ICO models. We plan to have libraries available for each major model as I release these articles every couple of weeks. Next time, I’ll be discussing the Interactive Coin Offering Model that we have started working on with TrueBit and some of the best Solidity Developers in the community!

We are all constantly learning and love to get feedback from the community, so if you see anything in this post or on our Github that needs clarification or improvement, we would love to hear from you in the comments. If you want to get involved, you can also contact us at modular.network!

References:

Will Warren

, Analyzing the 0x Token Sale, https://blog.0xproject.com/analyzing-the-zrx-token-sale-a94b8642c78e