具有隐私保护的ZK Layer1——Iron Fish

Iron Fish对于隐私的思考 隐私是有争议的，但它不应该是。事实上，隐私导致了创新--通过改变法律实现社会进化，并使人们能够自由地做自己。关闭房门或遮盖银行账户密码，这两者都是大多数人采取的预防措施，尽管他们可能会说他们没有什么可隐瞒的。就像 90 年代 SSL/TLS 的引入打开了电子商务（HTTPS的前身）的闸门一样，Iron Fish相信可访问的隐私币将催生无边界产品和公司的新一类行业。他们的使命是实现价值的自由流动，同时保护个人隐私的权利。

Monero和Tornado cash的局限 数据安全是永恒的话题，保护用户隐私是P2P公司最基本的责任。以去中心化为核心的区块链不乏有很多尝试，最著名的就是Monero，但由于其不支持智能合约，用户想获得隐私的保护需要将资金换成XMR再进行交易，这样的设计使得Monero始终无法得到大范围应用。而在盗币事件中频繁出现的Tornado cash，在dApp层级实现个人的财富转移和存储隐私，但随着NFT头像、社交账号绑定、mirror文章等的流行，使得doxing的发生更为频繁，Tornado cash这种程度的隐私保护远远不能满足大部分人的需求。

Oasis的分层解决方案 区块链主要分为网络、应用、共识这三层。出于不同的目的，各个公链针对这三层进行优化。市场呼唤针对应用层的加密方案，以满足各种金融环境下的隐私保护需求。现行的Oasis从共识层分离出ParaTime层负责执行交易，每个ParaTime可独立并行执行交易互不影响。其对于ParaTime提供了一种TEE（可信执行环境）的安全计算技术。TEE 充当在机密 ParaTime 中执行智能合约的假设黑匣子。加密数据与智能合约一起进入黑匣子，数据被解密，由智能合约处理，然后在发送出 TEE 之前进行加密。此过程确保数据保持机密，并且永远不会泄露给节点运营商或应用程序开发人员共识。但之前由于高APR和EVM compatible而吸引了大量关注的Emerald Mainnet并没有集成这项功能，即将推出的Sapphire将呈现EVM的TEE。 [Image]

Iron Fish的隐私保护 而Iron Fish从底层设计上就考虑到隐私保护，分别在这三层使用了不同的策略来协同保障链上用户隐私。Iron Fish 网络层支持带有 WebSockets 的 WebRTC，使所有用户无需其他设置要求即可轻松建立真正的 P2P 连接。Iron Fish节点首要目标是在未来的迭代中，使直接在浏览器中运行一个完整的节点变的可能。我们的关注点是降低进入门槛，让任何拥有计算机的人都可以加入Iron Fish的网络。

