用于物联网驱动的加密币服务接口设计

目前，加密币与物联网各是一个系统，两者并没有直接的逻辑关系。物联网里的支付结算要如何衔接到加密币系统上去呢？

一种可能的方式是在物联网里整合加密币技术，建立一套专用的物联网数字支付系统（尚无现成的案例）。这需要大量的投入，包括研发的资金和人力。这种方式对于开放的社区基本行不通。

这里我们提出一种简单的方案：在现有的加密币系统里加入一个机制——「交易监听和回调」。

例如当外部物联网需要探测用户（或其它设备）发送的付款情况时，可以用「收款地址」、「最小金额」和一个「外部命令」在加密币的客户端（服务器）上进行登记注册。一旦客户端检测到目标地址上收到付款，即执行已经登记的外部命令，从而实现加密币系统与外部世界的联动。这有点类似于浏览器中JavaScript响应用户行为的工作方式——事件驱动模型。

或许我们可以认为这是一种“交易驱动”的工作模型。在这里，加密币系统更像是一个“引擎”，而非一个“平台”。当然，这个机制其实只存在于客户端中，由客户端独立提供交易的监听回调服务，对核心协议没有任何影响。所以这也不影响核心系统向平台化方向发展。

我们以Peercoin加密币为例，进行简单的设计探讨。

基本设计

登记与注销（命令）：

付款监听（pay listen）

ppcoind attach-payout   "command"    //登记 ppcoind detach-payout     //注销

收款监听（receive listen）

ppcoind attach-receivables   "command"    //登记 ppcoind detach-receivables     //注销

说明：

min-amount指定监听的最小值（包括该值），这样可以略过不必要的细小支付； 指定的值包含单位字符，p->PPC，m->mPPC，u（U小写）->µPPC，无单位字符默认为PPC； 监听地址是任意的，与当前客户端钱包内的地址无关；

示例：

//如果监听地址收到大于等于10PPC的付款，调用外部命令"door-on" ppcoind attach-receivables PKgs4ERqhwB6jvHvNUTvzFZXPtHMK8eoCr 10.0 "door-on" //如果监听到地址对外支付大于等于100mPPC（0.1PPC）付款，调用外部命令"watch-done" ppcoind attach-payout PKgs4ERqhwB6jvHvNUTvzFZXPtHMK8eoCr 100m "watch-done" //如果监听到地址对外有任何付款行为，调用外部命令"report" ppcoind attach-payout PKgs4ERqhwB6jvHvNUTvzFZXPtHMK8eoCr 0 "report" //注销对该地址的收款监听 ppcoind detach-receivables PKgs4ERqhwB6jvHvNUTvzFZXPtHMK8eoCr

监听的各个阶段：

检测到交易； 检测到交易10秒后未收到双花警告；(注：10秒为可配置值) 1个确认完成； 第n个确认完成；（可配置，如6,120等） 延时交易的到期确认； 其它……

外部命令接收参数（JSON）：

付款（payout）

