ITPub博客

区块链系统中，去中心化程度与效率之间天然地存在矛盾关系。如果区块链智能合约系统想追求类似比特币的去中心化程度，理论上效率就会大打折扣。现实也是这样的：比特币每秒钟只能处理7笔左右的交易，每一笔交易要用至少30分钟才能确认，这种效率和速度是远远不如银行转账的。作为一个全球资产交易平台，比特币这样的效率或许可以接受，但对于智能合约平台这样的效率是远远不够的。因为在智能合约中，每一个动作都可以看成是一笔

EOS 最新的白皮书中已经将共识机制从 DPoS 升级为了 BFT-DPoS（Byzantine Fault Tolerance - Deligated Proof of Stake，带有拜占庭容错的委托股权证明），本篇文章将详解新共识机制的原理。传统 DPoSEOS 项目刚刚发布的时候的共识机制是 DPoS(Deligated Proof of Stake，委托股权证明)，类似于 Bitshar

到底什么叫“智能合约”？名词解释：本篇文章出现很多 “Action” 和 “Active”，Action （动作）为 EOS 中账户可以接受的动作，也就是别人可以对你做什么；Active 为 EOS 账户权限的一种。阅读本文前建议先阅读之前的文章：https://mp.weixin.qq.com/s/K6ClE1TDfH2hB7lbXOZUJA在 EOS 里，不论是真人用户还是智能合约，本质上都是

Hello World!稍微了解 EOS 系统，你就会知道 EOS 的智能合约基于 WebAssembly(WASM) 技术，这种技术在性能和跨平台兼容性之间取得了很好的平衡，通过将原始代码编译成字节码，使得代码可以在多种平台的 WASM 虚拟机（或者叫解释器）中执行。得到了苹果和谷歌等科技巨头的支持，被誉为下一代互联网前端技术。目前的 WebAssembly 技术支持 C/C++ 语言，并开发了

成为最早一批运行EOS的人复习一下上次文章的内容，EOS 系统主要有三个应用程序：nodeos： EOS 系统的核心进程，也就是所谓的“节点”。cleos:本地的命令行工具，通过命令行与真人用户交互，并与节点（nodeos）和钱包（keosd）通信。是用户或者开发者与节点进程交互的桥梁。keosd：本地钱包工具。可以管理多个含有私钥的钱包并加密。要求本篇教程适用于以下系统，但是不论你的电脑是 wi

写在前面，这一篇文章是许晓笛 2018.05.20 在北京 《IPFS开发者圆桌会议》上的发言实录，感谢主办方戴嘉乐和董天一的邀请，感谢编辑们。 先介绍一下《IPFS开发者圆桌会议》，创办人是戴嘉乐，前百度高级工程师，最早的IPFS工程师，一个会跳街舞的天才程序员，一个成功的价值主链投资者，能做学术研究也能做团队组织者，简直太全面了有木有。联合创办人是董天一，国内IPFS界不可不知的布道者，为I

Daniel Larimer 在最近的博客中透露，EOS 新增了官方的 WebAssembly 解释器，用来解释执行 WebAssembly 智能合约，加上之前的编译执行，EOS 智能合约有了两种执行方式。对于很多没有中间语言的（字节码）的编程语言来说，根本不存在解释执行与编译执行的选项，比如传统 C/C++ 只能编译执行，直接将代码编译成为可执行的二进制机器码，我们电脑上 .exe 文件就是编译

其实没有那么复杂相信关心 EOS 系统的同学肯定见过下面这张蓝图。对，目前只是一个蓝图，而且以 BM 的尿性，肯定在心理已经把这张图改的面目全非了（比如图中的 eosd 早就改名了）。所以这张图只能作为未来 EOS 发展方向的参考而已，目前的 EOS 还远没有这么复杂和完善。了解系统架构之前我们先看看目前 EOS 系统的主要组成部分：nodeos： EOS 系统的核心进程，也就是所谓的“节点”。运

EOS 数据库开发实战上次的文章详细讲解了 EOS 数据库的架构，本文将以官方示例为基础，详解 EOS 数据库的开发实战。基本步骤在智能合约里与 EOS 数据库交互，首先要定义存储的数据：定义对象：具体就是定义一个 C++ 类或者 C++ 结构体，数据表就由一个个对象组成。定义主键：在刚才的类/结构体中，定义一个const类型的成员函数primary_key()，返回值必须为uint64_t类型，

