【老梁谈落地】开篇：数据交易落地以太坊业务流程

2018年对于区块链项目什么最重要，那一定是落地。只有真正落地了，才是真正有价值的区块链项目。

大家好，我是老梁，也可以叫我York，之前从事通信及互联网行业超过16年，负责的产品涉及VoIP网络电话、社交网络、博客BSP、分类信息、智能硬件等。曾任国内上市公司百姓网产品总监。目前担任 CarBlock 首席产品官，负责 CarBlock 整体的技术和产品，包括整个协议层设计以及交通数据交易市场在各个公链上的搭建。我从今年下半年开始参与到项目的落地产品设计开发中，我们这个项目第一阶段目标简单的说就是将车辆行驶数据上链，通过区块链及相关加密技术建立一个交易平台，实现数据的交易流通。

在做的过程中遇到过各种问题，接下来会花一些时间和大家分享在落地过程中遇到一些产品及技术经验教训，以及我们怎么看这些问题，怎么解决。希望这些能够对也在相同方向上努力的你有帮助。

好在我们在搭建产品之前，硅谷领先的车辆上门维修公司YourMechanic已经就获得用户车辆车载电瓶相关数据和我们达成合作意向。这样就算有了非常真实的需求和应用场景，不再是飘在空中。

不过通常理想是丰满的，现实是骨感的。在大规模推进前，通常都要先做一个PoC（Proof of Concept）来验证概念，看看现实到底有多骨感。后面会用“PoC”来作为代称，方便描述。

这次的PoC核心是在以太坊上建立并验证完整的数据上线到查询交易的完整过程，这里主要是车辆行驶数据，其实其他数据也类似。今天这篇主要看看业务流程的设计，关于技术、实现等后面会陆续聊到。好了，那么先看看我们目前设计的业务流程时序图。

为了方便从最上层最终用户层的角度来看这个流程，流程中的颗粒度并不完全一致。因为落地做应用，最终还是给用户使用，所以从最终用户的角度看简单可用，那才是真的可用。其中

1. End User是指最终产生数据的用户，也就是数据的原始所有者（大多数情况下是车主）。
2. Certify Partner是指提供数据采集设备的合作伙伴（比如硬件商、整车厂），End User通常直接面对的是这些Certify Partner。
3. Data Buyer就是各种数据需求方（比如车辆维修服务商、保险公司等）。

这个PoC整体流程还是比较简单的，主要分为两部分：数据上链部分和数据交易部分。

1. 数据上传部分是用户生成公私钥加密数据打包上传，这块后面准备单开一篇来讲。
2. 另一部分就是数据交易部分，这部分是基于以太坊用我们的数字货币交易数据资产的过程。

这里有个问题，在交易过程中买卖双方交易的是否过平台和Partner？

例如：Data Buyer在购买过程中先把CAR充值到平台，再由平台支付给Partner，再由Partner支付给End User。这种方式简单可控，但从我们做PoC的验证目标来说就不合适了。我们在做PoC的时候，有一个基本要求就是尽最大可能符合去中心化的指导原则，从而充分暴露问题。因此，在业务流程上，交易过程中Data Buyer直接通过Smart Contract支付给End User，中间不再受到平台和Partner的制约。当然，这也会引出来后面在以太坊上落地实现时的一个体验上的大坑，在我看来虽然技术上能跑通，但真正使用上几乎是不能接受的，后面会细讲。

从业务流程的角度来看还是比较简单，这里先开个头，后面会就产品、技术细节展开。

我们也是在摸索中前进，肯定还有考虑不周的地方，如果大家有任何疑问、评价，甚至质疑，或者对我们整个业务流程有不同的意见和建议，都希望你能够留言评论。我个人坚信任何不同意见都是从不同角度帮你完善你的认知，是推动你进步的最好动力。

第二篇会详细谈一下基于我们业务流程的用户体验考虑，毕竟区块链大规模应用最终依靠的开始普通用户，而我本人又是产品专业，会和大家详细说说我们如何平衡以太坊开发限制和满足用户体验上做的努力。