这就是预言机出现的地方——随着 DeFi 的发展，它们的用例变得比以往任何时候都更加重要和相关。

究竟什么是预言机？

预言机可以定义为第三方服务，它利用区块链上的智能合约从链下世界检索任何所需的信息或从外部来源检索数据。

从本质上讲，它们充当可以输入智能合约的数据源，要求它们从任何外部数据源检索实时数据。

由于区块链和智能合约是封闭的生态系统，预言机是区块链和现实世界之间必不可少的桥梁，可以实现更强大的链上服务。因此，它们必须非常安全。

预言机执行几个关键功能，例如：

• **监听——**预言机监控网络，扫描任何对链下数据的请求。

• **提取——**一旦预言机收到请求，它们就会从外部数据源中提取信息，例如链下 API。

• **格式化——**检索到的数据被调整为区块链可读的格式。

• **验证——**他们生成加密证明来证明预言机服务的性能。

• **计算——**为智能合约执行安全的链下计算。

• **广播——**在区块链上广播交易以将数据发送到各种智能合约。

当前预言机面临的问题

当前的预言机面临着几个问题，最紧迫的是区块链预言机问题。需要克服这个问题才能看到网络上的智能合约（如以太坊）实现主流采用。本质上，预言机问题是一个简单的限制：区块链不具备从任何外部源提取数据或将数据推送到任何外部源的能力。正因为如此，区块链需要预言机才能看到完整的效用。

它们的隔离使区块链非常可靠和安全。然而，要让智能合约充分发挥其潜力，它们需要访问链下数据。

例如，处理金融的智能合约需要市场信息来确定结算；贸易融资智能合约需要获得贸易文件，贷款合同需要获得满足条件，作物/农业合同需要获得会影响农民的有害天气和模式。等等。; 事实上，区块链预言机还有更多用例，其中最突出的是 DeFi、保险、游戏和 NFT、可持续性和企业。某些在区块链上不可用，也没有任何链下信息可以直接访问区块链。因此，预言机问题。而且，虽然看起来很简单——只要找到一个预言机解决方案——预言机技术需要格外小心。

当前的预言机也有许多限制，例如：

• **DeFi 漏洞 –**当前的预言机和跨链桥的设计存在多个漏洞，仅在 2020 年就导致损失超过 7.3 亿美元，其中包括 Spartan DeFi 闪电贷攻击、BurgerSwap 闪电贷攻击和Poly Network 黑客事件，这是黑客利用系统中的漏洞发生的最大的加密货币黑客事件之一。

• **透明度问题——**预言机报告的数据或价格是不透明的，任何实体都无法检查以确定数据的准确性。这可能导致潜在的恶意行为。

• **价格延迟——**资产价格从链下到链上的任何转移都可能造成轻微的价格延迟和偏差。然而，在动态市场中，时间延迟可能是一个重要因素。

• **问责制——**目前，预言机缺乏问责制。由于外部数据源之间的串通，这可能导致数据操纵。它还增加了向预言机提供不正确数据的风险。缺乏问责制也意味着缺乏安全性，导致智能合约被操纵。这需要解决，因为它们是区块链生态系统的关键部分。

SupraOracles：下一代跨链预言机

SupraOracles 是 Entropy Foundation 的旗舰项目，将 DeFi 应用程序及其 Multi-Helix Ledger 带给世界各地的开发人员。该项目得到了一支多元化团队的支持，他们在密码学、物联网解决方案、企业解决方案、DeFi、预言机研究等广泛领域拥有丰富的经验。

SupraOracles 弥合了传统市场和 Web 3.0 生态系统之间的差距，重点关注跨链互操作性。作为一个强大的跨链预言机，企业和机构可以利用它将现实世界的数据和价格信息连接到公共和私有区块链。其解决方案可以直接在链上交付数据，提供更好的可扩展性和安全性，同时增强智能合约的用例。它还提供了市场上最快的速度、安全性和确定性，超过了该领域的其他预言机。他们的价格信息也具有很高的准确性，因此非常高效。

其前面提到的旗舰功能 Multi-Helix Ledger（也称为 Unitychain）提供了高可扩展性和更好的安全性，同时减少了网络停机时间。Unitychain 还允许并行处理，而阈值加密和随机采样等功能可确保进一步的安全性。

SupraOracles 的突出特点

SupraOracles 具有几个突出的特性，使其成为 DeFi 领域的顶级跨链预言机之一：

• 真正的去中心化——SupraOracles 上的节点不仅仅依赖于一个来源的数据，而是从多个渠道提取数据。该系统还通过激励措施确保良好的行为。

