FCH商业应用框架思路（第一版）
-
FCH商业应用框架思路（第一版）
一、在FCH链上发布供求信息的意义。
1.供求信息与具体的商业服务应用解耦，客户发布的商业信息不会再被某一平台垄断。
2.客户不用重复到各中心化平台发布很多遍信息。
3.各中心化平台争抢利用公链上面的商业信息会形成竞争，利于提高对客户服务的质量。
4.公链成为商业信息的第一发布和存放地点，各商业主体利用公链上的商业信息形成具体的商业服务应用，这样就形成了一个二层的相互解耦的新经济模式，有利于提升公链乃至密码经济的整体价值。
二、公链商业应用构建和演进的初步思路
1.公链商业应用的构建应该协议优先，协议和具体实现要解耦。
2.第一层，要先提出在公链上发布商业供求信息协议的最简单版本，不求实用，但求验证，以后再逐步改进完善。
3.第二层，提出利用第一层链上信息构建商业应用的方案模型。
4.在构建好第一层和第二层商业应用的初步标准和协议后，对现有的在线钱包和区块链浏览器的代码加以改造利用，实现公链商业应用的最简单测试验证版本。
5.之后在实践中不断摸索改进。
三、构建在FCH链上发布商业供求信息的协议（假设是FEIP20V1）。
第一级：在op return字段，按照如下格式发布供求信息。
格式：
协议名|发布状态（0开1闭2更新）|供求方向（0求1供）|信息编号|供求品类别编号（需构建另一个协议来规定）|供求品型号|计价币种_单价|详情文档Json.txt的哈希值|Json.txt文档下载地址
例如：
FEIP20V1|0|0|A1234567|Ae7d8843|oppo_R11_Red|FCH_500.372|dhdjf62848465dj48445hdhdj……|http://pan.baidu.com?id=……第二级：在Json.txt文档中按如下格式发布供求信息剩余部分（画下划线的为必备字段）。
{
"Language":"zh_cn",
"信息有效期":"例如：202003251321_202003311321注：这个字段的效率与前面第一级内容中的“发布状态”字段相关联，当“发布状态”字段中的值为0或2时，本字段控制信息的实际有效期，当“发布状态”字段中的值为1时，不管这个字段的值为多少，整个供求信息直接失效关闭",
"商品名称":"……",
"商品详细参数":{……},
"联系方式":"……",
"交易方式":"例如直接联系交易、担保交易等……",
"信任担保人":[一个数组，可用CID、金融账户、支付宝账户、微信账户等来指定担保人],
"商品图片下载地址":"……",
"商品视频下载地址":"……",
"合同文档哈希值":"……",
"合同文档下载地址":"……",
……
……
……
}
四、利用链上供求信息构建商业服务
1.改造sign.cash或者密签等钱包，使用户能够方便地按照FEIP20V1协议格式在op return字段发布供求信息或者对某一交易的好差评信息（这个功能也需要搞一个协议），并通过交易发布出去。这部分的功能可以叫做“链上市场发布器”。
2.改造一个FCH区块浏览器，抓取显示op return字段中FEIP20V1协议发布的供求信息内容。这部分的功能可以叫做“链上市场浏览器”。
3.抓取的链上供求信息按照供求价格撮合交易样式来排序显示，效果有点儿类似交易所买卖挂单深度的界面。
4.同样单价的商品供求信息，有效期短的优先排序显示和匹配。
5.可以按照是否有共同信任担保人来匹配供求信息。
6.可以按照好差评情况来匹配供求信息。（注：至此，一个类似于58同城＋订单撮合的商业应用框架就能初步搭建起来。供求商品可以是实物、虚拟商品、算力、数字货币等，如果商品是数字货币就类似场外交易撮合平台了，配合各qq群、微信群等机器人转发，可以实现在公链上一处上链，信息即可穿透式发布到各场外OTC交易的qq群，微信群、微博等各种平台去。其收入来源可能有：一是可以将信息上链时的交易地址推荐为本服务方的地址，用这个地址来收取信息发布费，甚至可以尝试搞一点比较合理的竞价排名。如果出现多个服务方，这一收费模式会因为相互间的竞争而被淘汰掉。二是提供其他增值服务来收费，例如广告位收费、json.txt文档以及商品图片和视频存放服务收费，前提是用户愿意在你这里存放文档或图片等）
7.在此简单的测试案例的基础上不断演进。
CID：水雷_zzHe
-
很好的思路，建议：
- 按照FEIP1V1形成规范协议。https://bbs.cash/topic/142/
- 编号暂为“x”，成型后分配正常的编号
- 重点把数据结构和基本规则描述准确，数据结构要考虑op_return总空间为220字节。
- 状态0或1即可，习惯上0位关闭，1位开放，重新发布并且状态为1即为更新
- 做成石墨文档，邀请愿意协作的人一起修改
-
@水雷_zzHe 根据从第一层抓取到的供求信息类型不同，第二层显示和撮合可以做成各种相应类型功能和样式。比如从第一层抓取的是任务类的供求信息，那第二层就可能是威客网之类的样式和功能；如果从第一层抓取的是数字货币OTC供求信息，那第二层就可能是OTC交易撮合平台之类的样式和功能；如果从第一层抓取的是房屋租赁和家政类供求信息，那第二层就可能是58同城等广告列表平台之类的样式和功能；如果从第一层抓取的是算力租赁类供求信息，那第二层就可能是算力合约交易撮合平台之类的样式和功能；如果从第一层抓取的是实物商品供求信息，那第二层就可能是电商交易平台之类的样式和功能。总之，第一层的功能基本要保持简单和相对长期稳定，第二层要百花齐放，各显其能。这就是第一层和第二层解耦的好处。
-
@CY_vpAv 谢谢指导
-
@水雷_zzHe 对的，最底层的协议应该足够简单，适用于多种情况，二层再考虑实现更多含义
-
@CY_vpAv 手机上搞这个协议提案实在是太困难了，石墨文档昨天到今天用业余时间学习了一下，磕磕绊绊好像是发布上去了。已用石墨文档的协作邀请昌用老师，希望昌用老师能给予指导和帮助。