编者按：本文来自以太坊爱好者，作者：WeiwuZhang，翻译&校对：安仔C1int&阿剑，Odaily星球日报经授权转载。在TokenScript项目中，我们只会将靠得住的技术手段应用到公链上。但糟糕的是，人们对区块链数据空间的使用往往并不切合区块链的设计目标。人们总在抱怨以太坊“大塞车”，同时又编写一些收发聊天信息的智能合约。不过在区块链上传播“crypto街头涂鸦”还不是最大的问题。我们认为，最大的问题在于没有站在互操作性、可拓展性以及持存性的角度设计数据结构。换句话说，在各个独立的Token项目中，数据结构都随用例量身定制，难以和非区块链系统联动，在别的去中心化项目中使用时也容易出错，并且但凡需要改动，就得从头设计整个数据结构。数据对象举例
我们先来从这个例子出发，然后再进行归纳推理。假设某个活动的门票是数据对象，并以JSON编码：
1.这是主办方发行的第24张门票。2.这张门票的级别为“class2”3.这个活动在2020年1月1号20:00开始。上述数据对象可以在区块链交易中使用。假设我们有一个以太坊智能合约来转移门票的归属权：
然而将数据编码成JSON格式会消耗大量的gas，因为这会增大交易体积并增加智能合约解析的负担。由于需要紧凑地打包数据对象，我们必须首先把数据从它的模式中分离。数据和模式的分离
我们把数据编码成了20个字节：0x3012020118020102180A32303230303130313230。可以看到这20个字节包含了3条消息：
其中票号24被编码成了0x18；票务级别"VIP"被编码成了0x02；日期信息被编码成了ASCII字符串。这三条信息之间的结构数据是使用标准DER编码规则后产生的结果?。对数据的模式，我们用ASN.X语言描述。
数据模式需要存储在智能合约之外。在我们的TokenScript项目中，数据模式直接由TokenScript存储，因此，兼容TokenScript的钱包和dapp浏览器能直接使用对应的数据模式来解析20字节的数据。你也可以用别的格式把数据模式存在应用程序中?，但你不应该直接把它存到智能合约里，至少，你可以把数据模式编译成一块简洁的solidity字节码以方便智能合约解析那20字节的数据。模式的使用
一旦我们能把数据和模式分离，以太坊上的智能合约函数就能变成这样：
可以看到现在门票对象从字符串类型变成了字节类型。让我们通过函数声明前后的几行代码来进一步分析：
parse_ticket函数包含了由模式语言编译得来的代码。这要比JSON解析器的效率高出不少。另一方面，dapp是否需要构建DER编码后的字节数据供交易调用，用户端钱包是否需要可读化呈现一个已经构建好了的交易，都应取决于数据模式。为什么要模糊化？
所以DER或者ASN模糊化处理和以下直接了当、对新手友好的方法比，有什么好处呢？
或者跟这个更结构化一点的版本相比又如何？
难道模糊化仅仅是为了减少交易大小吗？上述问题的答案都是“是的”，并且这个“对”的程度超出你的想象。首先，经过DER或ASN处理后能把交易负荷减少50%以上，其次还有很多别的优势：理由1：用于制作签名证明
一串经DER编码的字节数据非常便于签名。不过，我们为什么需要签名呢？签名是为了得到认证。我们之所以把被签名过的数据对象称作“认证”，因为它确实代表着签名者对某些事情的认可。我们依然以上面的门票为例。一开始，你可能会认为门票合约控制了所有票务和归属权信息。比方说，当“Alice”想要把一张票转给“Bob”时，Alice会发起一笔交易，将门票的所属权重新指认为Bob。活动主办方往往会为一场活动发行数以万计的门票，或者少说也有几千张，其中绝大部分收到门票的用户并不会把门票转给别人。要不是有这种票券转让的需要，门票根本就不需要放到区块链上。活动主办方完全可以签署一份attestation，将门票的所属权签署给特定的以太坊账户。账户私钥的持有者则可以通过一个质询-应答式的合约来证明门票的所有权。另一方面，如果数据用JSON格式编码，它就无法被安全地签名，因为JSON并不是一种确定性的编码方式。见证的用途非常广泛。以下列举几个例子。你可以编写智能合约，使得被认证为合格投资人的用户能参与ICO预售。汽车保险公司能证明你的车已经上了保险。如果你的车是个智能载具，你完全可以在不进行任何以太坊交易的前提下，利用认证消息把车借给你的朋友。签名认证的设计模式只应根据现有的标准进行改造，而不是重新发明一种崭新的模式。TokenScript已经在研究这样的改造方案，但革命尚未成功，同志仍需努力。比方说，我们目前需要用默克尔树，甚至零知识证明来实现一种可以做部分见证的格式。理由2：数据互操作性
经过DER编码过后的数据有更好的互操作性。依然是以票务证明为例：哪些系统需要用到认证信息？我们目前知道以下几个。1.智能合约：如果Alice想要出售她的门票，智能合约需要具备查验活动主办方签名的能力。2.钱包：用户钱包必须能正确显示认证消息的内容。每当有交易涉及到认证消息时，钱包都需要提醒用户交易的实际内容。不止上述两个端口。活动主办方的网站也需要具备读取见证消息的能力，因为门票持有者可能会利用见证消息来登录网站，获取活动的最新消息。检票员也需要能读取这个数据。使馆和边境警察也会用到这些证明。去年一整年，刻画成了认证消息形式的FIFA门票取代了VISA，被大规模应用到了俄罗斯边境过境的场景中。不难看出很多系统都需要用到见证消息，而这些系统往往都是异构的。比方说，智能合约属于区块链，而钱包属于移动应用程序。在活动主办方的网站中，JSON的表现方式是标准。而出入口的自动门作为一个物联网设备，通常认二维码。由于系统由可验证签名支撑，它不能随意转换——在这种场景下，签名过的数据必须有一种统一的呈现形式。如果数据模式发生改变，我们没有理由要求所有的去中心化系统一起升级。然而如果数据基于模式驱动，可以很轻易地对整个模式发起更新。你可能会觉得自己的token不会被用到那么多其它系统上。但事实上谁也说不准。像以太坊这样去中心化平台的优势在于搭积木。许多系统不需要MakerDAO授权就使用了DAI。你可没法在美国运通这种传统中心化系统上看到那样的创造性活动。理由3：持存性
持存性和互操作性紧密相关。要时刻牢记一旦数据被签名，如果没有把原有的签名无效化处理，它是没法被“转换”到一个新的系统中使用的。因此，所构建的系统必须同时理解旧的以及新的数据格式。假设你是一份用cryptoattestation写就的遗嘱的继承人。当双亲过世后，你能兑现遗产了。此刻你肯定不希望那份多年来经过屡次升级的遗嘱合约要求你双亲用新的数据结构再进行一次签名吧！X.509数字证书是经过时间检验过了的一种数据结构。它的发明早于SSL，而目前依然服役状况良好。X.509是以一个ASN.1模块设计的，它天生具备持存性。今时今日区块链的数据对象也应该自豪地加上这个支持。在此篇幅有限，我们无法涵盖整个实现过程，但一句话总结，那就是持存性依赖于设计模式。举例来讲，一个设计良好的设计模式能实现数组数据到所要求二维矩阵的转换。那下一步呢
在TokenScript项目中，我们通过改造现有的标准来正确地处理数据。TokenScript本身就在OASIS的指导下实行了标准化。想要参与进来，你可以：TokenScript论坛参加GoogleHangoutMeet的设计会议每周四下午七点(下一次是在2019年11月28号)。如果你住在澳大利亚墨尔本附近，欢迎参加11月22号的见面会脚注?DER是密码工程学中编码数据的默认手段。举例来说，比特币签名以及X.509证书使用了这种编码。如果你想试验DER编码数据，你可以像下面这样使用openssl:
?同样的模式可以用一种被称作ASM.1的格式等价缩写:
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。