• **可扩展性——**节点存在于多个分布式密钥生成配置中。这些在随机网络拓扑中并行组织。

• 安全——SupraOracles 利用其“部落”和“部落”的嵌套架构，通过利用阈值加密、随机采样和分布式密钥生成等加密原语实现并行处理。

• 近乎即时的确定性——SupraOracles 提供 3-5 秒的链上刷新率，与最接近的竞争对手 Chainlink 相比，后者需要 120 秒才能实现完全确定性。

• 互操作性——SupraOracles 与区块链无关，并与多个区块链兼容，例如 Ethereum、Polygon、Solana、Cardano、Polygon 和 Binance Smart Chain 等。

结论

SupraOracles 允许区块链准确可靠地访问链下的真实数据。他们还已经宣布在区块链和 DeFi 领域建立一系列值得注意的合作伙伴关系。该项目是区块链寻求以快速、安全和可扩展的方式访问链下数据的答案。跨链预言机的未来终于来了。

分片技术并不是什么创新的概念，早在区块链技术出现之前，就已经在传统数据库中运作了，主要用于大型商业数据库的优化。

其概念就是将数据库中的数据，切割成很多数据分片，再将这些分片分配到不同的伺服器中储存，如此一来，就不会因为短时间内出现大量数据访问请求，而出现单一伺服器压力过大的问题。

在传统的区块链网络中，交易必须有网络中的每个节点进行确认，以保证交易的安全，然而这也是导致交易速度难以提升的主因之一。

分片技术-pow

而把分片技术运用到区块链网络中的方式，是将区块链网络划分成若干个子网络(或称分片,shard)，每一个子网络都会包含一部分节点，网络中的资料储存与交易，会被随机分配到各个分片中做处理。

如此一来，每个节点只需要处理一小部份的工作，且不同分片上的交易可以并行处理，网络的交易速度便能因此获得提升。

分片技术-分片

另外，传统的区块链大部分都是单链结构，所有矿工都会相互竞争取下一个区块的计帐权。

且大部分区块链产生区块的平均时间是固定的，例如比特币平均每10分钟产生一个区块。

即便有越来越多的矿工加入挖矿行列，区块链也会自动提升挖矿难度，以确保区块产生速度固定在每10分钟产生一个区块。

简单来说，区块链网络中算力的提升没办法增加交易速度，这也就是为什麽区块链会是不可扩展。

如果要用简单一点的例子来形容的话，就好比你把汽车改车V8大马力引擎，但汽车电脑却设置了速度限制，不能开超过60。

在分片技术中，区块链算力的提升，意味著分片数量的提升。

也就是说网络中所投入的算力越多，能够同时并行处理的交易也会越多，整个网络的交易速度也会线性提升。

运用在区块链上的分片技术，又能够分为三种:

网络分片（network sharding）、交易分片（transaction sharding）、状态分片（state sharding）。

网络分片（network sharding）

由于区块链的区块与区块之间具有强连结性，也就是说，每一次的区块新增，都需要矿工互相通信确认新区块的有效性。

虽然这能确保链上交易纪录的正确性，却也导致区块链结构上存在不可扩展性的缺点。

因此，分片的第一步，需要先将区块链网络分片，再尽量降低互相通信的前提下，由各个分片处理链上交易。

说的简单一点就是将矿工随机分组，再将工作分配给各组矿工独立验证。

网络分片涉及到的问题是，分片后如何确保链上交易安全性能够维持。

随机分配

矿工分组之后，网络分片第一个会面临到的问题是，攻击者的攻击成本会大幅降低。

下方这张图说明的是，本来假设有100个矿工,要掌握51个才能瘫痪网络，自从有分片后,假设是100个分片，矿工一人顾一个分片下，就变成我只要有全网1%的攻击力，就有机会瘫痪某一个甚至两个分片，而这1%在原本的PoW下，根本起不了作用。

要防范攻击者最好的做法，就是建立随机性。

区块链底层Layer1扩容方案

在区块链领域建立随机性的方式主要是利用可验证随机函数（VRF,Verifiable Random Function），利用此演算法，网络可以随机抽取节点分组形成分片。

这样一种随机抽样的方式可以防止恶意节点控制单个分片。

分片的共识机制

解决了矿工分组的问题后，所要面临的问题是分组后的矿工，验证过程如何达成共识。

达成共识的算法可以选择我们熟知的PoW、PoS、PBFT等共识机制。

