StarkWare:

     目前以太坊的 rollup 扩容方案中，主流的有两种：基于欺诈性证明的 optimistic rollup，以及基于零知识证明的 zk rollup。基于 optimistic rollup 的 layer2 为 Optimism 和 Arbitrum，其优势在于：兼容 EVM 的难度不高，可以直接使用 solidity 部署智能合约，直接开发 Dapp；劣势在于：提款等待时间长，安全性、TPS和交易成本方面不如 zk rollup。基于 zk rollup 的 layer2 为 StarkNet 和 zkSync，其优势在于：安全性更高，交易确认的时效性更强，TPS和交易成本显著优于 optimistic rollup；但是其劣势在于不易兼容 EVM，目前业界正在开发 zkEVM 解决方案，还需要一段时间。

目前主流的生成零知识证明的系统有两种，分别是zk Snark和zk Stark。zk Snark是最早提出的，并且应用到了早期的Zcash项目中，也是开发者资源最多的，因此最受主流市场接受。**ZK Stark是基于ZK Snark的改进，因此在技术上更优越。**优势在于：更加安全且生成证明的算法复杂度更低，计算效率更高且提升了扩展性。

StarkWare 是目前业界技术领先的 zk rollup 扩容解决方案开发公司，其团队核心成员是两种算法的提出者和改进者，并以 zk Stark 技术为核心开发两条产品线：扩容服务引擎 StarkEx，二层扩容网络 StarkNet。

StarkEx:

     一款技术服务引擎，提供给有扩容需求的项目方客户（例如Immutable和dydx，扩容方案的代码都是StareWare团队写的）。本质上是一款面向B端的定制化服务，扩容即服务（Scalling as a Service）。目前服务和服务间相互独立，还不能满足项目间的可组合性。

组成部分：

• Application：面向C端用户的独立应用，定义了应用层面的逻辑，用来接收用户端的链下交易，并把交易发送给 StarkEx。例如 dydx、Immutable 应用。

• StarkEx Service：面向B端应用的定制化服务引擎。用来执行一个批量的交易，并更新批量交易的状态。一旦链上 Stark Verifier 合约验证完这笔批量交易的合法性后，StarkEx 会把新的确认状态发送上链到 StarkEx 合约中。状态由 Merkle 树结构表示，每一个叶子结点都表示一个独立的交易，这颗 Merkle 树的树根 root 就表示这批量交易的最终状态，root 哈希一旦被记录上链，就完成了整批交易的确认。

• Shared Prover (SHARP) ：一个通用型的 zk Stark 证明生成系统。可同时接收来自多个应用的批量请求，并生成这些请求的 zk Stark 证明，然后提交上链。

• Stark Verfier：零知识证明中的验证者。这里是一个链上验证合约，用来验证外部接收的 zk proof的合法性。

• StarkEx 合约：有两个用途。一方面，满足用户的充值和提款代币的需求，使得在任何情况下，用户都有权限进行资金管理（例如dydx中的出入金操作，同时作为统一的资金池也管理着dydx交易所的流动性）。另一方面，在 Stark Verifier 确认交易的合法性后，更新链上的状态（记录新的 Merkle 树根哈希），以确认交易最终完成。

流程：

1. 应用中所有的用户交易都会被发往StarkEx服务并在链下计算执行。

2. StarkEx批量执行交易并“打包”，将“打包”后的交易发送给SHARP系统；SHARP系统会计算出一个证明（用来证明这笔批量交易的合法性）。

3. SHARP会将生成好的 zk Stark Proof 发送给链上的 Stark verifier 合约进行校验。

4. 校验通过后会通知 StarkEx 合约，同时 StarkEx 服务会将执行后的确认状态 calldata 发送给 StarkEx 合约。如果 Proof校验通过，状态才会被在链上确认，这才最终完成了批量交易。

用户端的交互：

1. On-chain transaction: 与 StarkEx 合约（L1）直接进行交互，例如dydx进行现货交易的充值操作。

2. Off-chain transaction: 充值确认后，用户所有的交易都在链下执行，交易被用户的 StarkKey 签名后，发往 StarkEx 进行下一步执行计算。

StarkEx 合约架构：

     StarkEx 合约实现了去中心化的用户自托管资产，例如对于去中心化交易所的实现，StarkEx 合约允许用户在任何情况下能够有效的充值或提款。另外，StarkEx 合约也保存了每次从链下提交的合法的状态（以 Merkle树哈希的形式保存）。 组成部分：

