TRON节点验证交易的时间容忍度

少年恃险若平地，独倚长剑凌清秋。这篇文章主要讲述TRON节点验证交易的时间容忍度相关的知识，希望能为你提供帮助。

这篇文章主要介绍深入分析TRON的节点配置文件中??vm.minTimeRatio???和??vm.maxTimeRatio??这两个标志的意义。
这两个标志的表示的是节点（包括sr和fullnode）验证区块中智能合约交易的时间比例（时间容忍度）。
注：

sr节点：超级节点，负责出块，全网只有27个超级节点
fullnode节点：从sr节点同步区块

什么是时间容忍度？
在tron中，sr节点打包一个智能合约交易时，允许执行智能合约的最大时间是50ms，如果超过50ms就产生OutOfTime错误，让后将错误保存到??contractRet???中，并且回滚所有执行的状态。同时扣除??energylimit??指定的所有费用，所以这样的交易是可以被打包的，开发者要非常小心，避免出现这样的情况，否则人财两失。
这里的50ms时间是机器的绝对时间，也就是说当sr开始执行智能合约时，会获取一下系统时间记为vmStartInUs ，然后计算一个截止时间??vmShouldEndInUs???，??vmShouldEndInUs = vmStartInUs + 50 ms??，然后每执行一条智能合约指令，都会比较系统当前时间是不是超过了截止时间，一旦超过，就会触发异常，立即停止执行指令。假设有一笔交易执行的时间是49ms，没有超过50ms，并且也没有其他错误，所以被记为succes，记录到交易的receipt.result中。
当sr把包含这个49ms的交易广播出去后，某一个fullode节点收到这个区块，并且执行区块中的每一个交易，当执行49ms的交易时，那这个fullnode执行这笔交易的总时间一定也是49ms吗？答案肯定是不一定的，因为sr节点的机器配置和fullnode不一定完全相同，假如fullnode节点配置比sr节点差一些，很可能执行的总时间会超过50ms，假设是51ms，fullnode会发现这个结果和交易的receipt.result不一致,log日志输出 “[pool-34-thread-1] DB Different resultCode ”，直接导致整个区块验证失败。那这肯定是不能容忍的，不能因为小小的机器误差就导致区块无法同步？
tron的解决方案是，所有节点验证执行其他的节点广播过来的区块中的交易时，允许的时间不是50ms，而是一个可以自己设置的值。怎么设置呢，这里就用到了??maxTimeRatio???和??minTimeRatio??。
【TRON节点验证交易的时间容忍度】当执行的一笔交易的??receipt.result???的不为??OutOfTime???，那么执行这笔交易最大的时间是??50 *maxTimeRatio???,如果这笔交易的receipt.result本来就是OutOfTime，那么执行这笔交易最大的时间是50*minTimeRatio。一般tron的节点启动配置文件中??minTimeRatio???默认为0，??maxTimeRatio??默认为5。
还是刚才我们举的例子，sr执行交易的时间为49ms，那其他节点验证执行这笔交易只要不超过250ms（505），都不会认为是??OutOfTime??。如果sr打包的交易的本来就是??OutOfTime??，那么其他节点验证执行这笔交易的时间不能超过0ms(500),也就是直接认为是超时的。即便多了5倍的时间，有一些性能比较差的机器还是会将本来没有问题的交易误认为是超时交易。所以如果fullnode节点的性能一般，可以将maxTimeRatio调大一些，以防止由于自身的性能原因导致对一个正常的交易验证失败，最终导致区块不能同步。
推荐将??minTimeRatio???设为0，为什么呢？为什么对sr认为超时的交易验证要更加严苛呢，我的理解是如果别的sr已经认为是??OutOfTime???超时了，我就使用最小的时间系数来验证这个交易，是为了尽量也产生??OutOfTime??的结果，和sr达成一致。不过这样似乎不太公平，相当于某一个sr的机器性能成为了交易执行时间的上限，只要出块节点认为是timeout，那其他节点也会服从。
总结