Iron Fish 项目研报

Iron Fish 项目研报

  1. 项目简介
  2. 项目详情
    -Network
    -储存
    -区块创建&验证(挖矿)
    -事务&钱包的创建
    3.个人见解
    项目简介 1
    Iron Fish 是一个去中心化、并基于工作量证明 (PoW)、抗审查且可公开访问的区块
    链隐私项目,旨在为每笔交易提供强大的隐私保证
    Iron Fish 的想法是让包括交易信息、挖矿信息、钱包信息全都隐藏起来,除了私钥所
    有者以外,其他钱包地址都无法查看。为实现这一目标,Iron Fish 使用了 PoW 共识
    机制(古老经典的共识机制)和零知识证明(Zcash 的 Sapling Protocol)。并且
    Iron Fish 未来网络层将支持 WebRTC 与 WebSockets,这意味着可通过浏览器直接
    运行完整的 Iron Fish 节点
    另外,他旨在成为所有链的隐私层,所有其发展潜力远比直接制作隐私性高的公链来
    得更通用更有可行性,同时也更有发展潜力。
    而这个项目所采用的零知识证明体系 zk-SNARK 我就不深入讲解其原作原理,我会尽
    量以最浅白的方式告诉大家 Iron Fish 是怎么样实现它保护隐私的功能的
    (PS:这篇研报的内容可能比较艰深,但我不会解说到区块链基础的知识,因为连带基
    础区块链知识也一并解释的话篇幅会太长和连贯性也比较不好
    另外,因为我不是数学专业的,但这个项目牵扯到的 Zk-SNARK 里面包含了太多复
    杂的数学公式,所以我对于完整的运作流程也是一知半解,所以如果有说错的地方请
    各位大神指正>~<)
    项目详情 1
    为了帮助你更好理解下面的内容,我先简单介绍 2 个大家可能不是很认识的名词
    zk-SNARK-就是一个为了将实际的零知识证明类问题转为计算器程序问题的理论
    ZCash-是一个匿名交易系统,支持多种隐私交易型别
    2.1 Network
    网络层(Network)决定了节点之间如何相互交互,使用哪些传输层通信,如何向其
    他节点发送消息以及如何请求/相应来自其他节点的特定消息
    而传输层方面,Iron Fish 着重于可访问性(更方便用户使用),所以选择了
    WebRTC 和 WebSockets,让任何人都可以更轻松地使用 Iron Fish。而
    WebSockets 用于进行初始的连接引导节点,所有后续对等连接都使用 WebRTC
    关于节点的信息种类和传输的信息种类我就不细说了,我直接说关于 Iron Fish 的节点
    之间的信息传输模式,也就是经典的 Gossip 协议,昵称是“流行病协议”
    这个协议就是 Bitcoin 区块链上传播交易和区块信息的协议,原理其实非常简单也就
    是,当一个种子节点有状态需要更新到网络中的其他节点时,它会随机的选择周围几
    个节点散播消息,收到消息的节点也会重复该过程,直至最终网络中所有的节点都收
    到了消息,就跟病毒传播的模式一样
    但为了让网络更为有效率和减少网络的堵塞,所以 Iron Fish 改进了这个机制,添加了
    多 2 项规则
    • 当节点 A 向节点 B 发送消息时,节点 B 不会将消息发送回节点 A。
    • 当节点 A 向节点 B 发送消息时,节点 B(知道 A 已经处理了它)将避免向节
    点 A 和 B 都连接到的任何对等节点发送消息。
    这样可以避免同一消息的无限广播,同时每个节点又能存储一组它所收到的所有信息
    演示例子:
    当节点 A 成为种子节点时,信息在节点间传播的步骤如下:
  3. 节点 A 向节点 B、C、D 和 E 广播。
  4. 节点 B 将消息转发给 G,不会将消息转发给 C 和 E,因为它知道节点 A 已连
    接到它们并且已经发送了它。节点 C 将消息转发给 H。节点 D 转发给 I,节点
    E 转发给 F
    所有这一切的发生,用户其实都无需做任何事情,甚至无需意识到这一点的情况下都
    可以。当启动了一个节点时,用户将看到的只是节点连接到引导节点,然后快速连接
    到许多其他节点
    而目前这种节点传输的模式其实还不是最有效率最省算力的,还是会造成部分节点的
    信息传输不即时,所以 Iron Fish 在主网上线前改进区块的传播模式,让节点不会发送
    整个块,而是首先发送块的标头。然后,对等节点可以在请求完整区块的数据之前验
    证它是否已经收到。目前也同时在考虑其他优化的方式例如 IBLTs 或 Minisketch
    2.2 储存
    Iron Fish 采用了 ZCash 的基本数据结构,也就是 Note,nullifierCommitment 和
    Merkle Trees。而 Zcash 参考了 BTC 的 UTXO 模型,拥有交易输入和交易输出的概

    Note 就像一个更新你钱包数据的标签,而为了避免用户重复使用自己钱包的 Note 来
    篡改自己的代币状态&数量,又有了 nullifier 列表,在 Note 使用后被列入列表里,
    如果被重复使用也会因为在被使用过的列表里而拒绝执行
    Note 和 nullifier 都会储存在 Merkle Trees 的累加器数据结构,用于保存所有创建的
    Note 和 nullifier,不过会在零知识证明 zk-SNARK 网络体系中构建来达到保护用户
    隐私的效果
    Iron Fish 存储这些注释、无效符、区块、交易和区块头的同时,存储层也可以完全在
    浏览器中作为命令行界面 (CLI) 工具在您的计算机上作为程序运行
    但因为 Iron Fish 需要在浏览器和 NodeJS 终端环境中运行浏,因此对于需要能兼容
    浏览器中使用数据库的应用程序,最强大的数据库选择是 IndexedDB。但因 NodeJS
    不兼容 IndexedDB ,所以我们选择了更具兼容性的 LevelDB 数据库
    不过因为同时运行的关系,为了避免两个不同的数据库处理两个单独的存储,我们的
    Iron Fish 实现具有基于 LevelUp 的数据存储和数据库访问的通用抽象层。这个抽象层
    负责底层数据库的执行,并公开了一个可在浏览器和 NodeJS 环境中使用的通用层,
    提供一个简单的与数据存储无关的 API,更简单地说,存储层是其底层数据存储的
    API
    综合了以上的说明,最终形成了一个同时在浏览器和 NodeJS 运作的双储存数据库的
    结构,同时也用了 zk-SNASH 和 Zcash 来设计整个储存网络,形成了完美的数据储
    存隐私结构
    2.3 区块创建&验证(挖矿)
    在区块链中缺一不可的环节就是创建区块+验证了,也就是完美俗称的挖矿,而不管
    一个块是否有交易,创建块的过程都是一样的:
  5. 确定块体
  6. 设定难度和目标
  7. 包括基于代币排放时间表的矿工奖励
  8. 区块头构造
    确定区块
    块体中的交易已被其他希望将其交易添加到区块链中的对等方广播。为了激励矿工将
    此类未决交易纳入区块主体,交易中会多支付给矿工的公开可见的交易小费
    而具有无效交易的区块在被矿工验证后将被拒绝执行
    设定难度和目标
    Iron Fish 区块链算法动态调整挖掘难度以达到 60 秒的平均出块时间,如果观察到先
    前的块进入太快或太慢,则通过增加或降低挖掘难度来实现(和以太坊挖矿难度 EIP2 机制很像)
    挖矿奖励
    挖矿奖励(矿工为成功挖出一个区块而分配了多少硬币)与 Iron Fish 代币排放曲线相
    关。Iron Fish 排放曲线的逻辑是主网启动后的第一年,总代币供应量会增加了创世区
    块价值的四分之一(由于挖矿奖励)。根据衰减函数,随后几年新铸造的硬币将越来
    越少,但永远不会完全达到 0
    其中 s 是 4200 万个创世区块的初始供应量,k 是衰减因子 -.05,x 是主网上线后的年
    份(从 0 开始)
    Iron Fish 区块计数中的“年”是 525,600 个区块为一年(假设 60 秒的区块时间)。我
    们使用上面的公式来计算使用 Iron Fish“年”的块奖励,四舍五入到最接近的硬币的
    0.125
    因此,发布后最初几年的整体奖励和总供应量分布如下
    使用上述区块奖励公式的排放曲线,总供应量上限为 256,970,400 个硬币,如下所示
    区块头构造
    目前这个部分最重要的 Iron Fish Hashing Algorithm,还没有公布,所以暂且不详

    2.4 事务&钱包的创建
    一个交易的结构在 Iron Fish 下是这样的
    • 交易费用:任何成功将此交易包含在区块中的矿工的费用
    • 消费(Spend):消费描述列表
    • 输出(Output):输出描述列表
    • 绑定签名:用于签署交易并用于验证交易是否平衡,以确保不会凭空破坏或创
    造代币,并且验证是消费描述中的所有资金减去输出描述中的资金描述等于矿
    工的交易费用
    在 Spend 中使用的 Note 将来不能再次使用,因为在使用它时必须显示唯一的
    nullifier,因为如果该 nullifier 在过去被使用过,后续尝试的话将被验证者(例如矿
    工)拒绝
    例如,如果 Alice 有一张价值 5 个代币,并想向 Bob 发送 4 个代币,那么交易将如
    下所示:
    • Alice 会使用 Spend 描述的 Note(在本例中是一张价值为 5 个代币的 Note)
    以及该 Note 的 nullifier(根据 Note 更新 Alice 钱包的代币数量)
    • 并且将有两个 Output 描述诞生,一个的 Note 是给 Bob 的四个代币,一个的
    Note 是给 Alice 自己的一个代币(直接根据 Note 更新这 2 个地址的代币数
    量)
    而为了确保隐私,Spend 描述在零知识证明(特别是 zk-SNARK Groth16 Sapling
    证明)的模式下花费 Note,但不会透露花费了哪个 Note
    而验证者(矿工)验证整个交易的过程如下:
  9. 针对 Spend 描述中的公共参数验证所有零知识证明
  10. 根据 Output 描述中的公共参数验证所有零知识证明
  11. 检查交易余额(确保交易的平衡,没有在过程中产出代币或销毁代币)
  12. 检查 Spend 描述中的每个签名是否都签署了交易哈希(确保是发起人发起的
    交易)
  13. 检查根锚 (rtr _) 在所有 Spend 交易中,在验证者的 Merkle 树上的 Merkle 树
    根之后都是有效的(这部分我就不解释了,这个用途是为了证明验证路径是有
    效且正确的)
  14. 检查 Spend 描述中的任何 nullidier 是否在过去都被使用过
    Iron Fish 的钱包结构
    Iron Fish 中的账户和交易受 Sapling 协议的影响很大,但存在一些小小的差异。Iron
    Fish 帐户的所有关键组件均源自单个密钥。尽管底层账户的构建可能看起来很复杂,
    但总体而言,除了密钥之外,每个账户都有一组用于该账户资金执行 Spend 描述的密
    钥,查看提供给任何第三方以进行只读访问的密钥,以及用于接收他人资金的公共地

    Secret Key(私钥)- 可以直接授权钱包的所有活动=钱包的最高权限证明
    Spending Key Pair - 授权任何更改账户资金状态的 Spend 描述,又私钥直接派生
    Nullifer Key Pair – 这些密钥负责创建从密钥派生的 Spend Note 所需的 nullider
    Outgoing View Key - 允许解密传出事务
    Incoming View Key - 允许解密传入事务
    个人见解 1
    Iron Fish 是一个使用零知识证明来创建用户体验更号的私有加密货币的去中心化区块
    链网络。并且 Iron Fish 受到基于 zk-SNARK 的 Sapling 协议的启发,允许用户以设
    计完全屏蔽的方式发送交易
    Iron Fish 未来会再扩展以提供更多资产、稳定币、手机上的可用性以及与其他链的桥
    梁,包括第 Layer 2 支持等等
    所以这个项目最大的价值捕获就是成为所有公链的通用隐私层,并基于良好的用户体
    验来让每个需要隐藏交易,钱包等等信息的用户可以更方便地保护自己的隐私
    因此它的潜在市场是极大的,应用场景极广,以 Metaverse 来说每个人的生活是非常
    需要隐私的保护,这种零知识证明的体系不只保护的是资产的交易更是未来每个人之
    间的交互都能保护。
    因此虽然目前隐私赛道在投资的热度上还普普,但这个赛道的潜在硬需求是很明显
    的,只做合约隐私的$SCRT Marketcap 有 8 亿市值,而像 AR 这样的基础设施蓝筹
    最近也在搞零知识证明,Iron Fish 还被 a16z 投注了 2700 万美金,因此目前项目和
    VC 端已经开始注意到了隐私赛道的潜在硬需求
    不过当然目前隐私赛道最大的风险就是目前还无法证明其潜在需求量以及不排除未来
    各个公链或项目直接推出原生的隐私保护机制,直接抹杀掉第三方的隐私赛道项目。
    但如果排除掉这 2 个风险因素的话,基本上隐私赛道就是下一个基础设施里 Alpha,
    而这第一个是大概率不会发生的问题,第二个的话除非有更好解决隐私问题的技术方
    案出现,不然这些公链就需要完全地把 zCash 融入到公链的设计中,基本上就是要完
    全重新改革公链的结构,而这也是一个大概率不会发生的事情,所以这个赛道我还是
    很看好的,因此 Iron Fish 作为其中应用层面最广的项目(直接从底层公链出发,到钱
    包,合约等等都涉及隐私的设计)自然也看好后续的发展
    目前团队的负责人是来自微软、Tilt 和 AirBnb 的前工程师 Elena Nadolinski 领导,并
    且获得了 a16z 的领投,所以背景方面也是没有太大问题

参考数据
Iron Fish 白皮书:https://ironfish.network/docs/whitepaper/1_introduction
关于零知识证明:https://www.itread01.com/content/1522388432.html
ZCash 完整的匿名交易流程:
https://www.itread01.com/content/1558595104.html
— 版权信息 —
本报告版权仅为 CYBER J Club 所有。未经书面许可,任何机构或个人不得以翻版、
复制、引用或再次分发他人等形式侵犯版权。

Subscribe to blockchain
Receive the latest updates directly to your inbox.
Verification
This entry has been permanently stored onchain and signed by its creator.