• Proxy Contract（代理合约）：托管了所有用户资产，并且保存了所有确认状态。实现最简化的逻辑，具体通过下面的调度合约实现功能逻辑。

• Dispatcher Contract（调度合约）：实现了 StarkEx 的业务功能逻辑。由于合约的大小在以太坊中被限制不超过24kb，为了实现完整的逻辑，又被分为若干个子合约，每个实现特定的功能，并通过 delegate call 的方式触发。

• Sub-Contracts（子合约）：每个子合约实现了 StarkEx 合约的特定的功能逻辑，只实现逻辑，存储在 Proxy 合约中。

• Verifier Fact Registry: 用来对接应用合约与Verifier Contract的合约。它执行了 fact registry API，并且将应用合约的fact的格式转换成了Verifier Contract的使用格式。Fact Registry（事件注册）具体的生成过程为：在链下 StarkEx 系统中运行 CAIRO 合约，输入批量交易，生成 execution trace，然后通过 SHARP 模块生成 zk Stark Proof，将其提交上链验证；验证后生成一个 fact，将 fact 发送给注册合约进行注册，以供后续的 Dapp 合约能够通过接口验证这个事实已经被合理注册（例如 Alice给Bob转移了1000DAI这个事实行为）。

• Committee Fact Registry: 自定义链下状态记录能被强制转换成链上状态记录，这里就用到了 Committee 注册表（例如，交易所的交易确认数据储存在链下，需要依赖可信任的第三方机构如Infura、Coinbase组成的 Committee 委员会共同授权，才能把状态迁移到链上确认）。

• Escape Verifier Fact Registry: 用于满足用户资金自托管的需求。例如，一旦应用方的服务遭到了冻结或者宕机，用户可以通过预设定好机制证明 Proxy 合约内资产的所有权，然后自主提出资产。

StarkEx 后端架构：

• Gateway网关：接收来自应用方的交易，并且把交易排序到队列中。

• Batching & Validation 批量发送交易并验证：负责一个batch一个batch的批量发送交易，并且保证每个子交易的合法性（例如，同时检查链下和链上状态，用户的余额是否充足）。每个batch的状态依赖前一个batch的执行情况，如果前一个batch执行失败例如链上回滚，那么后面batch的执行依赖再前一个batch的执行状态（例如下图中的batch4，原本应该在batch3之后执行，但是batch3执行失败，使得batch4自动接在batch2后面执行）。

• Batches Info (Feeder)：一个外部监视器，用来监听batch中的交易数据。

• Change Approval Gateway：为了保持 StareWare 后端保存的数据和应用（例如dydx交易所）数据的一致性，同时为了保证链下数据可用性。采用了第三方 approver 进行对batch交易数据进行签名的方式，来保证batch数据的有效性。

• Proving (Ambassador)：负责对 batch 数据生成零知识证明。

• Packing (Dispatcher)：负责发送“打包的”数据给主链。“打包的”数据包括接收交易的地址以及 calldata。打包的数据以此形成数据队列，队列的排序就是链上执行的顺序。

• Blockchain Writer：进一步将上面“打包的”数据进行打包，这一步会包含发交易的必要数据，比如 gas price、nonce、signature等。然后通过标准交易发送给链上合约执行。

• Catcher：一个监听器，用来监听链上事件，将回滚的 batch 通知给 batcher。

StarkEx 项目集成技术架构：

     任何合作项目方集成 StarkEx 服务，可以参考下面的架构图（去中心化交易所的架构图dydx为例）。StarkEx 能接收合作方后端发来的交易，使用 zk rollup 批量提交上链，提高交易TPS，减少每笔交易的手续费，提升用户体验。

组成部分：

• 前端：由项目方开发提供，直接面向用户。能够支持两种操作：链上操作和链下操作。链上操作为常规的给以太坊发送交易的操作，例如用户通过metamask钱包签名交易发送资产到 StarkEx 指定合约进行存款操作，这就要求前端需要集成合约的ABI，以及适配 StarkEx 支持的钱包。链下操作为一种特殊的操作，通常需要前端额外适配 StarkEx 的加密签名算法库，以适配 StarkEx 链下引擎适配的签名格式。签名后的交易会从项目方的后端发送到 StarkEx 后端执行后续操作。

