为什么要使用分布式存储/计算 现如今计算机需要处理的数据量越来越大, 然而摩尔定律却前正在慢慢失效中, 我们无法在维持成本不变的情况下制造出性能翻倍的芯片了, 这意味着人们要花比以前多得多的金钱才能造出能够处理这么多数据的机器.   既然如此, 人们就想到能不能把现有的机器集合起来协同处理这些数据, 达到更高效率;

用过 websocketpp 的同学都知道, 应用程序需要自己保存各个客户端的连接句柄, 这个动作一般是在连接打开后, 在 on_open 回调中将句柄加入自己的容器中, 然后在 on_close 回调中将句柄移除. 问题就在于这里选用什么容器. 一开始会想这还不简单, 无非就是 vector, set, map 嘛, connection hdl 这种东西用 vector 就行了! 这里用 vector

假设有 a, b, c 三个见证人轮流出块, 他们在出块的过程中可能会碰到如下的一些窘境. 首先是最简单的情况: a, b, c 第一轮出块很完美, 第二轮开始 a 基于 c 出块, 依然正常. 但是 b 可能恰好 c 和 a 的块他都没收到, 也可能是它自己确实是坏人, 总之这第二轮它的块指向了自己在第一轮出的块. 接下来 c 出块时 (假设 c 正常收到了所有消息), 他看到的就是图上这番景象.

本文基于 BM 的唯二的两篇阐述 DPoS 机制的文章, 第一篇文章是 BM 首次提出 DPoS 共识机制, 第二篇是 BM 后来对 DPoS 机制补充的白皮书. 两篇文章的链接见文末. 最近精读了这两篇文章, 从中提炼出了以下我认为是最核心的内容. 见证人选举与调度 DPoS 里最重要的两个部分就是见证人的选举以及调度出块. 见证人的选举靠持币人的投票, 并且是一币一票的规则, 持币量有多少, 投票权重就多大.

今天写了一段很 sb 的代码: socket_.async_read_some( boost::asio::buffer(recv_buffer_), [&, this](boost::system::error_code ec, std::size_t bytes_transferred) { if (!ec) { auto iter =

拜占庭将军问题是将军发起一个提议 (同时向各个副官分别发提议), 然后副官们决定采取什么行动. 区块链共识也是由一个节点发起一个提议 (基于当前最长链出一个块), 然后其他节点决定采取什么行动 (是否接受这个块). 在拜占庭问题最简单的模型中, 副官们所做的就是相互询问将军给的提议是什么, 然后少数服从多数决定是进攻还是撤退. 而在区块链共识中将军们做的是先验证提议本身是否合法 (区块的工作量是否满足阈值),

交易费用 操作类型不同, 所需费用也不同. 各项操作的费用记录在 global_property_object::chain_parameters::fee_schedule 中. 石墨烯代码将创世信息中的 inital_parameters::current_fees, global_property_object::chain_parameters::fee_schdule, 以及各项操作中的

API 注册这部分感觉又是 BM 炫技的部分, 之前数据库索引篇的各种泛型, 奇异模板, 递归模板已经让我抓狂了一次, 没想到 api 注册本以为很直观的东西, 竟然也搞的那么复杂, 真是累觉不爱, 本篇不做详解, 只陈述一下概念和流程. Graphene 的 api 被分为 login_api, database_api, network_broadcast_api, history_api, asset_api

git submodule 的那几个命令每次查完都记不住, 所以这次就在这里好好思考一下其原理, 希望以后不要再忘了. git submodule 的原理是在父模块中记录子模块的 commit, 并监控记录的 commit 和子模块的 HEAD 的差异. 父模块所记录的子模块 commit 属于父模块的版本信息, 这一信息的改变不会实际影响子模块的 HEAD. 当 cd 到子模块中做了一些更改提交,

欢迎大家继续阅读, 看完了上一节 节点实例 这个公共组件, 这节我们就来介绍一下比特股系统中最重要的部分 --- 见证人, 的配置与启动过程. 见证人配置 在 bitshares 中, 见证人功能是在 witness 插件里实现的, 类似的还有 cli_wallet, delayed_node 都是通过独立的插件提供, 这些插件的公共部分就是上一节我们介绍的 节点实例. 见证人在启动时依赖 config.ini

大家好, 本文正式开启架构篇. 如果你还有印象的话, 我们之前在 源码结构 中曾简要的介绍过 bitshares 源码中的每个模块, 这个篇章将会和大家探讨各个模块之间的调用关系, 节点运行时模块之前如何交互, 逐步为大家呈现出一条清晰地脉络. 与整个节点的运行最相关的要数 app 模块了, 所以 app 模块就作为架构篇的第一个模块在本文介绍. 下文中 app 模块我们将其称之为节点实例模块或者直接成为节点实例,

(首发于 sdnlab: 阅读任何一个协议都要注意的一点是这个协议中所定义的专有术语, 对这些术语的理解不到位的话也会造成对协议的理解偏差. 本文想和大家分享几个可能容易混淆的术语. 在 OpenFlow 协议文档中经常会看到这么几个词语: Instruction, Action, Apply-actions, Action Set, Action List, Clear-actions, ...

左值与右值 C++ 中左值和右值的概念来源于 C, 在 C 中左值和右值的区别很简单, 能出现在赋值号左侧的就是左值, 否则就是右值. 比如变量是左值, 字面常量或者 const 定义的常量是右值. 然而在 C++ 中, 左值和右值的区别就不再是那么简单了, 甚至和 C 还会有冲突, 比如在 C 中 const 定义的常量对象是右值, 而在 C++ 中却是左值. 实际上在 C++ 中左值和右值的情况非常复杂,

今天碰到一个奇怪的问题, 在这里记录下来. 我的 U 盘上有一个分区, /dev/sdd1, 这个分区本来上面的文件系统是 FAT32, 在 fdisk -l 的输出中可以看到, 最后的 System 字段是 HPFS/NTFS/exFAT. 然后我使用 mkfs 将其分区格式化为 ext4 格式: mkfs -v -t ext4 /dev/sdd1. 然而再次运行 fdisk -l, 发现最后的

2013 年, 全职挺进区块链行业. 在 bitcointalk 上找到了 Adam Levine 和 Charles Hoskinson 一起开发了 bitshares 2014 年发布 Bitshares 第一版, 沿用了比特币的数据库技术和 UTXO 思想, 导致性能不好, 不能跑什么实际应用 2015, 首次提出, 从 “So how does Delegated Proof of Stake

从现在开始我们进入一个新的篇章: RPC 篇, 这个篇章会包含客户端 (钱包, UI 等) 与节点间的通信细则, API 分类, 服务端的实现等内容, 最后会挑几个主要的 API 讲一下. 本文是 RPC 篇的第一章, 我们就先来介绍一下整体的通信机制和服务端 (节点) 实现. 通信协议 Bitshares 提供两种通信方式: http 和 websocket. 这俩最大的区别就是 websocket

见证人节点起来之后, 会周期行的检查是否轮到自己出块了, 判断自己是否能出块的逻辑在 maybe_produce_block() 方法中, 这里面的第一步就是判断自己是不是和网络同步了, 同步了的话就继续下面的判断, 没有同步的话就直接返回 not_synced错误告诉外面不要出块. 211 block_production_condition::block_production_condition_enum

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

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

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