我为什么要创办兔基社区?

在2017年底决定做交易所之后,我们团队确定了一个规划——未来要做区块链界的“蚂蚁金服”。我们要帮助区块链降低门槛,让人人都能用上区块链资产。当时我们规划了各种和金融衍生品相关的方向。然而,在2018年我们在进行交易所融资的过程中发现,区块链行业的形势已经产生了很大的变化,行业中涌出了大量的交易所。这让我们的融资的过程变得有点不顺利。我接触过的所有的投资人都会问:“交易所这么多,你们有什么特色?”“你们怎么跟火币、币安竞争?”“你们怎么获取流量?”等等。而且我跟同行沟通下来,发现几乎所有的交易所团队都看到了类似的方向。大家都在做数字资产、金融衍生品、交易所联盟等等。我们预感原来我规划的路线会异常拥挤,竞争更加激烈。

2018年下半年开始,币圈形势急转直下。一下进入熊市之后,用户交易的积极性也变差了,行情萎靡,交易所的活跃度也大大降低。各种项目方也开始蛰伏。这对于交易平台来说是一个巨大的打击,行业面临洗牌。为了能在这种大环境中突围,我果断选择从我最擅长的社区和社交领域找到突破口。

兔基的诞生

现在币圈存在很多问题,受众有限,落地应用少。已经入场的存量用户基本都已套牢,他们在熊市里面也不喜欢交易。

回顾我们的目标:降低区块链的门槛,做增量市场,培养圈外的用户进入区块链,而非继续在有限的币圈内进行厮杀。

我希望我们的产品不要那么单薄无趣,让用户即便不想交易,也能保持每天上平台活动一下。

而大家都知道交易所的用户转化是非常难的,成本很高,处于转化漏斗的底部。而社区则可以产生较好的粘性,用户进入社区的门槛也会比较低,当用户在社区上逐渐学习到币的知识,并且获得了一些币之后,可以逐渐转化到交易所成为交易用户。这也符合我们设计的初衷。

所以首先我想在交易所基础之上做一个社区,给用户更容易注册的理由。

当有了社区之后,我了解到很多项目方也对于拉新的转化有着同样的困扰,而且他们运作币的手段和方式非常少,成本也很高。项目方主要使用社群的模式来和用户互动,但是社群难以沉淀内容,共识是存在内容中的。

关于钱包,总发现很多用户其实并没有能力独立自主使用钱包——而且像 EOS 的钱包的上手难度太高了——所以有相当多的用户是直接把币存在交易所里的。

交易所是服务于项目方的,帮助项目方进行融资和提供币的流动性,我自然非常关心项目方的诉求,如果项目方能获益,我们自然也能获益。

于是我认为如果能缩短这中间的路径,便可以提高我们用户转化率,也可以帮助项目方提高他们的转化率。

很多项目方都非常重视“社群”的运营,但是主要阵地是在微信群、telegram群,这样的“群”非常的碎片化,虽然实时互动有时候看上去很热闹,但是很难沉淀“内容”。而区块链行业中,最核心的“共识”,是应该承载在内容中的。所以我认为论坛的形式要优于即时通讯软件中的群的形式。

最终一个给项目方提供舞台,让用户唱主角,帮助项目方和用户之间进行沟通和互动的兔基平台应运而生。

最后总结一下:

  1. 培养、教育新用户
  2. 提高平台的粘性,促活
  3. 提高平台的转化率
  4. 提高代币的流通转化,减少摩擦
  5. 沉淀内容、共识

那么这么一个社区平台究竟有没有前途呢?

在我这一年多从事区块链的过程中,我一直反复琢磨着区块链到底是什么,他代表了什么,他能改变什么。后来我领悟到,区块链跟人工智能其实是人类发现的两驾马车。很多人都说人工智能是生产力的提升,而区块链是生产关系的变革。我的理解中,人工智能是为了帮助人类去完成一些重复的劳动,让人类少做一些事情。而区块链的出现则是想通过一些方式,激励人类在一定的规范下做更多的事情。

例如比特币,通过他的算法和网络,鼓励矿工的加入来帮助其他人见证交易同时获得回报。区块链非常强调社区的自治、系统的激励,这就是区块链的魅力。

从这点上来看,我发现其实从很久之前我就已经在探索社区的自治和激励的问题。

回顾糗事百科时期

我从2008年开始做糗事百科的时候,便希望糗百能成为一个用户自己发布内容,用户自己审核和筛选的一个UGC平台,让用户自己主导笑话的质量,而创始团队尽量少的去干预社区的口味。所以当时我们做了两个超前的产品设计:

  1. 是国内最早将“顶”和“踩”引入内容系统,作为优劣的评选——这在全球也应该是领先的,Facebook 在2009年才推出 Like 功能。而我们在08年便有了。
  1. 推出群众审核,通过一定的算法,利用群众的智慧决定帖子是否应该出现在公众视野。

然而因为缺乏适当的激励,参与审核的人很少,因为长时间的审核并不能得到什么回报,虽然起初很多人都非常有情怀。同时因为算法不够好,非常容易让内容走偏或者是审核速度太慢。最终还是非常依赖于运营人员的审核。

回顾暴走漫画时期

接下来我在做暴走漫画的时候,为了解决激励的问题,曾推出过“尼玛币”。

(当时其实恰逢比特币的第一波高潮,当时狗币也莫名奇妙就火起来了,我还跟王尼玛说要不自己也发个链,当时因为不懂技术所以作罢,现在想想还挺遗憾的)

与糗事百科的段子不同,暴走漫画的创作难度更高。因为段子只需要一些文学功底,而暴走漫画需要点子、对白和分镜绘画等。虽然暴走漫画提供了创作工具降低了制作门槛,但难度依然很高。所以暴漫在初期是让自己的运营人员创作,以及找一些画手来兼职创作。

由于王尼玛一贯的高举高打,所以在融资之后,最终是公司通过现金补贴画手,走上了 PUGC 的路线,最后转型做视频,创作的门槛又是更加高了。

然而因为“尼玛币”的设计不当,单纯通过行为激励来奖励用户,最终导致超发和贬值,最终也失去了激励的意义。本来还能换辣条的,现在已经不值钱了。