简单来说，网络分片就是矿工的挖矿规则，为了在分片的同时不失去去中心化特性，开发者需要尽可能地在安全与效率取得良好的平衡。

例如，网络中分片的数量与每个分片中节点的数量等问题，都需要谨慎考虑。

交易分片（transaction sharding）

网络分片针对的是矿工的游戏规则，而交易分片所针对的是哪些交易要被分配到哪些分片，然而，区块链的帐本模型的不同会对交易分片的开发造成影响。

UTXO帐本模型

UTXO的帐本系统，例如比特币，交易纪录是由多个input和多个output构成，没有帐户的概念，也不会有馀额的纪录，我们没有办法按照地址进行交易分片来有效地避免双花问题。

UTXO较直观的交易分片方式是按照交易hash值的最后几位进行分片。

例如，“如果哈希值的最后一个值是0的话，那麽交易将被分配给分片1，否则它被分配给分片2(假设只有两个分片)。”

然而，我们说过，UTXO的交易是由input和output构成，假设A发起了一笔交易，该交易的哈希值的最后一个值是0，被分配到第一个分片验证。

此时，A又发起一笔input相同但output不同(发给不同人)的交易，该笔交易被分配到第二个分片，如果不採取任何措施，这两笔交易将因为同时在两个分片当中进行处理和验证，而导致双花攻击。

在UTXO帐本系统的交易分片中，解决双花攻击的办法是分片1和分片2相互通信，以确保同一笔钱没有被重复花费。

但是在实际过程中，分片数量众多且交易的hash值是随机的，交易会被随机分配到各个分片，这就表示每个分片之间都必须相互沟通。

很明显，这方法行不通，因为如果这么做，就代表分片无法独立验证，分片就没有意义了，因此UTXO先天上就较难以实现分片。

Account帐本模型

由于UTXO帐本模型较难实现交易分片，因此，大多数采用分片技术的区块链，都是像以太坊一样的Account帐户帐本系统。

有了帐户，每一笔交易将会包含发送者的地址与余额。

因此我们只需要将交易按照发送者的地址进行分片，即可保证同一个帐户发出的多笔交易将被在同一个分片当中被处理，这样该分片即可有效的检测双花交易。

不过一但涉及到跨分片交易，例如：分片1的帐户要与分片10的帐户进行交易，势必需要跨分片的沟通来验证交易的有效性。

但与UTXO相比，至少不需要跟所有的分片沟通，只需要分片1与分片10沟通即可。

状态分片（state sharding）

状态分片可以简单理解为，在区块链资料分配在在不同分片中储存。

其所涉及的是链上资料的分片，也就是链上资料与交易纪录分片储存，借此减少节点的存储负担。

与其他两个分片机制相比，状态分片是最棘手的难题。

目前的状态分片有以下三个问题需要解决。

1)跨分片交易通讯的效益平衡

过去区块链的状态，例如帐户馀额状态储存在全网中，由全网节点共同更新维护。

但是在分片机制下，交易会根据地址分配在不同的分片处理，也就是说，状态只会储存在其地址所在的分片中，此时要面临的一个问题是，交易不会只在一个分片中进行，时常会涉及到跨分片交易。

因此若交易双方帐户被分配在不同分片，分片与分片之间势必要进行沟通才能够确保交易的有效性，频繁的跨分片互动，很容易导致整体网络效率下降。

例如:

A的地址分配在分片1，交易的纪录也会储存在分片1。

B的地址分配在分片2，交易的纪录就会储存在分片2。

一但A要打币给B，就会形成跨分片交易，分片2就会向分片1调用过去的交易纪录，确认交易的有效性，A频繁的打币给B，分片2就必须不断跟分片1互动，交易的处理效率便会因此降低。

2)分片动态刷新和节点状态更新之间的平衡

区块链的节点会随着时间而增加，且节点若长时间未重新分配，会导致交易状态过度集中化，降低遭受攻击时的弹性。

因此网络每隔一段时间需要重新调整网络节点，也就是所谓的动态分片，而新进节点也会借此更新与同步其所在分片的状态。

然而每一次的节点调整，都必须在该分片完成网络同步后，才能开始处理交易，这会造成部分延迟问题，因此设计时必须掌握好节点调整的数量与时间，否则很可能会造成分片瘫痪。

3)全网数据备份与中心化风险之间的平衡

还有一个问题是，若某些特定的分片遭到了攻击而导致其验证失去有效性。由于分片并没有複制系统的全部状态，所以网络也无法验证那些依赖于该分片的交易。

