您正在查看: EOS 分类下的文章

后台运行nodeos,避免ssh掉线

问题:

怎么后台运行 nodeos 呢,我用xshell 连接的,但是 xshell 总断,断的时候有时会引起 nodeos 退出

解决方案

需要的程序 Tmux

  1. 安装Tmux
    sudo apt-get update
    sudo apt-get install tmux
  2. 开始使用
    tmux
  3. 返回会话
    tmux a

多个会话

  1. 新建会话
    tmux new -s 会话名字
  2. 切换(查看)会话
    tmux a - t 会话名字
  3. 删除会话
    tmux kill-session -t first

    问题收集自 eosfans

EOS 块数据结构:块内通信和跨链

一、 块主要结构


block 是区块链中最重要的数据结构,EOS 在 block 结构中设计了 7 个参数,
下面我们将一一进行分析解释。

previous

previous 为指向前一个区块的 hash 值,EOS 采用的 hash 算法是 SHA。

timestamp

timestamp 为时间戳,该区块的生成时间。

transaction_merkle_root

transaction_merkle_root 为该区块内所有交易的 merkle 根,用于快速验证交
易的完整性。

producer

producer 为该区块的生成者。EOS 采用 DPOS 共识机制,预计每 3 秒生成一
个区块。任何时刻,只有一个生成者被授权生成区块。

producer_changes

EOS架构中区块的产生是以21个区块为一个周期,在每个出块周期开始前,
21 个区块生成者会被投票选出。producer_change 就记录了未来的 21 个出块者。

producer_signature

producer_signature 是该区块的生成者对该区块的签名。EOS 采用的是 ECDSA
签名算法,使用的椭圆曲线参数是 secp256k1。

cycles

EOS 设计的目标之一是使得两个账户(合约)能够在单个区块内来回交换消
息(交易),而不必在每个消息之间等待 3 秒。为了实现这一点,EOS 将块内的
消息分成了 cycle 来顺序处理。cycles 就是 cycle 的一个顺序向量,那么 A 发给 B
的消息在 cycles[1]中处理,B 返回的消息就可以在后续的 cycles[4]中进行处理。
区块生成器将不断把 cycle 添加到区块中,直到最长的区块时间间隔达到,或者
没有新的可传送交易生成。

二、 Cycles 主要结构

前面提到了 EOS 为了提升消息交互的效率,在 block 中设计了 cycle 结构来
实现了一条“小链”。而在 cycle 内部,EOS 设计了 threads 来实现消息、交易的
快速并行处理。

相比较 cryptonomex 中的设计,EOS 的这种设计将更好的支持高并发管理,
利于提升 EOS 的整体效率。

generated_input

generated_input 包含了一组 GeneratedTransaction 的 id,用于顺序查找和处
理 GeneratedTransaction。我们将在后面对 transaction 的类别进行详细的解释和
分析。这些 transaction 将被顺序处理。

user_input

user_input 包含了一组 ProcessedTransaction,这些是已经被处理过的交易。

thread

不同的 thread 将会根据主机的实际情况被并行处理。在同一个 cycle 内,当
两笔交易 A 和 B 同时涉及到同一个账户时,这两笔交易将会被放在同一个 thread
下进行处理。

三、 Transaction 结构

EOS 中主要使用三种 transaction 结构。其中 SignedTransaction 是由用户发出
的交易请求,ProcessedTransaction 是由区块生成者处理完用户发出的交易请求后
生成的交易实体,GeneratedTransaction 是由区块链生成的交易请求,特别的是由
智能合约生成的交易请求。

Transaction

Transaction 作为所有 transaction 的父类,包含了 5 个参数。refBlockNum 用
于指定之前的一个块,其中将包含一个由该交易签名者申明的已知状态申明,作
为该交易执行的上下文。refBlockNum 只使用 16 个 bit,所以只能回溯到两天前
的 65,536 个块。refBlockPrefix 就是被指定的块的 hash 的前 4 个字节(32 个比
特)。expiration 给出了交易的内存过期时间,这样将保证节点的内存不用保存过
多的交易。
scope 内将记载此次交易涉及到的账户信息。
messages 内将记载此次交易的实质内容,它可以包含多个消息。在设计上,
只有所有的消息都被接受了,整个交易才会被接受,任何一个消息被拒绝都会导
致此笔交易失败。这些消息将会在同一个线程里面顺序执行,因此将多个消息放
到一笔交易里面在性能上并不理想(比如同时给两个人转账)。而且 EOS 会根据
交易涉及到的用户数量数来收取手续费,因此涉及到多个账户的交易的时候,最
好采用原子交易来进行(每笔交易只包含一个接收账户)。