而接触了区块链之后,经过不断的探索,我才真正找到了解决这些问题的方案。

兔基的未来

过去互联网的黄金时期,涌现出了很多优秀的论坛社区,比如西祠胡同、天涯社区、百度贴吧等。他们无一例外都是兴起于用户自治。而最后的衰落,则往往是因为用户无法得到激励而离开,或者平台需要变现,侵犯了用户本身的利益。像百度贴吧的衰落,就是一部用户自治权不断丧失的历史。

所以兔基社区的宗旨是要真正把平台运营的权利还给用户,让社区真正做到“自治”。社区平台一直是一个自治的问题。

于是兔基社区平台未来将为发币的项目方进行全方位、一条龙的赋能。

  1. 帮助项目方沉淀内容和共识。
  2. 通过各种工具如打赏、红包、投票,帮助项目方使用自己的代币来运营自己的社群,吸引新的用户进入。
  3. 通过挖矿等工具来激励社区的用户在平台上的活跃,让用户能为社区做出贡献的同时获得回报,产生正向的循环。
  4. 通过交易所来实现变现和代币的流转

比特兔和兔基未来会一直坚持社区自治,在社区共同努力中逐步迭代出适合我们的社区自治方案,让为社区做出贡献的成员获得最大收益。为广大用户提供一片属于自己的天空。

地址:https://pub.bitrabbit.com/zh-cn/blackboard/topics/95438

兔币(BRB)的经济体系理念和价格分析

兔币作为比特兔平台兔基社区的通证,未来的价格走势,是非常让人关注的。有很多早期投资的朋友担心在现在这个行情下,兔币将来开通交易之后是否会破发。当然我不能打包票一定会涨,更不能承诺什么百倍十倍。但是长远来看,我对兔币是非常有信心的。下面我就来分析一下兔币未来的价格。

首先我们回顾一下兔币的闭环:

  • 通证的生产:社区的内容创作者和互动网友,从互动挖矿中获得平台给予的激励,网友还可以把兔币打赏给内容创作者。
  • 通证的回收:持有兔币的用户,可以从平台通过广告竞价等方式购买流量。兔币未来也可以在平台兑换商品、礼包和各种实体店代金券。
  • 生产者和消费者在兔所交易兔币

通过打破线下消费场景和线上生态体系之间的壁垒,让兔币拥有真正的价值。

关于平台币价格和平台流量之间的关系,我们研究了币安的 BNB 和 Kucoin 的 KCS,发现平台币价格跟平台流量之间存在一定的关系:

一、币安和 BNB

SimilarWeb的币安流量图,纵坐标是月访问量

Clipboard Image.png

币安的BNB 对 USDT的月K线,来源币安官网

Clipboard Image.png

二、KuCoin 和 KCS

SimilarWeb的KuCoin流量图

Clipboard Image.png

