说一说一文带你读懂法索取ICPunks NFT的背

qw0800

ICP是D上第一个C风格创建的IC NFT项目，ICP上的NFT是引入ERC-721进行铸造的，该项目一共铸造10000个不同特征免费供于社区索取链上小丑，该项目10000个NFT的索取过程分为4个时间线：北京时间9月2日凌晨0点，北京时间凌晨2点，北京时间凌晨点，北京时间凌晨4点，前个时间线皆是白单索取，凌晨4点时间线为普通参与者索取，在4点时间线时有大部分用户到点之后几乎大部分参与者法索取NFT，本期文章带各位小伙探讨ICP法索取的根本原因要知道[url=http:///www.imotken.net/]imtoken官网下载[/url]的成长也是要经历很多磨难的，但创业者们从不畏惧，大胆向前。[align=center]

                               
登录/注册后可看大图

[/align]

我们回忆一下当时UTC时间20:00（北京时间凌晨4点）当时在ICP法索取的两个问题：第一个是ICP前端没有加载出C功能法索取，第二个是C按钮出现后大部分人C不了NFT。

以下部分资料由开发者论坛的队员提供，注意：以下均是个人分析，ICP官方解释出来可能会有变更：

我们在P钱包中查看交互过的D查看到IC D由两个部署在ID为P的公共子上的C组成，通过ICR区块浏览器可以查看到该C的分布详情。由此可见ICP 的C均部署在ID为P 的子上。

----

---4-

回到在开发者论坛队员提供的资料显示在UTC时间2021-09-01 16:00（北京时间0点）时第一波增加流量开始访问子，该时间是ICP第一波白单索取NFT的用户，在下图边界节点发送的HTTP请求显示在UTC时间16:00至19:00发送的HTTP请求只增不减，逐渐增长的流量发送的HTTP请求开始达到边界节点配置的速率限制，所以边界节点开始限制对子上容器的消息请求，这不仅对ICP部署的容器造成了影响，也对子上的其他容器造成影响，这就意味着边界节点开始限制用户发起的HTTP消息请求。

边界节点发起的HTTP请求

而在UTC 20:00的时候从边界节点发起的HTTP请求急剧增加，这也是ICP全面开放的极端，当时发起HTTP请求的峰值达到了每秒8次以上。

UTC 20:00 边界节点发起的HTTP请求

在ICP还未启动C时，节点和子表现是正常的，而在开启C索取时，大量的更新调用提交涌入子，从每秒提交18次更新到超过每秒提交1000次更新调用请求。

以下图片是通过边界节点发起的请求响应的返回结果的数据：

图一

图二

我们可以看得到在图一在UTC时间16:00之前状态峰值相对于来说处于一个稳定的状况，自ICP第一批百单开始（UTC时间16:00）之后，大批流量涌入通过边界节点不断的发起调用请求之后，子节点开始返回40结果，而在UTC时间20:00 ICP全面启动的的时候，返回40结果的数量更是达到了一个新的临界点（40结果是被子节点拒绝的调用请求）。而在图二中ICP全面开启之后返回202结果只有少数部分（202 HTTP状态代表消息调用被受理）这意味在ICP从20:00开始之后只有少部分人的调用请求被受理了，而大部分人的调用请求被节点拒绝，也就能表明当时出现C界面之后只有少数人可以索取，大部分用户则是被拒绝请求的。

由于ICP全面开启（UTC时间20:00）之后大量流量涌入导致子的最终区块的确定率从1秒块下降至1秒0个区块。

并且这个阶段子通过入口的消息调用限制为每秒50条。

在根据开发者论坛队员给出的资料我们可以将ICP造成子络拥堵的时间线流程分为：

2021-09-01 16:00?：ICP第一批白单C，倒计时开始流量开始涌入2021-09-01 16:15 ：在查询调用中边界节点开始速率限制，速率限制随着20:00的临近继续增加。2021-09-01 19:00：第二波C发生，导致流量的进一步增加，但由于第二波C的参与者数量有限，所以在更新调用的量仍然很低。2021-09-01 20:00：I全面开始C导致流量急剧增加，以每秒发起8 达到边界节点的峰值从个人导致子因为大量请求涌入导致区块最终确定率降至0块秒。2021-09-01 20:40：随着NFT的索取降低，流量开始逐渐减少，流量请求降低至10 每秒，并随着时间继续下降。2021-09-01 20:45：子恢复正常完成率。根据开发者论坛队员的描述：在客户端（浏览器的控制台日志中）显示边界节点关0返回大量的报错代码500，而ICP的静态资源是通过D提供服务的，所以只有ICP的前端加载足够多的静态资源才能够发挥作用：这也是为什么这么多用户除了不断的重新加载页面而什么都做不了的原因。

从UTC20:00时间之后边界节点涌入大量流量并向ICP的两个容器发送高频的调用消息请求，而容器高频更新负载导致子性能下降，这个因素导致用户法与ICP上的C进行交互索取NFT，以及访问子上的其他容器，并且这段时间内大多数消息请求要么会被受到速率限制，要么会被节点直接拒绝（因为消息请求过载）或者会被返回不同的报错结果，所以在当时只有一小部分用户的调用请求被受理，而大部分用户的请求是被拒绝的，而第一批白单的用户能够正常C他们的NFT是因为当时他们并没有受到速率限制并且当时子的完成率是正常的。

尽管在当时的流量很高子也继续处理查询调用和更新调用的请求，边界节点也继续为流量提供服务，速率限制是为了保护子免受大量流量的影响，因为未经过过滤的流量可能会导致子节点更多终端。

在开发者论坛中队员表示会通过改进以下要求防止再次出现此类事件的再次发生：

改进有关如何在IC拓展去中心化应用程序的文档。在边界节点上启用（符合标准）HTTP缓存并向开发人员传达最佳践。在区块之间评估节点上查询API调用结果的缓存。使用多线程进行执行调用（目前使用64内核中的一个进行单线程执行）负载测试并根据更显示的流量负载调整速率限制。