解决此问题的方法是维护存档或进行节点备份，这样就能帮助系统进行故障修复以及恢复那些不可用的数据。

但是，这样就代表系统的状态只会储存在少数节点，这会引发一些中心化的风险。

链金研究员总结

虽然分片技术与其他解决方案相比，较复杂也较难实现，但分片技术依然是目前备受期待的Layer1扩容方案。

知名的分片项目Zilliqa主网在2019年1月31日正式上线了，过去在测试网上都有相当不错的表现，实际的效能还有待确认。

而我们所熟悉的以太坊，也将会慢慢开始进化，从以太坊1.0进化到以太坊2.0，除了会将共识机制从PoW改成PoS外，还会加入Beacon Chain让分片技术得以在以太坊上实现。

分片技术的发展，或许将成为区块链迈向落地应用的一项重要决定性因素。

Fact Sheet

• Instructions are the most basic operational unit on Solana

• Each instruction contains:

  • The program_id of the intended program

  • An array of all accounts it intends to read from or write to

  • An instruction_data byte array that is specific to the intended program

• Multiple instructions can be bundled into a single transaction

• Each transaction contains:

  • An array of all accounts it intends to read from or write to

  • One or more instructions

  • A recent blockhash

  • One or more signatures

• Instructions are processed in order and atomically

• If any part of an instruction fails, the entire transaction fails.

• Transactions are limited to 1232 bytes

Fees

The Solana network collects two types of fees:

• Transaction feesopen in new window for propagating transactions (aka “gas fees”)

• Rent feesopen in new window for storing data on-chain

In Solana, transaction fees are deterministic: there is no concept of a fee market in which users can pay higher fees to increase their chances of being included in the next block. At the time of this writing, transaction fees are determined only by the number of signatures required (i.e. lamports_per_signature), not by the amount of resources used. This is because there is currently a hard cap of 1232 bytes on all transactions.

All transactions require at least one writable account to sign the transaction. Once submitted, the writable signer account that is serialized first will be the fee payer. This account will pay for the cost of the transaction regardless of whether the transaction succeeds or fails. If the fee payer does not have a sufficient balance to pay the transaction fee, the transaction will be dropped.

At the time of this writing, 50% of all transaction fees are collected by the validator that produces the block, while the remaining 50% are burned. This structure works to incentivize validators to process as many transactions as possible during their slots in the leader schedule.

Programs

Fact Sheet

• Programs process instructions from both end users and other programs

• All programs are stateless: any data they interact with is stored in separate accounts that are passed in via instructions

• Programs themselves are stored in accounts marked as executable

• All programs are owned by the BPF Loaderopen in new window and executed by the Solana Runtimeopen in new window

• Developers most commonly write programs in Rust or C++, but can choose any language that targets the LLVMopen in new window's BPFopen in new window backend

• All programs have a single entry point where instruction processing takes place (i.e. process_instruction); parameters always include:

  • program_id: pubkey

  • accounts: array,

  • instruction_data: byte array

Acccount

Account Model

There are 3 kinds of accounts on Solana:

• Data accounts store data

• Program accounts store executable programs

• Native accounts that indicate native programs on Solana such as System, Stake, and Vote

Within data accounts, there are 2 types:

• System owned accounts

• PDA (Program Derived Address) accounts

Each account has an address (usually a public key) and an owner (address of a program account). The full field list an account stores is found below.

solana

There are a few important ownership rules:

• Only a data account's owner can modify its data and debit lamports

• Anyone is allowed to credit lamports to a data account

• The owner of an account may assign a new owner if the account's data is zeroed out

Program accounts do not store state.

Fact Sheet

• Accounts are used to store data

• Each account has a unique address

• Accounts have a max size of 10mb

• PDA accounts have a max size of 10kb

• PDA accounts can be used to sign on behalf of a program

• Account size is static

• Account data storage is paid with rent

• Default account owner is the System Program

关键数据结构

Pubkey实际上就是32个字符表示的base58的Account地址，在Instruction中，我们看到的ProgramId 就是这样的类型，因为Program本身其实是一个文件，也就是Account，只是是可执行的文件。

AccountInfo就是一个Account在链上的表达形式，可以认为是一个文件的属性，想象一下state函数列出的文件属性。其中，key表示文件名，也就是base58的地址。而文件大小可以认为是lamports，这里区别于我们操作系统里面的文件，操作系统里面的文件的大小是可以为0的，且文件存在，而Solana链上的Account如果其大小也就是lamports为0的话，就认为这个文件被删除了。这里的“executable”表示文件是否可执行，如果是可执行的，那么就是一个智能合约账号。而data里面则是文件的内容，类似电脑上的ls列出的文件属性，和cat列出来的文件内容。每个文件都要由一个程序来创建，这个程序称之为这个文件的拥有者，也就是这里的owner。

