dApp 的未来在此: vRAM，LiquidAccounts，LiquidDNS，IPFS 托管和 使用 RAM 作为缓存的会话机制，这一切，都汇聚在一个永生的区块链程序之中，并且，具备前所未有的易用性。
1.jpeg
最近，LiquidApps 推出了多款新的 LiquidService 服务.
我们还发布了 Zeus SDK，以简化区块链开发，提供了开箱即用的功能，帮助开发者将 DAPP 网络上的 LiquidServices 集成到应用程序之中。
现在，我们第一次能够强调使用配备了 LiquidAccounts（DAPP Network 上所提供的虚拟账号服务，alpha版）和其他 LiquidServices 的 dApp 所提供的无缝体验。我们决定从开发者所熟悉的领域出发：Block.One 所创建用于 EOS 开发教程的游戏： Elemental Battles -- 元素之战游戏。
介绍LiquidBattles：有史以来最简单易用的dApp
Block.one 的元素之战（Elemental Battles）游戏是一款简单的魔法卡牌游戏。就游戏玩法而言，它只是为石头剪刀布的游戏增加了几重复杂性。
但是当你在台式计算机上启动LiquidBattles时（目前在Kylin 测试网上部署），你会发现这与你之前使用的任何 dApp 都不同。
在这款游戏里面，不需要输入密钥，不需要打开钱包，也不需要对交易签名。 只需要用户名和密码即可。它与传统的网络应用一样，提供了无缝的用户体验，甚至比传统应用做得更好。
不用钱包。无需冗长的私钥。远离烦恼。无缝登录，是 dApp 的未来
不用钱包。无需冗长的私钥。远离烦恼。无缝登录，是 dApp 的未来
这如何可能？
当你第一次登录 LiquidBattles 游戏时，你的 LiquidAccount 会（当前在Kylin 测试网上）获得公钥/私钥对 - 就像你使用喜欢的钱包创建主网账户时，会获得密钥对一样。但是，当你的 LiquidAccount 私钥用于签署交易时，这些交易将通过 dApp 的代理帐户发送到 EOS 主网，该代理帐户也会在此过程中签署交易。如果没有这些密钥，你仍然无法使用你的 LiquidAccount，但你不再需要仅仅为了尝试一个新的 dApp，就要管理 RAM，CPU，密钥和权限等。
无需管理资源。不再需要付费获得帐户。密钥也不再丢失。
当然，并非每个在 DAPP 网络上发布的 dApp 都会像 LiquidBattles 那样使用密钥。
终究 LiquidBattles 这款游戏会使用你的用户名和密码作为盐值(salt)生成帐户的私钥 - 并将其隐藏起来。只要用户能够记住密码，就可以再次生成私钥。忘记密码会导致密钥丢失。
未来使用 LiquidAccounts 的其他 dApp 可能会为用户提供密钥供用户保存，无论是存储在基于 Scatter 的钱包还是其他的地方。他们可能会使用其他要素而不是用户名和密码来生成密钥。还有许多 dApp 可能会设计强大的密钥恢复解决方案，因为，人们总有时候会忘事。
未来，另一个要素也可能会可能发生变化： LiquidBattles 的 LiquidAccount 密钥由创建它们的合约管理。默认设置如此，但这样做并不是必需的。DAPP Network上的未来 dApp 可以协同控制一个位于所有这些dApp的合约之外的一个单独的合约，该合约只用于管理 LiquidAccounts 。这带来的好处是可以使得 LiquidAccounts 被多个 dApp所 “共享”。
无论他们如何选择处理这些细节，第一批注定要能够实现大规模采用的 dApp 都需要流畅的用户引导流程。而 LiquidApp 提供了解决方案。
还有更多其他的问题。LiquidAccounts 如何发送和接收代币？它们如何与钱包应用一起使用，甚至可以跨链使用？
我们很快会发布一篇文章，深入探讨 LiquidAccounts 的可能性。 现在，让我们先来看看这个 LiquidApp 的更多功能。
LiquidBattles不仅易用 —— 运行成本也很低
在主网上运行原先的 “元素之战”游戏非常昂贵，因为需要为每个用户将大量细节信息存储在 RAM 中。 vRAM 使得游戏能够以低得多的 RAM 成本进行部署。
此外，vRAM 的内容会在用户会话期间缓存在 RAM 中，这意味着用户玩游戏时额外的延迟为零。
一旦用户处于非活跃状态，该数据将被移回至 vRAM 之中。这当然就是 RAM 的本来用途：仅存储使用中的数据。RAM 的缓存策略允许 dApp 在不牺牲性能的情况下享受成本效益。
这还不是全部。
LiquidBattles 展示了 dApp 永存的方法
无论智能合约如何难以摧毁，现代 dApp 的前端部分依旧脆弱。
当然，如果某个前端被攻击，其他人仍然可以创建新的前端指向相同的智能合约，使得智能合约最终免遭消失。但是，过渡期的停机时间，会导致 app 用户流失。
我们期待有一天即使AWS停机也并不意味着互联网停机。
我们期待有一天即使AWS停机也并不意味着互联网停机。
借助于 IPFS 托管与 LiquidDNS，LiquidApps 版本的元素之战不仅仅是更易使用-- 还更有弹性
我们后续文章会谈论 IPFS， 在此，我们先花点时间聊聊 LiquidDNS。
LiquidDNS 是一款新的 LiquidService(即，由LiquidApps 所提供的服务)，仍然处于早期开发阶段。借助 LiquidDNS，可以使得 DSP 运行域名服务器解析 dApp 的域名，用户无需在客户端安装或者配置任何内容。与去中心化的存储解决方案相结合，实现 web 托管永不下线。
对这一版本的 LiquidBattles 而言，我们的域名看起来有点奇怪： cardgame1112.dnsregistry1.com。 但是现在只需要做简单的域名服务器修改，即可将从任何其他地方获得的传统域名指向 IPFS 托管的 dApp。
我们应当注意，因为每个 DSP 都可以运行自己的 DNS 域名服务器，需要对各个 DSP 有一定程度的信任: 任何特定的域名都可能会被删除。这是Internet 的构建方式所带来的限制，如果不通过特殊的客户端定制（如 EOSDNS），则可能无法绕过 Internet。但是，虽然可以删掉单个域名，但 dApp 可以使用多个服务供应商和链上的域名表，使得攻击无效。如果一个端点发生故障，其他端点仍然处于活动状态可以访问。
审查、黑客攻击和意外停机等情形，都可能会破坏 WEB 应用的性能。虽然智能合约技术可以降低基础逻辑层的故障风险，但由于恶意参与者和技术故障的存在，仍然可以在应用程序堆栈对其余部分的组件下手。
正如 LiquidBattles 这一 dApp 所展示的那样，LiquidApps 在 DAPP 网络上的服务范围可以帮助开发者为产品实现“永存”。
LiquidBattles 本身并非永存的 - 它部署在 Kylin 测试网上，并使用 LiquidApps Kylin 这一 DSP，因此，其中任何一个实体的消亡，都将使得 dApp 消失 - 但它显示了实现永存 dApp 的方式。为永久生存而构建的主网应用程序，将使用多个服务提供商(DSP)，这样一来，任何一方或其中的小部分团体都无法将其删除。
正如去中心化可以驱动的永存智能合约一样，它现在也可以为永存的前端托管和永存的域名提供支持。有史以来第一次，开发人员获得了创建应用程序的新的可能性，从后端到前端都能够轻松创建，免于攻击。
LiquidBattles ，让我们一睹运行在 DAPP 网络上的 dApp 的各种可能性。
立即试玩游戏，查看代码，或安装Zeus SDK，在你的 dApp 中开始使用 LiquidServices 吧。
使用LiquidApps，使开发者的 dApp 易用、免费且永恒。LiquidBattles 是出现在测试网上的首个此类应用。哪个应用程序，又会在 EOS 主网上横空出世呢？
请加入 DAPP Network开发者电报群 向我们的社区询问任何技术问题，可以扫描文末二维码加入 LiquidApps 知识星球咨询其他问题。
关注 LiquidApps
网站 | 币乎 | Twitter | Telegram | LinkedIn
加入 LiquidApps 知识星球，一起交流
知识星球.png
网友评论