基于区块链的门票系统

基于区块链的安全活动门票

摘要

如今，音乐会门票是作为条形码打印在纸上的唯一标识符，并在入口闸门处进行扫描。虽然该系统对音乐会主办方来说方便且安全，但对票务所有者而言却存在风险和不便。
我们开发了一个原型系统，该系统将音乐会门票作为区块链上的资产进行管理。通过利用区块链的一致性特性，该系统可防止门票盗窃以及出售无效票、一票多卖等欺诈行为。
我们基于 Hyperledger Fabric V1 实现了该系统。我们开发了一个智能合约，用于在区块链上将票作为资产进行管理。我们还开发了一个运行在智能手机上的客户端应用，支持两个用户通过各自的手机无缝转让票，以及在入口闸门进行控制。

1 引言

如今，音乐会门票以及大多数其他活动的门票通常都是印刷在廉价的纸张上，顾客通常也可以选择自行在家打印门票。这些门票的不可伪造性并非通过物理手段保证，而是通过印在票面上的一个唯一标识符实现，通常以条形码的形式呈现。在入口闸门处，系统会扫描该代码，若此代码此前未被使用过，则允许该顾客进入。
尽管从音乐会主办方的角度来看，这种系统既方便又安全——只要妥善处理标识符，就不可能伪造门票——但对票务所有者而言却存在风险和不便。
“门票自拍照”发布到网上可能导致门票盗窃[6]：欺诈者可以从照片中提取条形码并复制该票。近年来，与重新打印门票或出售无效门票相关的欺诈已成为严重问题[1]。此外，转售多余的票缺乏安全途径，因为买家无法验证票上的条形码是否有效，特别是无法确认同一张票是否已被多次转售给其他多个买家。
解决此问题的一个标准方案是个性化门票并将门票与所有者姓名绑定[6]。然而，这种方法除了通过必要的身份验证使场馆入场检查变得复杂外，还严重 complicates 票的转售。我们在本研究中提出的问题是：我们能否利用区块链技术实现标准票的便利性，同时获得基于ID票证所具备的更高安全性？

场景设置

该场景中涉及三种不同类型的参与方。第一类是票务销售方，他们向客户销售并交付特定活动的票。第二类是顾客，他们可能希望相互之间转售票。第三类是活动组织者，他们负责查验票的有效性，并提供进入活动的权限。

区块链系统

区块链的概念因加密货币比特币而广为人知[8]。从概念上讲，区块链是一个区块列表，每个区块包含一系列（较短的）交易，并通过在区块区块中包含前一个区块的哈希值来链接。Chain 通过某种类型的哈希将区块 n−1 作为区块 n 的一部分进行扩展，具体取决于所考虑的区块链系统中的共识机制，因此整个区块链描述了一个交易序列。综上所述，区块链的核心思想是：只要满足共识的前提条件，它就能保证对交易序列的全局一致视图。共识机制
对于比特币，其共识机制基于一种特定类型的工作量证明，每笔交易允许先前交易的接收方将收到的价值分发给其他方。每个参与方都由一个（通常是临时的）加密身份来标识，完整的区块链会记录哪个身份拥有多少货币金额。
Our solution in a nutshell. 我们解决方案的核心思想是将音乐会门票的唯一标识符与当前所有者的加密身份一起存储在区块链上。每笔交易可以生成一张新票，或将票转让给新所有者，或在当前所有者决定使用该票进入活动场所时作废该票。所有操作都会改变该票在区块链上的状态。
我们开发了一种基于 Hyperledger Fabric 区块链的解决方案，利用数字签名保护所有交易，并允许用户通过智能手机上的客户端应用管理、出售和使用票。该解决方案在简单的 Blockchain 环境中实现，客户端应用运行在普通的智能手机上。

相关工作

自从比特币兴起之后，已经开发了多个新的区块链系统。虽然比特币仅限于作为加密货币的用途，但后来的系统（尤其是以太坊 [2]）支持通用的智能合约。我们在此工作中使用的区块链平台 Hyperledger Fabric [7], 也支持通用智能合约，但具有不同的信任假设。
其他用于管理资产的区块链系统已经发布，例如 Chain [3]。最近，一个商业票务交易平台被宣布推出 [4],，但我们未能找到有关该系统实际实现的任何细节，因此无法进行深入比较。

2 预备知识

算法可能是随机化的，除非另有说明。运行时间是最坏情况。如果 A 是一个算法，我们用 y ← A(x1 ,…; r) 表示运行 A
基于区块链的安全活动门票 439
使用随机硬币 r 对输入 x1,… 进行签名，并将输出赋值给 y。我们让 y←$A(x1,…) 表示随机选取 r，并令 y ← A(x1,…; r) 的结果。