ProgramResult实际上类型为ProgramError的Result对象，而ProgramError是Solana自定义的一个Error的枚举，也就是Solana抛出来的错误枚举。在合约中，当正常逻辑执行结束后，我们通过Ok()来返回这里Reuslt正确的结果，如果出错了，则通过这里的Result中的ProgramError错误返回。

AccountMeta主要用于Instruction结构的定义，用于协助传递这个指令需要的其他账号信息，其中包括了账号的地址，这个账号是否为签名账号，以及这个账号对应的内容(AccountInfo)是否可以修改。

Instruction在上面已经有介绍了，代表一个处理指令，包含了要处理他的程序的地址program_id,以及这个程序处理时需要用到的AccountMeta表示的账号信息，还有这个指令对应的具体数据payload部分的data。

这里真实的用户协议数据是序列化后，存放在data里面的，所以整体流程是DApp客户端将自定义的指令数据序列化到data里面，然后将账号信息和data发到链上，Solana节点为其找到要执行的程序，并将账号信息和数据data传递给合约程序，合约程序里面将这个data数据反序列化，得到客户端传过来的具体参数。

Reference

原因无他，去年V神便已定调Rollup将会作为ETH当前的主要扩容手段，未来在2.0分片时代也将会和分片一起承担ETH“全球结算层”的历史重任。定调之后，LRC（路印协议）算是第一个实现了Rollup方案的项目，但LRC本质上只是一个应用，并非一个通用型Rollup解决方案。

刚刚主网上线的Arbitrum，严格意义来说，才是历史上第一个上线了主网的“通用性Rollup Layer2扩容方案”（OP更早上线了测试网，但主网要7、8月份了）。

这几天在不少社群里看到有人问：“Arbitrum和Matic哪个厉害啊？不都是Layer2 么？Arbitrum和后面的Optimism以及Zk-Sync哪个厉害呀？不都是Rollup吗？”

但关于**Layer2** 解决方案的介绍文和对比文已经很多，所以本文打算彻底抛开技术，完全白话这几个的区别，好处是哪怕刚进圈不久的朋友也多少应该看得明白。

坏处就是里面的场景模拟从技术角度来讲并不完全准确，只是“白话”讲解的需要，要切实了解几个Rollup解决方案细节的朋友，还是应该去看技术层面对比的讲解文章。

我们会介绍4个不同，分别是Rollup与侧链的区别；OP与ZK的区别；OP里面Optimism与Arbitrum的区别；ZK里面Zk-Rollup与Validum的区别。

在说这些不同之前，需要先脑补一个场景：把ETH整条链看成鼎盛时期的北约组织，里面所有的ETH矿工看成是北约各国在北约各地驻扎的军队，每一笔兑换，都想象成一次“付费武装保护的金融押运”。

 01 Rollup与侧链的区别

Matic（Polygon）无疑是当前最火的Layer2 ，但严格意义上来讲，目前的Matic，并不算一个Layer2，它只是一个侧链。

Layer1（特指ETH），侧链 Layer2 （特指Rollup）区别在哪？

Layer1 你对发生在ETH上的兑换，即北约境内的发起的金融押运，无比放心。因为你觉得很安全，毕竟你交了钱给军队，这些军队是世界上最强大的武装力量，且国际信誉极佳。

侧链 - Matic上的兑换，相当于你的这次金融押运并没有发生在北约境内，而是发生在印度，由印度的军队负责押运。

如果你的起点和终点都在印度境内，那么全程印度军队押运，和北约毫无关系。如果你的起点在印度境内，终点在北约境内，那么此次押运将会先由印度军队负责，然后车队开到印度与北约领地交接处时，交由北约军队继续押运。

所以侧链和Layer1（纯北约境内）相比，区别有下面这几个点（单就安全角度）：

1、印度军队实力不如北约，理论上存在境内恐怖分子劫持你的车队风险。

2、即便没有恐怖分子劫持，有存在可能印度军队眼馋你押运的钱太多，偷偷的给你扣押了一部分。

你可能想从印度境内押送一千万去北约地界，然而印度军队和北约军队交接的时候车里却只剩500万了，北约军队只会相信看到的钱数和印度军队的文件，剩下的500万被押运的印度军队私吞了，毫无疑问，文件也做了假。