SignedTransaction

SignedTransaction 比 Transaction 多了一个参数 signatures,将用于保存用户
对该交易涉及的所有签名,每一个 message 至少对应一个 signature。
ProcessedTransaction
ProcessedTransaction 比 SignedTransaction 又多了一个参数 output,用于记录
对用户发出的 SignedTransaction 进行处理后的输出。特别的,这个输出包含一条
或多条交易信息 GeneratedTransaction。

GeneratedTransaction

GeneratedTransaction 是由区块链生成的交易,比如智能合约。它 比
Transaction 多了一个参数 id,用于方便查找到该交易。

值得注意的是,因为这个交易是由区块链(智能合约)产生的,它可以用于
EOS 上不同应用间的通信。但又是因为它由区块链(智能合约)产生,因此它并
不含有签名,所以它的验证必须要连同触发产生该交易的智能合约的交易一同被
验证。
例如,当多家大宗交易所、普通用户向 OraleChain(智能合约)提交了目前
的猪肉价格(以 SignedTransaction 形式)后,OraleChain 根据自己的 PoRD 机制
计算得到一个可信猪肉价格, 然 后 连同所有搜集到的价格 生成一个
GeneratedTransaction ,作为最后一个提交价格 的交易的处理结果
ProcessedTransaction 的输出信息,发送给另一个智能合约 AgriculturalInsurance,
AgriculturalInsurance 就可以根据这个可信猪肉价格进行保险赔偿等智能操作。
正是这样的巧妙设计,实现了 EOS 上不同的智能合约间的通信,也就是我们
常说的跨链,这将极大的丰富 EOS 的生态圈,为开发者开发更丰富的应用提供了
可能。

四、 Message 结构


Message 用于记录交易的主要内容,包含了 4 个参数。
code
code 指向了执行这个消息的智能合约。比如“eos”是指 EOS 自身自带的智
能合约,在前面系列指南里进行 eos 转账的操作,出发的就是这个合约。
type
type 指向需要执行的智能合约里的方法,比如“eos”里面的转账操作
“transfer”。
authorization
authorization 记录了处理该消息所需要的权限。EOS 里面目前设计了三种权
限:owner、active 和 recovery。owner 权限可以做所有事情,active 权限可以做
出了更改所有者之外的所有操作。recovery 可用于 EOS 用户在密钥被盗时恢复其
账户控制。
data
data 里面则存储了这个消息的其他参数。

五、 MessageOutput 结构


当智能合约处理一笔 SignedTransaction 时,有可能会生成一笔新的交易
GeneratedTransaction,它将被存储 MessageOutput 结构体中。
MessageOutput 包含了被通知对象集合 notify,在完成通知以后被应用了的
ProcessedTransaction 集合 sync_transactions,以及由智能合约生成的不带签名的
交易 GeneratedTransaction 集合 async_transactions。
通知对象集合结构 NotifyOutput 里面包含了被通知的对象 name 和一个输出
消息 MessageOutput。这和前面形成了一个嵌套关系,因为被通知的对象(合约)
还有可能生成新的交易,如此递归下去。
由于 EOS 代码中对 MessageOutput 和 NotifyOutput 的处理还没有完全完成,
我们会在后面的系列文章中做更详细的解释和分析。

六、 总结

EOS 在块内设计了 cycle 结构,实现了块内的通信,这样账户(合约)之间
的通信将变得更加快捷。
在设计上,EOS 是模块化的,每个人不应该运行所有的东西,因此不能假定
另一个账户(合约)的状态在同一台机器上是可访问的,这就意味着如果允许一
个合约同步调用另一个合约,但如果这个合约不在内存中,系统将会崩溃。因此,
EOS 要求所有账户间的通信都必须通过区块链上的交易进行传递。
为了实现跨链机制,EOS 特别设计了不带签名即可完成验证的交易机制,这
种验证是通过状态信任链来完成的:第一个带签名的交易触发合约产生了第二个
不带签名的交易,该交易又顺序产生了第三个不带签名的交易,依次下去,最后
所有的交易的验证都依赖于第一个交易的签名,和每一次合约执行后的状态。
从对 EOS 块数据的分析,我们可以看到 EOS 在设计上就已经考虑了高速、
融汇、跨链等区块链未来的发展方向,我们有理由相信 EOS 代表了区块链的一种
新的未来。
转载自oraclechain

