观点 | 关于区块链应用，我们需要一个更好的框架

我相信你肯定看过下图所示的诸多 “Web3 技术栈示意图”，在解释区块链（或者说 web3.0）涉及哪些技术时，这些示意图都很有用，也是正确的。但当你想拿区块链来做应用时，你会发现这些技术栈理论并不能提供什么指导意义。

你觉得我的意思不太好懂？那我们先来了解更多的细节。下图所示即为区块链应用最常见的结构。不论是基于网页的还是基于原生 App 的，99% 的区块链应用的结构都是这样的。

因为不论网页 App 还是区块链都被套了一层 web 框架，所以区块链应用并不能超越网页 App 的边界。

我只想强调这么几点：

• 安全性 ：按上面结构，整个应用系统的安全程度跟一个网页 App 是完全一样的，都没有底层的区块链和智能合约这么安全。

（作为用户）你并不知道你签署的交易内容是不是仅限于你想签署的部分。在用户发送标准的支付交易时，这是个小问题，虽然在一些记录键盘信息的恶意软件攻击案例中，这一点仍有负面影响。但是涉及到 token 转移的复杂逻辑时，这种结构会面临非常严重的问题。当然，开发者可以让交易以用户可读的形式呈现出来，交易可视化 工具 也很容易上手，但是最终来说，这个应用要整合的东西以及使用体验上的需求，是超过一个字典类型（dictionary-style）的交易可视化工具的能力范围的。

• 信任：因为构建区块链交易、呈现安全视听信息的代码都是放在网页 App 上的，这就让区块链应用的可信层级从区块链级降低到了跟一个普通网页 App 同样的水平。

• 可用性：区块链和智能合约都有高可用性，24 小时 × 365 天无休。而网页 App 的可用性跟区块链相比就低很多。两相加总之下，区块链应用的可用性就跟网页 App 没有区别了。网页 App 一旦挂掉 —— 甚至只是网页管理员忘了给 SSL 证书续期 —— 相关的区块链应用就基本用不了了。对于一些时间敏感的应用场景比如投票、拍卖来说，这一点是非常致命的。更糟糕的是区块链应用之间还有可能相互依赖。

• 互操作性：类似地，依赖于 Web 框架的区块链应用的互操作性也会下降到与网页 App 相同，不复智能合约本来的便利性。假设一个叫做 Peter 的房地产商做了一个叫做 “彼得之选” 的网站，陈列他认为市面上最好的房产并以 token 来代表及交付这些房产。他还可以列出关于这些房产的一系列信息，价格、地段，等等，让用户能一键购买。Peter 也不需要许可机制，因为这些 token 的数据都是放在区块链上的。但是 —— 他还是得知道如何在网站上呈现这些 token 的信息。而且一旦智能合约或者交易规则有所变动，他也得跟着更新网站。如果他忘了及时更新，那用户就会提交不符合要求的交易然后被合约拒绝掉。

• 用户体验：依赖于 Web 框架的区块链应用也跟网页 App 一样，缺乏 基于情境的用户体验 。假设你想买入彼得之选网站上房产的 1% 份额。在传统的钱包里，你只能看到一个小符号 —— 有已经算好的了 —— 看不到任何进一步的信息。这完全不是房产投资者希望看到的情况，他们想要房产的图片、价格；同区域房产的图表、预计成交日，等等。你当然 可以 在钱包里面展示这些东西。 只需要 钱包跳转到一个塞满这些信息的智能合约，或者去相信一个提供这些信息的不知道什么网站、根据这个网站来做用户体验上的适配。实际上，根本没有钱包能做到这些，最终要么是用户来使用网站，要么是智能合约开发方尝试做出一个能满足他们需要的钱包出来。

• 可扩展性：同一种类型的资产可能在多个网络（比如 Plasma 侧链）上有 token 实例。没有这样的架构，token 经济就很难扩展。但是，要让一个全知的节点来提供所有 token 的可展示信息是很困难的 —— 也跟我们在扩展区块链经济的同时保持节点负担小的目标相冲突。因此，关于 token 的知识（TokenScript）必须与 token 的访问途径相分离。

• 隐私性：几乎所有的业务运营都需要一些身份信息。当你买入 1% 的房产 token 时，在某些司法辖区，你需要提供某种形式的身份证明。在传统模型中，如果你使用了一个第三方网站（比如彼得之选），这个网站回要求你提供身份证明并转发给出售方、公证人和政府。在诸多 ICO 项目尝试合规的时候，我们已经看到了这种情况：投资者大量上传护照照片。这种办法的问题早已是人尽皆知。你肯定也不希望自己的身份信息存储在很多网站的数据库里，因为你也不想自己的身份信息被盗走。取得你的信任的网站也可以滥用这份信任 —— 比如卖掉这些信息，或进一步分析这些信息 —— 而且网站也可能被攻击。上传护照照片或其它身份文件到网站服务器，是又要整合网站服务器、又没有所有权和身份机制的网站所能引起的最恶劣问题之一。

另外，上述每一点都有许多 “解决方案”，这些方案，怎么说好呢，就像是头痛医头、脚痛医脚，但完全没意识到病症的整体性原因。

在我们讨论新框架以前，我们先快速回想一下，区块链到底是用来解决什么问题的？

2017-2018 年间爆发的区块链投机热潮，让所有人都只关心 token 的价格。我们一边炒作，一边就忘记了一开始到底想用它来干嘛；就好像是房产泡沫的时候，大家都忘了房子不仅仅是一种炒作资产，也是一个用来居住的空间。

