Mirror.xyz技术架构

Mirror.xyz技术架构

本文为Mirror.xyz技术团队在发布MVP时对其技术架构的描述。

用熟悉的语言学习 以太坊开发 ： NFT实战 | Java | Php | Python | .Net / C# | Golang | Node.JS | Flutter / Dart

Mirror 拥有雄心勃勃的愿景，即通过为作家提供基于Crypto的工具来重新定义在线出版。我们很高兴地分享已经正式 结束了我们的第一个全栈工程冲刺：Mirror 博客平台的 MVP。这将使我们能够加入我们的第一批作家，并作为未来 所有功能的基础。

在接下来的几个月和几年里，我们有很多事情要弄清楚——从为创作者发现新的加密原生商业模式到支持嵌入 NFT 等基本 事物。我们知道该项目的出发点是支持基本的发布体验；发布文本并与世界分享的能力。

这篇文章详细介绍了我们迄今为止的旅程。

我们对后端 API 的首次提交是 29 天前，即 2020 年 12 月 7 日——我（格雷姆）在 Mirror 的第一个正式日子。Denis 一直在与Trent讨论他关于 Mirror 的书的发布，以及与 Jon-Kyle 在设计和 UI 方面的合作。我们设定了一个雄心勃勃的 目标，即在圣诞节前让 Trent 的一切工作正常——这是我们给世界的礼物！🎁

为了发布 MVP，我们需要做出关键的早期技术决策。最重要的是，如何创建具有原生 web3 和加密基础的世界级写作工具。

2、如何构建 Web3原生写作平台

第一个挑战是从 web3 的角度思考构建平台。以下是 web3 游戏的规则（采用negativa风格描述）：

• 帖子内容不得集中
• 阅读体验不应该需要对 Mirror 的信任
• Mirror不应拥有作者的域
• 作家不需要连接他们的钱包并签署他们所写的一切
• Mirror 不应尝试在浏览器中存储以太坊私钥！
• 写作不应过于昂贵（对于镜子或作家）
• 奖励：不使用电子邮件密码注册！

我们提出的架构如下所示：

我现在将简要介绍我们如何解决这些问题。

1、帖子内容不得集中

我们决定使用Arweave数据存储协议来存储用户内容。Arweave 在上传时提供一次性数据的永久存储。 发布到 Arweave 的数据包括检索出版物的所有条目（包括所做的任何更改）和验证作者身份真实性所需的所有信息。 我们计划发布协议规范以及一个可以协助检索和验证过程的开源工具，以便在时机成熟时从 Mirror 迁移出来 是微不足道的。

2、阅读体验不需要信任Mirror

所有条目都由用户的签名密钥签名。这是一个非以太坊密钥对，不包含任何直接经济价值。稍后我将对此进行更多解释。 然后将签名连同已签名的摘要以及进入摘要的内容一起发布到 Arweave。签名密钥本身被放入声明作者权的消息中，然后 由作者的以太坊地址签名。所有这些信息与条目的内容一起存储在 Arweave 上——用于每个条目和更新。因此，任何人都 可以（并且相当容易）验证条目是否由给定的以太坊帐户创作。

我们仍在对这个模型进行迭代，而且显然还为时过早。

3、Mirror不得拥有作者的域名

我们使用 ENS 向作者提供域所有权，作者在入职期间通过销毁邀请令牌（称为 $WRITE；期待更多信息）来声明此所有权。 该过程涉及与 $WRITE ERC20 代币合约进行交互，该合约授权 ENS 注册商合约在注册 ENS 标签之前销毁代币。

4、作者不需要连接他们的钱包并签署他们所写的一切

我们不想让必须在 Mirror 上编写条目变得很麻烦——例如，需要使用他们的 Ledger 钱包（或 Metamask）签署所有内容。 特别是，因为我们设想允许用户采取更小、更频繁的操作，例如评论或喜欢其他人的条目。我们仍然希望拥有一流的安全性， 但我们认为如果作者需要他们的硬件钱包进行写作，这将是一种劝阻。

5、Mirror 不会尝试在浏览器中存储以太坊私钥！

