星球日报
搜索
手机客户端
iPhone · Android
微信公众号
微信公众号

iPhone · Android

微信公众号

应该如何处理上链数据?

2019-12-23 11:05:00

dapp 数据方案设计。

编者按:本文来自以太坊爱好者(ID:ethfans),作者:Weiwu Zhang,翻译 & 校对:安仔 C1int & 阿剑,Odaily星球日报经授权转载。

在 TokenScript 项目中,我们只会将靠得住(几十年来在密码工程学领域广泛应用且成果累累)的技术手段应用到公链上。

但糟糕的是,人们对区块链数据空间的使用往往并不切合区块链的设计目标。人们总在抱怨以太坊 “大塞车” ,同时又编写一些收发聊天信息的智能合约。不过在区块链上传播 “crypto 街头涂鸦” 还不是最大的问题。

我们认为,最大的问题在于没有站在互操作性、可拓展性以及持存性的角度设计数据结构。

换句话说,在各个独立的 Token 项目中,数据结构都随用例量身定制,难以和非区块链系统(Web/IoT)联动,在别的去中心化项目中使用时也容易出错,并且但凡需要改动,就得从头设计整个数据结构。

数据对象举例

我们先来从这个例子出发,然后再进行归纳推理。

假设某个活动的门票是数据对象,并以 JSON 编码:

应该如何处理上链数据?

1.这是主办方发行的第 24 张门票。

2.这张门票的级别为 “class 2”(类似于 VIP 席位的门票)

3.这个活动在 2020 年 1 月 1 号 20:00 开始。

上述数据对象可以在区块链交易中使用。假设我们有一个以太坊智能合约来转移门票的归属权:

应该如何处理上链数据?

然而将数据编码成 JSON 格式会消耗大量的 gas ,因为这会增大交易体积并增加智能合约解析的负担。由于需要紧凑地打包数据对象,我们必须首先把数据从它的模式中分离。

数据(data)和模式(schema)的分离

我们把数据编码成了 20 个字节:0x3012020118020102180A32303230303130313230。

可以看到这 20 个字节包含了 3 条消息:

应该如何处理上链数据?

其中票号 24 被编码成了 0x18;票务级别 "VIP" 被编码成了 0x02;日期信息被编码成了 ASCII 字符串。这三条信息之间的结构数据是使用标准 DER 编码规则后产生的结果 †。

对数据的模式,我们用 ASN.X 语言描述(一种 schema 语言)。

应该如何处理上链数据?

数据模式需要存储在智能合约之外。在我们的 TokenScript 项目中,数据模式直接由 TokenScript 存储,因此,兼容 TokenScript 的钱包和 dapp 浏览器能直接使用对应的数据模式来解析 20 字节的数据。你也可以用别的格式把数据模式存在应用程序中 ‡ ,但你不应该直接把它存到智能合约里,至少,你可以把数据模式编译成一块简洁的 solidity 字节码以方便智能合约解析那 20 字节的数据。

模式的使用

一旦我们能把数据和模式分离,以太坊上的智能合约函数就能变成这样:

应该如何处理上链数据?

可以看到现在门票对象从字符串类型变成了字节类型。让我们通过函数声明前后的几行代码来进一步分析:

应该如何处理上链数据?

parse_ticket 函数包含了由模式语言编译得来的代码。这要比 JSON 解析器的效率高出不少。

另一方面, dapp 是否需要构建 DER 编码后的字节数据供交易调用,用户端钱包是否需要可读化呈现一个已经构建好了的交易,都应取决于数据模式。

为什么要模糊化?

所以 DER 或者 ASN 模糊化处理和以下直接了当、对新手友好的方法比,有什么好处呢?

应该如何处理上链数据?

或者跟这个更结构化一点的版本相比又如何?

应该如何处理上链数据?

难道模糊化仅仅是为了减少交易大小吗?

上述问题的答案都是 “是的”,并且这个“对” 的程度超出你的想象。首先,经过 DER 或 ASN 处理后能把交易负荷减少 50% 以上,其次还有很多别的优势:

理由 1:用于制作签名证明

一串经 DER 编码的字节数据非常便于签名。不过,我们为什么需要签名呢?

签名是为了得到认证(attestation)。我们之所以把被签名过的数据对象称作 “认证”,因为它确实代表着签名者对某些事情的认可。

我们依然以上面的门票为例。一开始,你可能会认为门票合约控制了所有票务和归属权信息。比方说,当 “Alice” 想要把一张票转给 “Bob” 时, Alice 会发起一笔交易,将门票的所属权重新指认为 Bob 。

活动主办方往往会为一场活动发行数以万计的门票,或者少说也有几千张,其中绝大部分收到门票的用户并不会把门票转给别人。要不是有这种票券转让的需要,门票根本就不需要放到区块链上。活动主办方完全可以签署一份 attestation,将门票的所属权签署给特定的以太坊账户。账户私钥的持有者则可以通过一个 质询-应答 式的合约来证明门票的所有权。

另一方面,如果数据用 JSON 格式编码,它就无法被安全地签名,因为 JSON 并不是一种确定性的编码方式。

