再析Blockchain在航司FFP等相关方面的应用 （1）

近日跟FFP的领导交流了很长时间，出乎我的意料，感觉也很深入。将之前的一些发表的思路汇总一下。

确实，各类消息，想法，思路，联盟，发币等等的铺天盖地的信息，往往让作为传统业务的常旅客业务专家，很难明确新的技术，例如Blockchain，会对自身的业务，管理，服务，产品及应用有多大的价值，同时价值产生在哪里，哪些是其管辖范围下的敲门砖或突破口。

首先Blockchain是一个技术层面的总称，包含网络通讯，包含加密算法，更包含存储等等。但其也是一个意识形态或一个潮流概括。就好比互联网，没人说其是个工具或某一项技术，因为其是大量技术的融合及应用投产，并带来了权限的交易模式。

其次Blockchain最关键的“公允的对等交易模式”，所以对于大量传统业务，行业，或者尤其有监管及审核的B端行为，从字面意思上确实有不同的概念和价值，但是正因为这样，其所产生的冲击，任何Blockchain从业人员需要考虑清楚，是否这样的B端行为，你是否有足够能量改观或冲击。或者在哪里投放，如何投放一定要全局梳理清楚，并不是B端不能涉足或受益于Blockchain，关键是需要“皆大欢喜”的过程和结果。

拿个例子来阐述一下我对Blockchain应用到FFP的理解，也分析一下一些销售所倡导的优势：

1) 应用Blockchain，可以实现实时兑换和账单提交：作为上链的航司FFP，可以在常旅客会员在合作伙伴上消费后，立刻可以实现兑换划扣和本地账单入账。

a) 貌似很有道理，但是现在那个航司的FFP没有实时兑换的服务接口？？？

b) 为什么必须上链，才能实现实时兑换？？？

c) 即使上链，是否航司FFP就能得到更全面的账单信息？？？航司FFP的兑换事件和数据存储，往往纠结一个问题，如何构建和扩展自身的数据结构和存储，可以存储更多更全面的合作伙伴订单信息。但是试想，我作为航司FFP，存储这些内容有没有价值，未来如何使用。FFP会员去个连锁超市购买一篮子商品，8个红苹果，3瓶水.....，航司FFP要记录这么细节的东西吗？难道航司FFP的客户会使用苹果，购买个数去搜索查询吗？

d) 上链后的航司FFP，是否支持C端的快速累积兑换的实时要求？？？区块链的选型和构建，极大影响其性能，更关键的是其不一定支持实时数据交易。封闭的联盟链或私有链，也许性能okay，但是也阻断了更广更多合作伙伴的加入。

e) 虽然航司FFP已经有了实时的Web服务接口，为什么航司和合作伙伴没有很多实时累积兑换的应用场景？？？正因为产生实时交易的是合作伙伴的平台，他的订单系统，结算系统，或者平台没有具备改造和应用实时接口的能力，或者其本身就不愿意做这个事情。那航司FFP上链之后，势必也需要合作伙伴也要IT开发，实现对链的使用和数字账单提交。所以这个是IT的事情，不是说上链跟大家签一个合同，达成个Agreement就能High跑了。

f) 航司FFP期望收集更多交易的Profile，而不是像上面哪些红苹果的个数。例如交易地点，时间，场景，购买行为等等，其实最终需要这些数据进行交易分析，通过分析和FFP的子计划等能力，打包或开发针对性的促销活动，让FFP会员在合作伙伴平台上更多的使用FFP虚拟货币消费，并且提升他“挖取”FFP虚拟货币的潜意识，即多乘坐本航司的航班。但是试想，这些交易Profile数据，不是上了链就会有的。是建设链和契约化链条的时候约定的，也就是电子数据账单的结构定义，就好比数据库Table的定义。即使你定义成这样，是否合作伙伴，或者上链的同仁们就按照这个提交数据？未必吧？我能或我愿意跟什么数据我说了算。更关键的是这些电子数字契约是不是能够满足更多样性的数据表述需求？就好比各位航司同仁熟悉的NDC和ONE Order，大量精力不都在投入到如何将纷繁复杂的订单数据，电子交换数据进行各类“Mapping”嘛？好不容易有个放诸四海而皆准的NDC Schema了，结果又来一个Blockchain的电子数字账单，那谁来定义Schema，哪些数据应该在Schema里面，我怎么定义一个放诸四海而皆准的Schema，肯定航司或个别合作伙伴之间主导和设计是实现不了的。

2) 上链的航司FFP与合作伙伴，将没有清账结算的工作。

a) 确实其仿效的概念是原始社会公共市场上的交易。但是因为那个时候“原始人”们没有记账的数字化能力。我们还是原始人吗？？？

b) 但是现在虽然清账很繁琐，但是都是IT的体力活。我感觉我是全中国最有权威发表此方面意见的人。没有一个人彻底从头到尾做过航司FFP与合作伙伴的清账工作。从SLA，到规则指定，到账单格式，日累积日兑换，日累积日兑换反馈，月度结算账单等等。我真没感觉有多复杂，只不过Spring Batch小半天就能完成的一个编码任务。即使有1000个合作伙伴，每个的文件交互Schema不同，我也就放大后才1000人天吧，成本多低，自己做私活，小几十万，甚至10多万我都干。如果上链，为了上链所投入的成本不仅仅1000人天或10多万搞定吧？少说需要几百万。

c) 航司FFP与合作伙伴没有清算工作了，但是航司FFP还是要给内部财务结算或清算部门进行结算吧。否则人家怎么把消费里程所对应的实际货币转账给合作伙伴，不是航司FFP说今天给某某银行400万，结算部门就转账400W，他也要核算的，也要清算的，要走流程，要签字的。

d) 即使航司FFP内部减少了清算核算，但是估计没有那个航司FFP领导“大条”到这样的程度，不安排专职时不时的扫描和检查一下账本数据吧。

故，终究还是有审核清算的。不是完全没有。

3) 数据的可靠性，账本的可靠性。

a) 上链的航司FFP会开心的说：”这样妈妈就不怕我再丢失数据或数据库损害丢失东西啦“。

b) 确实是这样，上链后，一份累积兑换的账单会有多个副本存放在合作伙伴之间。但是航司FFP不仅仅是C端的累积兑换记录吧，还有大量里程账户，规则，信息的数据，这些是不会上链的，还是要航司FFP自己保存。要是系统坏了，数据都了，还是丢了。

c) 同时哪个航司FFP或合作伙伴的数据库或应用系统没有备份，不都是Oracle的RAC吗，不都有备份，归档，运维规则吗。甚至还有双活数据中心，异地双活数据中心。任何关键数据的损毁或丢失，其实即使上链也会很麻烦。试想航司FFP数据损毁和丢失，怎么从上链的账单副本中恢复回来，怎么用数据重新构建里程账户，交易信息？？？不是简单的copy/paste吧？