{    "type":         "out",          // 类型-付出    "network":      "peercoin",     // 网络    "original":     ,      // 付款地址（即注册地址）    "txid":         ,  // 交易ID    "to": [        {            "address":  ,   // 目标地址            "amount":       // 发送金额        }    ],    "total":        ,       // 当前地址发送的总金额    "confirmed":    ,      // 确认次数（-1表示刚刚发现，0表示10秒内没有发现冲突的支付——双花警告）    "balance":      ,       // 当前地址余额    "message":              // 交易中的40字节数据 }

收款（receivables）

{    "type":         "in",           // 类型-收入    "network":      "peercoin",    "original":     ,      // 收款地址（即注册地址）    "txid":         ,    "from": [        {            "address":  ,   // 来源地址            "amount":       // 接收金额        }    ],    "total":        ,       // 当前地址收到的总金额    "confirmed":    ,    "balance":      ,       // 当前地址余额（未确认时余额不包含total）    "message":       }

注：外部命令接收JSON格式的字符串参数，解析获取数据、执行自身逻辑。

应用场景

自动售货机：

用户点击售货机屏幕上的商品名称，屏幕显示一个二维码，用户用手机扫描，支付某零售币； 售货机控制单元（树莓派）检测到付款交易，触发预先登记的操作命令，传递必要的信息（message：机器和商品编号）； 操作命令解析传递过来的信息，合法，启动售货机出货控制；

开放式寄住（有保安）：

小梦出差，深夜来到某一城镇，四邻安睡。

发现一家开放式旅社，来到空闲居室门口，按门锁开启按钮； 门边显示屏上出现一个价格说明和支付二维码，价格公道。小梦掏出手机扫描二维码支付； 门锁控制单元检测到付款交易，触发预先登记的门锁控制程序，传递必要的信息； 控制程序解析传递过来的信息，合格，开门。小梦终于可以享受一下睡觉觉了；

房屋产权证明：

2020年的某天，多多想投资干点事但没钱，手头有几套房产准备卖一套，倩倩正准备安家想买房子。于是他们见面了……

因为成本的原因，2020年的Peercoin网络已经十分强大（数十万节点遍布全球），PPC被用于实施各种「证明」，拥有公认的信用权威。

购房流程如下：

倩倩和多多来到房产管理中心，登记了付款和收款的NuBits地址、联系手机号； 几天后，倩倩将协商的20万房款（NBT）打到了多多的NuBits账户上； 负责房产转移登记的nu客户端检测到这笔交易，经过120个确认后，该nu客户端触发了预先注册的处理程序houseAdm； houseAdm从倩倩支付给多多的NBT交易中取得了倩倩的身份ID和多多的房产ID，然后构造了一份新的房产所有权证明（数字式）； 倩倩为房产新主人的证明被houseAdm嵌入在一笔PPC交易中，发送到了经久不衰的Peercoin网络； 倩倩和多多在houseAdm处登记有手机号。当Peercoin网络完成了这笔交易的6个确认后，houseAdm登记在Peercoin客户端上的监听被触发，然后houseAdm短信通知了他们；

注：houseAdm在两个网络上都注册了监听；倩倩和多多也可以自己去Peercoin网络查询结果。

优点：

这种机制将加密币和外部系统分离开来，使得可以很容易将支付运用在任何系统之上； 这种分离带来的解耦，也使得任何加密币都可以应用到同一个系统上，两者是自由的“多对多”关系；

需要注意的问题

在前面的3个应用场景中，前2个场景对付款响应有较高的实时性要求。一般的，我们希望在对自动售货机付款之后能立即拿到东西，支付了住宿费用后，门很快的就打开了~~所以，加密币支付响应的即时性很重要。

在区块链的世界里，没有得到正式确认（至少1个区块完成）的交易被称为0确认交易。为了实时性，我们只能接受这种没有确认的交易，但这种做法可能会遭遇双花攻击。在Bitcoin的设计中，如果节点检测到一笔双花的交易，会广播一个警告。基于P2P数据传播的原理，我们需要一个简短的延时，如5-10秒，以等待可能存在的那个警告（双花可在地球的另一端发起）。

如果对实时性要求更高（如3秒以内），或许采用中心化的局部子系统更好——它们有可靠的无理连接和高速带宽，并且遭受攻击的可能性更低。

题外话

目前对于类Bitcoin的加密币应用，大多数趋向于一种“平台”思维——即把区块链作为一个承载交互数据的工具。这使得区块链更像是一个仓库。P2P网络用于存储会产生大量的数据冗余，这在效率和成本上似乎划不来。

换一种角度，天生具有信用特质的区块链是否可以让它继续保持精简？我们只把它当做一个驱动信用的“引擎”，由外部通过接口进行衔接，并依然由外部系统自身行使其功能。在这里，外部系统仅需要“略作调整”，改变它们的某一部分驱动来源——由区块链负责的那些~~

期待您的思考……