Libra 币

Share
蹭热度一时爽,一直蹭一直爽

昨天FB宣布了他们自己的数字货币Libra 币。各路新闻纷纷报导顺带着把FB的股价推高到了194。昨晚的新消息是各路机构开始呼吁要对Libra加强监管,审查等,又把股价拉了回来。

那么问题来了,要知道市面上各种币数以十万计,为啥偏偏Libra币就能突然爆火?就凭他爸是FB?

简单来比对一下Libra币与其他数字货币

储备金支持

数字货币被人诟病的问题之一就是背后缺少储备金支持,导致空气币满天飞。这家吹完自己的一个币能够在北上换一套房,那边就敢吹自己一个币就能让马一龙带你去火星转一圈。与之相反Libra背后有着储备金的支撑,换句话说就类似你把钱存进银行,你的账户上多出来的数字是有着真正的金钱对应的。所以风险相比其他数字货币低很多。

稳定币

Libra号称稳定币,会与当地法币依一定比例稳定兑换,因而相比比特币更具有交易属性。比特币的波动性使它的投资(机)属性远大于交易属性

挖矿

根据白皮书所说,Libra Coin 的唯一获取途径就是通过法币向Libra 机构购买(是不是很像Q币?),并且销毁途径是用Coin从机构回购法币。而非比特币通过奖励的coinbase来增发新币

交易速度

未见白皮书披露Libra具体交易速度,但是第三节开头有提到可以支持十亿级用户量交易。相比,比特币的每笔交易需要经过约一小时的时间来确认交易记录在主链上。因而Libra相比比特币更具有日常交易属性。

匿名

与比特币一样,所有账户均为匿名

去中心化

虽然Libra标榜自己去中心化,但是从其白皮书而言,我个人的感觉是它更类似于以寡头(机构)为中心的“伪去中心化”数字币。原因有二:
一,寡头完全掌握铸币权
二,白皮书并未披露如何决定所提到的Libra 币与当地法币兑换比例,但推测应有寡头(机构)决定。

从此两点来看,寡头(机构)在Libra币交易中充当一个“应被绝对信任”的角色——有权发币,有权定价。

无国界货币

Libra在发布初期,构想是做无国界货币。最终目标是一处换币,处处潇洒。主要受众大多是移动支付不发达,本地法币波动性大,甚至不存在银行的不发达地区。但是考虑到如果一个地区落后到不存在银行,它的配套设施(网络,带宽,线下购买渠道)很难支撑Libra交易。很可能会面临的一个局面是:发达国家用不着(有自己的联储,货币保值),落后国家用不起,发展中国家不敢用(想想97金融危机?)

监管

白皮书未披露如何监管交易/账户/外汇。这也是很多人对Libra不看好的原因——技术并没有重大突破,瓶颈在于如何通过监管许可。

总结

从Libra的描述上来看,FB对Libra的构想是它能够成为新一代的交易货币而非比特币之类的投资大于交易的投资商品。如果Libra能够解决监管上的问题,那么其未来不可限量。否则,可能只依靠FB的噱头赚一下眼球,然后泯然众币矣。

Read more

低绩效同事,先别急着下结论

低绩效同事,先别急着下结论

团队里最难处理的,往往不是最差的同事,而是那些卡在board line上,挤挤能出活、但不挤就磨洋工的low performer 同事。 这类 low performer 一出现,很多Manager的第一反应就是:ownership 不行。问题是,这句话太空了,空到几乎没法行动。 我更喜欢用一个简单的框架看这件事:先判断原因,再调整支持,接着设观察期,最后做去留决定。 先判断:到底是哪一类问题 low performance 不等于 low ability。常见情况其实不一样: * 不会做:能力还没到,拆问题、推进、沟通都卡住。 * 不想做:知道怎么做,但投入不够。 * 做错方向:很努力,但目标理解偏了。 * 岗位不匹配:人不差,只是不适合这个角色。 比如: * 一个同事总是晚交,但每次都能把问题讲清楚,可能是任务切太大了。 * 一个同事总返工,

By andy

Vibe coding 之踩坑记

Vibe coding 对于程序员的技能要求反而比之前高了 先讲一个故事。 我这几天突然被隔壁组叫去,帮他们解决一个支付系统的问题。 简单来说,我们的客户分成机构和下属的医疗场所。一个机构下面可能有多个场所,然后机构可以统一管理下属场所的账单,支付等等。这样就需要我们能在我们的支付系统里面建立一个关系树,让父结点能看到子节点的账单,并支付。 问题就出在这个关系树上。因为我们之前用过一个另外的支付系统,所以有一部分老客户是从之前的系统迁移过来的。 这个老系统给每个客户创建了一个独特的id,但是这个id 和我们内部使用的id 并不一致,所以我们需要自己把客户的id 和他们的支付账户连接起来。然而: * 新的支付系统只支持固定的一些属性进行搜索。所以之前做这个项目的工程师A耍了个小聪明,用客户的last-name 属性存储了我们的id * 第一个雷:用户的last-name是可以由用户自行修改的。如果他们修改了,我们的对应关系就乱套了。 * 但是这个id A存错了,应该存储机构的id,A存成了下属场所的

By andy

关于flashblocks

争取整个短文系列,迎合短视频的潮流。 base前段时间整了个活,提出了一个新的概念叫flashblocks。 在有flashblocks之前,每个区块的状态是要么这个区块还不存在,没法拿到区块的任何状态和信息;要么就是这个区块已经存在了,它的状态是不可变的,拿到就是最终区块。base链每2秒产生一个新的区块,即任何的交易需要2秒钟才能确认。 如下图,区块A生成之后,2秒内用户只能看到区块A,直到区块B生成。 flashblocks呢,它允许用户提前获取正在打包的区块的状态。正在打包的区块每200ms更新一次状态,直到10次更新之后,正在打包的区块变成一个完整的区块。 如下图,区块A打包200ms后,用户可以立刻看到区块B的状态0. 再200ms后,可以看到区块B的状态1,直到区块B的状态9,然后区块B稳定,开始生成区块C的状态1。 flashblocks的好处是什么呢?它可以在一个区块完全打包好之前,让用户提前知道自己的交易是否有被打包进当前的区块,加速交易状态的确认。 缺点又有哪些呢? 首先这个确认属于预确认(preconfirmation), 这个预确认还没有状态更新

By andy