(KuCoin 平台币KCS 对 USDT 的周K 线,来源 KuCoin 官网

Clipboard Image.png

根据上表的数据,我们发现平台币价格和流量之间存在明显的正相关关系。

当然,这是非常合理的。平台币的作用就是在自己的平台上使用和流通,当平台流量下降的时候平台币的使用率降低,需求会变少,自然价格也会走低。

那么我们用类似的逻辑分析一下兔所的兔币。

在兔币的消耗方面,目前主要是用在两个地方,一个是兔所的交易对开通的投票,另一个购买社区的广告流量。本质上都是把兔币和平台的流量进行了挂钩。因此兔币的价格有非常清晰的价值支撑。

当社区流量上涨时,投放广告效果变好,广告价格便会上升,广告主对广告的唯一通证兔币的需求就会上升,兔币价格就会上涨。

当交易所流量上涨时,此时通常是币市活跃的时期,这个周期中,会争相有创业团队发币募资,此时对交易所提供币的流动性有更强的需求。为了能在兔所开通交易对,则必然对兔币有更强烈的需求,促使兔币价格走高。

然而,与币安和KuCoin单纯作为交易所不同,兔基作为一个综合性社区,其流量不容易受到币市币价涨跌影响,所以对熊市有天然的抗性。最有力的证明是:从我们上线兔基到现在,流量一直在稳定上涨(来自 Google Analytics 的数据):

Clipboard Image.png

综上所述,我们认为兔币的价格是和平台流量呈强烈的正相关关系,以下是我们对币价和流量之间关系的预测,当比特兔和兔基的流量达到月访问量1000万时,兔币的价格应该在3.6美元

Clipboard Image.png

所以希望兔币持有用户们跟我们一起大力推广兔基和比特兔平台,把他打造成区块链时代最强的平台,一起享受流量带来的红利。

声明:以上内容并非投资的建议,预测仅供参考,并非担保。

来阿里巴巴一年有感(下)——毕业一周年祭

距离发表中篇已经过去一年了 。可能很多朋友猜不到当时发表中篇的时候,我就已经离职了。然而因为后来发生了太多的事情,下篇拖了一年还没有写完。

其实去年在阿里巴巴达摩院成立的时候,我就已经写过一篇当时匿名的回答来阐述过阿里巴巴的一些大公司通病(其实我觉得也不一定算病),已经写了一些我为什么离开阿里的理由。

至于到底至于为什么要离开,简单的说就是不“match”。你的行为方式和团队的,你擅长的东西和你的岗位要求,你追求的和公司能给的,等等。就好像谈恋爱的两个人,不契合就是不契合。

闭塞的“大学校园”

在阿里,同事之间都以同学相称,园区也自称大学,颇有种象牙塔的感觉。 进了阿里之后,似乎就像大学校园一样与世隔绝。

因为每个人都被安排了自己的一亩三分地,跟固定的一些关联方合作,基本上并不需要多与外界接触。

虽然看起来网络确实还通着,你还能与外界沟通很多工作相关的东西,但是因为工作上关注点过于集中,工作压力大,非常容易忽略其他的事情。体制内的技术体系非常的完整和完善,一旦熟悉了也不需要去多学习其他的新东西。再加上绩效考核等等东西,个人能力的发展非常容易被体制固定化。长期以往容易与时代脱节。

这就是所谓的“体制化”。

不过这点上阿里巴巴还算优秀,因为整个公司危机意识强,技术人员也乐于通过一些技术的模仿和微创新来完成自己的 KPI,所以基础设施的更新还是比较快的,国内是强于百度和腾讯的。所以在阿里做技术,暂时还不太容易出现做了好多年出来发现技术领域完全变天了的情况——当然也不轻松。

如果前面说的闭塞是对于外包而言的话,其实内部的沟通也同样非常受限。

森严的等级

在我待了半年之后,听说同一大团队下的另外一个专家要转岗去其他部门,他已经在阿里巴巴待了8年了。我私下跟他聊了一下,问他为什么要转岗,他说对未来感到迷茫,遇到了天花板,不知道干嘛,想准备尝试做产品经理。我对他说他在阿里待了这么久,怎么也认识一些大佬,为什么不能找大佬聊聊为什么工作遇到瓶颈,让大佬看看有没有更合适的机会。然而他告诉我,除了一直跟着的老板,没有其他什么特别熟的大佬了,即便是曾经的同僚,一旦高升之后便也没有了往来。 我顿悟。

我非常理解这种情况。大公司的体制决定了,上级对下属有非常大的权力,可以调配非常多的资源。下属将来能不能晋升,都要靠上级。权力是多疑的,上司会非常清楚凑上来的下属都觊觎着自己手上的资源,都希望往上爬。这就是体制。如果这都能轻松越级沟通的话,估计离高升也不远了。 同时太跳了也容易卷入各种政治斗争中。

虽然我觉得找大佬不见得就一定是要资源,我更多的是希望能向大佬们学习,了解他们的工作方式,打开自己眼界,从他们的角度审视自己,并且给自己规划更长远的路线。然而上司们不会有足够的时间和精力来帮助到每个下级。因为他还要想着如何围着他的上级去转。

所以最终基本上就是什么层级的人跟什么层级的玩。当然,因为眼界、责任各方面并不对等,所以这也是非常合理的。

甚至,我有个大学同学也在阿里,到杭州来的时候只有入职那阵子约到过一次,其后每次约都是有事在外出差。我不清楚为何。

然而,对于创业来说情况则完全不同。当我还在上海的时候,我经常可以参加一些创业朋友之间的聚会,会大家可以互通有无,开阔眼界,思辨一些问题,从完全不同的角度来审视自己的事情。

创业的时候能接触的人会有各种各样的人。甚至我能接触到上市公司的创始人,因为我的特殊专长也会敬我三分。试想一个在阿里巴巴任职的普通员工,即便他在全国也算顶尖的专家,只要级别上不去,能有什么机会得到马云或者低一些逍遥子等大佬的垂青,能在饭局上跟他们谈笑风生? 其实越级都相当困难。而我可以尝试整合一切可用资源,而不局限于体制内被分配的那些。

在体制内是千军万马过独木桥,而创业是八仙过海各显神通。这就是创业的魅力。

海阔凭鱼跃,天高任鸟飞

——非常感恩在阿里巴巴的这一年。

 

一个新的的区块链组织合作形式 – 去中心化合伙制度

分布式自治组织(DAO )和相关社区的募集资金问题一直是区块链社区讨论的热点。我们深刻感到了DAO在解决一些例如开源社区工作和管理的可能的优点,也感受到了在集资领域 ICO 架构的不足和缺点。我们决定提出一种基于去中心化系统上的合作形式,即去中心化合伙制度(DAP)。

1.1 什么是去中心化合伙制度

去中心化合伙制度主要指建立在去中心化系统上的一种合作制度。合伙制体系以合伙制公司为例,在金融、会计以及咨询领域都十分常见。而我们认为金融活动是目前最容易被定义运作在去中心化系统之上的一种系统。因此,我们提出的去中心化合伙制度,可以供相关领域的公司在进行金融活动时参考。另外一方面,去中心化合伙制度对粗犷的ICO方式提供了一种开发的修正和完善,即区块链项目应该勇于自我监管,促进社区进步。

1) 自由人与社区

人类历史上,有段非常恢弘的篇章称之为罗马共和国,罗马共和国的一个重要信念就是自由,而自由是所有追求权力的罗马人渴望的共同理念,因此所有的政治行为和争论集中在这套自由理念框架内进行的。我们可以认为罗马共和国就是“自由人组成的社区”。

罗马政治家对这种具体的自由理念有各种各样的解读和应用,但实质上这也传递了摆脱君主统治获得自由的道理——罗马公民的权利:法律面前形式上的平等、一定程度上受到保护而免受行政官员的专制压迫、有权通过法律和选举行政官员。

然而,认为罗马共和国是民主体制的人忽视了这样的事实:政治权利不是存在于真空中,而是存在于社会和经济结构中,那才是真正决定其能否变成现实的地方。

我们认为,在一个社区发展当中,无论是否认定其是一个区块链社区,都必须去思考一个问题——它的社会和经济结构是怎样的?实际上,当我们参与一项活动时,无论这项活动是投票还是投资,一定会同时有社会结构和经济结构这两方面的原因。简而言之,社会和经济结构决定了我们的每项活动的原因和性质。

一个社区,无论是基于互联网APP还是区块链应用,都应该反思几个重要问题:

1. 我们的生产关系是怎样的?

2. 我们的权力如何分配?

3. 我们的经济活动和规则有哪些?

区块链社区的创立者们常常会提出一些宏大的梦想,并试图建立一个个行业领域的大平台,但是现实往往不尽人意——它们缺乏实际的落地效果。许多区块链项目的估值建立在其可以成就的那个庞大的自治社区,而我们需要注意到的是,一个自治社区是需要特定的社会结构和经济结构的。

以比特币为例,它拥有核心开发者、矿工和用户三类角色,它们组成了比特币社区的社会结构。其中矿工和用户贡献了比特币的主要经济活动,即相互之间币的流通。唯有比特币的核心开发者们无法很好得参与到比特币的经济活动中来,并且也没有一个有效的保障体系来确保他们的利益。所以之后的虚拟货币开发者们采取了 ICO 的方式来确保自己有充分的经济活动地位。危险的是,这种方式让核心开发团队在经济活动和社会活动中占据了太大的优势,这使得开发团队成为了社区绝对的“国王”,而“国王的权利”是至高无上的。

