×

不吹不黑,Ulord白皮书读后感

96
mike_88d3
2018.02.12 17:38 字数 1721

       说实话,朋友转来这篇白皮书让我看的时候,我内心是拒绝的,由于一直从事技术和产品研发工作,在“区块链爱好者”朋友的威逼之下被迫看了些XX币的白皮书,实在是一种煎熬。我对技术类文档的标准就是简单粗暴上干货,用什么技术/模式解决了什么问题产生了什么价值,1、2、3说清楚就完了,可这些所谓的白皮书就像小学生写的作文,扭捏干瘪空洞,咬牙看了几段后明白了,这是因为XX币们就没打算认真做产品,copy几段以太坊的代码翻译点英文资料就上场忽悠不明技术的群众了。我对这类做法虽不认同,但也不好泼朋友冷水,只是说看不太懂,因为太多的教训告诉我,风口上飞起来的猪最不care的就是技术,果不其然去年各种币大涨特涨,还好我TM没瞎哔哔,不然那哥们儿得吃了我。

        朋友为了让我看,专门跑来请我喝咖啡,说这个真不一样,人善面薄的我又一次妥协了。认真看完后谈谈感受,首先,总体上来讲白皮书的可读性不错,团队应该是下了不少功夫,将文档分成了应用层面和技术层面两个部分,普通投资者看完第二章就基本明白Ulord究竟是什么,要做什么事情,怎么赚钱,有点BP的意思;有点技术基础的人可以继续读之后的章节,写的也很明了,技术框架、业务逻辑、运维原则递进描述,配上流程图、结构图,典型的技术加产品的文案套路,跟我写文档的风格高度一致,好感度加分。通读下来,对平台各个层面的内容有了比较清晰的概要性了解,起到了白皮书应该有的效果,至于程序员关心的开发文档估计要等正式上线的时候才发布。

       关于文档的表达细节提一点小建议。白皮书第13页,平台架构图,箭头表示的应该是请求和响应数据的流向,ProtoBuf序列化框架往内走的两个箭头应该是分别代表两类业务请求,一个是查询一个是发布资源,这两个请求在架构图中的处理流程是不同的,建议使用不同颜色的箭头区别一下,或者在现有逻辑功能组件中针对这两类业务做更加细化的划分,不然容易造成读者的困惑。


原图

我根据自己的理解画的优化图,数据流向的理解如有错误,欢迎指正。


优化图

       说完文档的写法,再来谈谈我对Ulord业务的一些感受。目前互联网业务发展越来越呈现出分层的趋势,无论是前些年流行的云存储、云计算、虚拟/增强现实还是现在大热的人工智能、区块链,都是大公司做基础Service ,小公司用这些服务做Application。Ulord白皮书上来就表明的态度,要做基础平台和生态,首先说明团队对自己的技术是有信心的,因为基础服务考验的就是稳定性和易用性,特别对于区块链这种新技术想要保证这两点需要经过大规模的验证测试,由于还没有上线,我对创始团队也不了解,行不行还不好说。Ulord定义是做数字内容的公链,对服务范围做了一个明确的界定,这是一个聪明的切入点,区块链能够应用的范围很广领域很多,数字内容版权保护则是这项技术天然的基因,做基础协议和上层应用之间的服务平台,既覆盖了足够大的应用领域,又能充分利用区块链底层协议的基础减少自己的研发风险,定位很准,佩服一下这个项目的产品经理。

       白皮书中描述的创新点的具体实现都是用的行业主流成熟的方案,我虽然从事信息安全研发工作多年,但真没开发过区块量项目,不敢瞎评论别人的技术水平,但是从构架来说我能想到的问题白皮书都有相应的解决办法,至少说明产品设计是经过比较严谨的论证。平台有意弱化了“挖矿”的概念,把Token作为对平台贡献的奖励的分配规则从原动力上促使用户和玩家不再单纯的炒币,而是要真实的参与到平台的运营中来,有这个基础原则我认为至少创始团队的目标是为了项目落地,赞一个。

       在看到后面关于内容的传播部分,我最担心的就是不良信息的问题,因为传播者分享收益的原则可能会助推这类内容的传播,“快播”事件就是最典型的例子。虽然后来看到有共识机制和AI分析,但这个不确定因素始终存在。因为共识机制采取的投票办法也是由用户决定的,在这里Ulord选择了相信人性本善,充分体现出程序员的纯良可爱。AI分析算是对共识机制的补充,万一邪恶战胜了善良,咋们还有王炸,可惜白皮书没有对这块的算法做展开说明,无从判断它的可靠性以及是否跟1.0版本一同上线。

       总的来说这是我愿意去看去分析的一个项目,白皮书里能看出创始团队的用功、诚意和情怀,他们希望构建一个公平、平等、按劳分配、能者多劳多得的社区,这不正是每个程序员追求的么?虽然还有很多不确定因素,但是我祝愿他们能成功。

日记本
Web note ad 1