# CosmWasm：进化的虚拟机与智能合约

By [jazzlost](https://paragraph.com/@web3🐕) · 2022-07-21

---

CosmWasm：进化的虚拟机与智能合约

1\. 虚拟机的进化
----------

### 1.1 虚拟机是什么

*   虚拟机是通过软件模拟、运行在一个沙箱环境中的完整计算系统。在区块链上，虚拟机就是智能合约的运行环境，是一个可以完全对外隔离的完整计算系统。区块链通过虚拟机来调用和执行智能合约，并要求所有节点都达成计算的确定性。
    
*   智能合约最大的特性就是要求任何环境下运行的`确定性`。由于运行节点的计算机或其它计算设备可能支持不同的CPU指令集，X86、ARM等；操作系统处理精度不同，32位，64位。不同机器对相同数据类型的表示也不一致，这样很难确保所有机器运行的结果一致。传统的 Java 虚拟机对于计算结果的少量的差异有一定的容忍度，但是在区块链上所有结果必须一致，因此一个新的、适用于区块链的虚拟机是必不可少的。
    
*   达到确定性的要求是不容易的，甚至为了代码的一致性还需要一套新的语言。区块链虚拟机还需要防止各类网络攻击以及恶意行为，所以还需要内置Gas之类的保护机制。也正是因为虚拟机的加入，区块链从1.0时代的分布式账本变为了2.0时代的分布式状态机，然后到了3.0时代的分布式状态集群。
    

### 1.2 理想区块链虚拟机特性

*   **确定性**：在调用同样的智能合约输入时，应该返回相同的输出结果，输出结果不依赖于时间、运行环境等外部的条件。包括运行时的资源消耗计算方式也需要准确。
    
*   **安全性**：沙盒执行环境，对于基本的网络攻击(日蚀攻击/女巫攻击/重放攻击/ DDOS )有预防机制。虚拟机发生故障不会影响其余模块。
    
*   **灵活性**：模块化架构，可以方便的组装到执行层中。多语言和开发框架支持。
    

### 1.3 技术发展

#### v1.0 - Bitcoin Scripts

*   比特币通过执行一组脚本来获取链上交易的状态与验证交易的有效性，可以看成区块链虚拟机的雏形。
    
*   比特币脚本功能上可以分为锁定脚本与解锁脚本，因为比特币没有帐户只有 UTXO 的概念，这两个脚本就是用来对 UTXO 有效性进行验证的程序。锁定脚本存在于每一比交易的输出中，里面明确了可以使用这笔输出的条件。解锁脚本则是用来生成特定解锁信息的。
    
*   整个交易会先执行解锁脚本，如果没有错误则复制主堆栈数据并执行锁定脚本，返回结果为TRUE则证明该解锁脚本满足锁定脚本的解锁条件，也就是满足这个 UTXO 的使用权。可以看到这里的**脚本是整个交易过程进行扩展的对外接口**。
    
*   比特币的脚本解释器是**基于栈式结构的非图灵完备程序**。操作和数据不分离，无额外存储需求。数据处理精度相对固定，空间使用松散。脚本能执行的操作简单，流程较为固定，灵活性和扩展能力差。
    

#### v2.0 - EVM

*   以太坊提出了智能合约的概念，并且提供了进行智能合约开发的高级语言以及图灵完备的虚拟机。用户通过交易与智能合约进行交互，虚拟机执行交易进行状态转换，所以以太坊更像是分布式状态机。
    
*   EVM 本质上也是一个**无寄存器，基于栈的解释器(interpreter)**, 通过解析智能合约编译出来的字节码进行数据操作。EVM 的栈帧宽度位256 bit, 一定程度上是为了符合密码学计算的要求(SHA256/Keccak256)，也可以减少 Opcode 操作降低 Gas 费用。EVM 对栈的访问不是严格的 FILO, 它允许一定规则的栈帧复制移动。每次操作只能取栈顶的若干元素，把结果压栈。当然也能够把栈顶元素放到 memory 或者 storage 区域保存
    
*   EVM 具备了stack, memory, storage 三种存储模型。stack 和 memory 都是临时存储，合约运行时有效，运行结束后回收。 stack 最多可以容纳1024栈帧，memory 更像是堆，用来放数组，字符串和对象等复杂数据类型，storage是永久性储存，采用 uint256 的 kv 类型进行存储。
    
*   EVM创造性的在虚拟机中内置了Gas系统，使得与EVM的交互花费成为可预估，可计算的。具体的资源消耗花费被定义在了Opcode中。Gas的设计在安全性与经济模型上都形成了开创性的作用。
    

![EVM Architecture](https://storage.googleapis.com/papyrus_images/04f3938c07f2f0dc21fd57bd723f0bb876f8559b6f3f78364c26b45788c49a49.png)

EVM Architecture

#### v3.0 - Wasm & Others

*   随着智能合约的普及和发展，市场已经渐渐不满足于 EVM 和类 EVM 虚拟机，无论从性能还是安全性以及合规性来说，整个行业都知道 **EVM 不会是最终解决方案**，我们现在正处于市场对于新虚拟机解决方案的强烈需求中，这个阶段较为成熟的便是 Wasm 虚拟机，当然也包括 Move VM, Agoric VM, 3em, CKB VM 等小众虚拟机方案。
    
*   新的虚拟机方案大体都是对于 EVM 遗留问题的迭代，无论从开发或是用户层面，大家都在追求一种更近似于 web2 的体验，例如更好的运行时支持，更多的语言选择，更多的硬件架构适配，效率更高的指令集，更快的运行速度等。同时很多 EVM 的经典设计也得以继承，例如合约体系，Gas设计，账户模型，沙盒环境等。
    

### 1.4 问题与挑战

#### EVM 的遗留问题

*   EVM 的架构是释放其原始性能的最大阻碍之一, 256位的栈帧虽然有利于哈希和椭圆曲线算法，但也使得 Opcode 到硬件指令的转换变得效率低下。这样的设计最初是以通用性与安全性为首要目标，间接的就是牺牲了性能，在处理大量复杂操作时速度是远低于 Wasm 虚拟机的。EVM 的 Opcode 规范一直没有更新，虽然开发过类似 evmjit 这样的JIT编译库，但也是实验性质的没有投入生产环境。虚拟机的优化是个费时间又费钱的工作，看下大厂在 JVM 或者 Wasm VM 上的投入就知道了。
    
*   智能合约的开发上也有很多遗留问题，类似标准库的缺失，调试和测试的不便等。其中最为诟病便是无法在原合约上进行升级，所以现在的项目为了达成合约升级的目的，一般会为同一个业务部署三份协议，一份核心合约直接和前端交互，里面会调用逻辑合约和数据合约来完成业务，之后升级时只需替换核心合约指向的逻辑合约地址就可以了，这样的弊端就是部署与维护开销变的更大了。其次 EVM 为了减轻计算密集操作(如密码学计算和哈希)的 Gas 开销， 提供了一些预编译合约，这些合约会在节点本地进行预编译，链上合约调用时再进行加载，如此一来进行任何新的预编译合约更新都需要全网硬分叉级别的升级了。对于这些问题，**Wasm 等新兴合约有望解决链上合约的升级，调试测试与预编译的问题。**
    
*   最后还要提一下浮点数的支持，EVM 中大部分人都觉得货币计算根本用不上浮点数，因为虚拟机的第一个特性就是确定性，而浮点计算的结果和平台与硬件架构相关。浮点数的缺失不会影响 Defi 的发展，但是很大程度会影响智能合约的适用领域，例如科学计算，机器学习，3D建模等。而新一代虚拟机例如 PlatOne-Wasm 就进行了浮点数改造，在一定条件下也可以保证计算的确定性。
    

#### 模块化

*   EVM 在设计之初可能没有想过之后会被如此多的其他链移植，以至于 EVM 兼容似乎成了行业标配。以太坊作为 Monolithic 链的代表在设计之初也没有预想过将 EVM 拆分为可以快速接入的模块化设施。所以在这股 EVM 兼容浪潮下，我们看到大部分公链都开始进行 EVM 的移植。早期 EVM 的移植集成并不是一件容易的事，首先更多的需要考虑底层链的特性从而对原始 EVM 进行修改适配，ABI接口实现，Opcode也会被修改。后来为了适配 ETH2.0 兼容 eWasm 的路线，以太坊也将 EVM 从客户端中单独剥离形成一个独立的模块，然后通过 EVMC ABI 接口与底层进行通讯来实现多虚拟机支持。**越来越多语言的实现版本一定程度降低了 EVM 移植的难度，一定程度上加速了 EVM 的模块化**。下面是一些 EVM 的实现版本，有包含在客户端实现中的，也有独立的：
    
    *   Geth - Golang
        
    *   Nethermind - C#
        
    *   Erigon - Golang
        
    *   OpenEthereum - Rust
        
    *   Py-EVM - Python
        
    *   evmone - C++
        
    *   ethereumjs - Javascript
        
    *   eEVM - C++
        
    *   Hyperledger Burrow - Golang
        
*   EVM 的模块化进程中大家也看到了多虚拟机支持的需求。**兼容 EVM 是当下构建生态最佳选择，而兼容其他虚拟机是为了探索未来的合约发展方向**。由于 App-Chain 发展的加速，应用的最小部署单位已经从合约变化到了应用链，对于应用链开发框架来说，虚拟机模块已经成了必须要考虑的部分。多虚拟机支持的架构以及内置的虚拟机模块可以给应用链开发者充分的选择权，**可以预见模块化区块链的发展将会加速多虚拟机的支持以及 Wasm 之类的新虚拟机的普及**，下面是一下支持多虚拟机的项目：
    
    *   Cosmos - Evm / Wasm
        
    *   Substrate- EVM/ Wasm
        
    *   Solana - EVM / Pipeline (运行BPF字节码)
        
    *   Avalanche - EVM / Wasm / Custom-VM
        
    *   Near - EVM / Wasm
        
    *   EOS - EVM / Wasm
        
    *   Hyperledger - EVM / Wasm
        

2\. Wasm
--------

### 2.1 什么是 Wasm

*   Wasm 是一种**基于栈式虚拟机上运行的可移植编译目标格式**。原始用途是作为可以部署在浏览器中的汇编对象，提升web应用的性能。和 EVM 一样 Wasm 只是字节码编码标准，可以实现多种虚拟机来运行。Wasm 标准由 W3C 制定，其开发团队分别来自Mozilla、Google、Microsoft、Apple，四大浏览器 Firefox、Chrome、Microsoft Edge、Safari 已经支持 Wasm MVP 版本的所有特性。
    
*   Wasm 的出现很大程度上来源于 Javascript 的性能填坑史，JS 最初被设计为解释型语言，没有静态类型支持，所以在 JIT 出现之前基本只能运行时逐行解析与编译，最后才能作为机器码来执行，显然这里面有太多的重复工作。在网页应用进化的越发复杂，性能需求越发苛刻的情况下，JIT 氤氲而生，通过强大的上下文理解能力将一些大量重复调用的逻辑实时编译为机器码，将 JS 性能提升了20倍以上。可是 JIT 带来的性能很快也被榨干了，本质还是因为 JS 不是强类型语言。于是大家有了两个继续优化的思路，一个就是重新创造一门强类型语言作为 JS 的超集，然后编译成 JS，类似于 Typescript。另一种便是通过注释的方式在原 JS 代码上进行类型标注，然后用一个可以识别标注的 JS 引擎来执行，也就是 Wasm 的前身 asm.js，这种方式性能远远超过 JIT，直逼原生代码执行效率。再之后就是几个大厂将 asm.js 标准化的过程了，最后形成了今天的 Wasm。
    

![asm.js performance](https://storage.googleapis.com/papyrus_images/64966bfe0e7a85cb1a4fed1e58f4f1e48e6205f5dc98e3b85f20047779f86d02.png)

asm.js performance

### 2.2 Wasm 特性

*   安全
    
    *   **Host安全** - Wasm 在一个由虚拟机管理的沙盒中封闭运行，这使它无法看到主机，也无法直接与主机交互。对系统资源(文件、硬件或互联网连接)的访问只能通过该虚拟机提供的系统接口 WebAssembly System Interface(WASI) 进行，可以有效减少安全攻击面，在Web环境中 Wasm 严格遵守同源策略以及浏览器安全策略，这意味着某个页面上的恶意脚本没有办法通过 DOM 对象获取到另一个页面的数据，这些限制使得Wasm 模块很难做出不当行为。
        
    *   **内存安全** - 与普通的编译程序相比，Wasm对内存的访问非常受限，对它们自己也是如此。Wasm 虚拟机不能直接访问尚未调用的函数或变量，不能跳转到任意地址，也不能将内存中的数据作为字节码指令执行。在浏览器内部，Wasm 模块只能获得一个线性内存(linear memory)进行操作。WebAssembly 可以直接读写该区域中的任意位置，或者请求增加其大小，但仅此而已。这个线性内存包含字节码、执行堆栈、当然还有运行 Wasm 虚拟机的区域分离。而且如果使用 Rust 这样的内存安全语言进行开发，在代码层面就已经杜绝了大多数内存问题。
        
*   性能
    
    *   包体文件小，加载速度快。
        
    *   与大多数现代硬件架构兼容的指令集，指令集效率高。
        
    *   大多数平台上趋于机器码的运行速度，一个可供参考的数据指标，JS 使用 JIT 后整体性能可以达到机器码 的1/20，Wasm 可以跑到机器码的 1/3 量级（视场景而定)。
        
    *   Wasm 虚拟机的性能也需要辩证的看待，\\这篇论文\]([https://arxiv.org/pdf/2012.01032.pdf))详细的比较了](https://arxiv.org/pdf/2012.01032.pdf\)\)%E8%AF%A6%E7%BB%86%E7%9A%84%E6%AF%94%E8%BE%83%E4%BA%86) EVM 与 Wasm 虚拟机的性能，结论是 Wasm 虚拟机引入的开销不低，并没有达到预期的性能。
        
*   开发
    
    *   多语言支持 - `Rust / C++ / Javascript / AssemblyScript`。前端会对特定语言进行词法分析、语法分析、语义分析，然后生成中间表达形式 IR(Intermediate Representation)。后端对 IR 进行优化，然后生成目标代码 Wasm。
        
    *   工具链支持
        
        *   主流JavaScript引擎 ( Chakra / V8 / Spidermonkey )
            
        *   非浏览器引擎 ( ml-proto / wasm-jit-prototype / wabt )
            
        *   更多的编译器与开发调试工具
            

### 2.3 智能合约为什么要用Wasm？

*   因为区块链需要扩容，为了最大程度的提高网络的交易吞吐量，智能合约的执行效率与安全性产生着非常大的影响，吞吐量直接影响了交易成本，间接影响了区块链的大量采用。合约开发语言与工具链也对开发者生态产生着影响。**Wasm 就是一种可以继承 EVM 的特点(确定性，可终止性，独立性)，同时能够克服 EVM 暴露出的问题的一种解决方案**。Wasm 内存安全、平台独立，可以有效地映射到所有类型的CPU架构, 指令集效率高，同时保有可移植性，Wasm 指令集可以很容易地通过移除浮点指令来达到 EVM 的确定性，这将使它适合于替换EVM语言。Wasm 在传统互联网领域的成功已经证明了其优势。在性能，安全，开发者生态上Wasm 是远远超过 EVM 的，也许以后会有更加适合智能合约的虚拟机，但是现阶段看来， Wasm 应该是不二选择了。
    

3\. CosmWasm
------------

### 3.1 基础模块

*   CosmWasm 的原型来自 Team Gaians 在2019年柏林黑客松的项目，在黑客松取得成功后 Interchain Fundation 授予了 Confio 一笔 Grant 用于继续 CosmWasm 商业版本的开发
    
*   CosmWasm 并非独立的区块链，而是作为 CosmosSDK 模块级别的开发工具链，和 CosmosSDK 中其它模块比如 Staking/Bank/Auth 等处于同一级别。任何使用 CosmosSDK 构建的项目都可以按需接入模块从来获得 Wasm 合约的执行环境。CosmWasm 还提供了一个拥有 Wasm 功能的 Hub模板，叫做 \\wasmd\]([https://github.com/cosmwasm/wasmd](https://github.com/cosmwasm/wasmd))), 作为Cosmos Hub 集成 CosmWasm 的第一个实现版本。
    
*   这里有两张图可以清楚的看出 CosmWasm, CosmosSDK 和 Tendermint Core的层级关系。交易从 Tendermint Core 经过 ABCI 传进 Comos SDK 后，进行交易的解码后就会路由至相应的模块进行状态转换，最后再将执行结果通过 ABCI 返回给 Tendermint Core 进行 SMR(State Machine Replicated)操作。因为模块化的设计，结构清晰，流程可控性强。
    

![Tendermint ABCI](https://storage.googleapis.com/papyrus_images/c10f48f322eed5885e024ddbf2021014e9d7c12e098d2bffb51ebd6f313c3dd6.png)

Tendermint ABCI

![Moduler Flow](https://storage.googleapis.com/papyrus_images/06a2e659bad9e80b2c05ad6a966ef36a938c9a644606d7ba0d6551d1a50d4c23.png)

Moduler Flow

### 3.2 模块特性

*   **模块集成**
    
    *   CosmWasm 在设计层面上追求可插拔性集成，目标是释放多链虚拟机的最大可能性。所以在区块链架构或是语言上都尽可能的做**最小化限制**，只有很少的接口需要实现就可以完成集成，这对于新语言支持的添加是很便利的，不只可以使用 Rust，可以按需求添加 Golang 和 AssemblyScript 等可以编译为 Wasm 字节码的语言。
        
    *   CosmWasm VM 的 runtime core 提供了 Rust 和 Golang 两种实现版本，对于其他非基于 Tendermint 共识构建的项目依然可以集成 CosmWasm 的虚拟机，享受 CosmWasm 在安全与性能上的优势。而只要是构建在 Tendermint 之上或是拥有 BFT 即时最终性(BFT Instant Finality)的区块链, 还可以享受到 CosmWasm 的 IBC 跨链支持。
        
*   **合约安全**
    
    *   合约的安全是 CosmWasm 最大的卖点，他们从 EVM 合约的漏洞中吸取经验，为一些最常发生漏洞的地方提供了原生的解决方案，其中包括重入攻击(Reentrancy)，类型溢出(Arithmetic Overflow)，默认可见性(Default Visibilities)，短地址攻击(Short Address Attack)，时间戳操纵(Block Timestamp Manipulation), 未初始化指针(Uninitialised Storage Pointers)等。这其中很多问题因为 CosmWasm 的架构设计天然就不存在了。
        
*   **Actor模型**
    
    *   Actor 模型是一种在并发与分布式计算中常用的设计模式，概括来说就是把 Actor 作为最基本的计算单元，Actor只拥有自己内部资源的访问权，通过 Dispatcher 来和其他 Actor 进行沟通，当受到消息后，Actor可以进行逻辑处理，创建Actor或者发送信息，然后决定收到下一个信息时的响应。 Actor 可以修改的只有自己内部的状态，每次只会处理一条信息，但是对于消息在 Actor 内部的处理是并发的。
        
    *   CosmWasm 架构上通过运用 Actor 模型来增加合约执行环境的安全性，最直接的成果就是可以防止重入攻击(reentrancy attacks)。重入攻击本质上是利用了调用栈中的执行顺序，在状态改变执行前不断利用原始状态来进行攻击的。然而 Actor 间只能通过信息来沟通意味着处理下一次信息前调用栈一定是返回的状态，也就保证了栈中的状态更新一定是执行完成的，天然的就避免了重入攻击。
        
    *   虽然类似 EVM 的栈式合约调用会带来重入攻击之类的问题，但是优势就是跨合约调用的原子性，一次执行如果失败，所有栈上的状态修改都可以统一进行回退, 这个问题对于 Actor 模型来说就不适用。CosmWasm 则通过创建一个 SavePoint 来存储所有外部调前的全局状态，然后确保将调用分为多个子调用，如果某个子调用失败，则可以退回之前保存的全局状态，保证执行的原子性。
        
    *   Actor 模型还有一个优势就是松耦合性，对于 Actor 来说，信息的发送和接受端都无关紧要。这对于模块化通讯来说意义非凡，合约可以和另一个合约进行通讯, ，也可以与 CosmosSDK 的其他模块进行通讯，对于 Actor 来说区别不大，只要是在 Dispatcher 中注册过的地址，都可以进行信息发送。
        
*   **多链合约**
    
    *   CosmWasm 出现的本意就是作为多链生态的智能合约环境，同时也一直都将 IBC 集成作为高优先级任务。Actor 模型的异步调用方式和 IBC 也是非常契合的，在保证了本地链的执行有效情况下，链间通过 IBC 来确认各自链上执行的有效性， 最后才进行本地状态的变更。只要 IBC 能保证信息传送的有效性，跨链合约调用也就是安全的。
        
    *   目前 CosmWasm 和 IBC 的集成进度是合约已经可以通过 ICS20 在链间进行 CW20 代币的转移。下一步是 CW721 还有 Interchain Accounts 的集成。
        
*   **合约升级**
    
    *   之前我们讨论过 EVM 合约的升级问题，现在项目基本需要多个合约模块配合来支持升级功能，随之而来的代价便是更高的部署费用，更复杂的工程结构，引入更多的漏洞可能性。CosmWasm 从一开始就将合约的升级作为最高优先级，就像我们之前的判断一样，Wasm 一定可以优雅的解决合约迭代升级这种问题。
        
    *   CosmWasm 将合约部署划分为三个步骤，一部分考量也是为了合约的更新。在初始化合约的步骤中，你可以选择设置一个拥有迁移权限的账户，之后下一次进行迭代升级时，首先上传代码，然后使用迁移权限账户发送一个迁移交易，这个交易会将合约指向新的代码并且完成链上数据的转移工作，最后进行初始化操作就完成了代码升级。整个流程自动化程度很高，项目也只需关心业务代码而无需考虑工程结构的拆分。
        
*   **数据库存储**
    
    *   CosmWasm 的创作者 Ethan Frey 说过，以前他在传统互联网公司做后端工作，基本不会接触到用户存储的原始数据，而是使用 SQL 或者 ORM 库来对数据库存储对象进行操作。Solidity 中提供了很少的存储数据结构比如 `mapping`, 但是连遍历操作都没有原生支持，这个和 SQL 比起来就很简陋了。CosmosSDK 中提供了更多的存储数据操作，例如可以针对容器做遍历操作，但是依然是缺少像传统数据库的那种抽象层。于是CosmWasm 提供了 cosmwasm-storage 这个存储库，里面提供了类似 `Singleton` 和 `Bucket` 这种高级存储数据类型。CosmWasm 在之后还添加了加强版的存储库 `cw-storage-plu`，里面提供了 `Item` 和 `Map` 这样的数据类型。这些抽象存储类型的添加充分释放了开发的可能性提高了开发效率，也隔绝了对于原始数据的直接操作降低风险。Ethan 最后还说，用过了这些存储库之后，他再也不想回去用 CosmosSDK 进行开发了。
        

### 3.3 Contracts Pallet vs. CosmWasm

*   Contracts Pallet 是 Substrate 提供的原生 Wasm 模块。两者最大的共同点是都属模块级别的执行环境，可以方便的进行集成。另一个共同点是依托于 XCM 和 IBC，两者的智能合约都能支持多链的合约调用。
    

![CosmWasm vs Ink!](https://storage.googleapis.com/papyrus_images/fe4ad6ddd152a848b4e7ff16d055a669d73d074605b7af5c1c916e1a1b63b0de.png)

CosmWasm vs Ink!

*   两者最大的区别在于 CosmWasm 合约是基于 Actor 模型设计的，而 Contracts Pallet 合约是类似于 EVM 的同步执行模型。对于 Actor 模型的优势在上文已经进行了说明，Ink! 中为了处理这些情况提供大量的宏来帮助各种合约元素的生成。从代码角度来看因为 ink！因为很类似于 EVM 合约的开发思路，而且有大量宏的辅助，代码量相对 CosmWasm 会少很多，从这篇[代码示例](https://jkyin.me/comparing-modern-smart-contracting-environments/)可以看到同一个功能合约，ink!用了 108 行，CosmWasm 用了 200 行。目前看来是因为 CosmWasm 缺乏程序性宏的使用，后期更新有望解决，我相信**未来的合约生态一定是多种设计模式并存的**。
    
*   有趣的是 polkadot 生态的 Wasm 平行链 Gear 也使用了 Actor 模型来创建智能合约。**Gear 说通过 Actor 模型避免了共享内存带来的潜在风险，可以构建一个性能和鲁棒性更好的系统**。合约间永远不会共享内部的状态，Actor 间获取或者修改状态信息都必须通过发送信息的方式。有趣的是传统 Actor 模型中不强调信息的时序性，而 CosmWasm 和 Gear 对针对时序性做了保证来满足智能合约的要求。
    

### 3.5 生态

*   参与了 CosmWasm 生态的项目现在应该是超过25个的，数量还在不断增多，这里简单介绍几个较热门项目。要理解 CosmWasm 生态的发展还需要回顾下 Cosmos Hub 的 **Proposal 69**，可以参考[CosmWasm on Osmosis, Cosmoverse的跨链智能合约引擎](https://mp.weixin.qq.com/s/xzVu3zI3LvHg9wfFne4LEg)
    

![ecosystem](https://storage.googleapis.com/papyrus_images/43beae8731ba52045b3e7e5620bc8d71bbf2945ee00434d4e1cc0c57148823a0.png)

ecosystem

*   InterWasm DAO
    
    *   \\InterWasm DAO\]([https://github.com/InterWasm/DAO](https://github.com/InterWasm/DAO))) 由 Confio / Terraform Labs / Enigma / Juno community representatives 发起，目的是帮助 CosmWasm 生态的发展。InterWasm DAO 拥有自己的代码库，给予生态项目 Grants / Bounties，加速生态的增长，组织生态内的活动。现在的组织成员还有 deus labs / Stargaze / envoy labs / Oraichain / DAO DAO。
        
*   Juno Network
    
    *   Juno Network 是由 Cosmos 生态中数十名开发人员、验证者和委托人推动的社区项目。作为 Cosmos 生态系统中的主权公共区块链，旨在为可互操作的智能合约运行提供环境。该网络最大的特点就是无许可和抗审查的合约部署。Juno 作为 InterWasm DAO 理事会成员，一直积极的在推进 CosmWasm 的发展，在开发者逃离 Terra 之后，Juno 有望吸引更多的 Wasm 项目加入。
        
*   Osmosis
    
    *   Osmosis 是 Cosmos 生态的多链 Dex 中枢，作风实验激进，是我最喜欢的项目之一。从出生第一天起就内置 IBC，常年霸榜 [Map of zones - Cosmos network explorer](https://mapofzones.com/?testnet=false&period=24&tableOrderBy=ibcVolume&tableOrderSort=desc)，是 IBC 的最佳践行者。在传统 AMM 功能之外还不断的探索各种最新技术，比如无准入的 [Frontier](https://frontier.osmosis.zone/pools), 超流体质押(Superfluid), 以及即将到来的 CosmWasm 集成。虽然 Osmosis 上的 Wasm 合约部署是准入制的，但是借助于 Osmosis 的流动性以及强大的 IBC 中枢能力，我个人认为非常有可能出现生态创新级别的产品。
        
*   Secret Network
    
    *   Secret 是第一条具备隐私能力的 Wasm 合约链，通过 TEE(Truested Execution Environment) 来对合约的输入，输出以及状态进行加密，TEE 属于硬件级加密，比 ZK 系更成熟扩展性也更好，而且支持选择性披露信息，是有助于合规化的。Secret 形容自己是以太坊的可编程性 + Moreno 的默认隐私性 + Cosmos 的互操作性 。Secret 的前身是以太坊扩容项目 Enigma，是一家源于 MIT 的软甲公司，也是区块链行业最资深的一群开发者。隐私赛道无论现在还是未来都一直会是行业的热点，TEE + CosmWasm + IBC 想象空间是巨大的，可编程多链隐私计算也给 Cosmos 出现生态级创新产品打下了基础。
        

参考
--

[详解 CosmWasm：兼具 Cosmos SDK 和 IBC 的跨链智能合约引擎 - Web3Caff](https://web3caff.com/zh/archives/14622)

[Introduction | CosmWasm Documentation](https://docs.cosmwasm.com/docs/1.0/)

[现代智能合约生态的比较 (jkyin.me)](https://jkyin.me/comparing-modern-smart-contracting-environments/)

[NEAR | Robert Yan：基于 Rust 的智能合约开发框架的比较 | by BeWater Community | Medium](https://medium.com/@bewatercommunity/near-robert-yan-%E5%9F%BA%E4%BA%8E-rust-%E7%9A%84%E6%99%BA%E8%83%BD%E5%90%88%E7%BA%A6%E5%BC%80%E5%8F%91%E6%A1%86%E6%9E%B6%E7%9A%84%E6%AF%94%E8%BE%83-100ded99f0b4)

[Why we believe in Wasm as the base layer of decentralized application development | Parity Technologies](https://www.parity.io/blog/wasm-smart-contract-development/)

[The War on Virtual Machines: WASM vs. EVM | by kadeemclarke.eth | Momentum 6 | Medium](https://medium.com/momentum6/the-war-on-virtual-machines-wasm-vs-evm-8e68f9d53ef4)

[WebAssembly 101: Bringing Bytecode to the Web (fortinet.com)](https://www.fortinet.com/blog/threat-research/webassembly-101-bringing-bytecode-to-the-web)

[以太机虚拟机 (EVM) | ethereum.org](https://ethereum.org/zh/developers/docs/evm/)

[区块链虚拟机技术简述 - 知乎 (zhihu.com)](https://zhuanlan.zhihu.com/p/97902859)

[从EVM到Wasm的范式转换，为什么波卡会成为公链的常青树？ (qq.com)](https://mp.weixin.qq.com/s/UHOjmVrqzyaxEUOxcR8y0A)

[CosmWasm for CTOs I: The Architecture | by Ethan Frey | CosmWasm | Medium](https://medium.com/cosmwasm/cosmwasm-for-ctos-i-the-architecture-59a3e52d9b9c)

[ink! vs. CosmWasm | ink! documentation (substrate.io)](https://ink.substrate.io/ink-vs-cosmwasm/)

---

*Originally published on [jazzlost](https://paragraph.com/@web3🐕/cosmwasm)*