从HiveSQL被攻击说起

一些天以前曾看到有朋友在微信群里提到HiveSQL被黑，当时我还不以为意，因为我以为的被黑是被插入一些脏数据，查询时会导致一些错误结果，我以为这对我使用HiveSQL毫无影响。

(图源 ：pixabay)

没错，我偶尔使用HiveSQL查询一些链上数据，比如说代理呀、投票呀、转账信息以及一些自己的文章等等。但是查询这些信息只是作为参考，并没有使用这些信息作为依据来进行一些涉及金钱方面的操作（比如根据代理发放利息等），所以至少不会因为数据被篡改而损失金钱。

但是这两天当我想查一些信息时，发现HiveSQL完全无法链接，想起前几天群里提到的被黑的传言，赶紧跑到HIVE开发者聚集的聊天频道看一眼，发现了@arcange给所有人的关于HiveSQL的情况说明，主要有两组信息。

第一组信息是在2月11日发布，大意如下：

当日早晨@arcange的HIVE基础设施遭到黑客攻击，服务器被关闭并在进行了硬盘级别的加密。更惨的是，黑客绕过层层防线，访问且加密了备份设备。这导致了HiveSQL等服务均无法使用。@arcange已报警，且正在上传异地备份至新的基础设施上，但是由于数据量超大以及带宽限制，传输和恢复将需要几天的时间。

第二组发布在2月17日，算得上是一些好消息吧，大意如下：

超过5TB的离线备份数据已经上传至服务器，并用了一天多时间恢复备份。由于备份是几个月以前数据，所以还需要一些时间来同步。一旦HiveSQL恢复可用，将会立即通知大家。

首先强烈谴责黑客的攻击行为，并感谢@arcange的辛苦工作，以往做服务器的时候我也经常被攻击或者被黑，这绝对是个让人焦头烂额的事情，有时候为了解决问题，真的是几天不眠不休。

然后就是希望HiveSQL早日恢复正常，继续造福广大HIVE上的开发者等用户。虽然区块链上可以查询各种链上数据，但是涉及一些历史数据或者需要做一些计算、统计等工作时，HiveSQL还是非常方便的。

(图源 ：pixabay)

再有就是HiveSQL被攻击导致不可用，让我想起一个词汇，单点故障（英语：single point of failure，缩写SPOF），维基百科上介绍如下：

单点故障是指系统中的一旦失效，就会让整个系统无法运作的部件，换句话说，单点故障即会引起整体故障。

虽然没做过具体调查，但是应该有很多用户以及很多服务依赖于HiveSQL，比如我除了直接连接HiveSQL查询一些数据外，cutehive.com上的一些功能，比如Delegations Check就是通过HiveSQL来查询Delegations (In)。

而且我不止一次构想过在我的一些脚本中加入HiveSQL数据查询，并根据查询得到的数据进行相应的处理，让脚本更加高效且智能化。但是由于懒惰一直只限于构想。

当然除了懒惰之外，也担心HiveSQL发生类似这样的错误，那么我就又得去改写脚本啦。以前在一些脚本中使用过@furion的steemdata数据库，后期数据库经常出错，我经常改写脚本，到之后steemdata服务关停，我的脚本全作废了。

事实上，HiveSQL稳定地运行好多年，我也坚信@arcange能妥善地解决此次问题，而且历经风雨，HiveSQL将会更加稳定和安全。

但是从开发者的角度，我们却不得不重视单点故障的问题，不能把鸡蛋都放到同一个篮子里。区块链本就是分布式系统，以节点为例，有很多公共节点提供服务不说，自己也可以运行私有节点来实现快速、高效、稳定的查询和处理操作。

所以在程序中使用数据库功能，也不应该完全依赖于一个数据库，最为安全的方式，应该是基于应用的实际情况，实现自己的数据库，比如很久以前，我曾经把自己的所有文章放到一个ACCESS数据库中，并用MFC做了一个界面来操作（更新等）以及查询。

所以类似于根据代理HP数量发放利息的程序，安全的做法是维护一个自己小代理数据库，根据区块信息实时更新，因为只针对特定账户的指定类型数据，所以代码量应该并不大，实现起来也并不困难。

(图源 ：pixabay)

当然了，说起来比较容易，但是实际要做的话，首先克服懒病就比较难。还是希望HiveSQL早日恢复，继续造福我们这些懒人吧。