Graphene 源码阅读 ~ 数据库篇 ~ 区块数据管理 在 bitshares 中除了对象数据需要落盘之外, 网络上接收到的区块数据也是需要落盘的, 区块数据的管理依赖的就是 chain::block_database 模块. chain::block_database 这个模块听起来好像很复杂 - 毕竟管理着区块数据的落盘与加载, 但实际上非常简单. 它维护了两个文件流: _blocks 存储具体区块数据,

大家好, 欢迎来继续阅读数据库篇的第 5 篇 - 对象索引库, 这个名字可能听起来有点奇怪, 什么叫 “对象索引库”, 实际上是根据 object_database 这个模块的功能直译过来的, 因为 object_database 管理的是 bitshares 中所有的对象, 而且这些对象数据又直接存储在索引中, 所以本章就叫 “对象索引库” 了. 到后面我们会说到在数据库篇里除了对象数据, 还会有区块数据,

This release contains several security fixes. All nodes please upgrade as soon as possible. Detailed info and binaries for download: Note: libcurl-dev is a dependency since release 2.0.171212. For Ubuntu,

Genesis 生成 egenesis 最前面的 e 代表 embedded, 意思是说创世信息嵌入代码中, 它有两个 full 和 brief 两个版本, full 版本包含所有创世信息, brief 只包含这些创世信息的 hash (创世信息的 hash 也是 chain_id). full 和 brief 的生成靠的都是下面这段 make 脚本. //

C++ 自身的 RTTI 提供了两个操作符: typeid 和 dynamic_cast<>, 但这俩操作符的作用都仅限于运行时得到类型名而已, 很多时候尤其是对象序列化操作时, 光知道类型名是不够的, 我们还要知道类成员的类型, 成员名称等信息, 所以还是要靠各种编程库实现反射功能. fc::reflector 就是石墨烯代码中反射实现库, 前一篇 对象序列化 里已经多次提到了, 可能严格来说,

虽然 graphene 的代码我还没看完, 但我敢说 <fc>/io/raw.hpp 肯定能算得上 graphene 代码中最难读的部分之一. 实际上 fc 整体都是比 graphene 其它部分的代码要难读很多的 (见 源码结构). <fc>/io/raw.hpp 对 C++ 模板的运用可谓无所不用其极, 说是达到了丧心病狂的地步可能也不为过, 单单一个 pack() 方法,

最近这一周一直在研究共识机制, 本来想先写一篇共识篇的, 无奈共识涉及到的东西太多, 一直没有构思好怎么写, 眼看着距离上一篇 对象模型 一文越来越远, 再不动笔有跳票嫌疑了, 所以共识篇就暂且往后放, 再来一篇数据库篇凑凑数. 话不多说, 让我们进入数据库篇的第二篇 - 索引模型 索引模型 从源码结构来讲, 索引和前一篇 对象模型 所介绍的 object 基类属于同一层级. 索引结构的定义位于

我之前向 bitshares-core 提交的第一个 PR 就是关于数据库的, 所以最先了解的就是数据库这块, 所以在写上一篇 源码结构 时我就计划先从数据库开始了. 本来想数据库用一篇文章介绍, 但今晚梳理了一下发现一篇文章不可能写得完.. 所以就有了标题的 “数据库篇 ~ 对象模型”. 类似的, 其它几个模块可见也不是一篇文章能说清的, 所以后面计划还会有共识篇, 网络篇, 钱包篇, 插件篇等几个篇章,

一般拿过一个项目我是习惯先了解一下项目的目录结构, 看一看项目是怎么组织依赖库, 构建脚本, 以及头文件和源代码文件的, 这样能够对整个项目结构大概有个数, 除了能够了解这个项目包含哪些模块, 模块与模块之间的调用关系之外, 还能在后面阅读代码时碰到对符号的引用时, 大概知道到哪里找它的定义, 对阅读和理解代码帮助会很大. 所以继前一篇 基础知识 之后, 本篇就来过一遍项目源码结构. 前一篇说了 Graphene

最近一直在业余时间看 Graphene 的源码, Graphene 是 bitshares 和 steem 的底层技术, 得益于 LMAX 架构和 DPoS 这一高效的共识机制, 使得基于 Graphene 成为目前最稳定和最高效的区块链底层. 接触区块链技术后, 我对区块链的各种共识协议做了很多浅薄的思考, 最后真的觉得 DPoS 共识才是未来的趋势 :P. 看 Graphene 的源码, 一方面是学习一下

