示例代码

//demo.hpp
#pragma once

#include <eosiolib/eosio.hpp>
#include <eosiolib/print.hpp>
#include "json.hpp"
#include <string>

using json = nlohmann::json;
using eosio::contract;
using eosio::multi_index;
using eosio::print;

class[[eosio::contract]] demo : public contract
{
  public:
    using contract::contract;

    [[eosio::action]] void demoaction();
};

//demo.cpp
#include "demo.hpp"
using json = nlohmann::json;

// ACTION
void demo::demoaction()
{
    json demoInfo = R"(
    {
        "demoInfo": {
            "hello": "world"
        }
    }
    )"_json;
    std::string demoInfoString = demoInfo.dump();
    json demoInfoJson = json::parse(demoInfoString);
    print("It worked\n");
}

EOSIO_DISPATCH(demo, (demoaction))

json.hpp从https://github.com/nlohmann/json/releases 下载并将其放在同一目录中demo.hpp。

参考

https://github.com/EOSIO/eosio.cdt/issues/110

最近更新EOS代码，由于历史上最伟大的发明qiang,导致编译过程中某些依赖下载失败，so..

ubuntu 18.04

Ubuntu 的软件源配置文件是 /etc/apt/sources.list。将系统自带的该文件做个备份，将该文件替换为下面内容，即可使用 TUNA 的软件源镜像。

#备份
sudo cp -i /etc/apt/sources.list /etc/apt/sources.list.bak
#编辑
sudo vi /etc/apt/sources.list

将文件内容修改为如下

# 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse
deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse

# 预发布软件源，不建议启用
# deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse
# deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse

保存后，重新sudo apt-get update后，重新编译

数据来源

https://mirrors.tuna.tsinghua.edu.cn/help/ubuntu/
http://mirrors.ustc.edu.cn/help/ubuntu.html

每个开发人员都需要一个良好的IDE，它是为他的项目的开发过程而设置的。这就是为什么我们创建了一个关于如何为EOS dApp开发设置VS Code和/或CLion的快速教程 。
我们还为VS Code创建了一些脚本，它们将自动执行您在终端中使用的一些命令。

Visual Studio代码设置

首先，如果您还没有安装一些VS代码扩展，请安装它们。通过dApp开发，它们将非常有用：

• C / C ++ - VS Code的IntelliSense，调试和代码浏览
• CMake - 对Visual Studio Code的CMake语言支持
• CMake工具 - Visual Studio Code中的扩展CMake支持
• WebAssembly - WebAssembly文本表示的语法高亮显示

当我们开发EOSIO dApp时，我们在.hpp和.cpp文件中编写代码。但是，这只是整个过程的一小部分。大多数情况下，我们需要生成一些其他文件，我们将使用这些文件在区块链上部署合同，对其进行单元测试等。这就是 CMake派上用场的地方。

CMake是一个用于控制软件编译过程的命令行工具。一旦在IDE中正确设置，它就会变得非常容易。
现在我们将使用CMake工具，我们应该对项目结构进行一些更改。我们将重用EOSIO项目的骨架，因为它拥有我们需要的一切。当然，我们做了一些小改动。

我们有一张图片显示了新的项目结构。让我们来看看。

首先，我们有build文件夹。这是放置所有构建内容的地方。您将使用的每个生成的文件都在那里。接下来是CMakeModules，其中包含一些有用的cmake模块，其中包含用于编译过程的自定义函数。

该合同是我们的核心文件夹中。这是我们准备智能合约的地方。目前，eosiolib，libc ++和musl默认存在，因为它们用于编译。行中的下一行是外部和库。这两个文件夹都包含用于使整个编译过程更容易的库。

项目结构中最后一个重要的事情是配置文件 - CMakeLists.txt。每个目录都有自己的带有命令的CMakeLists.txt文件。

你可以找到我们的回购里面的所有文件夹和脚本的新项目结构在这里

CMakeLists

让我们看看一些配置文件，因为您需要知道如何使用它们。

1.CMakeLists.txt（4）

这是设置编译过程的主要配置文件。您应该知道，在开发dApp时，需要设置项目名称。版本和语言是可选的。

2. CMakeLists.txt（3）

第二个配置文件位于contracts文件夹中。应将每个新的智能合约添加为此配置中的子目录。因为合同不会编译，所以不要忘记这一步很重要。CMake不会知道。

3. CMakeLists.txt（2）

每个智能合约都有自己的配置文件。在这里你需要注意每个合约有不同的目标，基本上，它是文件夹的名称。

现在，当我们拥有新的项目结构时，我们必须制作自定义命令，这些命令将编译和构建我们所做的一切。但是怎么样？幸运的是，VS Code有一些很酷的东西叫做 Tasks。它帮助我们只需点击几下即可自动执行每个命令。

VS代码中的任务

首先，我们必须生成将包含我们的自定义命令的tasks.json文件。按⇧+⌘+ P在VS Code中打开命令选项板，然后键入“ 任务 ”并选择“ 配置任务 ”。

下一步选择“从模板创建tasks.json文件”，然后选择“其他”

VS Code将创建一个名为“ .vscode ” 的文件夹，在其中，您可以找到tasks.json。现在我们需要添加命令。将以下代码复制并粘贴到tasks.json中：

我们创建了三个名为CMake， Build和Generate ABI的自定义命令。它们执行三个shell脚本 - compile.sh，build.sh和generate.sh。前两个脚本基本上做同样的事情，除了build.sh同时编译和构建。可能大多数时候你会使用第二个。

另一方面，第三个脚本 - generate.sh（Generate ABI）用于生成智能合约的abi。在构建期间需要生成一些文件。您必须在合同所在的文件夹中执行该命令。选择例如.cpp文件并运行它。

