EOS applications are heavily reliant on querying blockchain data. The “history plugin” allows applications to query any historical information that is stored on the blockchain. However, not all mechanisms for achieving this vital function are created equal. In fact, the original history plugin was actually deprecated in the EOSIO 1.2.0 update on August 14th, 2018.
Unsurprisingly, due to the rapidly growing EOS network, the history plugin has become increasingly difficult to support. Syncing and running a full history node in early November 2018 required roughly 800 GB of RAM. In less than one month, the history plugin now requires more than 1.5 TB of ram, nearly doubling in a matter of weeks! Using the history plugin to run a full history node now costs around 30k USD. At this rate the history plugin is neither sustainable nor cost effective.
Furthermore, BPs reduce their storage costs by filtering out “heavy traffic” accounts. Consequently, EOS mainnet doesn’t have a “true full history” node that stores everything on the EOS blockchain. For example, many BPs do not keep any transaction history for blocktwitter due to excessive transactions (which many consider spam). Additionally, there was a brief crisis during the week of November 14th in which all full history nodes went down. Without any publicly accessible endpoint, there was no way to query the full state of the blockchain. Since maintaining a full history node is very expensive, time consuming, and technically demanding, dApps leverage BP API nodes. As a result, dApps like DEXEOS and wallets such as Lynx were momentarily unable to complete their user requests.
While the EOS network is not suffering a crisis today, we’re forecasting many more issues related to the history plugin. Neglecting to take action now will eventually result in crippling effects on the network. In order to amend the current infrastructure vulnerability and nourish the longevity of the network, EOS42 is teaming up with other community members to offer a scalable solution for full history nodes.
Potential Solutions
The history plugin was always considered a short term solution that would necessitate migrating to more efficient solutions. Additionally, the EOS community has been working hard to develop better for solutions that can be leveraged by anyone. First, let’s explore the current solutions.
MongoDB Plugin
Block.one has been developing the MongoDB plugin. The MongoDB plugin enables blockchain data to be stored in a MongoDB database, where one can index and query data more efficiently. The MongoDB plugin is a great alternative that offsets the history plugin crisis. However, there are a number of challenges with the MongoDB plugin. For example, the MongoDB plugin alone is not a complete solution. While the MongoDB plugin will populate a MongoDB database with blockchain information, it does not allow external users to query the database for information in the same manner as the history plugin.
The community had to create the API interface to allow the MongoDB plugin to “plug-in” to the classic API interface that many dApps now rely on now. Cryptolions have developed and now maintain a great open-source solution called the EOS Mongo History API.
Furthermore, the current MongoDB plugin is not yet finalized and we have seen multiple schema changes between updates in EOS.io releases. Whenever the schema changes, anyone maintaining a MongoDB node is required to completely resync their node to build the new schema. Depending on the hardware being used, fully syncing a node can take days or weeks. Resyncing has also caused a lot of frustration and time lost. Many have reported needing multiple resync attempts before succeeding.
Once synced, there are additional challenges that need to be overcome. If the MongoDB instance becomes overrun with too many requests and the database goes down, NodeOS will continue to receive blocks in realtime and attempt to insert information into the database. If the database itself is down for as little as a few minutes, gaps will be present in the database. Under this scenario, the only solution is full replay/resync of the node.
Another difficulty reported with the MongoDB plugin is the tendency to insert duplicate data for the same event. This problem can bloat storage requirements and add an extra level of complexity when managing the database. Most notably, duplicated data must be manually removed.
EOS Light API
The EOS Light API is a new BP sponsored open-source plugin and API. The developer known as cc32d9 authored the initiative, and also developed the original ZeroMQ plugin. The ZeroMQ plugin has played a crucial role in the development of Chintai. In fact, ZeroMQ is the basis of our open-source plugin used in Chintai. The EOS Light API uses ZeroMQ at the plugin level and MySQL as the database storage. The EOS Light API is ready for public testing and more information can be found here.
Elasticsearch Plugin + API
Elasticsearch is a popular solution for analyzing large datasets. EOSLaoMao has developed an open-source plugin for Nodeos to support indexing the EOSIO mainnet historical data in an Elasticsearch cluster. The advantage of this solution is the ability to quickly search and correlate data metrics on the full history of the blockchain. Currently EOSLaoMao and EOS Rio are working to develop an open-source API and new API standard for this and other history solutions.
DFuse
DFuse is a new solution developed by EOS Canada. DFuse allows dApp developers to get historical data and real time events from the blockchain. While Dfuse is a closed-source solution, it’s equally important for the EOS community dApp developers to have another option for getting historical information from the blockchain when building their applications.
State History Plugin
Todd Fleming from Block.one has been developing another history solution called the State History Plugin. The state history plugin solves a number of the issues experienced with the MongoDB plugin:
- Automatically handles forks and will not store any duplicated data.
- The database storage is decoupled from Nodeos. Therefore, if the database goes down it can easily be synced without stopping Nodeos or requiring a replay of the blockchain.
- Functionality that until now was not possible. Features include getting smart contract table contents at every block they are changed.
- Any future schema changes won’t require a replay of Nodoes because of the decoupled design (note: this feature will beincluded in future updates).
Todd has also developed a utility called fill-postgresql, which populates a Postgresql database with new historical information. In the future there will be fillers developed for many other databases instead of being limited to one.
What does this mean for the MongoDB plugin?
According to Todd, Block.one is developing the MongoDB in parallel with the State History Plugin and plans to support both. Todd envisions multiple history and storage mechanisms to use in the future, allowing the community members to freely pick solutions that fits their needs, budget, and expertise.
State History API
The State History plugin is currently available, but without an API like the Cryptolions EOS Mongo History API. Fortunately this is no longer the case. Recently EOS42 became the first to setup an EOS API node running the State History Plugin. This marks an important milestone in the journey to a new full history solution. EOS42 is offering the first production system to test and run the State History plugin on the mainnet.
We’re also excited to announce that we’ve created an open-source RPC API for the “state history plugin” called the EOS State History API. The EOS community will soon be able to use our API to query historical data, which further increases the redundancy and resiliency of the community’s full history API.
In order to standardize the plugins commonly used by the network, we’ve made certain that the API responses match the current implementations so that existing dApps can seamlessly plug into our solution. Additionally, we are working closely with the initiative started by EOS Rio and EOSLaoMao to develop a new API standard as part of their continued development on the Elasticsearch Plugin.
Finally, in an effort to make the State History Plugin more accessible to everyone, EOS42 is teaming up with Block Matrix to offer daily snapshots of the State History data files, effectively allowing anyone to stand up a brand new history node in a matter of minutes instead of waiting weeks to sync.
More questions? Ideas? Comments? You can find us on telegram or other social media outlets.
EOS42 — Pioneering a Decentralized Future
EOS42 PROJECTS:
【中文版/Chinese】
可扩展的完整历史节点
EOS应用程序对区块链数据存在严重的依赖性。历史插件使得应用程序可以查询存储在区块链上的任意历史信息。然而，并非所有实现这一重要功能的机制都是相同的。事实上最初的历史插件，已经在2018年8月14日的EOSIO 1.2.0更新中被弃用。
不出所料，由于EOS网络的快速增长，历史插件变得越来越难以维护。
在2018年11月初同步和运行一个完整的历史节点大约需要800 GB RAM。在不到一个月的时间里，历史插件现在需要超过1.5 TB的ram，在几周内几乎翻了一番!
使用历史插件来运行完整的历史节点现在需要花费大约3万美元。按照这种速度，历史插件既不具有可持续性，也不具有成本效益。
此外，BPs通过过滤掉“高交易量”账户来降低存储成本。因此，EOS 主网没有“真正完整的历史”节点来存储EOS区块链上的所有内容。例如，由于过多的事务(许多人认为是垃圾邮件)，许多BPs不为blocktwitter保存任何事务历史。此外，在11月14日的那一周发生了短暂的问题，所有完整的历史节点都崩溃了。如果没有任何可公开访问的端点，就无法查询区块链的完整状态。由于维护完整的历史节点非常昂贵、耗时和技术要求，dApps利用了BP API节点。结果，像DEXEOS这样的dapp和Lynx这样的钱包暂时无法完成它们的用户请求。
虽然EOS网络今天没有遭遇危机，但我们预测，与历史插件相关的问题，未来会出现更多。如果现在不采取行动，最终会对网络造成严重影响。为了改善当前基础设施的脆弱性，提高网络的寿命，EOS42正与其他社区成员合作，为完整的历史节点提供一个可扩展的解决方案。
可能的解决方案
历史插件通常被认为是一个短期的解决方案，需要切换为更有效的解决方案。此外，EOS社区一直在努力开发更好的解决方案，让每个人都可以使用。首先，让我们探讨一下当前的解决方案。
MongoDB插件
blockone开发了MongoDB插件。MongoDB插件允许将区块链数据存储在MongoDB数据库中，这样可以更有效地索引和查询数据。MongoDB插件是一个很好的选择，可以弥补历史插件危机。
然而，MongoDB插件有许多挑战。
例如，MongoDB插件本身并不是一个完整的解决方案。虽然MongoDB插件将用区块链信息填充MongoDB数据库，但它不允许外部用户以与历史插件相同的方式查询数据库中的信息。
社区必须创建API接口，以允许MongoDB插件“接入”到许多dApps现在依赖的经典API接口。Cryptolions已经开发并维护了一个很棒的开源解决方案，称为EOS Mongo 历史 API。
此外，目前的MongoDB插件还没有最终确定，我们已经看到了EOS.io软件所发布的多个更新版本之间数据表结构(schema)的变化。
每当结构发生变化时，任何维护MongoDB节点的人都需要完全重新同步他们的节点，以构建新的数据结构。根据所使用的硬件不同，完全同步一个节点可能需要几天或几周的时间。重新同步也造成了许多挫折和时间损失。许多人反馈说，需要多次同步，才能够最终成功。
一旦同步完成，还有其他需要克服的挑战。如果MongoDB实例被太多的请求造成了溢出，数据库会崩溃，Nodeos将继续实时接收区块，并尝试将信息插入到数据库。如果数据库本身停机了几分钟，就会在数据库中出现缺口。在这种情况下，唯一的解决方案是完全重播(replay)/重新同步节点。
MongoDB插件的另一个问题是，可能会为相同的事件插入重复的数据。这个问题可能会增加存储需求，并在管理数据库时增加额外的复杂性。最值得注意的是，重复的数据必须手动删除。
EOS Light API
EOS Light API是一个由BP赞助的开源插件和API。名为cc32d9的开发人员创建了这个项目，并开发了最初的ZeroMQ插件。ZeroMQ插件在Chintai的开发中发挥了至关重要的作用。
事实上，ZeroMQ是我们在Chintai中使用的开源插件的基础。EOS Light API在插件级别使用ZeroMQ和MySQL作为数据库存储。EOS Light API已经准备好进行公开测试，更多信息可以在这里找到。
Elastic Search插件+ API
Elastic Search 是分析大型数据集的一种常用方法。EOSLaoMao已经为Nodeos开发了一个开源插件,来支持通过Elasticsearch集群对EOSIO 主网中的历史数据进行索引。此解决方案的优点是，能够快速搜索并关联区块链的完整历史上的数据指标。目前，EOSLaoMao和EOS Rio正在为这一方案和其他数据历史解决方案，开发一个开源API以及新的API标准。
DFuse
DFuse是EOS Canada开发的新解决方案。DFuse允许dApp开发人员从区块链获取历史数据和实时事件。虽然Dfuse这一解决方案并未开源，但是对于EOS社区dApp开发人员来说，在构建应用程序时从区块链获取历史信息的多一个选择，也同样重要。
状态历史插件(state history plugin)
来自BlockOne的Todd Fleming 开发了名为State history Plugin(状态历史插件)的这一解决方案。状态历史插件解决了MongoDB插件遇到的一些问题:
- 自动处理分叉，不会存储任何重复的数据。
- 数据库存储与节点解耦。因此，如果数据库宕机，可以很容易地进行同步，而无需停止节点或需要重播区块链。
- 其他以前无法实现的功能。这些功能包括，在某个智能合约所有相关区块中，获得该智能合约的数据表中的记录。
- 由于采用了解耦设计，未来对任何数据表结构的更改都不需要重放Nodeos(注意：这一功能会包含在未来的更新中)。
Todd还开发了一个实用程序 fill-postgresql，它会用新的历史信息填充Postgresql数据库。未来会开发出许多其他向数据库填充数据的程序，而不只局限于一个数据库。
这对MongoDB插件意味着什么
据Todd所说，BlockOne在并行开发状态历史插件和MongoDB插件，并计划同时支持这两个插件。Todd设想未来可以使用多种历史插件和存储机制，允许社区成员自由选择适合他们需求、预算和专业知识的解决方案。
状态历史API
状态历史插件目前已经可以使用了，但是没有像Cryptolions EOS Mongo History API这样的API。幸运的是，情况已不再如此。
最近，EOS42成为了第一个安装并运行状态历史插件的EOS API节点。这标志着在新的完整历史解决方案之旅中的一个重要的里程碑。EOS42在EOS主网上测试和运行了状态历史插件，提供了第一个正式环境下运行的系统。
我们还激动地宣布，我们已经为状态历史插件创建了一个开源RPC API，称为 EOS状态历史API。EOS社区将很快能够使用我们的API来查询历史数据，这进一步增加了社区完整历史API的冗余性和灵活性。
为了对EOS网络中常用的插件进行标准化，我们确保API的响应与当前的实现匹配，以便现有的dApps能够无缝地插入我们的解决方案。
此外，作为Elasticsearch插件项目持续开发的一部分，EOS Rio和EOSLaoMao发起了开发新API标准的倡议，我们也会进行紧密的合作。
最后,为了使状态历史插件更容易使用, EOS42正与 blockmatrix一起，提供针对日常历史状态数据的快照数据文件, 这可以让任何人都能够在几分钟内创建起来一个全新的历史节点, 不用花费数周时间等待数据同步。
如果更多的问题，想法，或者评论，您可以通过电报群，微信群，或者其他社交媒体渠道联系我们。
[한국어 번역/ Korean]
확장 가능한 FULL 히스토리 노드 지원
EOS 앱들은 블록체인 데이터를 쿼리하는데 크게 의존합니다. “히스토리 플러그인”을 사용하면 응용 프로그램이 블록체인에 저장된 히스토리 정보를 쿼리 할 수 있습니다. 그러나 이 중요한 기능을 사용하기 위한 메커니즘이 모두 동일하게 만들어 지지는 않았습니다. 실제로 히스토리 플러그인은 2018 년 8 월 14 일 EOSIO 1.2.0 업데이트에서 사용되지 않습니다.
EOS 네트워크가 빠르게 성장하고 있기 때문에 히스토리 플러그인은 점점 더 어려워지고 있습니다. 2018년 11월 초 전체 기록 노드를 동기화하고 실행하려면 약 800GB의 RAM이 필요했습니다. 한 달도 채 되지 않아, 히스토리 플러그인은 이제 1.5TB 이상의 RAM을 필요로 하며, 몇 주 내에 거의 두 배가 될 것입니다. 히스토리 플러그인을 사용하여 전체 히스토리 노드를 실행하면 이제 약 3만 달러의 비용이 발생합니다. 이 속도로는 히스토리 플러그인은 지속가능하거나 비용 효율적이지 않습니다.
또한 BP들은 “트래픽이 많은” 계정을 필터링하여 스토리지 비용을 절감합니다. 따라서 EOS 메인 넷에는 EOS 블록 체인에 모든 것을 저장하는 “진정한 풀 히스토리” 노드가 없습니다. 예를 들어 많은 BP들은 블록트위터등 스팸성의 거래 히스토리를 보관하지 않습니다. 또한 11월 14일 주간에는 전체 히스토리 노드가 모두 다운되는 위기가 있었습니다. 공개적으로 액세스 할 수 있는 포인트가 없다면 블록체인의 풀 스테이트를 쿼리 할 수 있는 방법이 없을 것입니다. 전체 히스토리 노드를 유지 관리하는 데는 비용과 시간이 많이 들고, 기술적으로 까다롭기 때문에, dApp 들은 BP들의 API 노드를 활용합니다. 그 결과 DEXEOS와 같은 dApp과 Lynx와 같은 지갑은 일시적으로 사용자 요청을 완료 할 수 없었습니다.
EOS 네트워크가 지금 위기를 겪고 있는 것은 아니지만, 저희는 앞으로 히스토리 플러그인과 관련된 더 많은 문제가 일어날 수 있다고 예측하고 있습니다. 이에 조치를 취하는 것을 무시하면 결국 네트워크에 심각한 영향을 미치게 됩니다. 현재의 인프라 취약성을 수정하고 네트워크의 수명을 길러주기 위해 EOS42는 다른 커뮤니티 멤버들과 팀을 구성하여 풀 히스토리 노드를 위한 확장 가능한 솔루션을 제공합니다.
잠재적 솔루션
히스토리 플러그인은 지금까지는 더 효율적인 솔루션을 더해야 하는 단기 솔루션으로 간주되어 왔습니다. EOS 커뮤니티는 누구나 활용할 수 있는 솔루션을 개발하기 위해 열심히 노력하고 있습니다. 먼저 현재 솔루션을 살펴 보겠습니다.
MongoDB 플러그인
Block.one은 MongoDB 플러그인을 개발 중입니다. MongoDB 플러그인을 사용하면 블록체인 데이터를 MongoDB 데이터베이스에 저장할 수 있으므로 데이터를 보다 효율적으로 인덱싱하고 쿼리 할 수 있습니다. MongoDB 플러그인은 히스토리 플러그인 위기를 상쇄시키는 훌륭한 대안입니다. 그러나 MongoDB 플러그인에는 많은 어려움이 있습니다. 예를 들어, MongoDB 플러그인만으로는 완벽한 솔루션이 아닙니다. MongoDB 플러그인은 블록체인 정보로 MongoDB 데이터베이스를 채우지만 외부 사용자는 히스토리 플러그인과 동일한 방식으로 정보를 데이터베이스에 쿼리 할 수는 없습니다.
커뮤니티는 MongoDB 플러그인이 많은 dApp이 현재 사용하고있는 클래식 API 인터페이스에 “플러그인” 할 수 있도록 API 인터페이스를 만들어야 했습니다. Cryptolions는 EOS Mongo History API라고 하는 훌륭한 오픈 소스 솔루션을 개발하여 현재 유지 관리하고 있습니다.
게다가, 현재의 MongoDB 플러그인은 아직 완성되지 않았고 EOS.io 릴리즈에서 여러 스키마 변경 사항을 보았습니다. 스키마가 변경 될 때마다 MongoDB 노드를 유지 관리하는 사람은 노드를 완전히 다시 동기화하여 새 Schema 를 작성해야 합니다. 사용중인 하드웨어에 따라 노드를 완전히 동기화하는 데 며칠 또는 몇 주가 소요될 수 있습니다. Resyncing 은 많은 좌절감과 시간을 낭비하게 만들었습니다. 많은 사람들이 실패로 인해, 여러 번의 재동기화 시도가 필요했다고 보고하기도 했습니다.
일단 동기화되면 극복해야 할 추가 과제가 있습니다. 너무 많은 요청으로 인해 MongoDB 인스턴스가 오버런되어 데이터베이스가 다운되면 NodeOS는 실시간으로 블록을 계속 수신하고 정보를 데이터베이스에 삽입하려고 시도합니다. 데이터베이스 자체가 잠깐 동안 다운되는 경우, 데이터베이스에 갭이 존재하게 됩니다. 이 시나리오에서 유일한 해결책은 노드의 전체 재생 / 재동기화입니다.
MongoDB 플러그인으로 보고된 또 다른 어려움은 동일한 이벤트에 대해 중복 데이터를 삽입하는 경향입니다. 이 문제로 인해 스토리지 요구 사항이 증가하고 데이터베이스를 관리 할 때 추가 수준의 복잡성이 추가 될 수 있습니다. 특히 복제된 데이터는 수동으로 제거해야 합니다.
EOS 라이트 API
EOS Light API는 BP가 후원하는 새로운 오픈소스 플러그인 및 API입니다. cc32d9로 알려진 개발자가 초기 디자인을 저술했으며 오리지날 ZeroMQ 플러그인도 개발했습니다. ZeroMQ 플러그인은 Chintai 개발에 중요한 역할을 했습니다. 사실, ZeroMQ는 Chintai에서 사용되는 오픈 소스 플러그인의 기초입니다. EOS Light API는 플러그인 레벨에서 ZeroMQ를 사용하고 데이터베이스 스토리지로 MySQL을 사용합니다. EOS Light API는 공개 테스트가 가능하며 자세한 정보는 여기(here)에서 확인할 수 있습니다.
Elasticsearch Plugin + API
Elasticsearch는 대규모 데이터 세트를 분석하는 데 널리 사용되는 솔루션입니다. EOSLaoMao는 Nodeos 용 오픈소스 플러그인을 개발하여 Elasticsearch 클러스터에서 EOSIO 메인 넷 이력 데이터의 인덱스를 지원합니다. 이 솔루션의 장점은 블록체인의 전체 히스토리에서 신속하게 데이터 메트릭을 검색하고 상호 연관시킬 수 있다는 것입니다. 현재 EOSLaoMao와 EOS Rio는 이것과 다른 히스토리 솔루션을 위한 오픈소스 API 와 새로운 API 표준을 개발하기 위해 노력하고 있습니다.
DFuse
DFuse는 EOS Canada가 개발한 새로운 솔루션입니다. DFuse를 사용하면 dApp 개발자가 블록체인에서 과거 데이터 및 실시간 이벤트를 얻을 수 있습니다. Dfuse는 closed-source 솔루션이지만 EOS 커뮤니티 dApp 개발자는 앱을 개발 할 때 블록체인에서 히스토리 정보를 가져올 수 있는 또 하나의 옵션을 가지게 되었습니다.
State History Plugin
Todd Fleming은 Block.one에서 State History Plugin 이라는 또 다른 히스토리 솔루션을 개발했습니다. State History Plugin 은 MongoDB 플러그인에서 경험한 여러 가지 문제를 해결합니다.
• 자동으로 포크를 처리하고 중복된 데이터를 저장하지 않습니다.
• 데이터베이스 저장소가 Nodeos와 분리됩니다. 따라서 데이터베이스가 다운되면 Nodeos를 중지하거나 블록체인을 리플레이 할 필요 없이 쉽게 동기화 할 수 있습니다.
• 지금까지는 불가능했던 기능이 추가되었습니다. 예를 들어, 모든 블록에서 스마트 컨트랙트 테이블 내용을 가져 올 수 있습니다.
• 미래의 모든 schema 변경은 분리된 설계로 인해 Nodoes를 리플레이 할 필요가 없습니다 (참고: 이 기능은 향후 업데이트에 포함될 것입니다).
Todd는 또한 fill-postgresql 이라는 유틸리티를 개발했습니다. 이 유틸리티는 postgresql 데이터베이스에 새로운 히스토리 정보를 채웁니다. 앞으로는 하나의 데이터베이스로 한정되지 않고 다른 많은 데이터베이스를 위한 filler 들이 개발될 것입니다.
이 솔루션이 MongoDB 플러그인에 어떤 영향이 있을까요?
Todd에 따르면, Block.one은 State History Plugin 과 병행하여 MongoDB를 개발 중이며 둘 다 지원할 계획이라고 합니다. Todd는 향후 사용할 여러 히스토리 및 스토리지 메커니즘을 계획하여 커뮤니티 멤버들이 그들의 필요, 예산 및 전문 지식에 따라 적합한 솔루션을 자유롭게 선택할 수 있도록 할 것입니다.
State History API
State History 플러그인은 현재까지 Cryptolions EOS Mongo History API와 같은 API는 없었습니다. 다행스럽게도 더 이상 그렇지 않습니다. 최근 EOS42가 State History Plugin을 실행하는 EOS API 노드를 최초로 설정했습니다. 이것은 새로운 전체 히스토리 솔루션의 역사상 중요한 이정표가 될 것입니다. 저희는 Mainnet 에서 State History 플러그인을 테스트하고 실행하기 위한 첫 번째 프로덕션 시스템을 제공합니다.
또한 EOS42 는 EOS State History API 라는 “State History Plugin” 을 위한 오픈소스 RPC API를 만들었음을 알리게 되어 매우 기쁘게 생각합니다. EOS 커뮤니티는 곧 API를 사용하여 히스토리 데이터를 쿼리 할 수 있으며, 커뮤니티의 풀 히스토리 API의 부족함을 개선하고, 노드 회복성을 더욱 높일 것입니다.
네트워크에서 일반적으로 사용하는 플러그인을 표준화하기 위해 API 응답이 현재 구현과 일치하는지 확인하여 기존 dApp들이 원활하게 저희 솔루션에 연결할 수 있게 하였습니다. 또한 EOS Rio 및 EOSLaoMao와 긴밀하게 협력하여 그들이 개발중인 Elasticsearch Plugin 의 새로운 API 표준을 개발을 도울 것 입니다.
마지막으로, 모든 사람들이 State History Plugin 을 보다 쉽게 이용할 수 있도록 하기 위해 EOS42는 State Matrix 데이터 파일의 일일 스냅샷을 제공하기 위해 Block Matrix와 팀을 구성하였습니다. 이로 인해 동기화 하기 위해 몇 주나 기다려야 하는 대신, 몇 분 안에 새로운 히스토리 노드를 효과적으로 세울 수 있게 될 것입니다.
EOS42 — Pioneering a Decentralized Future
