最近XMR价格持续增长后
交易手续费开始高到不利于小额付费的使用
对此，官方发了一篇文来说明
https://getmonero.org/2017/12/11/A-note-on-fees.html
其实在之前的板上讨论时就有打算写一篇
不过一直没时间，既然现在有人写了
我就拾人牙慧翻译+编修一下希望可以解答一些版友的疑问
快速懒人包:
XMR动态手续费当初的设计是预期价格会跟货币使用量呈正比
所以就可以此校正抵销价格上涨的手续费升值
殊不知近期价格涨得跟使用量不成比例
连动态公式的启动门槛都还没触发所以导致的问题
然而因为手续费公式牵扯到自动扩容机制所以没办法随意的调整参数
所以目前只能等使用量跟上价格 & 防弹协定的启用来大幅降低手续费
另外手续费率也会随着时间降低，不过这就需要比较长的时间
以下是正文翻译:
近期社群中不断有抱怨认为Monero交易的手续费过于昂贵。虽然我们并不同意其中的一些
意见，但我们还是必须先彻底地分析一下这个情况。在那之前我们必须回应一点，有些抱
怨认为开发者理当要将手续费直接修改降低后释出新版本，但这样的作法是因小失大的，
因为 1. 这个方法只是把问题向后拖延；2. 改变参数与公式需要进行硬分叉，而这需要
全面的共识；3. 每当价格变化后就得人工介入调整手续费的作法与去中心化的生态是矛
盾的。
这就让我们拿几个同是使用工作证明(POW)的区块链货币来做个每单位容量(kB)手续费比
较:
比特币 Bitcoin: ~26.90 USD
乙太币 Ethereum: ~2.91 USD
莱特币 Litecoin: ~0.10 USD
达世币 Dash: ~0.07 USD
门罗币 Monero: ~0.24 USD
比较起来，Monero的每单位容量手续费其实并不算高。但是由于每笔交易所需的容量较大
，实质的费用就因此变得相当高。但必须注意的是，Monero较大的交易容量是来自于默认
的隐私保护功能。例如隐藏交易金额功能RingCT中的Range proofs可以占到12kB的容量；
但RingCT在强化交易隐私上是绝对必要的，当这功能还没有启用时，让许多交易泄漏了隐
私。 不过有个好消息是，未来Bulletproofs协定的启用将会降低Monero至少80％的交易
容量。
为了完整分析整个问题，让我们来看看程式码里的参数，就从打包区块(挖矿)的动态区块
算法与奖励惩罚公式开始吧，这部分的公式如下:
惩罚 = 基础奖励 * ((区块容量 / MN) – 1)2
所以实际的奖励为:
新奖励 = 基础奖励 – 惩罚
其中:
MN是过去最新的N个区块的容量中位数，N在Monero中被设定为100
区块容量是指目前正在打包的区块容量
基础奖励是根据当下的发行曲线的位置或是尾段发行量(tail emission)而决定
新奖励是矿工实际获得的奖励
区块容量的上限为2MN
而在公式中基础奖励被定义如下:
基础奖励 = 2 * ((S – A) * 2-20 * 10-12)
其中:
2是调整区块间隔时间为两分钟的因子
S是原子单位(atomic units)的初始值 = 264 – 1
A是目前的货币发行总量，可以在这里查到，此外，目前显示在区块链浏览器上的发行总
量数字必须乘上1012 (Monero有小数后12位)以转换为原子单位。
最小的区块容量限制为300kB，因此矿工得以最多将区块使用至300kB而不会受到奖励惩罚
，也就是说，上述提到的惩罚公式仅在区块容量超过300kB之后才会开始发挥作用。
举个例子，现在有一个标准的Monero交易(两个输入两个输出约需13.2kB的容量)来了，让
我们来放入公式看看:
假设目前的区块基础奖励是5.7 XMR:
惩罚 = (5.7 * ((313.2/300)-1)2 ，约为0.011 XMR。
另外可以注意的是与半年多前相比，目前基础奖励明显低很多，也因此目前惩罚随之降低
。
而矿工不会无故扩张区块容量。因此在容量超过300 kB之后，每多添加一笔交易时的手续
费必须比这些惩罚来得多，否则矿工将会只在打包至300 kB的容量后就不愿意处理其他的
交易，这样会导致交易网络的堵塞。以结论来说，目前的默认手续费(约0.013)就是为了
让矿工在多处理额外的交易时不会损失挖矿奖励的收益。
从上述的惩罚公式可以发现，惩罚会随着基础奖励的下降而减少，另外，将公式制图后可
以发现惩罚在一开始是比较缓和的，这代表着减少些许交易容量就可以降低相对更多的手
续费，譬如，80%的交易容量降低可以减少90%的手续费。让我们来用公式算个更精确的例
子，假设使用单输出的防弹协定(bulletproofs)，交易的容量将会降至2.5 kB左右；另也
假设我们希望矿工会愿意扩张区块容量来处理额外的两笔交易而不会损失收益，也就是说
在超过最小区块限制后，矿工可以多处理两笔交易而不会让惩罚超过奖励。
将数字带入后我们就得到:
惩罚 = (5.7 * ((305/300)-1)2 ，约等于0.0016XMR，或0.0008XMR的单笔惩罚
当降低80%交易容量时却保持着最小区块容量限制似乎不太对，因此最小区块容量限制可
以被降低至100、150、200或250 kB，让我们再次把数字套入看看:
惩罚 = (5.7 * ((255/250)-1)2 ，约等于0.0023 XMR，或0.00115 XMR的单笔惩罚
惩罚 = (5.7 * ((205/200)-1)2 ，约等于0.0036 XMR，或0.0018 XMR的单笔惩罚
惩罚 = (5.7 * ((155/150)-1)2 ，约等于0.0063 XMR，或0.00315 XMR的单笔惩罚
惩罚 = (5.7 * ((105/100)-1)2 ，约等于0.014 XMR，或0.007 XMR的单笔惩罚
你可以依此公式(MN 对 x 与 区块容量对 x+5)画出一张图观察变化的结果。
大家也许会很好奇，那动态手续费算法在这其中到底是扮演着什么角色？首先必须澄清
一下，默认的手续费仅仅只能应付最低限度的惩罚，也就是说，矿工只会在最小区块容量
之外多处理一笔交易。更精确的说，以目前的状况就是制造出一个313kB的区块(提醒一下
，最小区块容量限制是300kB)。当(最后一百个区块的)中位数区块容量开始成长时，动态
手续费算法才会开始发挥作用。
来看看动态手续费算法的运作：
手续费 = (R/R0) * (M0/M) * F0
R 是基础奖励
R0 是基础奖励的初始参照值(10 XMR)
M 是区块容量上限
M0 是最小区块容量上限 (300 kB)
F0 是 0.002 XMR
举个实际的例子，数月前区块容量的中位数一度增加到了400 kB左右，当时标准手续费降
低到了约0.0095xmr。我们可以在公式中看到，这是概略与理论值符合的。也就是:
手续费 = (6.5/10) * (300/400) * 0.002 = 0.00975
基本上中位区块容量(其在公式中扮演的角色与最小区块大小的基数相反)百分比倒数的增
加即可视为手续费减少的百分比。举个实际例子来说，若区块容量的中位数增长到了
600kB，就等于是扩容为两倍(200%)的区块，此时将可减免一半(1/200%)的单笔手续费。
这个设计使得交易手续费会因交易的数量增加而下降。用意在于当Monero日益热门时，增
加的交易量将会降低每单位容量手续费。
那么，为什么近期价格的飙升并未造成每单位容量手续费的骤降呢? 这是因为近期价格
上涨的效应比交易使用量这个影响因子大多了。而且区块容量的中位数需要维持在比
300kB大才能够让动态手续费算法顺利的运作，但目前Monero交易使用量并未维持在其
之上。手续费算法当初是被设计成要与价格连动的，但是我们可以发现Monero价格并未
完美的与Monero的交易使用量连动。综合以上，虽然Monero使用量成长了非常多，但还尚
未超过300kB的动态门槛，且与价格的成长相比却是小巫见大巫，因此最后造成每单位容
量手续费尚未开始如预期的下降。
另从结合惩罚公式以及动态区块大小公式与动态手续费公式看来，我们可以得知较高的最
小区块容量限制(比如300kB)会有着较低的起始手续费，但手续费的下降效应(因动态手续
费算法)也会较不明显。反过来说，较低的最小区块容量限制(比如150kB)会有较高的起
始手续费，但手续费的减少就会较为明显。
结论是，虽然目前手续费太高，但过一阵子之后很可能就不会再有这状况，因为当使用量
增加到一定程度后，动态公式就会开始发挥作用来减免手续费。此外，我们真正需要的是
仔细研究最适当的最小区块容量限制数值(如上段所述)，因为我们比较希望能够找到一个
以后都不会再需要人工介入修改的参数。
网页翻译正文与资料来源请见:
https://xmr-tw.org/2017/12/16/a-note-on-xmr-fees/