将用户的以太坊私钥直接存储在浏览器中被认为是异端，我通常会同意这一点。严格来说，你不能以这种方式构建有用的 web 应用程序（Dharma 做过一段时间），但安全负担会随着时间的推移而加重。这主要是因为无法使用原生 web-crypto 库制作 和存储不可提取的以太坊私钥；它不支持相同的 ECDSA 曲线。我不知道这在未来会如何发展，但就目前而言，我想说这是 要避免的事情。

我们通过两种方式避免这种安全负担：

• 通过使用与以太坊实现不同的签名方案（我们使用的是 NIST 曲线P-256），因此根本不可能让密钥“保持经济价值”， 并完全回避一个主要问题。在最严重的威胁模型（例如被盗的计算机）下，最坏的情况是作者身份欺诈。
• 通过使用不可提取属性生成密钥，并将其存储在 IndexDB 中。这意味着根本无法导出私钥——私钥只能用于在加载它的网页上 签署内容，而 IndexDB 会阻止它被加载到 mirror.xyz 之外的任何网站上。

我邀请大家对这种方案进行评判。我不是密码学专家，我们只是试图在一个安全且可用的平台上做出诚实的努力，该平台位于 令我们失望的传统 web2 标准之外。如果你想对该方法进行更详细的解释，我们将很快发布关于此主题的更完整的规范/RFC。

6、写作不能太贵

使用 Arweave 解决！🎉 非常便宜（目前？）——每篇博文花费大约 0.00005 AR，按当前汇率计算，约合 0.00015 美元。

7、奖励：不使用电子邮件密码注册！

由于我们有签名密钥和基于签名的真实性模型，我们不需要登录会话，也没有任何东西可以通过电子邮件恢复。将来， 允许电子邮件通知和电子邮件摘要可能会很有用，但现在有趣的是，使用 Mirror 不需要电子邮件确认。这是 Zerion 和 Zapper 等应用程序使用的原生加密方式，也是网络身份验证的未来。

我们通过在加入时添加交易确认来弥补这种摩擦的不足！😂但即便如此，我们也会随着时间的推移而变得平滑。

3、主网前测试

Mirror 仍处于早期阶段，我们正在使用以太坊测试网基础设施来探索我们的想法。这使我们能够以非常低的成本和快速的 确认时间运行复杂的协议流程（如销毁代币、部署合约和注册 ENS 域）。特别是，随着对更复杂系统的需求增长，我们仍在 探索我们的经济、命名和所有权协议的机制。一旦我们知道将我们的早期作者迁移到这个更好的协议将是可行且容易的，我们 希望尽快部署到主网。

4、将后端 API 构建为“协议网关”

为了促进良好的阅读和写作体验，我们决定构建一个后端 API，可以充当客户端和协议之间的网关。这允许我们在发布到 Arweave 之前进行签名验证等操作，或者自己支付 Arweave 发布费用并缓存条目内容以实现极快的响应时间。这使我们能够 拥有世界一流的写作和阅读体验，同时仍然实现我们所有的内容去中心化目标。

就在 2021 年构建这个后端 API 而言，可能有 10 多种可行的选择来部署代码，以及许多有前途的开发语言。挑选早期工具 可能很困难！我最终选择了一些在我能力范围内的东西，而且我们团队中的新工程师也很容易学习。我还选择了我认为在未来 具有最大可扩展性和灵活性的路径，这对我们来说意味着在 AWS 基础设施上使用 NodeJS构建我们的后端。然而，这个决定并 不明显，我想考虑到我们将在未来作为工程订单建立的能力。

在 AWS 上设置 Web 应用程序比使用 Heroku 或 Vercel 等抽象服务要耗时得多。环境、数据库、安全组和部署之类的东西都 必须单独配置。但是，从长远来看，它会授予更多控制权，这对于有时存在非标准问题的加密应用程序可能会有所帮助。我花 了大约 2 天的时间来设置这个基础设施——包括安全组、IAM 账户、数据库、暂存和生产环境等。但从这里开始，我知道我拥 有世界上最好的基础设施，没有新的平台风险，较少的全功能服务。

我们通过 AWS 的 RDS 服务使用 Postgres，并使用 VPC 和安全组在ElasticBeanstalk和 RDS 之间进行通信。我们将GraphQL 与 Apollo 一起用于我们的 API 端点。