英国第一位首相老威廉·皮特说过:“风能进,雨能进,国王不能进”。我们在保障最核心的团体(下文展开)在经济和社会结构的同时,也必须思考这条边界在哪里。国家这个高度复杂且有自律性的庞然大物尚且如此,何况当今社会几个人乃至仅仅十几个人组成的团体。罗马共和国和古希腊的历史告诉我们:

我们需要“国王”,但我们更需要“议会”!

2) 团队与组织

团体——或者说团队——越来越多的成为政治、经济、科研和其他活动当中的基本单位。我们认为组织是有复杂结构的团队。有着清晰的组织结构(社会结构的退化)和经济结构的团队(或组织),才会拥有较为稳定的发展和演进。我们注意到,在目前的区块链项目当中,往往只介绍了团队,而缺乏组织结构的部分。

组织虽然仅仅比团队多了更加复杂的结构部分,但正是这些结构提高了团队的决策效率和执行能力。我们注意到目前区块链社区比较火热的 Ethereum 和 EOS,其组织结构呈现集中化,比如 Ethereum 的 VitalikButeran 和 EOS 的 BM。虽然官方和当事人都没有具体提及到关于他们的组织信息,但是这种组织结构是不言而喻的。

如果说一个团队能够用某种技术去推动世界的改变的话,起初往往依赖于某个灵魂人物。而之后,则依赖于稳定有效的组织去完成。我们认为 Bitcoin core 团队和 Blockstream 在其后对比特币的推动上的乏力,正是由中本聪的光辉渐渐消失,并且同时没有形成一个可以自我生长演变的组织所导致的。

一个依托去中心化的系统来建立连接的自我生长的组织,做一个早期的区块链项目,看的不是这个项目团队的知名度和背景,更不是这个行业是否热门,而是他们构成的组织是否更有战斗力。

3) 小结

在考察了一些历史现象之后,结合我们今天在区块链经济活动领域的现象,我们应当充分明白,区块链项目活动必须有清晰的社会结构和经济结构:

社会结构:在基于区块链技术所诞生的社区中,代币的持有者如何分布,他们如何在社区中行使自己的权力,以及如何与社区中的其他角色互动。

经济结构:凝聚在代币中的经济资源如何被管理——这通常是投资货币(如以太坊)的使用问题。而新的社区往往并不成熟,总是会以更为成熟和通用的资源所定义, 比如用铜铸币。

当下,区块链募资活动以及他们所描述的景象,往往止于说明解决了什么问题,而这些募资活动又是作为一个生态去进行的。所以,在一个基于分布式系统建立的去中心化社区当中,它必须建立的是去中心化“宪法”——一个应该定义清楚了社区的角色和结构,以及他们的相互关系的文件。而建立一个编写宪法的组织基础,是一件比编写宪法更重要的事情。今天去建立去中心化“宪法”的事情,就和当初建立美国和编写美国宪法一样伟大。

1.2 价值:锚定、市场、价格

区块链社区一直在发币的锚定机制上摇摆不定。一方面,他们无法形成稳定的锚,因为他们需要一个无限可能的未来。另一方面,他们却又希望能够通过稳定的锚来获得收益(通常是法币)。讨论这个问题之前,我们必须去思考一个问题,货币稳定过吗?

答案显然是否定的,如果我们稍微把时间的尺度拉大,就会清晰的发现,如果以某种自然资源作为锚,法币同样也经历着巨大的涨跌幅。作为一个中国人,持有一个“袁大头” (一种20世纪初期的货币)也会享受当下几十倍的涨幅了。随着社会活动的变化比如战争、衰落和爆发,法币的本位机制一直在变动。但就其本质而言,货币的价值锚定的核心,不是外物,而是社会规则及其活动本身。社会规则甚至可以不定义一个实物来锚定货币的价值,比如央行的货币发行。在这种情况下,无论发行了多少货币,市场会调节,会让所有的商品得到定价。

市场似乎永远在变化,因为权力变得太快。

拥有优势的社会地位的人,似乎从来不需要担心货币问题。所以,货币或者说围绕货币的价值锚定,不应该是区块链这场轰轰烈烈大经济实验的核心。这个核心理应是区块链抑或分布式系统,以何种形式,更文明和民主地在更多领域去定义宪法——即经济结构和社会结构。而这个锚定只是其中的副产品——不过是一个副产物——它量化和凝聚了这种结构变化的原因。

我们希望将这一实质明晰的指出来,然后去践行这一理想,我们将对一个最简单的经济形式做尝试,即投资者和一个具有创造力的组织——比特兔团队。

1.3 实践:投票权委员会和中心权力团体

比特兔团队的理念很简单,我们需要一个委员会。

比特兔团队有着自己比较清晰的目标,即尝试用区块链的方式建立正确、受控的投资过程。在区块链的投资活动目前来看,可以分为两种:

简单的将股权投资搬到区块链上,区块链仅仅作为一个投融资工具来记录,这样的意义仅仅在于节省现在股权投资的成本而已。

粗犷的ICO模式,大家都说在泡沫中孕育希望,至于效果如何,不多赘述。

比特兔团队希望提出一种介乎于股权投资和ICO模式之间的新的投融资制度。在这里,双方的权力相互制约:

1. 投票权委员会(投资合伙人)有权管制政府的财务预算:

2. 投资人每个月决定该月团队可以提出的资金额度

3. 投资人有权投票降低甚至取消投资

4. 中心权力团体(团队)可以通过业绩承诺来提高预算: 可以承诺某个业绩数字来获得更大的该月预算,甚至,中心权力团体(团队)可以通过让渡部分经营权力来促进某事的达成。比如:

  1. 提高席位价格
  2. 扩大席位数量

我们会在附录中,明确该制度的议事法则和执行机制。

1.4 过渡的契约: 让智能合约具有法律效应

如果存在这样一个社区:她高度先进,她的规章制度由程序实现,我们所有人都遵守该规章制度作为共识,抑或该规章制度本身就是由所有人的共识产生的。这虽然非常理想,但并非完全不可能。如果在这种社区中,我们将很开心的写出一个类似公司章程的东西,并且所有的活动由这个规章程序来保证执行。经管这一社会看起来十分不可思议,然而,人类商业社会的高度发展,正是源于对契约精神的恪守。

