这篇文章主要介绍深入分析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。
当执行的一笔交易的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， 那其他节点也会服从。
总结
-
maxTimeRatio 表示的是验证节点对没有超时的交易验证时允许的时间相对于出块节点执行的比例。
-
minTimeRatio 表示的是验证节点对超时交易验证时允许的时间相对于出块节点执行时间的比例。