Networking 虽然其他一些网络层要求用户为其路由器设置端口转发以解决 NAT(Network Address Translation)问题，但我们在设计实现时侧重于可访问性，将WebRTC和WebSockets组合用于我们的传输层。他们使用大量技术来帮助节点建立直接通信。换句话说，Iron Fish节点实现开箱即用，无论是在 CLI 环境中，还是直接在浏览器中。这使得任何人都可以轻松使用 Iron Fish，无论技术能力如何。 当一个节点第一次启动时，它需要知道它可以连接到的至少一个其他节点（称为引导节点），它将把它介绍给网络中的更多对等点。与引导节点的初始连接通过 WebSocket 进行，所有后续对等连接都使用 WebRTC。本节将准确描述节点如何相互连接以形成支持 Iron Fish 协议的网络，从新节点如何启动开始。 新节点启动 当一个新节点启动时，会发生以下情况：

  1. 新节点从提供的列表中随机选择一个引导节点，并打开到它的 WebSocket 连接。如果用户在此步骤中有想要连接的特定节点，他们可以使用配置文件或命令行来指定他们自己首选的引导节点。引导节点将其身份发送给新节点。

  2. 引导节点向新节点广播对等列表。

  3. 使用该列表，新节点决定连接到哪些对等方。

  4. 与节点连接的每个新对等方重复第 3 步，直到建立最大连接数（最多 50 个）。

  5. 为了最大化我们网络的强度并防止网络碎片化，节点将优先连接到相对较少的已知对等点当前连接的对等点。 这些操作对于搭建节点的用户来说是无感的，只需要启动节点，接着就会按照上述顺序自动连接到引导节点，然后快速连接到许多其他节点。 通信 消息是要在对等点之间共享的一条信息的商定格式。根据情况，有以下几种类型的消息和它们与节点交互的方式： 内部消息类型

  • 身份：一个对等点可以向另一个对等点识别自己的消息

  • 信号：用于在两个对等点之间发出实时通信 (RTC) 会话信号的消息

  • Peer List：包含此节点当前连接的对等点列表的消息

  • 无法满足请求：出现问题时的错误消息 路由方式类型

  • Gossip protocol：这些消息到达网络中的每个节点。当一个节点收到一条Gossip消息时，它会验证该消息并将其转发给其他连接的节点。这用于将区块链的更改传播到网络中的所有节点。

  • Fire and Forget：这些消息是指向一个特定的已连接的对等体（不可能向一个你没有连接的对等体发送消息），不期望从对等体得到响应或接收确认。当你不需要确保数据被正确接收时，这很有用。

  • 直接 RPC：在这里，一个消息请求被发送到一个特定的连接对等体，并且系统期望一个响应。远程过程调用(RPC) 由两个部分组成：一个用于请求，一个用于响应。这用作 Global RPC 的支持层。

  • 全局 RPC：这些消息不发送给特定的对等方。如果没有得到响应，或者响应无效，网络库将选择一个对等点来发送消息并与另一个对等点重试（最多指定的有限数量）。选择算法是随机的，并加权以偏爱已知更有可能响应已注册消息类型的对等方。 Gossip protocol举例 当一个新节点上线并与对等点连接时，对等点会传达其直接对等点的列表。 假设我们当前的网络由一个新的节点 A 组成，连接到节点 B 和 C。C 本身连接到节点 D 和 E。D 本身连接到 F 和 G。从视觉上看，这看起来像下图： [Image] 节点只知道他们的直接邻居，以及他们邻居的邻居。节点 A 将不知道 D 和 E 之外的节点。 节点 A 现在可以决定连接到一些对等点，并将存储每个节点对等点列表的副本。

Storage Iron Fish存储的数据主要分为两部分：notes和nullifiers。当nullifiers附加的note被使用后，nullifiers就会显示出来，两者数量上呈线性关系，所以被存在两个大小相同的默克尔树中。但两者加密所用的哈希函数不同，前者是Pedersen hash，后者是blake3。与交易无关的notes和nullifiers不会被接受，并成为链上的一部分。 note默克尔树的组成部分： This content is only supported in a Feishu Docs 交易示意 [Image] 为了确保隐私，花费描述在零知识证明（特别是zk-SNARK Groth16 Sapling）的帮助下使用了一个note，而不会透露使用了哪个note。输出描述同样创建了一个加密的note，同时存在一个零知识证明的验证，证明新创建的note是正确的。这些证明的流程设计取自 Sapling原始工具，这些工具又是使用bellman线路工具构建的。 存储实现原理 由于我们知道在浏览器中运行Iron Fish的完整实现，要比在NodeJS终端环境中运行它更具挑战性，所以我们首先关注的是这个问题。对于想要在浏览器中使用数据库的应用程序来说，最强大的数据库选择是IndexedDB。不幸的是，NodeJS并没有相应的IndexedDB实现，所以我们选择了LevelDB作为我们的NodeJS实现。 为了防止不得不为两个不同的数据库采用两种不同的存储实现，我们对Iron Fish的实现有一个基于LevelUp的数据存储和数据库访问的通用抽象层。这个抽象层处理了底层数据库的具体实现，并暴露了一个通用层，可以在浏览器和NodeJS环境中使用，提供了一个简单的数据存储无关的API。 [Image] 简单来说，存储层是其底层数据存储的一个API--它可以从模式中创建存储，并通过所有正常的键值存储操作（如GET、PUT、DEL和HAS）对它们进行操作。