• 交易验证器 Order Verification：用户通过前端发送给后端的交易需要先被验证一遍（例如确保签名、用户余额等信息无误），然后再提交上链。对于一些操作的确认例如充值操作，这笔交易的最终需要通常等待几个区块才能确认交易的有效性，确认无误后，才完成了充值验证过程。

• 业务逻辑 Business Logic：这部分来完成项目的业务逻辑（例如dydx的订单撮合）。所有有效的撮合交易将会从项目方后端发送给 StarkEx 服务。撮合后，用户的新资产信息状态会被更新到 Account State中进行链下存储。

• 交易队列：所有发送给 StarkEx 的交易都要放在一个交易队列中，且队列中的每笔交易都有一个独立的索引值 tx_id；StarkEx 收到所有交易后，会根据这个 tx_id 来顺序化的执行交易。如果一个交易队列中的索引值有缺失，为了安全起见，StarkEx 会等待缺失值填满后才进行批量交易打包。

• 交易发送者 TX Sender：负责将交易队列发送给 StarkEx 服务中的 Gateway组建，执行后续上链操作。

• 错误处理 Error Handler：一般情况下，项目方后端会检查每笔交易的有效性（在 Order Verification中），所以发送给 Gateway 的交易队列都是有效的。但是会存在一些极端情况例如以太坊区块回滚导致的用户充值交易失败。这就要求 StarkEx 后端服务中也会检查一次交易是否有效。一旦检查出某笔交易失效，就会将交易情况发送给项目方接口并接收到项目方返回的新交易数据来替换错误的交易数据（例如，空的交易队列）。

• 状态批准 State Approval：为了保证项目方后端的交易数据与 StarkEx 的一致性，且为了保证项目方有最大的掌控权限，在每笔批量交易数据上链前，项目方后端都会进行一步状态确认的操作。具体的来讲，项目方此时充当approver的角色（参考上一张 StarkEx 架构图），对 StarkEx 发过来的 batch 数据进行比对然后签名批准。批准后才会通过 StarkEx 进行下一步生成 zk Stark Proof 并进行最终的上链。

• 抗审查机制：去中心化交易所为了实现用户资产的自托管以及资金安全，建立了抗审查机制。在特殊情况下（例如监管冻结、黑客攻击、严重bug等），允许用户生成特殊的 zk Stark Proof，直接与合约交互，强制从 StarkEx 合约资金池中提出属于用户自己的资产。

**     总之，从本质上来讲，使用 StarkEx 服务构建的项目（以dydx交易所为例），并不是把每笔交易放在链上计算、存储、执行，而是把每笔交易的状态和每笔交易计算过程的可行性证明（zk Stark proof）批量打包上链，最终在链上记录确认的状态（Merkel Tree Root）。而这中间所有的计算过程、中间状态、用户资产余额等放在了链下项目方自己的服务器里面执行。这样做的弊端显然是用户体验不如中心化交易所：TPS低、撮合系统不够高效、确认交易需要的时间长（一般每个batch的StarkEx交易需要5分钟才能完成链上确认）。那为什么不像中心化交易所一样，将所有的信息放在链下，而还要折腾一圈儿之后把计算后的状态证明提交上链呢？因为这里能够满足自托管的需求，相对于中心化交易所，其优势在于：资金安全（所有资金放在L1合约中，只能通过提交有效的 zk Stark Proof 才能提款）、抗审查（充值和提款可以与合约交互完成，不依赖链下服务器）、数据透明（所有资金池内的资产数量在链上可查，防止交易所作恶）。**

StarkNet:

     **去中心化的 zk rollup 二层网络，能够支持自主部署智能合约和Dapp，满足项目间的可组合性与互操作性（但是当前 L2 层的智能合约并不兼容EVM，StarkWare团队也正在开发一种Wrap语言来转换CAIRO与Solidity代码做两者兼容适配）。**商业模式包括：拍卖sequencer获取MEV的价值。用资金和技术孵化基于StarkNet的项目，通过发行tokenomics激励生态发展。

     与 StarkEx 对比来看，StarkNet的技术架构中将原先属于 StarkEx Service 和 SHARP 证明系统替换成了 Sequencers 和 Provers。Sequencers 此时充当类似矿工的角色，负责收集内存池中用户发来的交易请求，并排列交易的执行顺序（此处就会产生MEV价值）。Provers此时充当 SHARP 的角色，接收Sequencers发送过来的请求并生成 zk Stark Proof，同时在L1的验证合约通过合法性验证后，再将批量交易的状态确认更新到L1合约中。可以说，核心技术还是基于 zk Stark 算法、CAIRO 这些。只不过相对于 StarkEx 来说，StarkNet 将 Sequencers 和 Provers 的权力下放到了社区中，允许符合条件的节点运行这两个系统，更加去中心化。盈利模式也由前面的定制化服务收费变的更多样化，包括代币经济模型、构建 L2 生态获取价值、Sequencer 拍卖、用户交易打包服务费等。

