当设置一个账户的权限为多个账户时 cleos set account permission bcskillsurou active '{"threshold":1,"keys":[{"key":"EOS5bu13CujrEUdKB57LnvihUAqkdUycwSz2p7vPuac7vNBvfh7M7","weight":1}],"accounts":[{"permission":{"actor":"222222222222","permission":"eosio.code"},"weight":1},{"permission":{"actor":"111111111111","permission":"eosio.code"},"weight":1}],"waits":[{"wat_sec":1,"weight":1}]}' owner -p bcskillsurou 报错如下 Error 3010004: Invalid authority Ensure that your authority JSON is valid follows the following format! { "threshold": <INTEGER [1-2^32): the threshold that must be met to satisfy this authority>, "keys": [ <keys must be alpha-numerically sorted by their string representations and unique> ... { "key": <STRING: EOS.IO compatible Public Key>, "weight": <INTEGER [1-2^16): a signature from this key contributes this to satisfying the threshold> } ... ], "accounts": [ <accounts must be alpha-numerically sorted by their permission (actor, then permission) and unique> ... { "permission": { "actor": <STRING: account name of the delegated signer>, "permission": <STRING: permission level on the account that must be satisfied>, }, "weight": <INTEGER [1-2^16): satisfying the delegation contributes this to satisfying the threshold> } ... ], "waits": [ <waits must be sorted by wait_sec, largest first, and be unique> ... { "wait_sec": <INTEGER [1-2^32): seconds of delay which qualifies as passing this wait> "weight": <INTEGER [1-2^16): satisfying the delay contributes this to satisfying the threshold> } ... ] } Error Details: Authority failed validation! ensure that keys, accounts, and waits are sorted and that the threshold is valid and satisfiable! 解决问题 将添加的accounts按照ascii顺序添加 例如上面的例子，先添加 111111111111 再添加 222222222222 cleos set account permission bcskillsurou active '{"threshold":1,"keys":[{"key":"EOS5bu13CujrEUdKB57LnvihUAqkdUycwSz2p7vPuac7vNBvfh7M7","weight":1}],"accounts":[{"permission":{"actor":"111111111111","permission":"eosio.code"},"weight":1},{"permission":{"actor":"222222222222","permission":"eosio.code"},"weight":1}],"waits":[{"wat_sec":1,"weight":1}]}' owner -p bcskillsurou 参考 https://github.com/EOSIO/eos/issues/4433
编译EOS2.x版本时，由于使用WSL，或者Windows git 操作过，很容易把软连接丢了，所以报错如下 /eos/libraries/chain/webassembly/eos-vm-oc/llvmWARshim.llvmwar:1:1: error: ‘llvmWARshim’ does not name a type llvmWARshim.cpp ^~~~~~~~~~~ libraries/chain/CMa 手动修复软连接 cd /eos/libraries/chain/webassembly/eos-vm-oc rm llvmWARshim.llvmwar ln -s llvmWARshim.cpp llvmWARshim.llvmwar 修复后ll查看如下 llvmWARshim.llvmwar -> llvmWARshim.cpp*
问题 老同事今天问我，A合约inline调用B合约的action（B合约的action中的逻辑会修改B合约的某个Table）,A合约中执行完inline后，立刻查B合约中的Table数据，数据未更新，怎么处理。 解决方案 A合约inline调用B合约的action后，B再内联调用A合约的另一个新加的action（在这个action中再查B合约的Table数据） 先暂时记录下，等下再跟下链代码，详细分析下为什么合约是同步执行的，然而inline action 出现了“异步的效果”
当get table索引是name 时，无法精准查询 因为cleos 传入的参数默认是字符串，需要对应的转换参数 --key-type name 例如 cleos -u https://api.eosnewyork.io:443 get table eosio eosio voters --key-type name -L 111111111122 -l 1 参考 https://github.com/EOSIO/eos/issues/5019
查看插件返回(github) rm.get_account_limits( result.account_name, result.ram_quota, result.net_weight, result.cpu_weight ); 查看资源设置(github) set_resource_limits( res_itr->owner, res_itr->ram_bytes + ram_gift_bytes, net, cpu ); 结论 ram_bytes是实际买的RAM 大小，ram_quota 是加上了 赠送的ram_gift_bytes（等于1400）(github) 验证 cleos -u https://api.eoslaomao.com get account bcskillsurou 返回 memory: quota: 4.348 KiB used: 3.49 KiB 查看账户资源表 cleos -u https://api.eoslaomao.com get table eosio bcskillsurou userres 返回 { "rows": [{ "owner": "bcskillsurou", "net_weight": "0.0046 EOS", "cpu_weight": "0.0147 EOS", "ram_bytes": 3052 } ], "more": false, "next_key": "" } 计算 quota 与 ram_bytes差值等于 1400，与ram_gift_bytes值一致。
Transaction exceeded the current CPU usage limit imposed on the transaction
最近链发送交易过大时容易发生一下错误 { "message": "Internal Service Error", "code": "500", "error": { "code": "3080004", "name": "tx_cpu_usage_exceeded", "what": "Transaction exceeded the current CPU usage limit imposed on the transaction", "details": [{ "message": "transaction was executing for too long", "file": "transaction_context.cpp", "line_number": 488, "method": "checktime" }, { "message": "pending console output: ", "file": "apply_context.cpp", "line_number": 113, "method": "exec_one" }] } } 根据错误信息，定位源代码位置 （github） 由于now > _deadline并且 deadline_exception_code == tx_cpu_usage_exceeded::code_value 走到此断言逻辑 倒推到函数调用位置（github） checktime(); // Fail early if deadline has already been exceeded 提示信息为：如果已超过截止日期，则提早失败 继续反推代码 由于（github）交易组装时trx.max_cpu_usage_ms固定设置的0。所以，判断逻辑出自（github） // Possibly lower objective_duration_limit to the maximum cpu usage a transaction is allowed to be billed if( cfg.max_transaction_cpu_usage <= objective_duration_limit.count() ) { objective_duration_limit = fc::microseconds(cfg.max_transaction_cpu_usage); billing_timer_exception_code = tx_cpu_usage_exceeded::code_value; _deadline = start + objective_duration_limit; } auto& rl = control.get_mutable_resource_limits_manager(); objective_duration_limit = fc::microseconds( rl.get_block_cpu_limit() ); _deadline = start + objective_duration_limit; if(now > _deadline) { // 报异常 } get_mutable_resource_limits_manager（github） resource_limits_manager& controller::get_mutable_resource_limits_manager() { return my->resource_limits; } get_block_cpu_limit（github） uint64_t resource_limits_manager::get_block_cpu_limit() const { const auto& state = _db.get<resource_limits_state_object>(); const auto& config = _db.get<resource_limits_config_object>(); return config.cpu_limit_parameters.max - state.pending_cpu_usage; } 跟进停止 发现是由于合约中使用了std::vector<std::string> 持续存储大量数据，导致单次CPU运算执行耗时持续增长。 结论 当合约中Table单条记录中，如果使用vector不要存储过多数据，以及数据结构过于复杂的struct。 如有对应需求，可以拆分子表，然后使用子表记录id索引对应。
cleos查询账户RAM总购量与实际购买不一致
cleos get account 通过cleos 查询账户RAM余额 cleos -u http://127.0.0.1:8888 get account zer41iyhahwp ... memory: quota: 9.366 KiB used: 3.078 KiB 但实际创建账户时，RAM购买量为8192byte cleos get table 通过查询用户资源表 cleos -u http://127.0.0.1:8888 get table bitconch zer41iyhahwp userres $ cleos -u http://127.0.0.1:8888 get table eosio zer41iyhahwp userres { "rows": [{ "owner": "zer41iyhahwp", "net_weight": "10.00000000 EOS", "cpu_weight": "10.00000000 EOS", "ram_bytes": 8191 } ], "more": false } ram_bytes的数据与创建时RAM数据基本（所差1byte是因为，购买RAM通过Bancor估价代币购买，会与实际少许误差）一致。那cleos查出的数据差距在哪？下面跟下系统合约源代码 系统合约源码 查看RAM购买后，设置资源的位置(跳转GitHub) set_resource_limits( res_itr->owner, res_itr->ram_bytes + ram_gift_bytes, net, cpu ); 发现设置资源的位置加上附加的ram_gift_bytes 查看ram_gift_bytes具体数值（跳转github） static constexpr int64_t ram_gift_bytes = 1400; 所以，查询账户RAM比实际购买多的部分为合约设置时赠送的部分(忽略运算误差)。 9.366 KiB = 8191 byte + 1400 byte
error: use of undeclared identifier 'current_time_point'
包含头文件 #include <eosio/system.hpp> https://github.com/EOSIO/eosio.cdt/issues/470
EOS: billed CPU time ( us) is greater than the maximum billable CPU time for the transaction ( us)
先记录下，等测试完后，在完善 参考 https://github.com/EOSIO/eos/issues/8502 https://blog.csdn.net/wangke0809/article/details/104138651 https://eosio.stackexchange.com/questions/1609/how-to-increase-billable-cpu-time