I’m really happy about the simplifications that have been made to zcashd as part of the ZIP 317 work. (Most of them are in zcashd v5.5.0; the remainder will be in v5.6.0.)
The logic we inherited from Bitcoin for fee and priority estimation in the internal zcashd wallet, and for block construction in getblocktemplate, was grossly overcomplicated. It also made assumptions unsuited to Zcash — for example the concept of “coin age priority” depends on knowing which coins are being spent and their values, so it can only apply to transparent coins. We had a hack to work around that particular problem: transactions with any shielded component were treated as maximum priority. But there was still a divergence in fee behaviour between legacy and z_* APIs, which meant that the design simplifications to use a fixed fee (before ZIP 317) were never fully adopted.
I’ve been wanting to simplify this since before Zcash launched, but there was no practical opportunity to do that given all the other demands on engineering bandwidth.
Coin age priority is now completely gone in v5.5.0. (Upstream Bitcoin Core had removed it earlier, but their PRs were entangled with other changes we didn’t want.) Priority estimation and the estimatepriority RPC call is gone. The concept of “free transactions” is gone, replaced with the “block unpaid action limit” in the ZIP 317 block template algorithm. Fee selection is greatly simplified, and the old fee estimation code is almost gone. (It’s no longer used by the internal wallet; in v5.6.0 the remaining code and the estimatefee RPC call will be removed.) We’ve removed 6 zcashd config options (sendfreetransactions, blockprioritysize, limitfreerelay, relaypriority, txconfirmtarget, mintxfee), and added only one (blockunpaidactionlimit) in exchange! Verbose, near-duplicate code in implementations of several of the z_* RPC calls has been merged together and rationalised. This is all a huge simplification and removal of technical debt, replacing behaviour that never made sense in the context of Zcash with behaviour that has been specifically designed for it.
I don’t know whether adoption of ZIP 317 will in practice halt the sandblasting, but it’s a serious effort toward doing so. It will certainly make it more expensive for the adversary; whether that’s sufficient depends on their resources and motivations. In the meantime we’ve significantly improved zcashd’s robustness, performance (mainly in previous 5.x releases), and technical debt.