总结：

     对于StarkWare团队来说，可以从两方面理解它的这两个“产品线”。一方面，从技术上来看，两者都是以zk Snark技术为基础的解决方案，同时两者的区别在于，StarkEx具有定制化的特点，因此能满足专用应用的高可扩展性的需求；而StarkNet的定位与之相反，它采用的是通用的二层扩容解决方案，满足用户对区块链交易效率和交易成本优化的需求，也满足不同应用的兼容性和可组合性需求，但是可扩展性（TPS，Gas费优化）不如定制化的StarkEx引擎。另一方面，从商业模式上看，StarkEx面向的是B端合作项目方，赚取服务费用或项目分成；而StarkNet面向的广大的C端用户、开发者、sequencer、prover等生态参与者，通过tokenomics以及技术支撑做大L2生态来盈利。所以无论从技术上或者商业上，两个“产品线”都互为补充。

     StareWare团队也面临着风险，包括：1. 大客户流失：例如 dydx 做大后想脱离 StarkEx 的体系，而转向 Cosmos 的应用链解决方案。但是从实战来看，StarkEx 技术还是比较过硬的，未来随着应用层的百花齐放，用户对安全隐私方面的重视，可以想象选择使用它的扩容服务的客户也不会少。2. 社区建设问题：目前 StarkWare 注重技术与服务，而非社区建设，从四大layer2来看，StarkNet的月活地址数量也是最少的。CAIRO作为新语言，开发者生态不大。StarkNet 的sequencers和provers节点并没有完成去中心化的社区下放。

StarkWare:

     目前以太坊的 rollup 扩容方案中，主流的有两种：基于欺诈性证明的 optimistic rollup，以及基于零知识证明的 zk rollup。基于 optimistic rollup 的 layer2 为 Optimism 和 Arbitrum，其优势在于：兼容 EVM 的难度不高，可以直接使用 solidity 部署智能合约，直接开发 Dapp；劣势在于：提款等待时间长，安全性、TPS和交易成本方面不如 zk rollup。基于 zk rollup 的 layer2 为 StarkNet 和 zkSync，其优势在于：安全性更高，交易确认的时效性更强，TPS和交易成本显著优于 optimistic rollup；但是其劣势在于不易兼容 EVM，目前业界正在开发 zkEVM 解决方案，还需要一段时间。

目前主流的生成零知识证明的系统有两种，分别是zk Snark和zk Stark。zk Snark是最早提出的，并且应用到了早期的Zcash项目中，也是开发者资源最多的，因此最受主流市场接受。**ZK Stark是基于ZK Snark的改进，因此在技术上更优越。**优势在于：更加安全且生成证明的算法复杂度更低，计算效率更高且提升了扩展性。

StarkWare 是目前业界技术领先的 zk rollup 扩容解决方案开发公司，其团队核心成员是两种算法的提出者和改进者，并以 zk Stark 技术为核心开发两条产品线：扩容服务引擎 StarkEx，二层扩容网络 StarkNet。

StarkEx:

     一款技术服务引擎，提供给有扩容需求的项目方客户（例如Immutable和dydx，扩容方案的代码都是StareWare团队写的）。本质上是一款面向B端的定制化服务，扩容即服务（Scalling as a Service）。目前服务和服务间相互独立，还不能满足项目间的可组合性。

组成部分：

• Application：面向C端用户的独立应用，定义了应用层面的逻辑，用来接收用户端的链下交易，并把交易发送给 StarkEx。例如 dydx、Immutable 应用。