Consensus 共识层负责Iron Fish网络的交易验证，它设定了节点接受传入区块的规则。这些规则隐含地迫使节点按照这些规则构建区块，否则该区块将不会被网络中的其他节点接受。 如果一个区块的header和body都是有效的，它就会被接受。在高层次上验证区块header，可以确认该区块背后有足够的工作量，具体方法是检查其哈希值是否低于目标值，以及节点是否通过正确地将该区块中的所有事务应用于两个全局数据结构（notes和nullifiers），并提供两个由此过程产生的Merkle根来执行正确的状态转换。类似地，验证区块主体来确认该区块中的所有交易都是有效的。 坚持PoW 铁鱼在对PoS和PoW的优缺点全面分析后，认为PoW系统整体上更安全，更容易理解攻击媒介，有更好的途径实现平等和公平的去中心化，虽然PoS往往带来更好的用户体验和更短的交易时间，但对于Layer-1新公链来说，仍然不是个好选择。 交易验证过程 Block Header Iron Fish区块块头包括以下几个部分：

  • 序列

  • 前一个块的哈希

  • NoteCommitment

  • nullifierCommitment

  • 目标

  • 时间戳

  • 矿工费

  • 随机性 验证时遵循以下规则：

  1. 当前块头的序列必须比前一个块中的序列（例如区块数）多一个，并且前一个块必须是具有previousBlockHash的那个，且previousBlockHash必须对应于一个有效的现有块；

  2. 当区块Body中的事务被应用于两个全局数据结构（Merkle Tree of Notes和Merkle Tree of Nullifiers）之后，这两个树的结果，即Merkle树根必须对应于区块头中的noteCommitment和nullifierCommitment；

  3. 通过使用本区块的时间戳、前一区块的时间戳和前一区块的目标公式，来检查目标；

  4. 当前区块的时间戳必须晚于前一个区块的时间戳，并有15秒的容忍度（这意味着对于一个进入的最新区块，其时间戳与当前区块被检查的时间相比，可以有15秒的偏差）。 Block Body 验证区块块体包括验证区块中的所有交易，这可以并行进行，因为每个交易应该是独立有效的。对于其中的每一笔交易，验证者必须做以下几项检查：

  5. 根据Spend描述中的公共参数验证所有的零知识证明；

  6. 根据输出描述中的公共参数验证所有的零知识证明；

  7. 检查交易余额；

  8. 检查Spend描述中的每个签名是否签署了交易哈希值；

  9. 检查所有Spend交易中的根锚（rt）是否是验证者Merkle树上有效的前树根；

  10. 检查花销描述中的nullifiers是否在过去被揭示过。

Iron Fish未来计划 Iron Fish的初始版本为任何人都可以可靠地、低门槛地进行的私人交易奠定了基础。接下来的更新迭代包括：

  • 自定义资产

  • 对于稳定币和多条Layer-2的功能性支持

  • 对移动和网页端更丰富的支持

融资情况和其他信息 Iron Fish 由微软和 Airbnb 的前软件工程师 Elena Nadolinski 于 2018 年创立。 Iron Fish总融资27.7M（而Tornado Cash的market cap有39M），资方包括Sequoia、Arrington XRP、A16z等。 Iron Fish Token总量约为0.25B，初始供应量约4.2M。主网启动后第一年内，每个区块奖励20枚，随后每一年的区块奖励都将根据衰减函数递减。在主网启动前的激励测试网阶段，Iron Fish准备了总量42万枚的Token用于奖励用户。方式主要靠累计积分，积分可根据激励测试网挖矿、寻找 bug 或在 Github 中修改批注（Pull Request）等方式获得。每个获得积分的类别每周累计积分上限为 1000 分。同时，每开采一个区块累计100分，这意味着每周激励测试网挖矿获得积分上限为10个区块。