IOTA极客马拉松: 欺诈检测 (第一部分)

IOTA极客马拉松于11月17日至11月19日在波兰格但斯克举行。来自欧洲各地的软件开发人员联合起来共用测试IOTA平台的各种案例。该活动由IOTA、 Baltic Data Sc ience (区块链和大数据服务商)、 Datarella (区块链和大数据咨询公司)和 Bright Inventions (移动应用开发商)联合赞助。四组开发人员和软件专家围绕不同的应用案例，竞逐4200MIOTA的奖金。

本文描述的案例来自“Freedom Pass”项目团队，由来自 Datarella 的 Kira Nezu 执教。案例中技术方面的内容可以在这里找到 IOTA Hackathon – Lessons Learned: Fraud Detection (Part 2) “（作者：团队成员Jonatan Bergqvist）。该队在比赛中获得第二名。

1.  任务

Bogdan Vacusta加入了这一团队，他将一项现实生活的中的挑战从伦敦市政厅带到了IOTA极客马拉松。伦敦市政厅提出“Freedom Passes”项目，该项目打算让残疾居民免费使用城市公共交通，但是在得到免费通行证之前，必须获得医生出具的证明。

不幸的是，骗子们成功的为伦敦居民PS出了完美的医生证明。没有人确切知道究竟有多少免费通行证是通过欺诈获得的，但很可能是数以千计的。伦敦市政厅没有任何程序来核实证书是否伪造。目前仅有一个简单的警示，当一个医生出具的证书数量异常之多，则是一项成功检测欺诈行为的重要因素。

在IOTA的帮助下，如果能检测到欺诈行为，那么每年可为公众节约数千万英镑的成本损失。该团队的任务就是建立一个防止欺诈的概念模型，那么，IOTA如何用于欺诈检测呢？

2.  解决方案

该团队决定在医生与申请人之间创建一项事务，用以在缠结网络上证明申请人的残疾状况属实。如果一名医生出具的证书数量出现异常，该系统就会向伦敦市政厅发出警报。

在理想化的场景下，医生会从应用程序(移动端或网页端)发布数字证书，用她的私钥签署事务(该措施有助于防止欺诈)。考虑到IOTA极客马拉松的短时间框架(不到24小时)，团队选择创建样本数据并在医生部分执行事务以验证此概念。本地数据库将提供医生和申请人的详细信息，以确定他们的身份。因此，此验证概念的系统包括以下组件：

1. 医生和申请人的输入数据表

2. IOTA缠结的交互界面

3. 具有医生和申请人数据的数据库

4. 分析数据的后台

5. 带有警示清单的伦敦市政厅前台。

3.  流程

（1）输入数据

医生和申请人的数据是通过一个基于web的用户界面输入的(团队实际上是通过编写一个JavaScript来填充数据库，该方法直接将虚假数据写入数据库中，所以这个UI从功能上来说，并不是验证概念所必须的)。你可以在第2部分学到更多关于这个的知识（ part 2 ）:

（2） 认证

数据会被写入本地数据库。同时，从医生到申请人的一项象征着残疾证明的事务，以不可修改的方式写在IOTA Tangle上。事务ID依次向本地数据库写入，添加证明已经认证事务的能力。

（3）分析与报告

后台对数据进行分析，并在异常情况下发出警示。例如，当一名医生在一定时限内发出了异常多的证书时。

我们学到什么

我们在时间限制内完成了目标，尽管在这个不成熟的系统运行中，遇到了一些问题。 最后，我们依然设法建立完美适用于IOTA极客马拉松设定下的验证概念。

我们确实遇到了一些问题，这些问题必须由IOTA团队解决，用以改进系统，并使其适合于未来的实例：

事务处理速度，在IOTA测试网络上在确认事务时，我们经历了多次长时间的等待。提交事务确认大约1分钟，读取事务大约耗时3~5分钟，而且这还取决于数据量。不过，这可能只是测试网络独立于主网络的独有问题。

文档库不是最新的，出现有丢失信息的情况，而且现有的文档库有时候会产生误导（例如：属性标记被认为是可选项，但实际是必须项，用重放事务功能创建完全新的事务的效果并不明显，事务发送方发送的消息没有记录在缠结上等等）

发布没有经过预先计划，如果更新出现在项目开发期间，那么开发人员必须快速适应新变化，所以，IOTA的发布路线图将非常有帮助。

Node.js SDK是基于“Callbacks”(老技术标准)，而非“promises”(当前技术标准)。

API很容易被误用。不应该通过的值和属性可以在没有任何错误消息的情况下运行。该API缺少错误消息的描述，在寻找bug时让开发人员陷入困境。