• StarkEx Service：面向B端应用的定制化服务引擎。用来执行一个批量的交易，并更新批量交易的状态。一旦链上 Stark Verifier 合约验证完这笔批量交易的合法性后，StarkEx 会把新的确认状态发送上链到 StarkEx 合约中。状态由 Merkle 树结构表示，每一个叶子结点都表示一个独立的交易，这颗 Merkle 树的树根 root 就表示这批量交易的最终状态，root 哈希一旦被记录上链，就完成了整批交易的确认。

• Shared Prover (SHARP) ：一个通用型的 zk Stark 证明生成系统。可同时接收来自多个应用的批量请求，并生成这些请求的 zk Stark 证明，然后提交上链。

• Stark Verfier：零知识证明中的验证者。这里是一个链上验证合约，用来验证外部接收的 zk proof的合法性。

• StarkEx 合约：有两个用途。一方面，满足用户的充值和提款代币的需求，使得在任何情况下，用户都有权限进行资金管理（例如dydx中的出入金操作，同时作为统一的资金池也管理着dydx交易所的流动性）。另一方面，在 Stark Verifier 确认交易的合法性后，更新链上的状态（记录新的 Merkle 树根哈希），以确认交易最终完成。

流程：

1. 应用中所有的用户交易都会被发往StarkEx服务并在链下计算执行。

2. StarkEx批量执行交易并“打包”，将“打包”后的交易发送给SHARP系统；SHARP系统会计算出一个证明（用来证明这笔批量交易的合法性）。

3. SHARP会将生成好的 zk Stark Proof 发送给链上的 Stark verifier 合约进行校验。

4. 校验通过后会通知 StarkEx 合约，同时 StarkEx 服务会将执行后的确认状态 calldata 发送给 StarkEx 合约。如果 Proof校验通过，状态才会被在链上确认，这才最终完成了批量交易。

用户端的交互：

1. On-chain transaction: 与 StarkEx 合约（L1）直接进行交互，例如dydx进行现货交易的充值操作。

2. Off-chain transaction: 充值确认后，用户所有的交易都在链下执行，交易被用户的 StarkKey 签名后，发往 StarkEx 进行下一步执行计算。

StarkEx 合约架构：

     StarkEx 合约实现了去中心化的用户自托管资产，例如对于去中心化交易所的实现，StarkEx 合约允许用户在任何情况下能够有效的充值或提款。另外，StarkEx 合约也保存了每次从链下提交的合法的状态（以 Merkle树哈希的形式保存）。 组成部分：

• Proxy Contract（代理合约）：托管了所有用户资产，并且保存了所有确认状态。实现最简化的逻辑，具体通过下面的调度合约实现功能逻辑。

• Dispatcher Contract（调度合约）：实现了 StarkEx 的业务功能逻辑。由于合约的大小在以太坊中被限制不超过24kb，为了实现完整的逻辑，又被分为若干个子合约，每个实现特定的功能，并通过 delegate call 的方式触发。

• Sub-Contracts（子合约）：每个子合约实现了 StarkEx 合约的特定的功能逻辑，只实现逻辑，存储在 Proxy 合约中。

• Verifier Fact Registry: 用来对接应用合约与Verifier Contract的合约。它执行了 fact registry API，并且将应用合约的fact的格式转换成了Verifier Contract的使用格式。Fact Registry（事件注册）具体的生成过程为：在链下 StarkEx 系统中运行 CAIRO 合约，输入批量交易，生成 execution trace，然后通过 SHARP 模块生成 zk Stark Proof，将其提交上链验证；验证后生成一个 fact，将 fact 发送给注册合约进行注册，以供后续的 Dapp 合约能够通过接口验证这个事实已经被合理注册（例如 Alice给Bob转移了1000DAI这个事实行为）。

• Committee Fact Registry: 自定义链下状态记录能被强制转换成链上状态记录，这里就用到了 Committee 注册表（例如，交易所的交易确认数据储存在链下，需要依赖可信任的第三方机构如Infura、Coinbase组成的 Committee 委员会共同授权，才能把状态迁移到链上确认）。

• Escape Verifier Fact Registry: 用于满足用户资金自托管的需求。例如，一旦应用方的服务遭到了冻结或者宕机，用户可以通过预设定好机制证明 Proxy 合约内资产的所有权，然后自主提出资产。

StarkEx 后端架构：

• Gateway网关：接收来自应用方的交易，并且把交易排序到队列中。

