说说我持有的域名背后的故事（十二）

ety001 (72)in #cn • 5 years ago

今天要一口气说五个域名，所以文章会很长。今天说的五个域名分别是：stellarbot.top、stellarpay.top、steem-lightdb.com、steemeditor.com、steemtools.top。

之所以要把这五个放在一起说，是因为这五个都是跟区块链相关的域名。含有 Stellar 字样的是两个 Stellar 链的项目，另外三个则是 Steem 链的项目。

故事要从2017年底的SBC（恒星挑战赛）说起。SBC是恒星链面向开发者的比赛，目的是通过奖励开发者的项目，来提高恒星链的应用丰富程度，以及自己的知名度。比赛每个季度一评奖。当时我是拿到了2017年第四季度的奖励，大约 58000 个 XLM（即恒星币），参赛的项目就是 StellarBot（点击阅读原文可以查看我当年比赛的贴子）。

StellarBot 是一个简易的网格交易机器人，可以自动在 Stellar 链上进行买卖交易，提供简单的做市效果，并能随着使用者的增多给链上交易带来可观的流动性。实现思路也是很简单，大致就是基于当前买一和卖一价格，向上向下x%计算出一个下卖单和买单的价格，下单之后等待成交，其中超出 x% 范围的时候，会自动取消不符合的订单重新下单。

由于所有参加比赛的项目没有类似的东西，所以我很幸运的拿到了奖金，虽然不是大奖，但是数目很客观，58000 个 XLM 按照当时的市价 6 块全卖掉的话，也有30多万现金了。可惜的是我只卖了8000个。不过这个奖金也让我决定了接下来的一年自己搞点东西看看。

当时离职的时候，还写了个贴子，《今天正式离职了》，立了个碑。然而等到操蛋的2018年过完，发现帖子里说的事情一个都没有做，都被 Steem 给占去了时间。这个暂且不表。

既然离职了，就有了很多的时间，在第二年，即2018年，又参加了一次 SBC，于是就有了 StellarPay 这个项目。

这个项目核心就是在 Stellar 链上做一个类似支付宝这样的中心化支付网关，降低用户使用难度。但是似乎所有人对此并不感兴趣，因此也没有得奖。于是这个项目就死掉了。之后总结，觉得这种方向的项目，显然不是一个穷人就能搞的成功的东西，况且支付这种东西，世界上的大国都管制很严，因此这个项目也就没有了存在的意义。

在 StellarPay 之后，着了魔一样的想要去整理 Steem 链上的数据，于是就有了前文说到的计划一个都没有执行，都被 Steem 耽误了。

区块链最有意思的特性就是数据是按照时间发生的顺序去入库的，这就会产生一个问题，那就是检索数据很费劲。这就像数据结构里的单链表，你要在区块链的原始数据中查找个数据，需要从头一个块一个块的去找。

因此，工程师们会在区块链节点启动的时候，去从第一个块开始进行数据整理，把线性的数据整理为多维度（多索引）的数据集，然后存在内存里面。这样再找数据的时候，通过设计好的索引就可以快速检索数据了。

对于像BTC这样的只涉及转账信息的链来说，及时运行了这么多年，他们的数据还是有限的，现代计算机的内存还是能很轻松的去应对。然而 Steem 链做的是内容链，可以理解为是一个区块链上新浪博客，且用户来自世界各地。这种社交信息的爆炸增长是 Steem 开发者最初设计的时候不曾考虑的，这就导致目前要运行一个 Steem 的全节点需要至少256GB的内存。

同时由于社交平台的信息多样化，所以信息维度很多，而 Steem 最初的开发者，并没有设计很多的索引方式，这就导致现在想要检索一些数据的时候会很复杂。于是社区就有一个 SDBS 的项目，来把数据整理进 MySQL，而不是放入内容里。

不过 SDBS 项目我在运行的时候，经常遇到数据入库的时候有报错，尝试去修复，但是我发现去修复不如重新写，所以就有了 SteemLightDB 这个项目（steem-lightdb.com）。