数字签名

一个数字签名方案 DS 定义如下：一个概率密钥生成算法 DS.keygen，以安全参数为输入，生成一对（私有的）签名密钥 sk,pk 和（公有的）验证密钥 ←$，即 sk DS.keygen( pk)。第二，一个（可能是概率性的）签名算法 DS.sign，以私钥 sk 和消息 m 为输入，输出 s←$ DS.sign(sk, m)，即一个签名。第三，一个（确定性的）验证算法 DS.verify，以公钥 pk、消息 m 和签名 s 为输入，输出一个布尔值 b ←DS.verify(pk, m, s)。

Hyperledger Fabric

Hyperledger Fabric[7] 是一个具有模块化架构的许可区块链平台。特别是，其共识机制和身份提供者是可插拔的，可根据具体应用场景进行实例化。在 Fabric 中被称为链码的智能合约可以用常见的编程语言实现。
当前版本为 Fabric V1，也是我们在系统中使用的版本。
Fabric V1 的一个关键方面是将角色分离为 ordering service、对等节点和客户端。客户端通过生成交易提案并将其发送给对等节点以进行所谓的背书来调用交易。背书节点运行链码并在键值存储中管理链码状态。当接收到交易提案时，对等节点执行该交易，跟踪对键值存储的读取和写入访问，并对包含版本信息的读/写集（即交易对键值存储的影响）进行签名，以管理并发访问。这些背书，即已签名的读/写集，会被发送回客户端。
在收集到足够数量的背书后（这可以按链码进行管理），客户端将这些背书发送给 ordering service。该服务实现了其他区块链架构中已知的共识功能，其作用是接收已背书的交易，对它们进行排序，并创建包含交易序列的区块链。
排序服务拥有用于认证区块的签名密钥。
提交节点接收排序服务的输出，并将有效交易1的影响应用到本地键值存储。通常，背书节点同时也是提交节点，但一个对等节点也可以仅作为提交节点而不参与背书。交易的预排序执行确保了即使链码具有非确定性（例如访问系统状态），交易的影响仍能达成一致并保持一致性。
角色分离具有多个优势。首先，排序服务与链码的执行相分离；这使得实际的共识方法可插拔，并减少了共识节点的计算负担。其次，每个链码都可以拥有自己的一组执行它的对等节点。（不同链码的集合可能相交。）每链码背书策略能够适应每个应用的具体设置。第三，客户端
1 已背书的交易如果使用了过时的值，则可能无效。

3 设计

对于此原型，我们考虑一种简化场景，其中仅有一个售票方。（我们在第6节中描述了更通用的解决方案。）各方，包括售票方、顾客和主办方，均由数字签名密钥对进行标识。

系统结构和组件

售票方 s 拥有一个签名密钥对（sks,pks），用于将新票注册到区块链；此操作通过要求每个注册请求都使用密钥 sks 进行签名来保护。每位客户 c 拥有一个签名密钥对（skc,pkc），该密钥对用于将票转售给其他顾客以及在入口闸门出示票。每位音乐会主办方也拥有一个密钥对（sko,pko），用于在入口闸门使票失效。
系统的核心组件是在区块链上执行的链码，用于跟踪每张票的所有者和状态。该链码会配置售票方的公钥 pks。

链码

区块链上的每张票都是一个元组（id,pkc,pko, st, age），包含票务标识符 id ∈{0, 1}∗、持有该票的客户签名公钥 pkc{0, 1}∗、音乐会主办方签名公钥 pko ∈{0, 1}∗、票状态 st ∈{0, 1}（其中 st= 1 表示票为有效，st= 0 表示票已失效）以及票龄 age ∈ N。链码随后支持以下操作：

注册票证 ：输入票务标识符 id ∈{0, 1}∗、组织者公钥 pko ∈{0, 1}∗、所有者公钥 pkc ∈{0, 1}∗ 和签名 s ∈{0, 1}∗。如果没有票 id 且 DS.verify((enroll id, pko,pkc) s,pks) = 1，则存储元组 (id,pko,pkc,1,0)。

转售票 ：输入为票务标识符 id ∈{0, 1}∗、买方公钥 pkb ∈{0, 1}∗ 和签名 s ∈{0, 1}∗。如果存在票 id，其所有者密钥为 pkc 且状态为 st= 1，则检查数字签名方案 DS.verify((sell id,pkb, age) s,pkc)，若该验证通过，则将元组 (id,pko, pkc,1, age) 更改为 (id,pko,pkb,1, age+ 1)。存储票龄可防止当同一用户多次拥有同一张票时发生的重放攻击。

