互操作性是近期在Web 3 兴起的概念，是指不同的计算机系统、网络、操作系统和应用程序一起工作并共享信息的能力。随着链上通信、语义交互逐渐复杂，链上用户多样的需求已然超出应用在单条链可承受的技术能力。
原本视作创新实验的Web 3 应用逐渐被公众接纳，它的出现让关键的问题看到可能解决的曙光。信息不透明、安全性、底层技术等问题将依靠区块链的技术优势得到改善。然而，支撑实验性创新走向普及的技术基础，这条路任重而道远。
Moonbeam的创始人Derek Yoo，在本篇内容分享了他对区块链兴起到未来发展方向的思考。
让每个人获得区块链技术带来的便利，这是Web 3 走向普及的动力；
如今的公链方案面临着链上性能和运营成本错配、碎片化流动性和有限可定制性等问题，无形中限制了链上应用的多样性和规模化扩张；
从去中心化应用走向定制化的应用链，是实现业务规模从 1 到 100 的可行之路，dYdX正在进行有价值的尝试；
Moonbeam引领的Connected Contracts正帮助更多跨链互操作协议从普遍使用的EVM兼容走向原生的多链业务拓展；
“Containerized app chain”是Moonbeam实现成为Web 3 云基础设施的重要一步，安全性、底层部署、可定制化等制约公链搭建的挑战将迎刃而解。
正如我在Illuminate/ 22 的开场演讲中提到的，Moonbeam的专长是支持新型跨链应用，提供更多专业的解决跨链场景的案例。
我的分享将包括：
Moonbeam专注跨链的背景
我们是如何构建跨链解决方案
为何坚信多链未来的原因
历史总能给予我启发，回顾技术变迁，让我受益匪浅。
正如马克·吐温曾说的，历史不会重演，但总会有惊人的相似。
我们能从历史中感知到一套发展的规律。对我来说，通用计算的发展史是一次值得学习的前车之鉴，它的变迁演进和区块链（Web 3 ）随时间巨轮前行的道路类似，在时间的推移中持续发展。
在这里，我展示了两条时间轴。相信你还记得计算机在诞生初期是昂贵而又稀少的，计算机资源是稀缺的，但后期得益于完善的功能体系，更多的用户共享获得了计算机的功能。
对比现在，这种规律依然存在，甚至在某些方面是正确的，当我们推及到区块链，以太坊主网，甚至是Moonbeam。
我们都很清楚，区块链上的资源仍旧稀缺，很多使用者仍像使用计算机一样共享区块链的资源。如此说来，区块链亦可简单地视为社区化的计算机。
到现在，我们的区块链又有了新的演变，应用链（APP Chain）映入眼帘。这就和电脑普及的历史道路有些相像了，我们不用共享一台电脑的资源，而是直接拥有自己的电脑。
以此类推，应用链也正在区块链世界中表达这一概念：即在Web 3 中，您的应用将匹配其专属于它的区块链，而不是在一个共享资源的区块链平台。
我认为我们正处于一个万链共生的环境，不管是应用链、共享资源的智能合约平台都是首次出现在一起。他们相互之间能传递信息。
要知道，“多链”是今年进入公众视野的事。可能很多人没有意识到，跨链互操作是今年兴起，但却在发展的初期成功引起了行业的关注，并且有可能成为去中心化应用的底层基础设施。
我认为，区块链会向着云服务的方向发展。作为开发者，你能获取用于发展应用的资源或服务，甚至更多。这是我作为开发者在行业内看到的趋势，也是我们可预见的行业未来。
按照这种设想，Moonbeam专注于我们所描述的Connected Contracts。通过跨链互操作协议，智能合约可以在Moonbeam获取来自任何链上的用户、服务等。已经有大量的应用已经运用这种方式运行在Moonbeam，你将看到更多运用跨链互操作协议实现自身业务的知名项目演示，包括他们的业务是如何展开和使用的介绍。
回到Moonbeam，我们是如何实现Connected Contracts的想法呢？
重点一：尽可能多地集成更多跨链互操作协议。作为基于波卡发展的平行链，我们有原生访问XCM的优势，XCM是一个跨链通信系统。
重点二：实现多类型的信息传递系统集成在Moonbeam，比如Axelar、LayerZero、Wormhole、Hyperlane等更多的协议正在Moonbeam大放异彩。
我们正竭尽所能，为开发者提供更多样的选择，协助他们同时集成更多的区块链。
同时，我们也在Moonbeam打造了全兼容以太坊的开发环境。这是一个巨大的工程，需要多种开发工具和基础设施的同步引进，共同创建一个友好又熟悉的开发环境。比如大家熟悉的Etherscan等区块浏览器，或是大家在EVM兼容环境中期望使用的各类开发工具。
最后一点是关于通过专业资源进行安全扩展，我会在最后的分享中提到这点，我对这一点有很多想法，以及改进他的方案。事实上，波卡是一个提供建设区块链所需资源的优质平台，这和Connected Contracts有相似的愿景。智能合约能利用这些专业服务拓展业务，与更多应用交互合作，获得更多用户。
所以， 多链的发展现状是什么样的，遇到了哪些瓶颈？
在第一轮多链部署的浪潮中，多链更倾向于多地部署的状态。
具体来说，如果一个协议希望运营在 5 条不同的区块链，可能需要 5 套不同的合约协议，以此支撑这个应用在 5 条不同公链运行的能力。比如，你需要在以太坊主网部署一套合约，在Polygon部署一套，在Moonbeam或是BNBChain部署一套单独的合约。
这种方式实现了多链部署的想法，但每条每条公链上的合约却和孤岛一般，用户和服务无法在链之间相互串通，显而易见的劣势是碎片化的挑战。
作为使用者，你必须清楚自己是在哪条网络。如果你希望移动到另一条网络的同一个协议，你需要借助第三方跨链桥的力量，将资产重新转换到新的网络再次开始。
在这样的现状下，比如DeFi用户体验的碎片化会造成碎片化的流动性，甚至是链上功能的割裂，碎片化成为了阻碍业务发展的挑战。
举一个例子，在稍后Prime Protocol成员Colton的讲解中也能听到这个案例，这是一个支持多链信息传递的底层架构方案。Prime Protocol创建了一个原生的多链架构，是一个中心辐射型的架构，帮助你在所有想要交互合约的公链部署业务，并同时实现业务在不同链之间的互通。
多链间的协调只需要专注于一条链，而不用分散精力至每一条部署业务的公链。这就像拥有一个超级智能合约，我们暂且称它为打造在Moonbeam的多链枢纽，在其他链上的业务交互如同围绕着枢纽的远程卫星，比如在以太坊主网、BNBChain或其他公链。
按照这样的想法，Prime帮助用户实现了用户在一条链上与任何其他公链交互的可能，跨链传输的信息也可传递会跨链的中心枢纽。比如用户在其他链上存入资产的动作可以被远程读取，并直接作为凭证作为在另一条公链交互的参考，这就好比是一个链上协调的总枢纽与分支机构协同合作。
我认为这是一个非常有想象力的方案，从功能性的角度，它弱化了链上流动性碎片化带来的挑战，Prime的解决方案将会优化“孤岛部署”的多链竞争。
另一个Connected Contracts跨链的真实案例，是Moonbeam与Osmosis之间的跨链交互。
Osmosis是一个基于Cosmos SDK的DEX，他们希望实现一键存入DOT的功能，用户可以把原生的DOT直接存入位于Osmosis的存入地址。
在这个功能背后隐藏了很多复杂逻辑，当用户使用原生的DOT时，这些DOT需要经过Moonbeam，通过XCM成为xcDOT，然后通过集成在Moonbeam的Axelar路由到Cosmos的interchain再到Osmosis。当DOT进入了Osmosis，合成LP的动作就会被触发。
这就像是连锁的渗透，多链的传输中发生了许多步骤。但回过头来看，用户却不需要了解这些繁琐的步骤，因为所有的复杂操作不需要他们承担。这是一个非常典型又简单的用户体验，也展现了Connected Contracts智能合约展现出得巨大能量。隐藏复杂的技术原理和技术底层，将简单便捷的体验展现给终端用户。
在Web 2 领域，类似的产品体验非常普遍，而在Web 3 ，跨链消息系统正在让这些便利的用户体验变成现实，一切才刚开始。
关于Moonbeam正在筹划的事，我也做一些介绍，那就是Containerized app chains（容器化的应用链）。
这又让我们回到了我最初提出的想法：Moonbeam拥有的优质EVM兼容开发环境，海量的开发工具和应用，选择多样的跨链协议。完成了这些后，在一个问题来了，如何帮助这些应用实现规模化的扩展呢？我们无法忽视近期的一个事实，应用链的数量正在快速增长。
回顾过去的几年，已经有大量的应用链上线在各个基础底层。即使我们只看三个生态系统：Polkadot、Avalanche和Cosmos，大量的应用链已经在这些生态中诞生。
你能发现一些业内知名的项目，比如dYdX（业内规模最大的去中心化衍生品平台），这个项目始于以太坊主网，之后他们迁移至Layer 2 解决方案，落地在Starkware，以便拓展他们的业务。近期，dYdX宣布他们正在Cosmos构建一条应用链。看到这类现象，值得我们思考的是，为什么应用的下一步是应用链？
我认为有几个关键的驱动因素。
首先，性能和成本。想象一下，当你处于一个共享的平台，并需要从这个平台获得大量的资源，资源的价格随着需求水涨船高，久而久之，使用你产品的用户将不得不承受服务成本提高带来的负面伤害。
铸造NFT的流程中就不难发现这类问题，链的运行效率变慢，NFT的可用性随之降低。如果拥有专属的应用链，在链上配备各种性能将不成问题，因为这是专属于你的产品app的链，用户的使用体验也能得到很好的保护。
对于正在经历快速成长的应用，扩大业务规模，希望用户成倍增长，这对他们来说极具吸引力。
其次，可定制性。随着dapp业务的拓展，产品将需要覆盖更广的用户群体。产品落地的执行力将成为优化dapp的动力。如果能在基础架构中满足业务拓展的灵活性，这将对效率的提升大有裨益。
我相信这个因素也会推动项目方拥有一条专门服务于其产品的链，实现定制化的灵活优化的开发环境。
最后的动因，可能有点偏哲学，是价值捕获。当你的应用升级成为一条公链，流通于应用中的token也就拥有和Layer 1 公链一样的价值，它具有保护基础链安全稳定的重要功能，比如质押或其他功能将融入token本身。所以，这也是项目方选择成为应用链的重要驱动因素之一。
以上这 3 个因素是我认为的驱动项目成为应用链的主要原因。
但机遇永远伴随着挑战，并不是所有项目都适用于自我升级成为应用链的解决方案，搭建链的执行难度有目共睹。
比如最基本对基础设施的要求，你会需要Bootstrap验证人集合，创建（或寻找）一群区块生产者，或是为整条链设置生产区块的角色，你得关注很多基础性的工作。不过，这些工作在你使用公链这样的共享资源平台时，你是能直接通过付费获取这些资源。所以，从应用到应用链，对很多项目方来说，是一个质变的转折点，这也让很多项目方对独立发展应用链的规划望而却步。
另一个重要的问题就是安全性，为链上安全性的付出可能和链实际的使用效率不成正比。直白点说，如果你的产品首次面世，产品却不对市场胃口，但为了维护应用链，你依然得在安全性上支付巨额费用。甚至应用链的安全性在初期并不稳固，可能只有一个小规模的验证人集维护，而且token的经济价值在初期也未体现，这时候的链很容易受到外来的恶意攻击。
第三，围绕着现有公链面临的挑战，可组合性的局限性和碎片化的流动性依然存在。毕竟你能依靠的只有自己开发的公链（Moonbeam还有完善的EVM开发环境支撑，EVM的可组合性适用于大多数项目）。
以上三个问题聚在一起，开发自有公链似乎不那么香了。
我正在思考一个概念，暂且把它叫做“Containerized app chain”，这个概念的目标是让开发者构建应用链这件事儿变得非常简单。
开发者只需要按照构建区块链的逻辑，或是利用Substrate Runtime的特性，按照他们自身产品的需求更改相应的代码，而波卡和Moonbeam则是应用链安全性的提供方。
注意，这边有一个新功能，也就是Container本身将是一个执行环境，它将提供完整的应用链所需功能和其他开发应用链所需的服务。因此Container是一个支持区块生产和维护区块链状态的执行环境，是支撑链运行（生产区块）的技术支撑。
如果你也认同我的观点，假设我们真的落地了类似Container的执行环境，我们能受益的好处显而易见。
比如我刚才提到的对成本控制的能力、业务拓展能力等。而这一切的实现就像智能合约部署在Moonbeam的EVM兼容环境中一样简单。开发者不需要纠结最基础的基础架构搭建，专注与和自身产品性能相关的代码即可。
我认为这项功能拥有无可比拟的潜力，而且这项功能的易用性令人期待。
我希望借这个机会向大家展现一幅版图，Container如何走向落地，并且让各个应用链组合在一起。这幅PPT会展现出比Moonbeam更广阔的视野。在这其中，你会发现Moonbeam扮演着EVM执行环境的关键角色---成为各个集成的网关，因为Moonbeam与各类跨链协议连接，相比于仅兼容EVM执行环境的原生DeFi拥有更出色的生态环境。
我有一个更宽泛的观点，未来需要更多的服务提供更优质的开发者体验，帮助他们管理产品的整个生命周期，并不断扩展业务，吸引更多用户。
在上述的架构下，Moonbeam和所有的服务组件显然是关键的部分，这就像路由器，交叉传递各类信息。我刚才说的App chain Container就是实现这些组建的基础。你需要完成大量的工作来完成基础工作的搭建，在建立起应用链后，你需要处理大量的交易在不同的链上，但这些业务的交互仍会回到Moonbeam，独立的业务，但是却能紧密交互。
我的行业愿景是构建一个像云一样的开发环境。作为开发者，使用不同的服务构建应用，并可以相互交互，协同工作，几乎可以将其视为专属于每个产品的产品工具包。
这就是我这几天在思考的行业愿景。
Moonbeam将在其中发挥关键的作用——相互连接，自由传递的角色。
观看视频回放：https://www.youtube.com/watch?v= 698 Ae-O 17 po
