MO NAN
MO NAN
当压测客户端同时连接多个节点，且多个节点负载非常高时可能出现这种情况 原因是多个节点由于负载高，区块高度不一致，导致sdk随机从多个节点读数据的结果不一致 修改压测客户端配置，只连接一个节点就可避免这个问题 未来3.0会开发一致读的功能，彻底解决这个问题
这是由于3.0版本在分布式架构下，单个EVM很难查询其他机器上EVM的合约代码大小，这个opcode会一直返回1，这个问题我们正在研究解决，也欢迎提出好的建议
tars只用于一个区块链节点内部的各个微服务互联，区块链节点间仍然使用p2p连接
3.2.5版本已经修复过内存相关问题，可以换3.2.5版本试试
新版本将原本部分线程池换为tbb的task，换取更低的时延，代价是会导致tbb调用sched_yield()的频率更高，该问题正在研究解决
这个问题叫“idle-spinning problem”，https://community.intel.com/t5/Intel-oneAPI-Threading-Building/sched-yield-when-pipeline-input-stage-blocks-leads-to-high-CPU/m-p/786029#:~:text=The%20trouble%20starts%20when%20the%20input%20filter%20blocks,then%20toss%20in%20a%20sched_yield%20to%20the%20loop
这种情况一般是有一个或多个共识节点异常了，有日志可以发出来看看吗
tars框架自身代码的std可以去掉，理论上不影响历史，如果真有历史代码依赖了tars框架的std，那也可以做成tars框架编译选项 tars2cpp可以增加选项（默认关），打开后才去掉std，这样就可以兼容历史代码了
这里的错误显示轻节点没有连上全节点，所以退出了 轻节点只保存区块头数据，交易、区块和回执都需要从全节点获取，因此不能独自运行
能否贴出完整合约代码供我们测试验证？