作废一张票 ：输入为票务标识符 id ∈{0, 1} ∗、所有者公钥 pkc 和签名 s。如果存在一张票 id，其所有者密钥为 pkc，组织者密钥为 pko，状态为 st= 1，则检查数字签名方案 DS.verify((invalidate id,pkc, age) s,pko)，若验证通过，则将元组 (id,pko,pkc,1, age) 更改为 (id,pko,pkc,1, age)。

Seller application

卖家应用允许在区块链上注册新票。输入票务标识符 id ∈{0, 1} ∗，组织者公钥 pko，
SecureEvent 票 on a 区块链 44 1
以及所有者公钥 pkc，卖家应用对注册请求 s←$DS.sign((enroll id,pko,pkc) sks) 进行签名，并将该请求和 s 发送到 Chain。

Client application

客户端应用支持两种基本功能：将票转售给其他客户，以及向组织者出示票以进行作废。
转售票时，所有者获取预期买家 pkb 的公钥 b（有关此步骤的实现，请参见第5节），对转售请求 s←$ DS.sign((sign id,pkb, age) skc) 进行数字签名，并将该请求连同 s 一起发送至区块链。
票务所有者向组织者出示票务标识符 id 和公钥 pkc 以作废票。为确保只有有效的票务所有者可以出示票，我们还要求使用所有者公钥 pkc 对票务标识符 id 进行签名 s。由于（在我们的实现中）此签名通过二维码传输，为防止 “自拍攻击”，我们在签名消息中 additionally 包含当前时间 t。

组织者应用

在入口闸门，组织者从客户端获取票务标识符 id、公钥 pkc 以及对票务标识符和当前时间的签名。他检查时间是否足够准确以及签名是否有效，创建签名 s←$ DS。sign((invalidate id,pkc, age) sko)，并将作废请求连同 s 发送到区块链。

4 安全讨论

所述系统的安全性基于两大支柱：区块链的一致性保证和数字签名的不可伪造性。简而言之，区块链的一致性保证每张票仅进行有效的状态转换：只有在不存在相同标识符的票时才能注册该票，只有当前所有者且票为有效时才能出售，只有声称的所有者拥有的票才能被作废。而数字签名的不可伪造性则确保发送到区块链的请求只能由相关方生成；只有票务销售方可以注册票，只有票的当前所有者可以出售票，只有指定的主办方可以作废票。
尽管完整的安全性分析超出了本短篇论文的范围，但某些方面应在下文进行更详细的讨论。

从发布的图像中窃取门票

防止从互联网上发布的图像复制门票的主要对策是，票在区块链上与用户身份绑定，并且在入口闸门出示票时，通过票状态上的数字签名来识别用户。然而，如果该签名仅包含静态数据，则仍容易受到同类型攻击。
因此，向组织者出示票的签名是基于一条包含当前时间的消息计算得出的。如果可以假设所有设备的时钟大致同步，则此方案效果良好——考虑到当今的智能手机通常从移动网络获取时间信息，这一假设似乎是合理的。（但似乎仍有意义允许组织者覆盖此检查。）如果自拍不是在音乐会开始前立即拍摄的，该方案可防止“自拍攻击”。
通过组织者与票务所有者之间的挑战‐响应认证方法可以实现更高的安全性。然而，由于该方法需要移动网络连接（可能不可用），或设备之间的临时无线连接（需要设备具备额外功能），或在相互进行二维码扫描时操作繁琐，因此我们在原型中选择了安全性较低的基于时间的方案。

“重复转售”票

纸质票允许转售者将同一张票的副本出售给不同的买家。由于我们的解决方案将所有者与每张票一起存储，并且区块链保证了交易的原子性，因此这种“重复转售”攻击是不可能的。

出售非有效或已失效的票证

对于当今的纸质票务系统，打印带有无效标识符的票证很容易，但在基于区块链的解决方案中情况并非如此，因为只有合法的票证才会被存储在账本上。此外，票证的作废也是区块链上的一笔交易。链码不允许转售已失效的票证，而区块链所保证的原子性确保了每张票的状态一致性。

未经用户同意进行作废

组织者应检查用户签名，但实际上，组织者可以在没有所有者同意的情况下生成作废消息（只要他知道 id 和 pkc，而这些都不是秘密信息）。在链码中不检查用户签名的原因是，音乐会主办方无论如何都可以（物理上）阻止票务所有者进入音乐会场馆——这并非区块链技术能够防止的“攻击”。失效请求的目的是将票的 st= 0 设置为无效，并防止将已作废的票转售给其他顾客。