契约精神不能仅仅依赖中心化的中心权力团体权威来保证,也必须能够在一个去中心化的体系中来执行。在我们的框架里:

1. 契约签订双方在一个不可变分布式存储系统里(ipfs)通过身份验证私钥加密并上传自己的法律身份文件: 包含一张身份证明照片,以及手持授权协议的照片。

2. 为了保证身份照片不乱用,利用防止光学伪造的水印算法在该照片上添加水印,水印信息为自己签署智能合约的公钥地址。

3. 契约签订双方交换私钥,确认对方身份。

4. 契约双方签署智能合约。

5. 如果某一方身份验证或者智能合约签署私钥丢失,可以发布新的 IPFS 身份证明并更换自己的授权协议。

6. 如果两者皆丢失,则需要想之前的合作伙伴通过联系后请求他们认可新的身份。在这里,我们利用授权协议保证了用户的私钥签名是具有法律效力,我们希望能够在真实的司法活动确认这一行为是有效力的。

以上,就是我们希望的去中心化合伙人制度。我们做了一些有益的尝试,尽管不是完全去中心化的,但是也许会成为智能合约具有法律效应的一次尝试。并且我们会邀请律师就这一新的方式进行相关法律上的操作。

附录:

规章和议事规则

去中心化合伙制度提出了一个规章用来约束去中心化合伙制度当中的行为。

1.服从智能合约。

2.服从智能合约非程序部分的效力。

3.服从智能合约的事件记录。

4.中心权力团体是合伙项目的发起方和执行者,负责项目的具体执行。

5.投票权委员会是所有拥有投票权的人,即相关的代币持有者,投票权的单位是票。

6.议题是一个二元命题,选项为是,否和弃权。

7.有必须议题和非必须议题。

8.必须议题是每个月必须讨论的议题,且必须议题至少包含是否清算项目议题。

9.清算项目议题是是否终止项目的议题,当投票权委员会中超过2/3的人投票并同意清算,项目停止,并根据清算条款进行清算。清算条款需通过智能合约强制执行。

10.待讨论议题由中心权力团体选出,并设置优先级,必须含有所有的必须议题。待讨论议题确定后,应通过日志函数发布在区块链上,并标号。

11.每个月至少召开一次会议,将讨论所有的待讨论议题。

12.议题的投票方式分为绝对多数和多数制,除清算项目议题外,由中心权力团体决定。

来阿里巴巴一年有感(上)

不知不觉,从上海搬到杭州已经一年有余。我于2016年8月加入阿里巴巴,从一个连续创业(失败)者,成为阿(da)里(qiye)员工,开始了按部就班的生活。做出这样的改变并不是件容易的事情。

我从初中开始学习编程,当时懵懂地觉得将来要在互联网行业创出一番事业。但是由于当时没有做出一个周密的职业规划,所以我从大学毕业以来就一直混迹于创业小公司。而对于去大公司就职,我一直是拒绝的。此次变故也是被社会现实教育的结果。

个人在整个社会中是非常渺小的。原本我并不太在意房产之类的事情,从小孩出生开始,就逐渐发现自己缺乏各种社会关系。比如小孩3岁到了上幼儿园的年纪,在上海想就近上公立幼儿园则要求必须有户口、房产和居住证积分等等才能入园。但公司并不能帮我解决这些问题。

从长远来看,为了家庭考虑,买房是一个必须的选择,我也不能像原来创业一样承担那么多风险,必须有一份可靠的保障。这时著名的寒冬winter出现向我抛出了橄榄枝,最后我选择了加入阿里。

那为什么会做出这样的选择?

首先当然是杭州房价相对于上海比较低,其次杭州落户比较方便。不幸的是刚来杭州赶上G20,手又不够快,所以赶上一波房价暴涨;幸运的是赶在了杭州政府调控之前通过人才引进落户,否则落户买房也受限制。

除了这个现实问题之外,职业生涯规划的转变也是一个非常重要的因素。


过去选择创业公司,是因为在创业小公司做事有一些好处,比如空间会非常大,做事方式往往比较自由。在技术的选型、产品的设计等等都可以有话语权。

然而如果一个人,尤其是职场新人,一直待在小公司的话就会产生很多问题:

  1. 小公司往往管理混乱,对于没有经过正规军训练的新人来说,很难理顺公司管理,而且长此以往,会令自己的工作习惯变得糟糕。
  2. 创业小公司风险大,运气不好的小公司成长很慢,规模小,会错失很多成长机会。
  3. 运气好的小公司成长很快,这时自己的经验往往跟不上,很多时候需要摸着石头过河,非常容易采坑。公司为了避免损失,需要外聘一些管理人员。然而当突然空降了其他管理人员之后,公司成员和新的管理人员必然有各种冲突和摩擦。

经过十年的创业摸爬滚打,可以说对于互联网创业的早期,我是轻车熟路的,从最初一个人做原型到带几个人搞作坊再到十来个人的准正规军甚至三四十人的技术团队管理,我都能轻松胜任。然而对于如何再往上发展,我感到很迷茫,似乎进入了一个瓶颈。现在即便再次创业,也只是把同样的经验重复几年,很难帮助团队进入一个新的高度。经过多方思考,我决心加入更大的平台,期望拓展自己的格局。

加入一家大公司的话则有很多好处:

  1. 大公司的管理很成熟,有很多现成的工具。大公司的体系和经验可以直接拿来使用。
  2. 大公司的履历相对更加容易被承认。能进去做事,肯定已经被大公司的团队认可了,他是一种标杆性质的存在。未来跳槽、融资都更有底气。
  3. 大平台就会有更多的牛人与自己同事,可以更加多的交流和学习。
  4. 个人的力量是渺小的,然而依托组织可以解决很多问题。像迁户口,公积金转移等等自己一个人跑可能要跑断腿的事情,组织就可以让专人去负责解决。阿里的福利还是很不错的。
  5. 有更为稳定可靠的薪酬回报。

而阿里都能满足这些条件,如上文所说,过去我毕业的时候没有非常周密的职业规划,导致走了不少弯路,而现在的话,我强烈建议有能力的同学优先选择成熟的大公司,先锻炼几年,然后再考虑自己感兴趣的方向会比较好。希望这篇文章也能为在校考虑未来就业方向的同学有所启发。