Keyboard 世界上的键盘有很多种, 它们按键数不同, 针对的市场, 用途, 国家, 人群也不同, 每个人都希望自己的键盘以自己习惯的方式工作. 所以在 X 中, 关于键盘的配置也是很复杂的, 因此 X 将与键盘配置有关的部分放到了 XKB extension 中. 整个键盘的配置, 叫做 keyboard map, 或者 keymap. 一个 keymap 中包含按键的数量, 键盘 model,

localedef localedef 是用来生成 locale 的工具. localedef 能够读取 locale 定义文件, 以及 charmap 文件, 然后编译他们, 将编译好的二进制的 locale 数据库放在 /usr/lib/locale 目录里 (这个目录不是绝对的, 你可以通过 localedef --help 查看编译好的 locale 数据库文件放在哪里), 然后 Linux

安装这个 gentoo 从今早 11:00 开始, 一直到现在 (00:27) 才安装成功, 其中经历了几个曲折. 我的安装是按照 Gentoo 官方手册 一步步来的, 使用安装介质不是宿主机, 而是同样依照官方教程制作的 LiveUSB: 目标介质是一块 SSD 硬盘. 这里不得不说, Gentoo 的官方手册内容组织的非常合理, 让人能够一口气从头看到尾不遗漏任何内容, 而不是看几节就被纵横交错的链接给绕晕了.

以前一直以为, Wi-Fi "穿墙" 就是指 "绕过墙", 然后波长越长, 自然就越能绕过墙, 振幅越大的话, 自然是更能够绕过墙了. 实际上, "穿墙" 确实就是 "穿" 过去了, 不是绕过去. 因为电磁波能以各种介质传播, 空气里可以传播, 墙里也是可以传播的. 从波动性的角度讲, 穿墙的过程就是空气中介质的振动转化为墙介质的振动,

当有客户端连接, 而程序中没有去处理时, select 就回持续不断的返回这个文件描述符可写, 例如, 下面是我以前写的一段有 bug 的程序: int csocks[MAX_CONNECTION]; memset(csocks, -1, MAX_CONNECTION * sizeof(int)); FD_SET(sock, &rset);while(1) { if(select(FD_SETSIZE,

今天晚上注册了minnowbooster，并且进行了出售投票权的行动，在持续的30分钟之内，我的sp从100%下降到68%。这个过程中收获$ 5.680171SBD。 sp恢复到100%需要37小时，大概的算了一下，一天获得的利润是4SBD（不知道有没有算错，还望大神出来指点）。在steemit上借用了minnowbooster作为中介，出售投票获取利润甚为惊喜。 在此还要感谢@hushuilan的帖子

O哥在之前的扯淡系列文章中，强调了粉丝的重要，确切地说建议作者们珍爱你的真爱粉。如果一味的发些SPAM内容，那么你的粉丝终将离你而去。 对于读者而言，粉别人，然后只看自己追随的作者们的动态，这个好比是白名单操作。但是时间久了，总看相同的面孔同质的内容，难免腻歪，就好比整天吃开封菜和金拱门，一周之后再看到汉堡和炸鸡估计都想吐了吧？ 那么换口味是一件容易的事吗？且听我慢慢扯来。 (图源 ：pixabay)

kyber 号称去中心化交易所. 要解决的是韭菜在中心化交易所买数字货币流程麻烦的问题. 要经过注册, KYC, 充币, 等待确认, 提币 (手续费) 等待确认 等漫长的过程, 另外中心化交易所还常常 "被" 黑客攻击. kyber 怎么解决这个问题呢? kyber 本质是跑在 ethereum 上的智能合约, 其自己的代币也是 ERC20 代币. 智能合约的背后有很多

C 语言由于没什么高级的特性, 所以现有的特性被玩的各种精. 宏展开就是很值得品味的部分. 递归展开问题 宏定义语句是这样的: #define identifier token-sequence 在具体的宏展开过程中, 遇到标识符时, 此标识符会整个的被使用 token-sequence 展开, 如果 token-sequence 中还包含有其他的被定义的宏标识符, 也都会相应的被展开. 但是显然,

Here are my definitions of BTS nodes: Witness - Stores blockchain, limits CLI access to local port, provides p2p for blockchain downloads, generates blocks, and does not include history plugins Seed -