这也是为什么说侧链安全性要低于Layer1，因为节点（军队）是侧链自主所有，跟主链没有关系。

其他的高速链，比如Near，Ftm，通过桥的方式连接ETH，你可以把这些链想象成韩国，日本等与北约有兑换或是贸易的国家，每个国家安全性各不相同，取决于军队的实力，以及信誉。

那么Rollup是什么？

**Rollup**相当于是——如果你把Arbitrum看成是非洲大陆，那么在这片土地上，负责武装押运的，是北约军队的嫡系部队，或者说北约军队直接远程控制的武装机器人。

那么你应该很容易看得出，在Rollup上面发生的兑换（金融押运），也是非常安全的，比所有侧链都安全，其安全程度接近，或者说等价于北约境内的金融押运。

 02 Optimistic Rollup与ZK Rollup的区别

OP：Optimistic Rollup - 乐观RollupZk ：ZK Rollup - 零知识证明Rollup

区别在哪呢？有了上面的场景铺垫，这两个区别其实也就不难理解了：OP是嫡系部队；ZK是武装机器人。

怎么理解呢？

OP-当你在非洲大路上金融押运的时候，因为嫡系部队装备都来自北约，火力强大，恐怖分子什么的你是不担心的。唯一的问题是，当你的押运要进入北约境内时，嫡系部队和北约军队开始交接，这时你的资金需要被冻结个几天。

因为负责押运的嫡系部队，存在见钱眼开，黑化的可能性，所以像是印度军队那种1000万给你扣了500万的场景，理论上也不是不可能，毕竟只是嫡系，我们一开始只是乐观的默认他们有着和北约军队一样好的信誉。

假设负责押运的是法国军队的嫡系，那么英国军队的嫡系可以在冻结期提出挑战，质疑法国嫡系在押运途中“搞事情”。由于押运一开始时候的各种文件和资金证明，嫡系部队都必须传真给北约本土军队，且嫡系军队里，是安插有一个北约本土战地记者全程拍摄记录路上所发生的的一切事情，所以北约军队完全可以通过庭审的方式来证明法国嫡系军队是否在押运途中搞了事情。

如果确认确实“有罪”，那么法国嫡系将会被罚款或者说“扣军饷”，资金冻结的时间，就是用来“挑战”以及“庭审”用的。

ZK-北约军队直接远程控制的武装机器人，火力强大的同时，根本不存在“搞事情”的可能性。毕竟机器人没有独立自主的思维，也不会想到要去贪你那500万，他们的诚信度本质上与控制他们的北约军队是一模一样的。

所以押运从非洲进入北约境内时，你的资金不存在什么冻结时间，几分钟交接仪式弄完，就可以由机器人换成人类军队继续押运了。

这也是为什么V神说短期看OP，长期看ZK的原因。Zk拥有着等同于L1的安全性和非常短的资金退出时间，然而远程控制的武装机器人难度自然也要比直接使用人类的嫡系部队大得多，整套系统还在研发当中，估计会在未来几个月和大家见面。

 03 OP里面Optimism与Arbitrum的区别

Optimism与Arbitrum都是用的嫡系部队，直观上最主要的区别在于 - 当押运进入北约境内，有其他嫡系部队质疑这只押运部队，提出挑战时，双方对于“庭审”环节的处理是不一样的。

OP是让北约军队做时光机回到押运开始的那一刻，由北约军队替代嫡系部队把押运过程完整的再跑一遍，然后比较。好处是一次搞定，坏处是时光机器时间使用比较久成本比较高。

Arbitrum则是通过先观看战地记者的视频录像，找到有问题的那一段，然后再由北约军队坐时光机回到那个有问题的时间点，查找哪儿出了问题

好处是费用较低，因为时光机只开了一会儿，坏处是整体花费时间比一开始直接用时光机要长，因为要先花时间看录像找到分歧点在那个位置。

其实OP和**Arbitrum**还有一个技术上OVM与AVM虚拟机的区别，一个Container与Virtualization，但是一是相对太过技术导向，已经不符合本篇的主旨，二是因为太多技术导向，笔者自己也不是理解的特别透彻，所以很难把这种区别带入我们的“武装押运”场景来，有兴趣的朋友可以自行找资料研究下。

 04 Zk里面MatterLabs与Starkware的区别

原本两者是有些区别的，主要在Matter Labs的使用了ZK-Rollup，Starkware使用了类似Zk-Rollup的Validium。

