狗池历险记(五)

五、包工头

  到 12 月 1 日,我们已经大致搞明白了比特币的原理,也知道矿池要做的事情,我手痒先设计了一个能用的矿池架构。这个架构主要有四个部分:钱包通信、矿机通信、主逻辑和 Web 界面。这些部分的功能是这样的(请跳过以下无聊的四段):

  钱包通信,顾名思义就是和钱包客户端通信了。比特币是在 P2P 网络上建立的,而其钱包客户端就是其中的一个普通节点,也就是说,这个客户端有着完整的功能。比如转账,比如宣布挖矿成功。我们也能从钱包客户端里面读取到当前虚拟币网络的任何信息。

  矿机通信,顾名思义就是和挖矿程序通信了。功能很单纯,有新的挖矿任务时,就给矿机发放任务;矿机挖到 share 时(下面会介绍什么是 share),就解析数据,并拉去检查提交。

  主逻辑,顾名思义就是主逻辑了。这个模块最初设计的时候是为了打通各模块之间的数据流,确保有新任务的时候可以及时通知到所有矿工。比如矿工算出新块了,要第一时间告诉钱包,及时同步到虚拟币网络。主逻辑的设计思想是尽可能抽象和简洁,随着后续的优化,主循环里面一共只有 20 多行核心代码。

  Web 界面,顾名思义就是个网页了。为了让矿工相信我们不是黑池,得把所有挖到的矿以及每个矿工的收入公开透明地展示出来。这个模块非常独立,上线之后才开始做。


architecture
最早规划的模块结构图(后期经过优化已经有所改变)

  我给自己封了个包工头的职位(史上亲自干活最多的包工头,本章标题就是为了纪念这个唯一出场机会的),由于整个设计思路数我最清晰,所以各个模块之间的协调由我来定。具体在开发过程中,每部分又可以继续拆分出一些独立模块,最后分出了八个独立模块大家一起来写。我写主逻辑以及矿机交互;D 神写分钱机制以及钱包通信;H 神写 share 验证;R 神写数据库接口、share 统计、Web。四个人,两周的业余时间基本都在开发矿池了。

  其实嘛,对于码农来说,编写矿池这几天完全就是“日常”,最没什么可以回忆了。基本都是,提出方案,讨论优化,然后敲代码,测试。不过,有些细节设计还是值得分享一下的。

狗池

  都写到第五章了,还是没说狗池是什么,现在终于要揭秘了:狗池就是我们做的矿池的名字。“池”肯定就是矿池的意思了,那为什么叫“狗”呢?我们在选择编程语言的时候,R 神和 F 神同时建议使用 Go 语言,可以应对“百万级”矿工的连接。D 神:“于是就叫 GoPool,简称狗池。”R 神:“贱名好养活。”于是名字就这么定了……不过后来因为 gopool.net 被注册了,我们只好抢了个 gpool.net,中文名还是不变。

  顺便插播一段漫画调节一下枯燥的氛围。Go 语言的吉祥物其实是 gopher,就是下面左边这个很萌的形象,后来 X 神为 Web 界面上每个功能都设计了一个对应的 gopher 风格的插图,后面不定期插播这套插图,先放一个首页的插图。


gopher首页插图
gopher以及矿池首页插图

share

  前面提到了 share,这是一个在矿池挖矿特有的概念。之前提过,矿池的设计目的就是让小算力的矿工能按照他们出的力分钱,从而得到持续稳定的小额收入。那怎么评估每个矿工出的力呢?其实思路很简单,就是让矿工做一些低难度的“挖矿”任务。比如比特币需要矿工找到一些前面有 67 个 0 的 hash 值,那么矿池可以降低难度到 50 个 0,如果矿工找到一个至少有 50 个 0 的方案,就可以提交,这个难度就小很多了。矿池如果在里面发现有 67 个 0 的,就可以提交给比特币网络了。质数币也类似,只是不以 hash 前面的 0 为难度衡量指标了,而以对应质数序列的长度为目标。质数币网络需要我们找到长度为 10 的序列,矿池就把难度降低到 6。这种矿工提交的低难度方案,就是 share。share 里面可能会有难度符合虚拟币网络要求的方案,就可以变成区块。

  这里还有个有趣的地方。矿工会不会在算到低难度的 share 时,就提交到矿池蹭分红,而在算到难度满足区块的要求时,直接擅自提交独占成果呢?其实这是不行的。还记得最早提过的挖矿其实在计算 hash(“基准字符串”+“随机字符串”)么,里面的基准字符串已经编码了:这个矿挖到之后是分给谁的。所以对于矿工而言,要么参加分红,要么自己挖矿,没法两者兼得。

分钱

  虚拟币矿池的分钱策略有两种现成的方案,PPLNS 和 PPS,具体可以看这个介绍。我们最后考虑到编程实现上的便利,改造了 PPLNS 策略,按照最近一小时的 share 数进行分配。对于矿工而言,PPLNS 手续费更低,只要收入稳定,一般都会选手续费低的。

  对于矿池而言,分钱还需要考虑另一个问题,那就是在哪分钱。这是什么意思呢?在虚拟币世界里有两种方式可以得到钱,一种是挖矿获得,另一种是别人转账过来。前面提到“基准字符串”里面编码了挖矿成功之后钱分给谁。如果是第一种方式,可以直接按照之前矿工的算力投入编写分钱方案,挖到矿时直接分给矿工。如果是第二种方式,则挖矿的收入全给矿池,之后通过转账的方式,把矿池里的钱转给矿工。

  这两种方案其实各有优点,前一种矿工可以及时看到收益;后一种按需取款,避免钱包都是碎银子……可能有人会觉得虚拟币钱包里的钱不就是个数字么,多笔小额的收入有什么关系。其实还真有关系,虚拟币用钱(给别人转账)的时候,需要说清楚,这笔支出的钱,分别是从哪几笔收入里来的。当然这些工作都是钱包客户端自动完成的。不过大量的碎银子会拖慢钱包的速度,甚至有可能导致转账数据包太大,而需要缴纳额外的手续费。

  我们最后采用的是前一种方案,因为该方案挖到的矿都直接分给矿工了,而矿池就不会存有大量虚拟币,也就不会成为黑客的攻击目标了。(后一种方案钱全在矿池,可以携款潜逃 23333)

  简单总结一下整个开发过程中的一些想法,产品设计上,我们第一目标是降低自己的风险,第二目标是为矿工提供稳定的收入。技术设计上,目标就是低成本(代码量和服务器成本),高性能。虽然这个目标不一定能泛化,但是在当时的情形下应该还是比较适合的。

p.s. 作为一个包工头,每天的 push 是必不可少的,那几天我的口头禅是“今晚上线”。然而这并没什么卵用。

2 评论

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注