Ruby/Rails为什么不如以前热门了?

最近在知乎上看到了一个问题,问“Ruby和Ruby on Rails在2017年还有前途吗?”我觉得这个问题很有意思,因为其实Ruby圈子里不少很资深的朋友,都转行去做别的了,有做前端的,有做Go,还有像我开始做Nodejs了。给人的感觉就是Ruby不行了,圈子也不够活跃了,
下面我来分析一下Ruby/Rails为什么最近声音小了。首先看大公司为什么很少用rails,据我所知有
1. rails的性能和内存占用不理想,规模效益不高
2. ruby作为动态语言在大团队开发上存在劣势,不能像java有接口和静态类型检查,能够帮助大团队在开发期减少Bug。
3. 小众语言,招人(相对)困难
4. rails本身是单块设计,而且很多地方并不OO,不适合大公司拆分、细化、优化的诉求

而rails更多是创业小公司在用,我的经验包括:
1. 全栈框架,有自己的前端逻辑
2. 完善的生态
3. 开发速度快,对人员数量要求少
4. 学习曲线很线性,容易培养(全栈的)开发人员

对于小公司来说,本身资金有限,人力成本又占主要部分,产品不确定性大,所以选择走小团队,快速开发的模式是很自然的事情。而大公司,往往有完善的体制——招聘、培训、管理,等等——支持,所以往往是希望能通过增加人手来扩大生产规模以及完成更多的产出,这就要求开发工具有足够的“工程性”。这跟Rails的理念就是相违背的,而Ruby的工程性也不如Java之类的好。

大家再回想一下这几年中国经济形势如何?实体凋敝,房价暴涨,很多人都觉得创业还不如买几套房子。这样创业公司少了,用Ruby/Rails的自然也少了。

再看这几年的技术发展趋势,一个是经过多年的发展,当初Ruby/Rails的很多先进思想也都被其他语言和工具吸收了,开发效率上的领先已经达不到最早那种数量级的差异。
同时很多开发者已经熟悉了自己的一套框架和工具链,如果实现相同功能,没有十足的必要学习另外一种新的技术。

而只有前端不一样,浏览器只支持JavaScript,整个前端的生态又顺理成章建立在了nodejs之上。加上手机客户端又适逢新兴的移动互联网浪潮,需求量突飞猛进。前端、客户端之前的积累也比较少,加上需求的推动,有很大的空间来造轮子。

所以Ruby/Rails近几年声音变小也是正常现象,即使我认为目前在开发体验上还没有能超过Rails的全栈框架。

从产品角度来看,早年开发产品拼技术,主要看你东西能不能做出来。后来开始拼产品设计,又讲究快速开发和快速试错。以前在Web时代,Rails在这些方面都有优势。而到了移动时代,产品设计和快速迭代的主要部分从后端移到前端,让后端开发变成了一个配角,尤其是后端开发在早期阶段的重要程度也降低了。

然而事到如今,各端入口都被占据,流量、用户基本被巨头们瓜分干净,各种现成的平台服务也层出不穷,又进一步让技术的重要程度又降低了。想想做一个公众号,用现成的平台,经营好粉丝就能拉投资捞钱;或者在现有平台上开个微店来做生意。现在很多创业门槛完全不在技术方面,技术的重要程度被大大降低。

而往后看,VR、人工智能、大数据、IOT等等也都不是Ruby所擅长的领域。

种种加起来,可以看到Ruby/Rails几乎不可能再掀起新的浪潮。总结了这么多,就是,Rails本身所擅长的领域在现在已经变得很狭窄也不那么重要了,所以才声音小了。任何技术也都有他的生命周期,Ruby/Rails是非常优秀的技术和工具,如果你要做的事情符合他的目标,那它依然是一个很棒的选择。

链接:https://zhuanlan.zhihu.com/p/25007358

博客被黑了

之前在参加公司封闭培训特别忙,​好一阵子没看过自己的博客,突然收到 Linode 的邮件说我的服务器在发送垃圾邮件,然后问我的服务器是不是被黑了,而且一连发现好几封。前阵子一直忙着上公司的培训课还有搬家,就忘了看邮箱。现在发现居然被黑了,不知道是 WordPress 还是插件的问题,文件夹下面多了很多奇怪的文件,而且好像被混淆了。还在/tmp 目录下有几个奇怪的文件,长期运行占用了100% CPU。清理过机器之后,我想登陆 Linode 去回复一下客服提的 Ticket,结果发现换了手机之后,原来 2步验证的没改,原来的手机又坏了不能看到验证码,很郁闷又邮箱联系客服,结果用注册邮箱发邮件给客户之间被回复该邮箱已经禁用,不知道是不是因为我的账号异常。然后换了个邮箱再联系,客服让我发送身份证照片和信用卡照片,然后才帮我禁用2步验证,然后进去回复了客服的 Ticket,客服建议我给 WordPress 装个 WordFence。

安装了 WordFence 之后扫描了 WordPress 的文件,发现大量php文件都被感染了莫名的代码片段,于是让 WordFence 进行恢复和清理,终于算是告一段落了。

而我印象深刻的是 WordFence 这个插件有一个收费的 Pro 版本,提供更强大的防护能力。让我回想起来以前看到的一篇访谈,讲的是 Ruby on Rails 的插件 Sidekiq 的作者 Mike Perham 如何一个人通过维护自己的产品 Sidekiq,最终获得了百万美元的收入。当时我十分震惊,因为之前我认为一个程序员想通过纯技术做自由职业实现财务自由,是不可能的事情。我认为程序员想实现财务自由,只能通过进入一个组织内,通过组织来实现,比如加入创业公司。然而这个风险也是非常大的,因为在组织面前,个人是很难抗衡的,公司做大了,可以把程序员、甚至把合伙人换掉。而自己创业,往往很快自己就无法继续做技术了。

Sidekiq,WordFence,和 Indie Hacker 上的很多案例给了我启示,我能不能发现一些细分领域里面小而美的产品,只要一个人,或者能用两三个人的小团队,就能充分发挥个人能力,实现我的人生目的。