• Batching & Validation 批量发送交易并验证：负责一个batch一个batch的批量发送交易，并且保证每个子交易的合法性（例如，同时检查链下和链上状态，用户的余额是否充足）。每个batch的状态依赖前一个batch的执行情况，如果前一个batch执行失败例如链上回滚，那么后面batch的执行依赖再前一个batch的执行状态（例如下图中的batch4，原本应该在batch3之后执行，但是batch3执行失败，使得batch4自动接在batch2后面执行）。

• Batches Info (Feeder)：一个外部监视器，用来监听batch中的交易数据。

• Change Approval Gateway：为了保持 StareWare 后端保存的数据和应用（例如dydx交易所）数据的一致性，同时为了保证链下数据可用性。采用了第三方 approver 进行对batch交易数据进行签名的方式，来保证batch数据的有效性。

• Proving (Ambassador)：负责对 batch 数据生成零知识证明。

• Packing (Dispatcher)：负责发送“打包的”数据给主链。“打包的”数据包括接收交易的地址以及 calldata。打包的数据以此形成数据队列，队列的排序就是链上执行的顺序。

• Blockchain Writer：进一步将上面“打包的”数据进行打包，这一步会包含发交易的必要数据，比如 gas price、nonce、signature等。然后通过标准交易发送给链上合约执行。

• Catcher：一个监听器，用来监听链上事件，将回滚的 batch 通知给 batcher。

StarkEx 项目集成技术架构：

     任何合作项目方集成 StarkEx 服务，可以参考下面的架构图（去中心化交易所的架构图dydx为例）。StarkEx 能接收合作方后端发来的交易，使用 zk rollup 批量提交上链，提高交易TPS，减少每笔交易的手续费，提升用户体验。

组成部分：

• 前端：由项目方开发提供，直接面向用户。能够支持两种操作：链上操作和链下操作。链上操作为常规的给以太坊发送交易的操作，例如用户通过metamask钱包签名交易发送资产到 StarkEx 指定合约进行存款操作，这就要求前端需要集成合约的ABI，以及适配 StarkEx 支持的钱包。链下操作为一种特殊的操作，通常需要前端额外适配 StarkEx 的加密签名算法库，以适配 StarkEx 链下引擎适配的签名格式。签名后的交易会从项目方的后端发送到 StarkEx 后端执行后续操作。

• 交易验证器 Order Verification：用户通过前端发送给后端的交易需要先被验证一遍（例如确保签名、用户余额等信息无误），然后再提交上链。对于一些操作的确认例如充值操作，这笔交易的最终需要通常等待几个区块才能确认交易的有效性，确认无误后，才完成了充值验证过程。

• 业务逻辑 Business Logic：这部分来完成项目的业务逻辑（例如dydx的订单撮合）。所有有效的撮合交易将会从项目方后端发送给 StarkEx 服务。撮合后，用户的新资产信息状态会被更新到 Account State中进行链下存储。

• 交易队列：所有发送给 StarkEx 的交易都要放在一个交易队列中，且队列中的每笔交易都有一个独立的索引值 tx_id；StarkEx 收到所有交易后，会根据这个 tx_id 来顺序化的执行交易。如果一个交易队列中的索引值有缺失，为了安全起见，StarkEx 会等待缺失值填满后才进行批量交易打包。

• 交易发送者 TX Sender：负责将交易队列发送给 StarkEx 服务中的 Gateway组建，执行后续上链操作。

• 错误处理 Error Handler：一般情况下，项目方后端会检查每笔交易的有效性（在 Order Verification中），所以发送给 Gateway 的交易队列都是有效的。但是会存在一些极端情况例如以太坊区块回滚导致的用户充值交易失败。这就要求 StarkEx 后端服务中也会检查一次交易是否有效。一旦检查出某笔交易失效，就会将交易情况发送给项目方接口并接收到项目方返回的新交易数据来替换错误的交易数据（例如，空的交易队列）。

• 状态批准 State Approval：为了保证项目方后端的交易数据与 StarkEx 的一致性，且为了保证项目方有最大的掌控权限，在每笔批量交易数据上链前，项目方后端都会进行一步状态确认的操作。具体的来讲，项目方此时充当approver的角色（参考上一张 StarkEx 架构图），对 StarkEx 发过来的 batch 数据进行比对然后签名批准。批准后才会通过 StarkEx 进行下一步生成 zk Stark Proof 并进行最终的上链。