print_floats.cpp:**undefined reference to `boost::program_options

编译EOS时出现以下错误

Scanning dependencies of target print_floats
......
[ 76%] Linking CXX executable print_floats
CMakeFiles/print_floats.dir/print_floats.cpp.o: In function `boost::program_options::typed_value<unsigned int, char>::name[abi:cxx11]() const':
print_floats.cpp: **undefined reference to `boost::program_options::arg[abi:cxx11]'**
......
print_floats.cpp:**undefined reference to `boost::program_options::validation_error::get_template[abi:cxx11]**(boost::program_options::validation_error::kind_t)'
print_floats.cpp:**undefined reference to `boost::program_options::options_description::m_default_line_length'**
print_floats.cpp:**undefined reference to `boost::program_options::options_description::options_description(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int, unsigned int)'**
print_floats.cpp:**undefined reference to `boost::program_options::options_description::add_options()'**
print_floats.cpp:**undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, char const*)'**
print_floats.cpp:**undefined reference to `boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*)'**
......
collect2: error: ld returned 1 exit status
make[2]: *** [tools/print_floats] Error 1
make[1]: *** [tools/CMakeFiles/print_floats.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 76%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/crypto/sha512.cpp.o
[ 76%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/crypto/dh.cpp.o
[ 76%] Building CXX object libraries/fc/CMakeFiles/fc.dir/src/crypto/blowfish.cpp.o

原因是之前手动安装过boost,但安装的不正确,或者文件缺失

解决方案,清理掉所有本地的boost文件,重新运行编译EOS,会自动下载依赖

cd ~/opt/
rm -rf boost*
cd eos_dir
rm -rf build

问题收集自 eosfans

自定义nodeos数据路径

--config-dir 自定义 config.ini 路径
--data-dir 自定义区块数据路径
--genesis-json 自定义genesis.json路径

nodeos 启动参数--checkpoint 作用

问题

看nodeos的启动参数的时候,看到这么一项: --checkpoint arg Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints.
这checkpoint是什么,主要用来干嘛的?
问题来自:eosfans

解答

查看config中的注释
Pairs of [BLOCK_NUM,BLOCK_ID] that should be enforced as checkpoints. (eosio::chain_plugin)
多对区块高度+区块id,用来作为检查点。默认注释掉,不设置检查点

大概的意思就是,接收区块时,根据区段的高度,查看当前区块的id与预期的一样不一样,防止数据出错。

撸一遍代码
eos\plugins\chain_plugin\chain_plugin.cpp

if( options.count("checkpoint") ) {
         auto cps = options.at("checkpoint").as<vector<string>>();
         my->loaded_checkpoints.reserve(cps.size());
         for( const auto& cp : cps ) {
            auto item = fc::json::from_string(cp).as<std::pair<uint32_t,block_id_type>>();
            auto itr = my->loaded_checkpoints.find(item.first);
            if( itr != my->loaded_checkpoints.end() ) {
               EOS_ASSERT( itr->second == item.second,
                           plugin_config_exception,
                          "redefining existing checkpoint at block number ${num}: original: ${orig} new: ${new}",
                          ("num", item.first)("orig", itr->second)("new", item.second)
               );
            } else {
               my->loaded_checkpoints[item.first] = item.second;
            }
         }
      }

先将config中配置的,或者命令行传入的,多对区块高度+区块id存入my->loaded_checkpoints,并去重。

接收区块时,进行对比验证

// relay signals to channels
      my->pre_accepted_block_connection = my->chain->pre_accepted_block.connect([this](const signed_block_ptr& blk) {
         auto itr = my->loaded_checkpoints.find( blk->block_num() );
         if( itr != my->loaded_checkpoints.end() ) {
            auto id = blk->id();
            EOS_ASSERT( itr->second == id, checkpoint_exception,
                        "Checkpoint does not match for block number ${num}: expected: ${expected} actual: ${actual}",
                        ("num", blk->block_num())("expected", itr->second)("actual", id)
            );
         }

         my->pre_accepted_block_channel.publish(blk);
      });

当接收的区块的高度与预定中的某高度一致,比较当前区块id与预定的id,如果不一致,则报错Checkpoint does not match for block number...