区块链履行了受信任第三方的功能。要想诉诸实践，仅仅知道这一点是不够的；我们还必须理解它对世界经济和互联网的意义。关于区块链的应用，我们团队已经在金融机构和创业公司中研究和实验了多年。靠着这些经验，我们开始意识到，区块链 —— 作为受信任的第三方 —— 可以实现两大关键功能：

• 提供无摩擦的市场环境
• 整合 web

虽然 17-18 年的泡沫破灭了，但大家一开始就关注到了 token，不是一个坏事。Token 就是者两大关键功能的赋能器。我们管这些致力于让 token 能发挥区块链关键功能的技术叫 “tokenisation（代币化）”。Token 化的权利可以在市场上交易、也可以在多个系统中整合，最终回形成无摩擦的市场并使无限制的整合成为可能。

哪些信息应该被 “存储”（代币化）到区块链上？

我们来看两个例子：

案例：USDC

a）代表我持有 100 USDC 的信息

b）代表我的美国公民身份的信息

c）USDC 的 Q&A（使用说明）信息

d）描述 USDC 交易逻辑的信息

e）表示 USDC 铸造逻辑的信息，例如：要在 Circle 上开设一个账户，并把美元转入某个银行账户，等等。

案例：表示一辆车的所有权的 token

a）表示我拥有这辆车的信息

b）代表我的驾照的信息

c）汽车的使用说明书

d）这辆车相关权利的交易逻辑，比如转让逻辑、卖出逻辑、用于担保的逻辑

e）这辆车的运行逻辑，包括开门、关门、启动、停车。

答案是 a 和 d。

如果是无关所有权的信息，比如 c 和 e，你可以使用数字签名。如果无关所有权的转让，比如 b，可以使用 attestation。

区块链是用来代币化可转让权利（比如所有权）并定义转让逻辑的。关键在于，所有这些信息都关联着一个 token 化的权利，进而让这个 token 成为释放 web3.0 功能的关键点。

明白 token 就是关键之后，理解 TokenScript 框架和区块链应用的新结构就容易多了

我们这个行业此前的工作几乎都集中在增强技术上（比如交易吞吐量）。TokenScript 却致力于代币化，属于功能而非技术维度。TokenScript 是一套标准，让区块链技术栈能够完整，并为经济活动和互联网提供功能。

一个 TokenScript 文件由两部分组成：1）让 Token 在用户的钱包乃至在跨越应用时能够正常工作的 JavaScript；2）能够提取 token 的状态和值的 XML 数据。并且，还有沙盒化且经过代码 签名 的模式来进一步保证文件的安全性。简言之，它就像 token 的安全前端。

如何生成 TokenScript 文件，又如何使用？

一般来说，TokenScript 是由 token 的建模者（modeller） —— 即开发底层智能合约（用于描述 token 的交易规则）的团队 —— 来创建的。

TokenScript 让 token 运行时的环境（用户代理或者交易引擎）能够：

• 从持有 token 的智能合约、attestation 乃至参考信息处获得与 token 相关的信息
• 生成图像或者音像来展示这个 token
• 提供可执行操作的清单，并解释如何构造交易

任意参与者都能使用 TokenScript 来展示 token 和使用功能，包括通用的市场平台、用户代理人和第三方应用。我们用 “congtext（运行时环境）” 来代指这些参与者。

TokenScript 文件里面包含什么内容？

TokenScript 是一种 XML 方言。它描述了由 token（通过智能合约或其它方式）提供的功能、在用户界面展示 token 的方法、token 所使用的 ERC 代币行为模板，以及构造交易和展示 token 所需用到的 JavaScript 代码。它也定义了 attestation 如何用来修饰、转换和验证交易。

为什么使用 XML 而不是 Json 或其它 JS 格式？

把 TokenScript 文件当成项目文件，而规范化的版本当成最终可分发的工程目标，你就更容易理解其中用意了。

XML 有确定的标准和已经经过时间考验的工具，对我们很有帮助：

A. XML 规范（c14n）指定并提供了一种可转移的方法来表示一个 XML 文件，并能在文件传输中始终保持同样的格式。

B. XML 数字签名（基于对标准化 XML 文件的签名）

C. XML 使开发者能够公开列举出并描述属性和 操作/交易。虽然 Json 也可以做得到，但其形式可能是在字典或者字符串中列举内容，这些文本很难执行模式、验证和追踪模式更改。

D. 标准函的静态类型，使用 XML 我们可以很容易地执行 ASN.1 变量编码来保证这些变量与定义一致。

这些方面加总在一起，我们就能保证，给定的一个经过签名的标准化 TokenScript 文件没有被篡改过。如果不使用 XML，那就必须重新发明 XML 的这些关键属性并使之可用。

最终来说，如果我们把 TokenScript XML 文件看作是项目文件，我们就可以预见：在未来，我们可能会开发出工具来管理它们，而不是依赖于直接编辑 XML 文件；然后，文件自身的可编辑性就变得没那么重要了，而文件的完整性会变得更加重要。

关于 TokenScript 和 AlphaWallet

• TokenScript: https://github.com/AlphaWallet/TokenScript/blob/master/doc/design_paper.md
• iOS : https://github.com/AlphaWallet/alpha-wallet-ios
• Android : https://github.com/AlphaWallet/alpha-wallet-android
• Website : AlphaWallet.com
• GitHub : https://github.com/AlphaWallet/
• Forum : https://community.tokenscript.org/
• Twitter : AlphaWallet
• Telegram : t.me/AlphaWalletGroup
• Facebook : https://www.facebook.com/AlphaWallet/

（完）

原文链接: https://medium.com/alphawallet/we-need-a-better-framework-for-applications-using-blockchain-3d7543ca9f99

作者:Victor Zhang

翻译:阿剑

本文由原作者授权 EthFans 翻译及再出版。