希望将来也有机会能做出一些这样的产品。不过,我觉得最大的天敌也许就是自己的胆怯和惰性。

互联网的未来属于实时交互

作为一个写代码的,我做互联网产品也有十个年头了,从来没有想过要在设计上指点江山,只是谈谈自己的一些感触。

我所谓的实时交互,指的是服务器端的状态会实时同步到本地并展示。比如即时通讯软件,你可以直接看到其他用户发来的消息,甚至能看到对方正在输入。比如 MMORPG 多人在线游戏中,在本地就能进入游戏世界并看到一切更新。而很多软件中使用『推送』、『通知』,还算不上实时交互。那种需要刷新页面的,就更不实时了。

我认为未来的产品的形态,交互模式会朝着这个方向去发展,过去的客户端发起请求,服务器产生响应的模式会被革新掉。以往的互联网是内容为准,以后的互联网便是以交互为主。为何呢?看我分析理由。

一、人喜欢更快的响应速度

我06年毕业,毕业论文就写的是关于 AJAX 方面的东西。从那时候开始,我就发现互联网应用是追求越来越快的响应速度的。当时Amazon有个说法是页面的请求每增加多少毫秒,销售额就会减少多少。可见响应速度是一个非常重要的『用户体验』。

从那时候开始,各种技术、组件、框架、语言,都在尽可能的提高应用的流畅度和响应速度。巨头们发明各种新的浏览器,以及 JavaScript 引擎,展开了速度上的竞赛。

用户界面也从服务器端搬到了客户端,原生 app 的兴起,为了尽可能提供能酷炫和流畅的界面。

这些都是在提高响应速度。然而,在过去的『请求-响应』的模式下,再快也是在我请求之后的,只有服务器端能直接把状态推送下来,才是真正最快的响应

二、人喜欢和活的人交互

即时通讯软件可以说是经久不衰的产品类型之一了,而且现在也是占据人类使用手机主要时间的 App。为何会这样?因为人的本质就是喜欢跟人交互的。

所以后来出现了一些特殊的产品形态,目的是为了『模拟』这种好像有活人在跟你交互的感觉。『弹幕』就是其中之一,大家知道其实弹幕最早是出现在点播的视频上的。但我们在使用的过程中,主要的体验就是好像这个时候也有其他人在吐槽视频。

twitter、微博则定时提醒用户有多少信息更新,告诉用户,我们有新鲜的信息,你赶紧来交互吧。

直播也是非常重要的产品形式,而直播上面的弹幕,毫无疑问就是最新的用户的交互了。

三、人喜欢更多的信息细节

前面说到即时通讯软件一直很火,但是我们也发现伴随即时通讯的,往往有语音对话、视频对话。当然,这些功能都是在技术的发展后,门槛越来越低。

图片、语音所包含的信息比普通的文字多,视频就更多了,所以所需要的计算时间和带宽也更多。但是也挡不住大家更喜欢用语音通讯和视频直播。

我认为,人到底都是感情动物,而感情是非常细腻的,比如人可以从细微的表情变化,语气语调中,看出很多东西,也更容易建立情感联系。这也是为何在现在的聊天当中,表情包占据了越来越多的份额。

我相信,从维持感情的角度来看,视频通话>语音通话>文本对话。而直接的对话交互又好于发一份异步的邮件。

实时交互能带来更多的信息细节,能让用户感受到真的是活生生的人,这就是大家对此爱不释手的原因。

四、现在是承上启下的时代

实时交互的技术基础基本上都已经完善了,像服务器端推送,高并发等等基础问题其实已经不是问题。在 Web 上,Socket.io,Primus 等基础通信框架帮助大家解决了实时通信的问题,而一些框架像 Sails.js,Feather.js 也号称是实时框架。最近兴起的『响应式编程』Reactive Programming 也为这种实时的响应和交互提供了支持,出现了相应的框架如 Rx 系列。

同时虚拟现实(VR)已经进入了人们的视野,难道人们会希望在一个只有自己一个人的虚拟世界里面玩吗?显然,我们需要的是一个互联的虚拟世界,在这样的世界里,不可能存在像过去那样的『请求-响应』的操作模式,一切信息都肯定是实时呈现到本地的。

这就要求我们能够打破传统的思维,能颠覆现有的交互方式,把实时交互考虑进来,去创新出一些新的产品形态。

本人也正在研究实时交互方向的产品,并希望提出一套实时交互的应用框架,最近正在写 Coronajs,有感兴趣的朋友可以一起交流。

Node.js 应该拥抱 Actor 模型

Node.js 是近年来服务器端开发工具中可以说最为成功的一个工具了,不仅仅利用 JavaScript 和 Reactor 模型来达到快速开发高并发应用的目的,也顺利入侵前端生态圈,前端开发各种必备的工具链基本都使用 Nodejs 开发。我也用 Nodejs 做过一些针对并发的项目如聊天室等等,但是始终觉得 Nodejs 的基础理念和各种框架还不足够抽象,以帮助我快速对此类项目进行清晰有条理的建模。当项目尺度越来越大之后, 为了达到更好的 Scalability 和高可用性,容错性,因此我越来越希望 Nodejs 能有类似于 Erlang 中的 Actor 模型的框架来实现这些目标。

以往解决并发,往往是一个进程服务一个链接,但是进程占用资源过多,无法很好的伸展。后来变成了一个线程服务一个链接,虽然可以开很多线程,但是频繁的上下文切换消耗过多的 CPU 时间,线程之间的状态共享又容易出问题,所以也无法很好扩展。

Reactor 模型利用事件机制,在 IO 密集的场景中,解决了两者的问题。由于 IO 密集的场景下,大部分链接都是在等待传输等,只有少数链接处于活跃状态,所以可以通过事件的方式,仅仅处理需要处理的那部分,来减少资源的开销。

但是Reactor 模型也不是没有缺点,在 Nodejs 中:

  1. 单线程,难以利用多核优势,一旦阻塞了事件循环,会导致所有任务都会延迟。
  2. 过多的回调导致难以组织代码
  3. 回调函数打乱了控制流程,让处理异常变得麻烦

Actor 模型的基本概念

