请求循环在1.8秒时持续卡住。不是失败。只是刚好打破了两个本应自动协调的机器之间的节奏。
起初我以为是网络噪声。事实并非如此。
这个问题只在两个代理尝试协商任务交接时出现。一个会发送指令,另一个会确认,但确认并不意味着同意。它只是意味着消息已到达。微妙的区别。在实践中很痛苦。
Fabric的身份验证门控几乎立即改变了这种行为。
一旦代理必须通过绑定身份操作,交互的语气就发生了变化。不是哲学上的变化,而是机械上的。一个在其身份背后抵押的节点停止发出乐观的响应。我的日志中,消息的延迟大约增加了300–400毫秒,但重试率从大约11%下降到不到3%。事实证明,当附带抵押品时,机器的行为会有所不同。
仍然不完美。
让我惊讶的一点是,路由决策开始集中在一小部分高度可靠的节点上。信任会产生引力。这对稳定性非常有利,但也悄悄提出了一个问题:合作是否最终会集中在那些能负担得起最大抵押的节点上。
也许这没关系。也许机器协调实际上确实需要一些引力锚点。
当我开始调整抵押阈值后,Fabric代币才真正出现在视野中。在某个抵押水平以下,同样的犹豫又回来了。超过这个水平,协调几乎瞬间变得顺畅。
我仍然不确定健康的界限在哪里。
接下来我想测试的是,几个中等抵押节点合作时会发生什么,而不是依赖单一的高抵押节点。这可能会展现出系统的真正特性。
@Fabric Foundation
$ROBO #ROBO