• 抗审查机制：去中心化交易所为了实现用户资产的自托管以及资金安全，建立了抗审查机制。在特殊情况下（例如监管冻结、黑客攻击、严重bug等），允许用户生成特殊的 zk Stark Proof，直接与合约交互，强制从 StarkEx 合约资金池中提出属于用户自己的资产。

**     总之，从本质上来讲，使用 StarkEx 服务构建的项目（以dydx交易所为例），并不是把每笔交易放在链上计算、存储、执行，而是把每笔交易的状态和每笔交易计算过程的可行性证明（zk Stark proof）批量打包上链，最终在链上记录确认的状态（Merkel Tree Root）。而这中间所有的计算过程、中间状态、用户资产余额等放在了链下项目方自己的服务器里面执行。这样做的弊端显然是用户体验不如中心化交易所：TPS低、撮合系统不够高效、确认交易需要的时间长（一般每个batch的StarkEx交易需要5分钟才能完成链上确认）。那为什么不像中心化交易所一样，将所有的信息放在链下，而还要折腾一圈儿之后把计算后的状态证明提交上链呢？因为这里能够满足自托管的需求，相对于中心化交易所，其优势在于：资金安全（所有资金放在L1合约中，只能通过提交有效的 zk Stark Proof 才能提款）、抗审查（充值和提款可以与合约交互完成，不依赖链下服务器）、数据透明（所有资金池内的资产数量在链上可查，防止交易所作恶）。**

StarkNet:

     **去中心化的 zk rollup 二层网络，能够支持自主部署智能合约和Dapp，满足项目间的可组合性与互操作性（但是当前 L2 层的智能合约并不兼容EVM，StarkWare团队也正在开发一种Wrap语言来转换CAIRO与Solidity代码做两者兼容适配）。**商业模式包括：拍卖sequencer获取MEV的价值。用资金和技术孵化基于StarkNet的项目，通过发行tokenomics激励生态发展。

     与 StarkEx 对比来看，StarkNet的技术架构中将原先属于 StarkEx Service 和 SHARP 证明系统替换成了 Sequencers 和 Provers。Sequencers 此时充当类似矿工的角色，负责收集内存池中用户发来的交易请求，并排列交易的执行顺序（此处就会产生MEV价值）。Provers此时充当 SHARP 的角色，接收Sequencers发送过来的请求并生成 zk Stark Proof，同时在L1的验证合约通过合法性验证后，再将批量交易的状态确认更新到L1合约中。可以说，核心技术还是基于 zk Stark 算法、CAIRO 这些。只不过相对于 StarkEx 来说，StarkNet 将 Sequencers 和 Provers 的权力下放到了社区中，允许符合条件的节点运行这两个系统，更加去中心化。盈利模式也由前面的定制化服务收费变的更多样化，包括代币经济模型、构建 L2 生态获取价值、Sequencer 拍卖、用户交易打包服务费等。

总结：

     对于StarkWare团队来说，可以从两方面理解它的这两个“产品线”。一方面，从技术上来看，两者都是以zk Snark技术为基础的解决方案，同时两者的区别在于，StarkEx具有定制化的特点，因此能满足专用应用的高可扩展性的需求；而StarkNet的定位与之相反，它采用的是通用的二层扩容解决方案，满足用户对区块链交易效率和交易成本优化的需求，也满足不同应用的兼容性和可组合性需求，但是可扩展性（TPS，Gas费优化）不如定制化的StarkEx引擎。另一方面，从商业模式上看，StarkEx面向的是B端合作项目方，赚取服务费用或项目分成；而StarkNet面向的广大的C端用户、开发者、sequencer、prover等生态参与者，通过tokenomics以及技术支撑做大L2生态来盈利。所以无论从技术上或者商业上，两个“产品线”都互为补充。

     StareWare团队也面临着风险，包括：1. 大客户流失：例如 dydx 做大后想脱离 StarkEx 的体系，而转向 Cosmos 的应用链解决方案。但是从实战来看，StarkEx 技术还是比较过硬的，未来随着应用层的百花齐放，用户对安全隐私方面的重视，可以想象选择使用它的扩容服务的客户也不会少。2. 社区建设问题：目前 StarkWare 注重技术与服务，而非社区建设，从四大layer2来看，StarkNet的月活地址数量也是最少的。CAIRO作为新语言，开发者生态不大。StarkNet 的sequencers和provers节点并没有完成去中心化的社区下放。