同样是由于线程和进程模型的一些缺陷,Erlang 之父Joe Armstrong在解决电信交换机上的高并发问题的时候,提出了 Actor 模型。简单的说,每个 Actor 封装了自己的逻辑和状态,互相之间不共享任何状态,只能通过消息(Message)来互相通信。每个 Actor 有一个自己的邮箱(Mailbox),是一个存放消息的队列,Actor 会一个一个处理每一个消息。

_JC@ABJ3(7{)]Y1VF@3PH58

Actor 之间不共享状态,就减少了很多多线程中的锁的问题。顺序处理消息,也保证了 Actor 内部不容易出现竞争条件(Race condition)。

当然,Reactor 模型和 Actor 模型并不完全排斥,Actor 模型底层也是可以使用 Reactor 的。

Actor 具有天生的分布式特性,我整理了一张表:

Actor Process Machine Service
标识 唯一 ID 进程 ID,端口 IP 地址,Mac 地址 IP,域名,服务发现
状态 不共享 通常不共享 不共享 不共享
交互 消息 信号,管道,网络 网络 网络
容错 Supervisor 机制 supervisord, monit,等 heartbeatkeepalived Cluster 内建,DNS,服务发现

其实 Actor, Process,Machine,Service,在很多方面都是一脉相承,正因如此,内置了 Actor 模型的 Erlang 才在云时代大放光彩。

虽然 Nodejs 号称是云时代的编程工具,但实际上在这方面做得并不特别好。

那为何 Nodejs 应该加入对 Actor 的支持?

清晰的单元

首先,Actor 本身只是将一个逻辑处理单元给具体出来,即便我们的 Nodejs 程序没有使用 Actor 模型,实际上在处理并发的时候,依然会隐含着这种逻辑处理单元。Nodejs 中是通过闭包来隔离内部状态,通过事件/回调函数来处理消息。随着代码量的增加,为了让代码更加结构化清晰化,我们通常依然会封装出一些自己的接近 Actor 模型的对象。虽然我们现在有 Promise,未来有 async/await,但是这主要是封装一次『任务』,而非整个逻辑。

Actor模型理念跟面向对象一致

Actor 模型其实本质上也是符合面向对象编程的理念的,面向对象编程中

  1. 对象也是同时封装了状态和行为的单元。
  2. 对象和对象之间通过『消息』进行互相操作

其实在面向对象语言的鼻祖 Smalltalk 中,方法并不叫方法,而是叫『消息选择器』(Message Selector),故名思议就跟函数式语言中,对消息结构进行模式匹配一样。

JavaScript 同样是一门面向对象的语言,是完全可以和 Actor 模型结合起来的。

把前两点结合起来举例,在 Nodejs 中,一个 HTTP 请求往往会对应到自己的一个上下文 context,里面包含了请求request和相应response的对象。这种封装的计算单元就有了 Actor 模型的一些基本理念,像 Koa 中更是使用了 generator/yield(将来可能是 async/await)来简化控制流。

我们可以得到一个理想的单进程内的 Actor 模型

KQRGE}1IRHRI9_M8P{V}W9C

其实上图用一般的面向对象和类来理解也是非常简单的,对吧?

可以优化错误处理以及容错性

在 Node 中,由于控制流的混乱,很难确定出错的位置,有时候出错也会导致整个进程的 crash。而有了 Actor 之后,错误的范围就可以聚焦到 Actor 上,而不会像原来那样找不到出错的位置。同时,也可以引入类似于 Erlang OTP 的 Supervisor 机制。Erlang 的理念是 Failfast,但是Erlang 中的代码出错之后,会有监控者进行善后。

分布式

Actor 模型的理念具有天然的分布式潜力。如果在 Nodejs 中能有良好框架的支持,让跨进程的消息传递变得透明的话,那么在各种应用上的 Scalability 都会有极大的提升。一般 Web 服务的 nodejs 层那样是无状态的,横向扩展比较容易,加服务器就够了,而写长连接的 nodejs 应用比如聊天室的时候,为了实现 nodejs 层的横向扩展,不得不通过更后端的诸如 redis 来实现跨进程通信,更后端的压力更大,也由于中转导致延迟更大。甚至在某种程度上,我们可以实现在不同服务器之间的动态调度。

有了透明的分布特性之后,同时高可用性也更容易达成,我们可以将 Actor 的状态,跨进程/机器去进行 Replication,当某个节点 crash 之后,可以在 replication 的节点上重启相应的 Actor。

L$7%A7B]C8VKFN2BRJP8STJ

(图片来自网络)

解决方案

在众多 Actor 模型的解决方案中,使用 Fiber 是跟 Reactor 最为自然的搭配,因为 Fiber 就是封装了一个计算过程,并且可以根据情况将 Fiber 暂停和恢复,这就可以通过 Reactor 中的非阻塞的特性,利用事件机制将活跃的 Fiber 唤醒,将需要等待的 Fiber 暂停。我们可以很容易的通过对 Fiber 进行封装,在 Nodejs 中实现 Actor 模型。像 fibjs 就能很好的完成这一任务。

但我认为 Actor 模型并不一定非等需要使用 Fiber,只要内心包含相应的理念,即使只使用 Promise,async/await,也是完全没有问题的。

Virtual Actor

微软提出了一套新的理念称之为 Virtual Actor,非常接近于我所追求的框架和平台。

Virtual Actor在基础的 Actor 模型上增加了几点:

  1. 实例化后始终存在,自动 replicate 到其他节点。
  2. 不活跃的 Actor 可以进行垃圾回收或者被持久化。
  3. Actor 位置透明,任何节点之间都可以互相访问
  4. 自动 Scale Out

RMV7Y~QEWMZ_[}K93``VQ(Q

目前实现了 Virtual Actor 的框架有,微软.net 平台的 Orleans, Java 上也有开源的 Orbit。并且 Orleans 的平台在微软内部有很多的实际应用,包括 Halo 的服务器也应用了,并能达到上百万的在线。

相对于 Erlang,Akka 之类的基础 Actor 平台,Virtual Actor 更为简单易用,而 Erlang 由于更加底层,能够对自己的应用进行更好的调整。

如果 Nodejs 也能出一套类似于 Orleans 的框架,我觉得对于 Nodejs 实现更大系统有极大的帮助。