--- title: 写在 Rooch v0.2 版本发布之后 date: '2023-11-02 14:18:23' draft: false summary: 技术人天然容易等系统更完备再拿出来，但越早把方向讲清楚，越容易拿到真实反馈，也越能逼自己说清楚边界。 slug: rooch-needed-an-early-external-explanation syndication: - platform: Weibo url: https://weibo.com/1648815335/4963633476667498 tags: - startup - product - rooch topics: - startup type: post --- 捣鼓了半年多，终于可以拿出来一个东西给大家体验一下了。 熟悉我的朋友虽然知道我们在捣鼓一个叫做 Rooch 的项目，但很多人还是没搞明白我们到底要做啥。一会 Move，一会 Ethereum layer2，一会 Bitcoin Layer2，所以总会问，你们到底是哪个生态的？ 技术人老会觉得还没做完备，不太好意思拿出来给大家试用。我已经是经过几个 startup 改造过的技术人了，深知早期反馈的重要性，但依然有这个毛病。趁着这次机会解答一下这个问题。 原来的叙事主导下的应用生态是围绕 L1 构建出来的，如果应用不忠实地站在某个生态里，就仿佛是要嫁给多个男人的女子一样，让人觉得奇怪。但如果以应用视角来看，应用面向的是用户，就应该博采各基础设施之长来给应用提供支撑，服务于用户。关于叙事逻辑和应用逻辑可以参看我的另外一篇推文：Crypto&区块链行业正在从以叙事逻辑转向应用逻辑。 那现阶段区块链上做应用的瓶颈到底在哪里呢？我认为主要有三个：用户门槛，智能合约的表达能力，可编程的数据源。 ## 1. 用户门槛 这个其实是一篮子问题，需要各种技术方案来解决，包括大家经常讨论的账户抽象（Account Abstraction）等。 Rooch 这个版本中先支持了 SessionKey 的机制。SessionKey 是一种面向应用的临时私钥，有过期时间，使用范围也受限，原理类似 Web2 的服务器端 Session。这样用户登录应用做一次授权后，就不需要和钱包频繁交互了。大家可以登录 Rooch 的 [Dashboard](https://dashboard.rooch.network/) 体验一下那个 Counter Example。每点击一次，实际上就会发送一个交易。但因为有了 SessionKey，用户不需要每次都弹钱包签名，这是高频交互应用的刚需。SessionKey 比完全把私钥放在浏览器应用存储空间里的方案安全，因为 SessionKey 有过期时间以及调用范围限制。同时也因为 Rooch 的交易是即时确认执行的，所以可以立刻得到执行结果，和 Web2 的交互体验几乎一致。 Gas 的门槛。这个版本由于是开发者测试网，所以我们先取了个巧，给新用户自动给 Gas，先把这个门槛去掉了。正在开发的版本里包含了 GasFree 特性，开发者在智能合约中的入口方法中声明该方法是 GasFree 的，Gas 会由应用的合约账户代付。 钱包的门槛。对 Web2 用户来说，安装钱包保存助记词的门槛还是有点高。Rooch v0.2 版本支持了 Authentication Abstraction，支持通过插件方式开发新的认证方案，社交登录就是一种认证插件。用户通过 OpenID Connect 连接 Web2 社交网站，然后会自动生成一个地址以及 SessionKey。关于 Rooch 的账户抽象方案设计可以参看文档：[rooch.network/zh-CN/docs/dive-into-rooch/account-abstraction](https://rooch.network/zh-CN/docs/dive-into-rooch/account-abstraction)。 所以下一个 v0.3 版本，我们希望给用户的体验是，从 Twitter 等社交网络上点击了一个链接打开一个基于 Rooch 的应用，弹个 Web2 社交应用窗口授权，然后调用一个 GasFree 的水龙头接口领一些 Gas（可以包装成游戏币或者应用积分啥的），就可以使用应用了，几乎感觉不到它是个区块链应用。 ## 2. 智能合约的表达能力 我从 19 年开始捣鼓 Move，一直认为 Move 是最有潜力的新兴智能合约编程语言。智能合约编程语言主要解决几个问题：1. 保证执行结果的确定性。2. 在编程语言内抽象和托管应用的状态。3. 提供应用合约之间的状态共享以及调用方案。 尤其后两个问题，整个行业内其实一直在摸索方案，这是在智能合约下运行复杂的应用必须要解决的问题。比如基于 Solidity 的 MUD 框架在不改变 Solidity/EVM 的情况下，提供了一种方案。而 Move 则尝试在语言层面进行创新来解决，并且还在继续演进中。关于这部分内容需要单独一篇长文来阐述，正在写一篇关于全链应用与智能合约的状态难题的文章。 Rooch 在 v0.2 中在 MoveStd 之上，提供了两个应用层的智能合约基础库框架： 1. MoveosStd：我们希望把和 Rooch 的业务逻辑无关的 Move 基础库，包括状态的存储、Object 等，放在这个框架中和社区共享。 2. RoochFramework：Rooch 相关的逻辑，包括账户验证、Coin、Bridge 等。 我们设计了一套 Account 和 Object 结合的状态存储方案，希望开发者可以像操作内存一样操作存储。兼有 Account 模型和 Object 模型的优势，便利开发者的同时，也方便系统做并行优化。已经迭代了几个版本，当前还在重构中，争取在下周再发布一个 v0.2.2 小版本，保证 Framework 的兼容性，让开发者没有兼容的后顾之忧。 Move 的另外一个优点是合约内的状态数据结构对外部系统是可感知的，可以直接映射到外部的索引表中，相当于自动基于智能合约中的数据结构进行 ORM，让应用可以通过检索语言进行复杂的查询。Rooch 的内置实时 Indexer 正在开发中，会在 v0.3 版本推出。届时，Fully on-chain Application 的基础设施基本齐备了，开发者完全可以只用前端技术，配合 Move 智能合约，把 Rooch 作为后端服务来开发复杂的 DApp。 ## 3. 可编程的数据源 智能合约编程遇到的另外一个困境是缺乏可验证的数据源，所以很多应用场景无法支撑起来。智能合约可以操作的数据主要来自于从创世块开始的状态积累，应用部署到一个新的基础设施上，面临的是一个空白的荒野，完全要从头积累。那我们能否把 L1 已经积累的交易以及历史状态利用起来呢？这就是 Rooch 多链结算方案的目标。 每个 L1 都可以是 Rooch 的一个数据源，一个可验证的数据源，当然也包括其中的资产。关于这块的详细方案可以参看 Rooch 如何作为 Bitcoin 的 Side Rollup 的方案。其他链的方案类似，如果 L1 支持图灵完备的智能合约，可以实现数据互通，否则只是 L1 -> L2 单向通信。 Rooch 的 v0.2 里，我们初步验证了不同链的轻节点校验方案、地址映射、钱包和 RPC 兼容方案。比如前面 Dashboard 例子中，用户使用的是 MetaMask 连接 Rooch，用 Ethereum 的账户来发交易，实际执行的是 Rooch 中的 Move 智能合约，就使用了相关的技术。 在下个 v0.3 版本中，我们会先实现 Bitcoin 和 Ethereum 的接入，以及 Celestia DA 的接入，让开发者可以基于 Bitcoin 和 Ethereum 的数据源进行智能合约编程，构建应用，将 Rooch 作为一个搭建 Rollup 应用的框架。也欢迎对 Rooch 方案感兴趣的 L1 开发者，来一起探讨接入方案以及如何利用 Rooch 扩展 L1 的应用场景。 ## 总结 从 Fully on-chain 角度来看，Rooch 是一个提供区块链环境的工具和服务。但我们又希望开发者不要把 Rooch 当作一个区块链，因为区块链给开发者一直的感觉是像一个重型坦克：大型、缓慢、昂贵。我们希望 Rooch 是一个开发者轻便、趁手的工具，把它当作运行智能合约的 Docker，或者存储应用状态的 Git，或者 Rails 这样的后端服务框架，发挥自己的想象力构建一些有趣的应用。 所以我们采用的是优先开发者的交付策略，优先交付一个让开发者可以探索应用场景的环境，然后再做后端那些不影响开发者的特性、性能以及安全的优化和改进。整个行业如果想要突破，就需要探索新类型的应用，而风起于青萍之末，创新往往是开发者们在一个不起眼的角落里捣鼓出来的。 相关版本发布说明见：[Rooch v0.2 release](https://rooch.network/zh-CN/blog/release-231018)。