使用区块链的必要性

从理论角度来看，所描述的应用并不需要区块链：对于每张特定的票，必须信任指定的组织者允许票务所有者进入活动场所。因此，也可以通过在组织者的控制下运行系统中的链码部分（而不是在区块链上），并让每个音乐会主办方运行其自身的系统实例来实现上述方案。
然而，从实际角度来看，使用区块链技术可以让音乐会主办方（其服务器也存在被攻破的风险）将应用程序外包给多个服务提供商而无需完全信任其中任何一方。此外，多个音乐会主办方共同运行此类系统似乎是合理的；这可以通过分散对其基础设施的信任来提高韧性（例如，抵御服务器被攻破的风险），并通过在单一应用程序中管理所有票来提升客户体验。

5 实现

我们使用 Hyperledger Fabric V1 作为区块链平台。为简化起见，测试平台采用“单节点排序器”（solo orderer），即由单一节点对交易进行排序；这可以轻松切换到其他共识方法，而不会影响系统的其余部分。数字签名采用椭圆曲线数字签名算法（ECDSA）与 secp256k1 曲线，因为该曲线受到所需平台的支持。

链码

该链码使用 Go 语言编写，采用标准的 Fabric 绑定以及提供的 LevelDB 键值存储。为了提高效率，我们以冗余方式存储数据；对于每张票，我们存储其当前状态，如第3节所述，而对于每个用户，我们存储其拥有的票的标识符列表。

客户端和组织者应用

由客户端和主办方使用的应用程序采用 Swift 语言编写，运行在 iOS 设备上。售票和检票步骤中的数据传输通过生成和扫描二维码实现。购票人 b 只需向售票方出示包含签名公钥 pkb 的二维码；售票方扫描该二维码并生成售出请求。如上所述，票务所有者 c 向音乐会主办方出示票时也通过二维码完成；在这种情况下，二维码包含公钥 pkc、票务标识符 id 以及 c 的签名。
通过 REST 代理实现对区块链的访问。客户端应用生成已签名请求，并将其发送到 REST 代理。随后，REST 代理作为区块链中的客户端，负责背书交易并将其提交至排序服务。请注意，这不会影响安全性，因为所有请求仍由客户端应用签名——只需信任 REST 代理的活性，其无法破坏一致性。

效率与可扩展性

客户端执行的所有操作都可以轻松地在普通智能手机上实现。每笔交易需要在相应的客户端设备上生成一个椭圆曲线数字签名算法签名，并在区块链上运行的链码中进行验证。在音乐会场馆每次验票也需在区块链上执行一笔交易。尽管对于当今拥有数千名参与者的大型场馆而言，这在非许可型区块链上似乎难以实现，但像 Fabric 这样的许可型系统显著更高的事务吞吐量预计足以满足需求。

6 下一步计划

我们考虑对原型进行几项修改，以更好地利用（并举例说明）Fabric 平台的灵活性。

使用成员服务对卖方进行身份验证

尽管通过客户端应用生成的签名密钥对顾客进行当前身份验证是合理的，但将链码与卖家公钥绑定会使方案缺乏灵活性。这一问题可通过使用 Fabric 成员服务并由成员服务向票务商发放证书来解决。随后，链码在注册请求中检查其是否来自认证供应商。

灵活背书

Fabric 背书机制可用于让每个音乐会主办方运行一个背书节点，以对各自场馆的票进行背书。从而确保票务商无法在未经相应组织者同意的情况下创建新票。

跨账本支付

当前原型不包含任何支付功能——票务转售的设计旨在方便交易用户在同一个地点时进行票的转让，支付可以通过现金完成。对跨账本交易的支持[5]可能实现原子票务交易。

分析、隐私与受限合约

当前系统的版本维护着一个交易图谱，其中个人用户是伪匿名的——类似于比特币——但其他信息是公开的。这使得可以对图谱进行“挖掘”。一个明显的扩展方向是采用隐私保护技术，以更好地保护隐私。当前无限转售的策略也可以加以限制，例如通过限制每张票的流转步骤数或每个身份的转售次数，从而遏制商业性转售。

7 结论

所展示的原型应用表明，区块链技术如何在不降低用户体验的情况下解决票务欺诈犯罪这一紧迫的现实问题。在点对点场景中，只需扫描接收方的智能手机上的二维码，即可轻松交易票务；场馆的入场控制也与当今系统一样，仅需扫描二维码即可完成。然而，与当今系统不同的是，区块链后端向顾客保证其获得的票证确实有效，且未被伪造或复制。