我会在这里指出，在提交这条路径之前的一段时间，我考虑过用 Golang 或 Rust 编写后端，并使用 protobufs，因为加密签名 需要严格的类型才能跨平台进行正确验证。但是如果我们走这条路，发展会慢很多。另一方面，从一开始就在 Rust 中建立能力 将使我们能够跟踪越来越多的有趣的第 2 层集成（这似乎很有希望）。

我们的部署是通过Github 工作流处理的，因此每次推送到我们的staging或main都会触发在 Github 上部署应用程序的操作。 需要明确的是，这里还有很多需要改进的地方——包括阻止部署测试套件通过，以及测量测试覆盖率。我们没有完整的集成测试， 例如针对带有暴露 GraphQL 端点的内置 docker容器。

5、构建博客前端

我们决定在前端使用 Vercel 和 NextJS，它们具有通配符子域支持，以及对静态渲染内容的支持。到目前为止，这一切都很好， 因为我们获得了快速加载、缓存良好的内容，这些内容可以被社交媒体平台和搜索引擎等机器轻松读取。它通常也是管理登台 环境、部署等的绝佳产品。

6、为什么进展顺利？

我们能够非常非常快地获得 MVP——我们的目标是在圣诞节前发布，直到 12 月才开始以某种方式构建后端。所以总的来说， 我们只用了几周时间就构建了一个新颖的 CMS，它使用公私密钥签名来验证内容，将数据存储在 Postgres 中，将数据存储 在 Arweave 上，在以太坊上烧掉一个通证以声明对 ENS 标签的所有权，验证该标签，我们签名模型的迭代等等。

以下是这些事情的一些具体示例：

• Trent 的第一篇博文：https ://stateful.mirror.xyz/a151ee1decb2028a8bb48277f6928c6f38319c32601dc1da1ee82acfcad2e525
• 烧掉 $WRITE 通证并声明 ENS 域的交易：https ://rinkeby.etherscan.io/tx/0x29b9d13187a2db64b7d85f4ff5be739729b07404fd1f5fce79b3bba13da7530b
• 永久存储 Linda帖子的 Arweave 交易以及证明作者身份的签名：https ://viewblock.io/arweave/tx/WvwsHyKCjfkLoKNbNSGfoV-vaWrJa2PMYB_c3wucXUA

即使回想过去一个月以及我们能够建立的一切，也令人筋疲力尽！事实上，这基本上是有效的，这非常有趣和令人兴奋。 我很高兴我们也在“公开”中做了很多这样的事情，并用屏幕记录了我们的入职会议。

7、什么地方出了错？

通过一次解决如此多的挑战，有时会感觉有大量的重要问题迫切需要修补。有时，这让我很难以线性方式沟通优先事项， 因此我们都在同一页面上，并在同一件事上理性地合作。鉴于该团队在这个项目之前没有合作过，并且只是在了解我们 每个不同的工作和沟通方式，因此我们需要改进相当多的“沟通不足”。

快节奏也造成了一些混乱。例如，一个星期四晚些时候，我正在配置 Github 工作流以部署我们的 AWS EB 环境，它在 暂存时运行良好。我们没有在周末部署到生产环境，在那段时间里，我将生产环境更新为全新的 AWS EB 环境。我们周一 的第一次部署发布到了过时的环境，并且在入职会议之前出现了一个错误！我们不得不回滚以防止直播失败的入职，这 非常令人困惑！我们为此编写了第一个验尸报告。

8、吸取了哪些教训？

我们了解到，我们可以真正努力工作并快速工作，以在短时间内实现雄心勃勃的目标。我认为我们通过达到 12 月 25 日的 最后期限证明了这一点。

我们还学到了很多关于每个人和我们的能力（我们只有三个人），以及我们需要如何相互沟通以建立对事情进展的更多信任 和信心。这包括过度沟通更多关于代码库和产品的期望和责任、悬而未决的问题、优先级和任何给定 sprint 的个人目标。

期待更多关于 $WRITE 的信息。

---

原文链接：The MVP Before Christmas

汇智网翻译整理，转载请标明出处