Accessing Cardano Blockchain Data with Ledger Sync (cardanofoundation.org)
Cardano 基金会的工程团队最近承担了开发一种名为 Ledger Sync 的基于 Java 的数据配置工具的工作，该工具可以访问 Cardano 区块链数据。 Ledger Sync 旨在实现与 Cardano DB Sync（也称为 db-sync）相同水平的数据完整性，同时提供在不同公司以及广泛用户群中成熟的编程语言选项。 为了配合基金会促进卡尔达诺开源成熟度的努力，该框架将在开源许可下发布，为开发者和合作伙伴提供额外的链索引工具，增加卡尔达诺开发者生态系统的多样性。
基金会选择在 Apache 2.0 许可证下发布存储库，允许在商业和非商业应用程序以及其他开源工具中使用该框架。 该许可证还以专利权的形式提供了法律确定性，即对其构建的工具或与之一起构建的工具，以及需要指出但不一定公开披露的框架本身的更改。 这种安排确保了公司以及其他开发商和社区成员的最佳可访问性和法律确定性。
区块链作为一种数据结构
许多基于区块链的系统面临着一个共同的挑战：由于存储的组织形式是链表，因此无法以随机访问的方式有效地检索数据。 例如，要访问 Cardano 上第 200 号区块中存储的交易，应用程序必须迭代前 199 个区块，然后才能到达包含所需信息的区块。 如果区块链网络不断扩展，这种方法就变得不可行。 例如，卡尔达诺目前在主网上铸造了超过 950 万个区块。
某些信息没有明确存储在区块链上的事实提出了另一个挑战。 由于 Cardano 基于 EUTxO 的会计模型，这甚至适用于钱包的当前或历史余额。 为了了解钱包中未使用的交易输出（UTxO），有必要跟踪所有进出钱包的 UTxO，然后汇总它们以确定最终余额。
大约到 2022 年初，db-sync 一直是生态系统中的构建者以有效方式访问 Cardano 区块链数据的唯一可用选项。 然而，为了到达链的顶端，db-sync 还需要在初始同步期间处理大量数据。 这使得为所有项目运行 db-sync 是不可行的。 此外，在许多情况下，项目并不需要 db-sync 提供的所有数据，这一现实导致了所谓的作用域链索引器的开发，允许用户精确指定哪些数据需要索引并可供某个项目使用。 一定的应用。 Kupo、Scrolls、Oura 和 Carp 等项目都为社区提供了不同的实现方式。
除了这些更多的技术要求之外，企业还经常需要此类数据供应服务的可靠性。 一般来说，这些要求与源代码中的实际实现无关，而是与这样的系统如何运行有关。 Cardano 基金会开发了 Ledger Sync 来准确满足此类业务需求。 虽然一方面它与 db-sync 有一些相似之处，但某些设计选择使其更适合分布式架构，因为它们允许高可用性设置。 事实上，基金会的新浏览器已经将 Ledger Sync 用作其底层数据管道。
如果项目需要来自 Cardano 区块链的非常具体的数据，但可以放弃内置高可用性和数据整合卸载等功能，那么 yaci-store、scrolls 和 Kupo 等模块化链索引器会提供合适的选择。 另一方面，Ledger Sync 为项目提供了在 Cardano 之上基于 Java 的数据层的可靠选项，特别是当项目需要基于以易于访问的编程语言构建的框架可靠地访问区块链相关数据时。
Ledger Sync 的最初设计旨在实现三个目标：
- 在 Java 中实现网络迷你协议，以便可以以 Java 编程语言本机的方式访问网络数据，而不依赖于其他框架。
- 将纯粹的爬行和数据整合步骤解耦以实现横向扩展架构，这意味着部分计算可以卸载到多个实例，例如容器或服务器，从而评估通过网络传输数据所继承的负面影响 将其保存在本地单个服务器中。
- 实施一个独立于节点的金库、储备和奖励计算版本，基金会最近已将其开源。
与基金会浏览器测试版一起上线的原始实现涵盖了前两点。 基金会的工程团队目前正在研究第三点，作为另一个开源项目的一部分。
Ledger Sync 存储库之旅
该团队在第一个开发阶段取得了许多经验，所有这些都已在现在根据开源许可发布的版本中得到解决。
我们从头开始用 Java 开发网络迷你协议，因为在项目开始时，著名的 Yaci 库尚未达到我们认为可用的状态。 尽管如此，我们在当前版本中用 Yaci 替换了之前的网络迷你协议实现，以帮助推动该社区项目的采用。 这一变化意味着只需要维护一个 Java 技术堆栈并根据协议的任何更改保持最新状态。
为了协调不同服务之间的任务（例如将爬行与下游处理和数据整合解耦），该团队最初使用 Redis 和 Apache Kafka（一种广为人知的开源流数据平台）。 虽然这种方法被证明是有效的，并且 Kafka 以及 Redis 在分布式架构中提供了强大的组件，但部署成本相当高并且可能变得很麻烦，特别是对于较小规模的设置。 在最新版本中，团队取代了 Kafka 的必要性并使其成为可选的。 虽然 Ledger Sync 在没有 Kafka 的情况下运行，但开发人员可以使用 Yaci Store 提供的应用内事件机制，并选择将块数据发布到各种消息平台（例如 Kafka 和 RabbitMQ），然后从另一个应用程序使用它。
我们最初也从 db-sync 使用的相同数据库模式开始。 这种方法在并行开发基金会的浏览器时被证明是有用的，因为它使浏览器后端能够使用真实数据进行测试。 然而，这也给 Ledger Sync 带来了设计挑战，因为我们偏离了领域驱动设计方法，并且没有为第一个 Ledger Sync 版本创建内置的模式。 虽然 db-sync 的数据库模式达到了其目的，但它不支持所选的架构，并且旨在 Ledger Sync 的数据处理过程中实现并行化。 因此，我们目前正在努力设计一种新的模式来取代现有的模式。
此外，最近添加的大多数源代码都包括对 Yaci 康威时代的支持。 此更新使 Ledger Sync 以及所有其他基于 Java 的工具能够与最新的分类账和网络迷你协议版本配合使用。
基金会的工程团队还启动了一个工作流，以实现多个区块的并行处理，以及在初始同步过程中单个区块中的交易。 并行化这些计算并不简单，因为有必要考虑 UTxO 之间的依赖性，从而降低了从并行化中获得的性能。 此外，正在进行的开发工作包括提供在各种部署场景中托管 Ledger Sync 的蓝图，例如在基于 Kubernetes 的设置中或简单地通过 docker-compose。
前方的路
除了其技术功能之外，Ledger Sync 还得到了卡尔达诺基金会的承诺，即提供持续维护以及将存储库作为开源项目进行操作。 除了作为库和工具本身的框架之外，这项工作还旨在与社区团体合作，寻求为去中心化数据 API 定义标准和潜在的参考实现，其中 Ledger Sync 可以用作底层数据层。
另一个目标是提供托管数据 API，通过专业支持模型保证高可用性、准确性和正确性。 保证这一点将满足组织和企业的需求，使他们更容易无缝实施区块链解决方案，从而促进更大的企业采用。 然而，这样的任务需要与现有项目保持一致和协作。 只有这样做，才有可能充分利用现有卡尔达诺生态系统的全部能力，同时确保支持新兴商业模式多样性的方法。
卡尔达诺基金会鼓励每个人尝试 Ledger Sync，并通过 Discord 或在 Ledger Sync 存储库中提交功能请求或错误报告来与我们的团队互动。 我们期待您的反馈和贡献。