真棒！我们几乎准备好了VS代码设置。为了使整个过程变得更加容易，我们将为命令创建快捷方式。当你还在VS Code中时，请转到首选项 - 键盘快捷键。将打开一个快捷方式窗口 - 找到并打开keybindings.json（它位于顶部）：

一旦打开keybindings.json，我们将创建我们的快捷方式。对于我们的命令，我们选择了“ cmd + e ”，“ cmd + r ”和“ cmd + i ”，但您可以选择其他命令。这是你必须添加的json：

完成所有操作后，您就可以开始在VS Code上开发EOS dApp

CLION设置

与VS Code相比，设置CLion非常简单。在CLion中加载框架时，IDE会自动在cmake-build-debug文件夹中创建所有构建文件。准备就绪后，您可以使用⌘+ F9快捷键执行实际构建。这就是你应该做的一切，太容易了吗？

但是，如果要为CMake设置其他设置，可以从首选项 - 构建，执行，部署中执行此操作：

有关在CLion中配置CMake的更多信息，请参阅IDE 的官方文档。真的很棒！

准备开始开发EOS dApps了吗？检查我们的教程
1.第一步在EOS Blockchain发展
2.最终的端到端EOS dApp开发教程 - 第1部分

英文原文：https://infinitexlabs.com/setup-ide-for-eos-development/

EOS出块时间

我们知道，新生产节点必须基于上一个区块生产新区块，因此新生产节点必须在指定的时候内接收到上一个区块的内容，否则只能跳过(只能基于上上一个区块生产)。如果出块时间太短，新节点很大可能接收不到上一个区块的内容，进而频繁出现跳块。只要有跳块，系统就会出现临时分叉，尽管EOS的DPOS的定时出块和最长链共识让系统很大可能最终达成共识，但是也会造成更多缺块，进而降低了有效单位出块数量，得不偿失。

因而一个合适的出块时间就显的很重要了，比如STEAM, BTXS的出块时间就设置为3S。那凭啥EOS能将出块时间设置为0.5S呢？因为EOS做了如下改进：

• 1个生产节点连续出12个块
  1个生产节点内的12个块不存在接收等待问题，是0等待，肯定也不存在跳块问题。比如生产区块2时，肯定能拿到区块1的数据
• 21个生产节点的出块顺序是固定的，且直连
  当A个节点完成12个区块时，系统会切换生产者，新的生产者B就需要通过网络接收上一个生产者的区块。由于A的区块是生产一个就广播一个，12区块传播到生产者B的可用时间最短， 由于网络时延和拥堵问题，B不一定能接收A的12区块。因此为了减少跳块，必须降低A->B的时延。由于STEEM,BTSX中，生产节点是随机排序的，A->B的时延是不确定的，可能A在美国，B在中国，美国和中国的来回传播就可能需要600ms, 同时A和B可能没有直连还需要中间节点跳转才能传播，时延就更久了，因而需要设置一个比较大的出块时间，最后测试调试下来，STEEM和BTXS就设置了一个比较合理的3S经验值。EOS为了减少相邻两个节点的时延，按照节点之间的时延安排出块顺序，即时延小的安排在邻近，比如A安排为香港，B为中国就比A是美国，B为中国好太多。同时，由于这21个节点的信息是透明的，这21个节点可以直连，进一步降低传播时延。有了这两个改进后，0.5s变为可能了。当然这种固定出块顺序的确定性也带来了不安全因素，比如攻击者可以准确预估每个出块节点，就可以更容易发起攻击行为。
  

然后我们来看下节点地域和实际出块顺序：
![]()
中国的节点没有将服务器部署在中国大陆的，要么在香港要么在日本，新加坡，甚至美国。

EOS区块不可逆时间

EOS中，21个生产节点轮流出块。一个区块是通过后续节点基于该区块的生产行为来间接确认的，为了实现BFT级别的不可逆，自然需要得到2/3+1的节点确认。由于每个节点生产12个区块，所以需要12(2/321+1)=12*15=180个区块确认。因而大家第一感觉是1个区块只需要后续180个区块即可变成不可逆状态。然而，如果大家在EOS区块链上查询区块的实时信息，就会发现一个区块都是在300多区块的时候才会被标识为不可逆状态。这是因为区块的确认分为两个阶段，第一个阶段是pre-commit阶段，该阶段需要接受2/3+1个节点的确认表明，超过2/3节点认可该区块。但是此时并不意味着超过2/3的节点已经了解到这个2/3确认信息。因而再次需要2/3的commit签名确认过程。两阶段签名确认流程类似下图：

EOS的特殊BFT

常规的BFT都是生产一个区块，等待共识，然后再生产一个区块，比如Tendermint和Cosmos里的PBFT的实现。由于PBFT共识需要比较长的时间(至少1s以上)，因而采用传统的PBFT是没法满足0.5s出块需求的。因而EOS 的BFT采取了不同的实现方式，出块和共识是流水并行工作的，区块生产完成后，不等待PBFT共识，继续生产同时参与并处理上一个区块的PBFT共识，当PBFT共识完成后即修改为不可逆状态。

EOS是否已采用BFT

其实很多人都在问我这个问题，我只能说，根据我目前了解点到的信息是代码和测试代码都有，但还没实行。其实从目前不可逆时间也可推测出BFT没有启用，如果BFT已经启用，1个区块在一个BFT共识完成后(该共识一般只需1s多)即可被确认，而不是目前的3分钟。

转载自 https://mp.weixin.qq.com/s/DlKA5xBhNUFC203t7sKy4A

eos 消息队列

https://github.com/TP-Lab/kafka_plugin
https://github.com/cc32d9/eos_zmq_plugin