见证的用途非常广泛。以下列举几个例子。

  • 你可以编写智能合约,使得被认证为合格投资人的用户能参与 ICO 预售。

  • 汽车保险公司能证明你的车(用一个以太坊 token 实现)已经上了保险。

  • 如果你的车是个智能载具,你完全可以在不进行任何以太坊交易的前提下,利用认证消息把车借给你的朋友。

签名认证的设计模式只应根据现有的标准进行改造,而不是重新发明一种崭新的模式(这样会重新引起很多已被解决了的安全隐患)。TokenScript 已经在研究这样的改造方案,但革命尚未成功,同志仍需努力。比方说,我们目前需要用默克尔树,甚至零知识证明来实现一种可以做部分见证(partial attestation)的格式。

理由 2:数据互操作性

经过 DER 编码过后的数据有更好的互操作性。依然是以票务证明为例:哪些系统需要用到认证信息?我们目前知道以下几个。

1.智能合约:如果 Alice 想要出售她的门票(以认证消息的形式),智能合约需要具备查验活动主办方签名的能力。

2.钱包:用户钱包必须能正确显示认证消息的内容。每当有交易涉及到认证消息时,钱包都需要提醒用户交易的实际内容。(Dapp 浏览器也有这种需求)

不止上述两个端口。活动主办方的网站也需要具备读取见证消息的能力,因为门票持有者可能会利用见证消息来登录网站,获取活动的最新消息。检票员(或者更现代一些,自动门)也需要能读取这个数据(呈现方式可能是个二维码)。

使馆和边境警察也会用到这些证明。去年一整年,刻画成了认证消息形式的 FIFA 门票(称作 Fan ID)取代了 VISA ,被大规模应用到了俄罗斯边境过境的场景中。

不难看出很多系统都需要用到见证消息,而这些系统往往都是异构的。比方说,智能合约属于区块链,而钱包属于移动应用程序。在活动主办方的网站中,JSON 的表现方式是标准。而出入口的自动门作为一个物联网设备,通常认二维码。由于系统由可验证签名支撑,它不能随意转换——在这种场景下,签名过的数据必须有一种统一的呈现形式。

如果数据模式发生改变(比方说我们加入了一种 “VVIP” 等级的新门票),我们没有理由要求所有的去中心化系统一起升级。然而如果数据基于模式驱动(schema-driven),可以很轻易地对整个模式发起更新。

你可能会觉得自己的 token 不会被用到那么多其它系统上。但事实上谁也说不准。像以太坊这样去中心化平台的优势在于搭积木。许多系统不需要 MakerDAO 授权就使用了 DAI 。你可没法在美国运通这种传统中心化系统上看到那样的创造性活动。

理由 3:持存性

持存性(Extensibility)和互操作性紧密相关。要时刻牢记一旦数据被签名,如果没有把原有的签名无效化处理,它是没法被“转换”到一个新的系统中使用的。因此,所构建的系统必须同时理解旧的以及新的数据格式(即使那些格式慢慢都废弃了)。

假设你是一份用 crypto attestation 写就的遗嘱的继承人。当双亲过世后,你能兑现遗产了。此刻你肯定不希望那份多年来经过屡次升级的遗嘱合约要求你(仙逝了的)双亲用新的数据结构再进行一次签名吧!

X.509 数字证书是经过时间检验过了的一种数据结构。它的发明早于 SSL ,而目前依然服役状况良好。X.509 是以一个 ASN.1 模块设计的,它天生具备持存性。

今时今日区块链的数据对象也应该自豪地加上这个支持。

在此篇幅有限,我们无法涵盖整个实现过程,但一句话总结,那就是持存性依赖于设计模式。举例来讲,一个设计良好的设计模式能实现数组数据到所要求二维矩阵的转换。

那下一步呢

在 TokenScript 项目中,我们通过改造现有的标准来正确地处理数据。TokenScript 本身就在 OASIS (Open Document ISO 标准背后的标准化组织)的指导下实行了标准化。想要参与进来,你可以:

  • TokenScript 论坛

  • 参加 Google Hangout Meet 的设计会议 每周四下午七点 (下一次是在 2019 年 11 月 28号)。

  • 如果你住在澳大利亚墨尔本附近,欢迎参加 11 月 22 号的见面会

脚注

† DER 是密码工程学中编码数据的默认手段。举例来说,比特币签名以及 X.509 证书使用了这种编码。如果你想试验 DER 编码数据,你可以像下面这样使用 openssl :

应该如何处理上链数据?

‡ 同样的模式可以用一种被称作 ASM.1 的格式等价缩写:

应该如何处理上链数据?

本文来自投稿,不代表Odaily立场。如若转载请注明出处。

Odaily星球日报提醒,请广大读者树立正确的货币观念和投资理念,理性看待区块链,切实提高风险意识;对发现的违法犯罪线索,可积极向有关部门举报反映。

参与讨论

登录后参与讨论

以太坊爱好者

特邀作者

以太坊爱好者

这个作者有点忙,还没写简介

总文章数: 63


分享至

微信扫一扫分享

0