但现在两者区别很小了，因为Matter Labs的Zk-Sync使用的是ZK-Rollup，但新推出的Zk-porter用的却是Validium，而Starkware的两款产品StarkNET和StartEx，也是Zk-Rollup和Validium都上了。

所以现在区别主要在细枝末节。MatterLabs的Zk-Sync用的零知识证明叫Zk-SNARKs - 简明非交互式零知识证明；Starware用的零知识证明叫Zk-Starks - 简明全透明零知识证明。

区别的话可以把它们理解成，一个是IOS系统控制的武装机器人，一个是安卓系统控制的武装机器人。

这里反而可以说说的是Zk-Rollup和Validium的区别。区别很简单，ZK-Rollup的数据都在链上，而Validium的数据都在链下。

放到我们的场景里是什么意思呢，其实也很简单。

Zk-Rollup- 北约军队的战地记者是一路跟着武装机器人的，路上的一切事情都被记录了下来传到北约总部。可想而知，这种方式更安全，然而开销比较大，你得多拍一个记者，还得一路拍摄一路上传数据。

Validium- 没有战队记者，只有机器人，路上发生了什么，没有人记录。会发生什么呢？机器人火力强大，恐怖分子是不担心。但如果万一路上有那种超级牛逼的黑客，神不知鬼不觉的黑进了机器人，拿走了用户的资金，机器人的控制者却一无所知呢？

因为没有记者，没有录像，用户只能吃个哑巴亏。所以Validium的安全性是要弱于Zk-Rollup的，但好处也显而易见，不用拍记者跟着，也不用一路拍摄上传数据，成本低了好多。这也是为什么Validuim的性能比Zk-Rollup高不少的原因。

毕竟熊掌与鱼不可兼得。

虽然不够严谨和准确，但希望至少本文可以让你大概了解侧链、Rollup、OP家族和Zk家族的那些“恩恩怨怨”。

目前Omniflix还能进行测试，可以去体验一下，测试奖励测试文档中说，所有奖励将在活动完成后决定，奖励将在主网启动后分发。但是根据空投说明，对于 FlixNet-2 和 FlixNet-3 上的活动参与者有空投（活动于 2021 年 1 月 11 日结束，有 2 天的宽限期）。因此，现在进行测试应该是没有奖励了。

信息源：https://blog.omniflix.network/announcing-flixnet-3-testnet-with-the-dapps-omniflix-studio-omniflix-market-4176fa112c09

打开https://app.omniflix.studio/dashboard ，连Keplr钱包。点击Go To Campaign。按步骤去操作，每一步骤正确完成后，会自动验证。1、领取测试币。

2、创立一个 Collection.点击右上角的CREATE，再点NFT Collection。输入详细的信息，上传图片。如果出错根据错误指示修改，例如Denom Symbol已被占用，就改一下符号3、铸造NFT 3个。

点击左侧栏目第二个Asset Library，选择刚才创建的合集，点击CREATE，输入具体的信息。

4、铸造好以后，随便上架。定价要以SPAY定价。

打开https://f3.omniflix.market ，两个测试代币各自都要购买一下。首先要把SPAY提到Omniflix Network 测试网，右上角点击账户，再点击IBC Tokens，点Deposit 提入SPAY。

6、把NFT转移给其他地址或者朋友。这个很容易完成。

。

image.png

准备：

要有metamask钱包和Kelr钱包，二者都可以在谷歌应用商店下载。

1）打开 app.umee.cc，窗口会自动弹出，授权小狐狸钱包连接到 Goerli 测试网；Keplr 钱包连接到 Umee 测试网.

2）领测试币。

加入https://discord.com/invite/mbfaBZ388P

钱包下拉，复制相应的测试网地址，从 discord 上的#umee-faucet机器人频道请求测试网 UMEE，输入!faucet +钱包地址获得。从 discord 上的#atom-faucet机器人频道请求测试网 ATOM；

从https://faucet.goerli.mudit.blog/ 获得测试网 ETH。

在供应里，各个币授权后，有个FAUCET，可以领取各自的测试币。

3）IBC跨链。

点左侧边栏的Markets，点IBC，从Cosmos测试网提币到umee测试网。注意要留点做费用，不要全提。

image.png

4）链跨链到以太坊。点Bridge，选择数量，再点Transfer,钱包确认。注意：额度不能太少，否则会失败。

image.png

5）供应（supply）。对ATOM授权，存入。有存入就有取出，withdraw提现。

image.png