EOS 数据库结构详解在 EOS 中，智能合约执行完毕后，所占用的内存会释放。程序中的所有变量都会丢失。如果智能合约里要持久地记录信息，比如游戏智能合约要记录每位用户游戏记录，本次合约执行完毕后数据不能丢失，就需要将数据存储到 EOS 数据库中。与数据库交互的 API 被官方称为 Persistence API，中文可以叫做持久化 API。下图说明了 EOS 智能合约在执行 Action 时，与数

EOS 区块长啥样？对于一个区块链项目来说，最核心的数据莫过于区块数据，区块数据结构是整个区块链项目的技术基础。不过由于 EOS 项目一直在快速迭代，区块数据结构也不断更新，所以今天才向大家介绍。区块头（block_header）首先是区块头数据结构，包括了哈希、时间戳、默克尔根、见证人账户等。//区块头结构体 struct block_header {   &

EOS 针对以下两种情况设计了应急措施：账户被盗（私钥被盗或有权限的其他账户被盗）账户遗失（私钥遗失或有权限的其他账户遗失）1.账户被盗EOS 有可能会强制要求所有账户的 Owner 权限必须使用多签名，也就是说 Owner 权限列表里要有至少两个私钥或其他账户，这样就减少了因为单个私钥泄露而导致的危险。再配合转账延时，为用户找回被盗账户提供了时间上的可能。理解了上一篇内容的读者应该明白，EOS

在EOS系统中，有“两股势力”是整个系统最关键的因素，那就是项目方 和 见证人。很多人觉得EOS这个项目“奇葩”，就奇葩在项目方和见证人的关系上。EOS的项目方是BlockOne公司，创始人是BlockOne公司的首席技术官（CTO）Daniel Larimer，坊间称BM（ByteMaster）。BlockOne公司曾经多次声明，其公司只开发EOS软件，并免费提供给任何想使用软件的人，公司不负责

Daniel Larimer 在他的博客介绍了EOS新的智能合约架构（EOS团队的开发速度实在是太吓人，根本追不上）。他给出了最简单的一个新币种的智能合约代码，仅有49行就能完成一个新币种的开发，一个新的“爱息欧”就诞生了。让我们一步一步实现吧。首先实现私有成员，建立一个 account 结构体，这个结构体里保存的是所有持有我们这种代币的人的账户和余额。   priv

适用于最新的 EOS Dawn 4.0/4.1前言最近在研究 EOS 的 RPC API，但是由于官方API文档的不够详尽，新建账号（new account）这一个操作就折腾了一个多星期。皇天不负有心人，终于调通了新建账号，代币转账也轻松解决。特地写这篇文章（适用于 EOS dawn 4.0 和 4.1），帮助准备使用 EOS RPC 做 Dapp 开发的朋友，如有问题，欢迎批评指正。少废话，先看

详解 EOS 智能合约的 abi 文件这次向大家介绍 eosio.token 智能合约的最后一个文件 —— abi文件。ABI 全称 Application Binary Interface，中文名“应用程序二进制接口”，顾名思义是一个接口文件，描述了智能合约与上层应用之间的数据交换格式。abi 文件格式类似 JSON，具备很好的可读性，有利于智能合约工程师与上层应用工程师之间的工作衔接。eosi

详解 EOS 智能合约的 cpp 文件之前的文章介绍了 eosio.token 智能合约的 hpp 文件，这次向大家介绍 eosio.token.cpp 文件，cpp 文件即 C++ 代码文件，智能合约所有的业务逻辑内容都是在 cpp 文件中实现的。eosio.token.cpp 文件地址： https://github.com/EOSIO/eos/blob/master/contracts/eo

为了帮助大家熟悉 EOS 智能合约，EOS 官方提供了一个代币（资产）智能合约 Demo —— eosio.token。eosio.token 智能合约目前还不是特别完善，个别功能还没有完成。但这个示例合约给出了 EOS 官方智能合约开发的标准结构和开发方法，并且真正的 EOS 代币也会借鉴这个示例合约的逻辑，是 EOS 智能合约入门的经典案例。