勿言迷茫-用户转化之伤

“考虑一种常见需求，发个类ERC721通证，总量500个，分发给社区里的小伙伴，所有持币数大于等于1个的小伙伴都可以免费来参加我们线下的meetup，持有超过10个的小伙伴来参加活动还可以获得一份我们线下活动的礼包。ETH和EOS目前有能力方便地实现这个吗？”

这是最近和一个朋友交流时聊到的一个基于公链的思想实验，这个需求在商业上不一定合理，但推演一遍，对我们理解区块链用户转化之难却是很有帮助。

首先，无论我们是发行在ETH还是EOS上，我们第一步就是要告知用户下载相应的钱包，并且创建账户，以便我们分发通证。其中下载钱包的难度理论上和下载一个普通App没有区别，对于移动互联网用户来说这存在一定的转化成本，但可以接受。痛点在下一步创建私钥，ETH和EOS在这一步都会涉及私钥管理，对于区块链这不可避免，但这的确有悖于移动互联网用户使用习惯，大多数用户对私钥这种概念是极其陌生的，转化率必定会大打折扣。

而当用户创建好私钥之后，在ETH钱包里，账户就创建完成了。而对于EOS这还没完，有了私钥之后，还需要绑定用户名，这一步只有抵押过EOS，并且拥有可用的CPU和NET资源的账户才能完成。如果由项目方来帮用户抵押，其中就涉及用户将公钥告知项目方然后项目方帮用户抵押EOS的一次额外交互，相对于Ethereum的方案，转化率之低可以想象。

如果按照区块链平台的原生逻辑，能够坚持到把账户创建好的用户就已经屈指可数了。但钱包作为第三方应用，可以一定程度上优化账户创建的用户体验。如果我们暂时忽略用户自己保存私钥的过程，那么一款优秀的钱包是有能力抹平区块链账户创建和互联网账户创建的差距的。

钱包创建结束后，接下来进入使用阶段。用户需要有能力正常发起交易，在Ethereum中这意味着需要Gas，而在EOS中这意味着需要抵押EOS获得CPU和NET使用权。在理想情况下，这都可以通过钱包对接类似Etheruem Faucet和EOS Emergency的服务自动完成。这样用户将能够在对区块链技术概念毫无感知的情况下，使用Ethereum和EOS。

推演至此，在借助钱包的极端场景下，项目方是有能力出钱为他们的用户自动准备好他们需要的一切资源的。但如果再刨深细看，我们会发现，这种方案下项目方的资金使用效率非常低。

如果每有一个新账户创建，便借助Faucet服务送用户一部分Ether，或者借助Emergency服务为用户抵押EOS换取CPU和NET，那项目方会被薅羊毛薅到破产。我们希望的状态一定是，当用户真正使用我们的应用时，我们才为其支付交易上链的费用，有的放矢。但这一点，目前在Ethereum和EOS上都极难实现，我们能想到的有两种方案。

一种方案是，用户先提交操作请求，然后项目方收到请求后给用户转Ether或者抵押EOS，用户得到反馈后正式提交。这种方案，反馈时间长，用户体验不好，而且依旧存在薅羊毛的可能，可行性不高。

另一种方案则是，用户把操作请求签名后发给项目方，项目方把用户操作请求作为内容包装到一个交易里，提交给项目方自己编写的接口合约中完成代付。这个方案，虽然项目方需要不断更新维护接口合约，操作起来复杂很多，但可以有效避免薅羊毛的风险，而且延迟低，具备一定可行性。

在我们的新项目Zerohm (zerohm.io) 中，我们便是基于第二种方案的思路做的改进。我们在Zerohm的交易模型中加入了Payer角色，用户签完名的交易，可以发给项目方，项目方加上Payer的签名后才是一个完整的交易。而在链上计算时，将会由Payer支付交易手续费。这样一来，项目方便没有了开发维护接口合约的必要性，也省去了一次合约间调用的Gas消耗。而且交易手续费没有直接给到用户，薅羊毛的风险也被极大降低。其中只涉及两次网络传输，处理过程都可以自动化完成，时延也可以接受。可见，这个方案可以非常有效地帮助项目方以一个可控的成本，为区块链用户提供互联网时代大家熟悉的免费服务。

而且更值得期待的是，Payer这样一个微小的创新，还为我们打开了另一扇大门。当Payer与Zerohm的通证层和合约层结合之后，我们发现我们有能力将区块链应用的灵活性带入一个全新的台阶，这部分内容我们会在后期陆续解读，敬请期待。

区块勿语，勿语幻想，勿语迷茫！

区块勿语

勿语幻想，勿语迷茫