6）借贷（Borrow）。在有存款的情况下才能借贷，这也就是抵押借贷。页面会显示可借贷数目。选择稳定币，输入数量，借出。同时，Repay是还款。

image.png

7）反馈。https://docs.google.com/forms/d/e/1FAIpQLSeDCnDprDTZhMQp5c38k4Pgmycr-FP5_jAAxc-s1scrBg1yeg/viewform

区块浏览器：https://explorer-umee.vercel.app/

RSS是什么呢？英文是Really Simple Syndication，中文就是简易信息聚合。

RSS订阅不仅能接收到海量资讯，同时还有很多意想不到的用途。

• 通过RSS订阅，看文章等没有广告，界面很清爽，十分适合阅读

• 通过订阅Youtube视频频道，观看视频是没有广告的

• 订阅twitter博主，免不可描述工具就可以接收到twitter消息

• 即使原地址的资讯被删除了，但是在rss上还能看到被删除的内容，是不是很神奇

• 每天可以接收到海量资讯，不用再一个个app或者网站去打开了，节省时间和空间

• 可以通过订阅播客网站，听到他们的录制的音频，比如喜马拉雅，蜻蜓fm等音频节目

RSS工具有很多，网上一搜索一大片，这里我推荐使用 Inoreader

下面就说一下如何用RSS过滤币圈有用的信息

一：如何订阅Mirror干货

链闻关停后，我一度很失落，找不到代替品，慌得很啊！

慢慢的发现Mirror上的文章都是干货，但是Mirror的导航功能欠缺，让我一度想放弃Mirror，但是现在越来越多的大佬都在Mirror上发表文章，我想了很多办法，但是阅读还是很累。

有一次在逛知识星球时发现，可以使用RSS阅读软件订阅Mirror文章，我突然两眼发光，这不就是我用了好多年的订阅神器吗？自从google reader停了后我就不怎么用了。

RSS + Mirror = 链闻？ 哈哈，如获至宝，那么如何使用呢？

举个例子：https://mirror.xyz/zlexdl.eth 是我的mirror地址，在域名的mirror前边加上sub

变成 https://submirror.xyz/zlexdl.eth 就是mirror的feed地址了。加到rss工具里订阅就可以了。一有新文章就会推送到rss阅读器上了。

但是我的问题还没有被解决，由于mirror的设计问题，我无法获得更多的mirror作者的精华文章，这里有一位朋友收集了几十个mirror作者的feed地址，放在了rss订阅工具上阅读，然后导出了一个OPML配置文件，你只要在rss工具上导入这个配置文件就可以一次订阅几十个Mirror作者的文章了，OPML配置文件下载地址是：

大家可以使用这个方法试着订阅一下。

Inoreader 还有手机APP，用起来非常方便。

二：如何订阅Medium文章

大家都知道很多项目的团队都使用Medium写博客，做宣传，那么如何使用RSS订阅Medium文章呢，方法很简单，和Mirror类似，只要在URL上追加feed就可以变成feed订阅地址了。

举个例子：我的Medium是 https://medium.com/@zlexdl.eth 在@前加上feed/变成

https://medium.com/feed/@zlexdl.eth 就可以加到rss阅读器中订阅了。

最后，我收集了500位优质Mirror博主的feed订阅地址，每天给我推送几十篇优质的文章，阅读的不亦乐乎。可以参照以下链接：

—— 来自 DFarm Club

Neptune Mutual 为您提供有保障的稳定币流动性，通过对冲可能的资本风险和智能合约漏洞来降低您的风险敞口。

目前排行榜158人

下面开始我们的教程：

1）进入测试网址，网络切换到Ropsten网络，连接钱包

2）领取Ropsten测试币

领取 DAI/NPM测试币（选择Ropsten网络）（请求DAI/NPM测试代币）

添加代币DAI/NPM

3）点击Animated Brands

4)点击采购（Purchase Policy)

点击Next

点击➕

输入金额，批准

点击PURCHASE POLICY

5)提供流动性（点击Provide Liquidity)

点击Next

点击MAX最大值

依次批准

点击Provide Liquidity

添加完成

6)取消流动性（点击上图ANIMATED BRANDS）

选择提取金额，批准

提取

操作完成后，去填写表单做空投任务。

• 以上为Neptune Mutual操作教程

• 欢迎大家关注@DaKuan，了解更多空投讯息，保姆级空投教程，互相交流进步！

• 推特账号：https://twitter.com/DaKuan_

• 油管账号：https://www.youtube.com/channel/UCSBB-psRcFfybzC-YoeAySQ