过程

比赛背景见 https://www.tuoniaox.com/news/p-327352.html 。 打算从几个角度来讲下这个比赛过程。

关于团队

我们公司3人（我、洪敏、天宇）参加比赛，都是开发背景。 主办方根据协调，一位来自台湾的社交方向创业者参加进来，英语演讲不错，技术会一点，有过hackathon经验。 比赛当天晚些时候，又有一位金融领域的伙伴加入进来，报名晚了，当时还没分配到队伍。 本来还有一位以太坊开发背景的参加，但是比赛当天还在加班。 最终是一支5人小组。

产品设计

团队主体是我们公司三人，花了比较多的时间在选题和创意设计。有想过比如聊天工具、抽奖工具，感觉都一般。我们的眼界还是比较狭窄。

主办方提供了多个topic，我们选了这个方向——了解客户（KYC）规则 Know-your-customer。因为这块涉及到用户身份，感觉能套在很多场景。

1. 比赛前一天（周五）定了一个政府中心化KYC数据库的方案，区块链用于授权与审计用。
2. 比赛当天清晨，改为去中心化的KYC方案，只有企业和用户，IPFS作为去中心化的存储，数据安全由公钥加密保证。区块链同样是用于授权、审计，和存储文件HASH。
3. 主办方宣讲完毕，与其他组员REVIEW，一致用去中心化的方案，更贴比赛。这个作为我们的基础模型。
4. 从B2C扩展到B2B，比如银行怎么Know一家向他借钱的酒店或是房屋租赁公司。引入IoT、智能设备采集真实入住率。通过合约，智能设备与C端用户交互，保证真实性。这里，区块链用于一份难以篡改的数据库，可以看出酒店的经营事件。
5. 分工：我们公司3人开发，他们2人准备演示材料。

技术实现

我们没有实际的以太坊开发经验。所以，趟了很多坑，绕了很多弯路。低估了技术复杂度。按时间线：

1. 当天下午，分析技术提供方提供的SDK（Go），是scryinfo的两个合约封装，一个是数据交换，一个是token交换。没法涵盖我们的设计场景，必须写自己的智能合约。
2. 智能合约开发很顺利，使用remix+metaMask这个组合。
3. 开始翻车之旅。
4. 前端使用web3无法调用合约，还有web3js的版本问题、下载问题。
5. 使用infura.io提供的免费的以太坊节点服务，发现有些方法没有开放。
6. 连入主办方提供的以太坊节点，面对跨域（可解决）、还有一些新问题。
7. 尝试同步一个以太坊测试节点，一个节点需要100G空间，时间和空间都没法满足。
8. 翻阅SDK源码，尝试套用SDK中使用Go来包装智能合约调用的方式来调用我们的合约。执行合约方法进入无限等待。找SDK提供者一起review代码，也是无解。本以为翻车到此为止，能360度翻回正常轨道。
9. 最后又想起创建一个私有链。但时间上不允许了。
10. 紧急魔改代码，用于作品演示。
11. UI设计因为时间问题，比较粗暴。
12. 第二天下午2点前，提交了代码。

技术上最大的问题，是应用无法调用合约。很多东西都是现学。 为此，我们几位就睡了几个小时。少壮不努力，老大徒伤悲。留下没有技术的泪水。

展示

因为评委主要是日本人，演讲全程需要英文。 台湾小伙上，讲了一个故事：

1. 以自己是一个开酒店的入题。
2. 基于区块链的KYC解决了C端和B端重复繁琐的资料登记过程。
3. 酒店初创，需要银行贷款，利用IoT+区块链和扩展的KYC应用，公开经营状况。解决银行对初创酒店的数据信任问题。
4. 演讲中，意思表达还是有点折扣。不过，已经非常自然了。

主办方整理的信息图

为了能增加亮点，金融小伙，拿来了之前准备好的树莓派和门锁，放入了演示环节。但是演示过程中，台上调试设备花了些时间，尴尬了几分钟。主持人马上与观众进入互动，避免令人窒息的安静。然后这个智能设备的演示也失败了，我们是唯一这么尴尬的小组。

这个过程，技术并不重要，合约没调通这个事情显得没那么严重了。重要的是演讲能力、演示效果。重要的是，打动用户，让自己的作品被理解。

总结

在最后的环节，我们也看到了其他队伍的演讲演示。准备得非常充分，都是有备而来，有非常酷的PPT、还有成型的app供下载、非常流畅自然的英文演讲、更贴合主办方业务的产品设计。没有得奖，心服口服。

功在平时，厚积才能薄发。如果要赢，一定做好充足准备。需要做好这些准备：

1. 痛点的定位。不能为技术而技术。
2. 技术储备。
3. sales的能力。
4. 英语。
5. 最最重要的，还是teamwork，我们需要培育一个更强大的团队。

Last modified on 2019-03-25