原文链接：https://developer.bandprotocol.com/providers/architecture.html
系统架构
在深入研究更多技术细节之前，我们先暂停一下，讨论一下Band的提供商网络的高级架构。如果您对设置节点更感兴趣，请跳到下一节。
在链上验证数据签
无论何时将数据点提交到链上数据集智能合约，数据必须由超过2/3的活动数据提供者签署。因此，除非对结果有明确的共识，否则数据不会在链上更新。数据提供者网络是一个由数据提供者组成的网络，它确保数据在短时间内得到所有提供者的确认和签名。
提供者网络的数据流
当用户请求数据查询时。将发生下面的事情。
1.用户向Coordinator（协调）节点发送数据请求。该节点目前由Band Foundation运行，负责与数据提供者通信。
- Coordinator（协调器）将数据请求分派给网络中的所有活动的提供者节点。
3.提供者节点执行数据查询，对数据进行签名，并将其传递回协调器。
4.协调器聚合来自所有提供者的所有结果，并将所有结果传递给活动提供节点，以获得聚合数据上的签名。
5.提供者节点对所有结果执行数学聚合，对数据进行签名，并将其传递回协调器。
6.协调器验证最终签名的完整性并发送聚合结果。
作为数据提供者，您有责任维护提供程序节点并确保其正常运行。如果提供者节点没有在指定的时间范围内对协调器进行响应，则其数据将不会包含在最终结果中，并可能面临令牌持有者失去令牌利害关系的风险。
数据的不断输入
如上所述，对协调节点的请求驱动了Band数据集上的数据更新。然而，为了数据消费者的利益，一些数据点(如Ethereum price)需要定期更新。在这种情况下，Band Foundation负责向协调节点调用数据请求，以确保发生状态更新。
下一个迭代
而在目前的设计中，由于需要数据提供者的签名在链上，所以BandProtocol无法控制数据的有效性，系统依赖BandProtocol的正常运行时间来保证其活性。换句话说，如果协调器宕机，整个系统也会停止运行。我们意识到这个问题，并正在积极地研究去中心化的、无领导的通信协议，以消除这个故障点。期待看到更新很快!
