您可能已经看到最近在 XYMcity Discord 服务器上出现了一个名为#rosetta-impl的新频道,并想知道它的全部内容。几周前,在频道活跃之前,我开始关注 Rosetta 的讨论,并认为我最好写一篇关于它的文章,但由于我还有很多其他事情要做,这被推迟了。我还认为这对我来说是一个挑战,因为我对它是什么一无所知,所以这样做的前景也不是超级有吸引力😆。
昨天看到@xembook的 Twitter 帖子和随附的日语文章(在Symbol 博客新闻更新中出现),我想我应该做一些研究并写下来。
所以这是一篇关于 Rosetta的文章😬 我不确定结果会如何,但我会尽力而为!
免责声明:我将这篇文章从我在 Discord 频道上收集到的内容拼凑在一起——如果我断章取意或犯了错误,我深表歉意。请告诉我,我会更新文字!
什么是Rosetta
Rosetta由Coinbase于 2020 年 6 月推出。他们将其描述为“开源规范和工具集,让区块链的集成更简单、更快、更可靠” 。
Rosetta 标准化和构建部署、通信和数据格式。应用程序不必为每个区块链编写自定义解析代码,而是能够直接读取链上数据并构建交易,而无需直接处理本地区块链代码库。这使开发人员和交流变得更容易,简化了代码的编写和维护。
截至 2020 年 12 月,有超过 25 个使用 Rosetta 实现的项目,包括比特币和以太坊,但这个数字还在继续增长。
为什么我们需要 Rosetta 实现?
首先,团队越容易让人们与 Symbol 区块链交互越好!如果它可以集成到其他平台,而不必花费很长时间学习所有技术细节并编写定制代码与区块链交互,那么它一定是一件好事。如果我们让开发者和交易所更容易与 Symbol 合作,那么我们将会看到更多人使用它。
我相信现在可能要求 Coinbase 在他们将其代币上架到他们的交易所之前拥有区块链的 Rosetta 实现。我找不到这方面的直接来源,但过去曾在 Discord 上提到过(?)。无论如何,它似乎肯定会增加Coinbase Asset Hub被接受的机会,而且似乎该团队已经与 Coinbase 就此进行了一些接触:
我们都想要 XEM 和 XYM 的 Coinbase 列表,对吗?好吧,看起来官方可能正在为这种情况的发生铺平道路。
Rosetta路线图
从阅读#rosetta-impl频道可以看出,计划是首先为 NIS1 制作 Rosetta 实现,然后再转到 Symbol。我对此感到有些惊讶,但显然 NIS1 比 Symbol 更容易做到这一点。不过,在与 Rosetta 集成之前,NIS1 似乎必须开源,因此存在一些复杂情况。
好吧,也许这是一件好事。我认为该计划无论如何都要使 NIS1 开源,众所周知这是 Coinbase 上市的要求。我仍然不知道 NIS1 的未来计划是什么。如果计划转移到 Symbol 的子链,那么我们不应该推动 Symbol 的实现吗?我很想看到 XYM 在 XEM 之前(或同时)在 Coinbase 上列出 😁。我猜想,在继续使用 Symbol 之前,NEM Rosetta 实施将是一个很好的学习练习。
该团队已经开始工作,现在有一个GitHub页面。不过我觉得我们还处于早期阶段。从 Discord 讨论和这个拉取请求中,我认为团队选择了 TypeScript 实现,并且目前没有可用的 Rosetta SDK(似乎只发布了GO SDK?)所以我想这意味着从头开始编写它。
Symbol的Rosetta问题
正如我上面提到的(基于阅读 Discord 讨论)Symbol 是一个比 NIS1 更复杂的野兽。显然,Symbol节点必须与 Rosetta 实现存在于同一个 Docker 文件/容器中。
带有内置节点的 Rosetta 实现
如果不能选择使用单独的容器/组合来运行 Symbol 节点,我们需要在同一个 Docker 文件/容器中的 Rosetta 实现旁边压缩一个 Symbol 节点。
这些 Rosetta 示例做到了这一点,将一个节点和一个 Rosetta 服务器并排运行。
https://github.com/coinbase/rosetta-bitcoin/blob/master/Dockerfile
https://github.com/coinbase/rosetta-ethereum/blob/master/Dockerfile这些是内置节点的一些初始选项:
全双节点:
将 Catapult、Broker、RocksDB、Mongo、Recovery、Rest 和 Rosetta 实现(新)压缩到一个大容器中。太大了,故障点太多。Rest 需要扩展添加或修改一些端点,因为它们不是 Rosetta 友好的。例如按哈希块,或块的交易哈希。
仅 Api 节点:
将 Catapult、RocksDB、Recovery 和 Rosetta 实现(新)压缩到一个大容器中。Rosetta 实现将查询 RocksDB 并直接与服务器 API 对话。我们很可能需要 RocksDB 查询/索引器服务/组件(新)。不确定查询和索引 RocksDB 有多难。
仅 Api 节点 + Light Rest:
将 Catapult、RocksDB、Recovery、Ligh Rest(新)和 Rosetta 实现(新)压缩到一个大容器中。Rosetta 实现将与 Light Rest 服务对话。Light Rest 实现将查询 RocksDB 并与服务器 API 对话。Light Rest 服务可用于常规节点部署,而不仅仅是 Rosetta。我们很可能需要 RocksDB 查询/索引器服务/组件(新)。
Catapult扩展:
通过直接查询 RocksDB 来公开 Rossetta 实现的弹射式 C++ 扩展。
自定义/Go Catapult客户端:
一个全新的 Catapult 客户端,用于公开 Rosetta 端点。例如,使用 Rosetta GO SDK 的 GO Catapult客户端。
端点映射。
去做。在本节中,我想谈谈如何将 23 个 Rossetta 端点映射到 Symbol 数据和操作。
未来的研究、问题、待办事项:
- 如何在 Rossetta 中实现特定于Symbol的交易,如元数据、限制等?
- 如何在 Rosetta 中使用特定于 Symbol 的实体,如限制、元数据等?
- 内置节点是否可以投票、收获、领取收获奖励?
- 如何为测试网和主网节点创建单个图像。如何在映像中设置节点配置,尤其是围绕动态/提供的键或自定义设置。
- Symbol/Nis1-Rosetta 可以成为一等公民吗?常规节点管理员会想要运行这些类型的节点吗?
- 如果我们为我们的网络或任何其他与 Rosetta 兼容的子链创建了解 Rosetta 的浏览器和钱包怎么办?
- 如何通过添加额外的 Symbol/Nis1 特定端点(如/node/unlockedaccount)扩展 Rosetta ?
- 了解内存池和子链在 Rosetta 中的工作原理。
- Storage prunning 以及我们如何删除旧块。
结论
嗯,这就是我写一篇关于 Rosetta 的文章的尝试。它非常注重 NEM/Symbol,所以如果你真的想去看看 Rosetta 可以做什么以及它如何工作的更详细的细节,那么我建议查看Rosetta 网站和技术规范。看起来实施是团队的首要任务,在接下来的几周和几个月内,您将听到更多关于此的消息。
我觉得目前有很多项目正在进行中,很难跟上所有的进度。我喜欢新的透明工作方式,我希望在未来为您带来更多文章,将 Pirate Crew 的项目和进展拼凑起来。我只希望他们不要把自己分散得太细!
原文链接:https://symbolblog.com/article/rosetta-implementations-nis1-and-symbol/