协议实验室官方信息丨IPFS激励层存储拍卖更新——bidbot系统介绍

Posted 2021-12-08 盘古开源

自IPFS激励层Storage Auctions 推出以来，Textile团队一直在不断从我们不断壮大的数据生产者和存储提供商社区收集反馈和用例。这些反馈帮助团队不断迭代Auctions堆栈以及我们的bidbot系统。

bidbot及其与之连接的存储拍卖系统的理念是，通过将IPFS激励层经济学与交易制定过程紧密结合，可以为每个人生成更便宜、更高效的存储通道。

对于那些还不熟悉的人来说，bidbot是一个sidecar守护进程，存储提供商可以运行它来允许他们观看拍卖（通过libp2p），并对其进行出价。存储提供商需要运行bidbot才能参与拍卖。一旦存储提供商运行了bidbot并连接到他们的存储基础设施，它就会自动对拍卖（基于预先配置的参数）进行投标，并在获胜后（以及市场节点接受存储提案）bidbot从源并将其导入到他们的Lotus存储提供商中。

在此，我们很高兴地宣布一系列新功能和优化，这些新功能和优化将使竞价机器人的运行和与拍卖系统的交互更加轻松和强大。

控制吞吐量

运行IPFS激励层封装操作并非易事。存储提供商的基础架构需要足够稳定，以便能够应对传入交易管道的不断波动。考虑到这一点，我们开发了一系列选项来帮助控制整个过程。

–running-bytes-limit 标志允许用户控制bidbot拍卖系统，将被处理的总字节数，从最初的 CAR文件下载导入到他们完成的交易。

限制检查发生在bidbot中标时，这意味着存储提供商仍将在拍卖中出价，但如果超过限制，他们将拒绝中标，而不会受到处罚。这种设计避免错过潜在交易，同时仍保持限额。

虽然上面的标志只考虑拍卖的交易，但–sealing-sectors-limit 标志知道所有的交易，离线或在线。如果存储提供商节点的扇区数超过 X 个，bidbot将停止竞价以避免超出密封容量。

请记住，从接受交易到密封点需要一些时间，因此建议使用–running-bytes-limit 来处理来自bidbot的激增，同时还使用此标志来管理整体负载。

在某些情况下，同时导入一两个文件非常快，但导入更多文件可能需要永远。如果您看到这种情况，您可以使用–concurrent-imports-limit 标志限制导入并发。

CID重力集成

即使有了上述配置标志，存储提供商可能仍然更喜欢直观的Web UI 而不是配置文件来调整定价规则，或者他们甚至可能希望能够在沙滩上管理他们的操作！这就是我们的CID重力集成发挥作用的地方。您提出要求，我们交付，现在使用 CID Gravity 管理bidbot就像在CID Gravity 控制台上单击“连接”一样简单，在运行bidbot时将生成的密钥作为 —cid-gravity-keyflag 进行处理即可！或者，您可以使用 —cid-gravity-strict 来控制当CID Gravity服务器暂时无法访问时的回退行为。

此外，如果您启用了CID重力集成，您在CID Gravity中配置的交易建议费率会自动应用于bidbot，为您提供另一种控制吞吐量的方法！

自动化

许多存储提供商喜欢创建脚本和机器人来帮助实时微调他们的封装操作。因此，为了向bidbot用户提供更大的灵活性，我们添加了一些有用的命令来控制bidbot行为。使用您手头的任何脚本工具，无论是shell、python 还是php，当您看到超过预期的负载时，您只需调用bidbot pause即可，当负载恢复正常时调用bidbot恢复。

守护运行进程

虽然像nohup这样的命令可以让您在注销后轻松保持bidbot运行，但许多存储提供商更愿意将bitbot与他们的系统工具一起运行。虽然制作systemd服务文件非常简单，但 sudo bidbot install-service 通过设置您可以调整的基本服务使其变得更加容易！

如果您更喜欢将bidbot作为Docker容器运行，可以拉取最新的映像并使用环境变量对其进行配置。对于任何命令行标志，您可以简单地在 ALL_CAPS 中指定它们（用下划线替换连字符），并在前面加上 BIDBOT_。例如，要将 --storage-provider-id=f011 配置为环境变量，您可以使用 BIDBOT_STORAGE_PROVIDER_ID=f011。