鉴于 Steem 链的金融数据结构和逻辑我搞不清楚，为了快速开工，所以计划从社交数据入手，社交数据的逻辑结构对我来说理解起来相对轻松很多，这也是为什么我称其为 LightDB 的原因。但是我却莫名的陷入了研究时间线的疯狂中，这也是导致项目失败的很重要的原因。

就像我上面说的，区块链的原始数据是一条时间线，我最初的第一版程序，就是按照时间线来整理，结果运行起来，发现要把到当前时间节点以前的数据（大约不到200G）都整理完需要好几个月。当然这与我使用PHP，以及代码设计有关，有优化的空间。我换成了Python，在入库方面也做了优化，但是效果并不理想。主要是 Steem 的数据都是只增数据，而我非要想做成可删改的模式，这种执着，让数据入库这个环节的优化很难。

之所以执着是为了后期使用数据的时候不蛋疼。举个例子来说，当你修改 Steem 的文章时，并不是去改你之前已经写入区块的数据，因为这就违背了区块数据不可篡改的规则，区块签名也会变动。所以修改文章的操作其实是比较你修改后的文章和之前的文章的差异部分，然后把差异部分写入区块。如果是只增模式，入库优化很简单，但是如果是允许删改模式，那么怎么批量入库数据就很麻烦。

接着我办了第二个很魔障的事情，就是想要用多进程打破时间线。

既然一条时间线很慢，我把社交数据按照维度拆分到几条时间线里去执行不就可以了。为此，我付出了差不多两个月的不休不眠。最终失败了。因为不同纬度之间的数据有因果，如果一条时间线上的果跑到了另一条时间线的因的前面，就不得不等着另外一条时间线的因先发生。其实最后还是绕不开因果。

后来回过头来想这两个月过的就跟傻逼一样，就像傻逼在做哥德巴赫猜想，不同的地方是哥德巴赫猜想有证明的可能，时间线上的因果根本不可能被打破。

这个项目让我很受伤，尤其是信心，至今未愈。当时分文收入没有，一心想着快速验证项目的，结果却因为自己错误的选择陷入泥潭中，这也是心态崩溃的原因之一。

修整了一个月后，紧接着又开发了 SteemEditor 和 SteemTools 两个工具，也就是后面这两个域名 steemeditor.com 和 steemtools.top。

在修整的这一个月，思考了很多。我发现作为一个面向文字创作者的平台，编辑器烂的跟屎一样这是不对的，于是就有了 SteemEditor 。虽然 SteemEditor 没有做到我的心理预期，跟尿一样，但是终究比屎好了很多，所以这个项目现在还在运行着。不过就是没有人用，因此也不再继续开发了。

而 SteemTools 则是借助微信服务号来提供 Steem 消息提醒服务，毕竟由于区块链本身的原因，并不具备消息提醒的功能。如果一个社交系统没有消息提醒功能，那还是社交系统吗？这个项目有几个用户在用，但是随着我自己的公司注销了，服务号没法认证了，就迁移给了国内的 WhereIN 团队，现在访问 steemtools.top 里面的二维码指向就是 WhereIN 团队的服务号了。

几个 Steem 的项目搞完，2018年就过完了，最初设想的计划一个也没有去实施。再后来到了2019年初，对于这个我投入了几乎一年时间的 Steem ，我思考了很多，我觉得这个体系是有问题，于是我就弃坑了，由于今天的篇幅实在已经又臭又长了，就等以后再有时间开个贴子单独聊吧。

五个域名基本上就是我一年多忙忙碌碌的缩影了。收获了很多，尤其是重新的进行了自我认知，懂得了什么叫做不自量力。

好了，到这篇为止，目前我所持有的所有域名背后的故事都讲完了。明天会有个终结篇，来进行一次总结和结尾，欢迎关注！

系列文章索引系列文章索引

ET碎碎念，每周一，晚六点一刻更新，欢迎订阅

感谢你的阅读，我是中文区见证人之一，欢迎通过 SteemConnect 来给我投票，或者打开 https://steemit.com/~witnesses/ 页面，输入 ety001 进行投票。

中文区的见证人目前有：
支持一下他们（按字母顺序），一人可以有30票：

Thank you for reading. I'm a witness. I would really appreciate your witness vote! You can vote by SteemConnect. Or open https://steemit.com/~witnesses page, input ety001 to vote.