谈谈Libra

考虑下电商平台的折扣优惠券.

一件商品价格为P.
用户在购买时平台提供折扣抵用D.

那么用户实际的付出就是P-D.

这时候跟商家结算的时候就存在一个差值D.

而如果平台把D以广告流量折扣券的方式跟商家结算的话.
那么实际上商家手上持有的就是现金P-D和价值D的广告消费券.

也即是说名义价格P的交易,实际上真正参与流通的现金之后P-D.

如果换个角度.
把D看作是买家的存款利率,卖家的贷款利率.

那么上述行为就可以看作是.
在期初卖家贷款以利率D生产价值为P的商品.
然后买家在期末以本金P-D利息D的存款购买商品.
而平台就作为发钞/产生信用的央行.

然后把它跟Libra和其他crypto currency的监管问题放一起看.

Libra所谓监管问题的点在于所谓的发钞权.
以及以此为由的所谓的对央行权威性的威胁.

而实际上能产生信用的,跟是不是Libra或者是不是央行其实关系并不大.
而且也并不是说能产生信用的,就是央行所排斥的.

央行排斥的是对于货币政策干涉手段有效性的影响工具.

之前看到有个关于负利率的文章.
观点就是建立一套非现金的货币体系作为现金货币体系的补充.

因为在负利率前提下,可以通过持有现金规避负利率的调控影响.
而如果是电子货币的话,实际上就不存在这种形式上推出流通管制的可能.

所以Libra的问题在于,在给定各国货币政策的前提下,它会不会有所反应.

按照白皮书的说法是一种一揽子锚定的形式.

而关于它的可靠性/可控/可信程度,可能更形象的比喻就是当前的人民币.

这样的话,对于央行来说,Libra不过就是一个汇率问题.
而且某种程度上来说,可能更受央行的欢迎.

至少可以作为一种负利率的实施工具.

以及就当前crypto currency标配的gas概念来说,就是更为直观和细致的一个交易费用手段.

因为当前的利率控制手段的传导终端因为复杂性,多数也只能从银行间业务作为触发起始.
并不能直接地渗透到每一笔单独的交易当中.

而gas的则是一种更直观且更微观的一种手段.

且因为blockchain本身的匿名性或者说分布式形态,这种调控可能更为不易察觉/有效.

那么Libra的问题是什么.

因为目前来说,像Brave有所谓BAT(Basic Attention Token)的概念.
这个延伸下就是一个简单的量化程度的问题.

就目前的广告模式或者说互联网的盈利模式来说.
Libra可以把每一个动作和行为都量化为一个直接的coin/token价值.
对于content creator或者广告商来说,可以有实时且准确细致的消费收入明细.

这个的潜在问题就类似于SEo的问题.

要么或者即使跟Gooogle一样,把每一个行为的量化方式做得难以逆向.
但是从技术和数据上来说,不是不存在被game的可能.

这个可能还不是个太大的问题.
因为反欺诈/anti flaw并不算是一个可选的东西.

它的问题在于内容创造者和广告上对于最大化收益的一种动机.

因为它能够有办法知道如何去做能够最有效地获得收入.
或者更有效率地获得收入.

固然,这个可能是以更优化内容/更精准的targeting来做到.
但也并不能否认会往一个更坏的方向靠拢.

而从目前的所见来说.
可能后者会是个更可能的事情.

当然,这算不上是Libra的问题.
可能特定地对Libra的问题在于Facebook本身.

至于非特定Libra的问题,或者说Libra们的问题就是.
可能不是人人都能使用,而是人人都能发行.

关于Ceph的CRUSH算法

考虑crush map的bucket选择.

对于一个obejct o,choose的时候需要经过一个hash过程得到一个pseudo random的id x.
也就是对于任何一种bucket 类型,有
x = bucket_hash(o).

假定bucket的长度为n,x的放置位置为y的话.
bucket specific的choose policy为p.
有y=p(x)

对于uniform bucket来说,这个p为
y=p_uniform(x) = x % n

除了uniform的bucket之外,其他bucket type都是有weight权重的.
同样,记录位置w_i为位置i的用权重值,且有0<=i1的prod替换的sum.

也就是,这里的straw其实是一个权重放大倍数比list高得多的一个进阶版本.
而且跟list不同的是,它的argmax没有< w_j的条件限定.
因此它的寻址复杂度是O(n)的.
而list因为条件限定的情况,实际平均表现最差也只是跟straw一致.

在考虑现在ceph的默认policy,steaw2.
这里对hash做个额外的限定,0
这个主要是ceph的实现里有个lookup table的优化.
给定0
所以实际上starw2的hash是一个到[0,1]区间的一个mapping.
对应的log(k)取值区间大概是[-11,0].

所以这里简单重定义-11<=hash(x)<=0
则
y=p_straw2(x) = argmax(\{j; hash(x)/w_j \})

这里可以看出,只要bucket item的权重不变.节点增减的变化只由argmax的骨架部分决定.
这个跟list也有点类似,但是它是位置无关的.
不像list有对于左右有相对确定的基础cost估计.

但也因为位置无关,所以它存在一些极端情况.

对于节点减少的话,则所有argmax为这个节点的数据都会受影响.
这个是符合intuition的.

对于增加节点,argmax的max value可能都指向变动的那个节点.
这样的极端情况就是造成整体数据的挪动.

但是由于w_j的存在,这个也是可干涉/存在可控性的.

而对于节点数量不变,只是权重改变的情况.
跟节点增加类似.

所以,straw2的基本上算是忠实指向w_j的.

然后考虑hash.

由于hash会对x走一个log的重新分布.
所以实际上考虑的数据分布性质的话,只需要考虑log分布之后的就行了.

也就是在大概[-11,0]的区间内的数据分布问题.

把w_j作为一个tuning parameter/placement parameter考虑的话.
那么理论上,针对现有的实际数据分布是可以做到人工精确干涉的.

而且这么考虑的话,其实starw2的计算也并不需要搞那么复杂.

因为归根到底还是通过w_j来控制的.