Heavily increased transaction load since June 14

General
1

I find it strange there’s no serious discussion about this neither from users nor from protocol devs (could be that I massively overlooked some threads), but the chain has been seeing an increased load of transactions since June 14, resulting in huge blocks:

image
image1118×671 91.2 KB

daily average block size in the past 1 year (source: https://bitinfocharts.com/comparison/size-zec.html#1y)

the only higher historical value was in April 2017, but that load wasn’t sustained for this long.

taking a look at the recent blocks and zcha.in’s transaction stats, it seems blocks are being filled up with Orchard fully-shielded transactions:

image
image752×416 35.1 KB

usage stats (source: https://explorer.zcha.in/statistics/usage)

that’s not the only method though, there are also huge transparent transactions with a thousand inputs, e.g. look at the transactions in this block: https://explorer.zcha.in/blocks/0000000000cd95f5de693164f92943fa67bcd018373bd850e128dc71299c759f

zooming in on the block size chart, you can see that the increase is gradual (actually, it looks artificially smooth), but it’s still quite a steep spike. it seems unlikely to me that suddenly the world woke up and decided that they will all use Zcash because now they can do so without the trusted setup, so I’d say buckle up, Zcash is being spam-attacked. I’ve been seeing a noticeable waiting times until transaction inclusion (while beforehand, transactions all got into the next block immediately), and syncing this period takes a lot longer.

Zcash doesn’t have a fee market, so the only real thing bounding this activity is the block size limit (2 MBs every 75 secs). presuming the above block is the cheapest way to fill up a block, the attackers can make the chain basically unusable while eating up 2.3 GB/day of node operators’ hard drives (excluding index files) for merely $435/day at current prices.

I suggest Zcash implement a fee market as soon as possible. for inspiration, take a look at mechanisms like EIP-1559.

as an aside, let this also serve as another alert on how the entities governing Zcash (Electric Coin Company, Zcash Foundation, and ZOMG or whatever you call that now) lost their ways. it’s quite cringe that the only reactions in this community I’ve seen so far are neutral about this event or treat it as an adoption signal (!). stop LARPing about proof-of-stake, shielded assets, cross-chain, voting and bickering on how you allocate the tax money, and make changes that make the chain and its users actually resilient to all scales of attacks, like getting rid of the transparent pool, turning off the tax (dev fund) and making usable wallets.

10 Likes
2

A friendly reminder that insulting or derogatory comments are unacceptable in this forum.

1 Like
3

Those 1000 input transparent => shielded tx’s are from ZF’s and ZCG’s addresses. No idea why they’re both shielding 1000 inputs, but if you look at the addr, you’ll see both of them receiving block rewards.

Zcash Transaction 0a17acac5a807d20fbeda803f97ea082034f8288caaa1b9891b4d18c2524e4a7 - ZF’s addr
Zcash Transaction 763aa4deeb06a25d8d6efe4ec089c468845b0222bf6bec1bc127edb14cfed062 - ZCG’s addr

2 Likes
4

I think he is referring to the thousands of orchard tx.

It could be worse, they could have created fewer tx with more actions. The 0.00001 fee is per tx.

4 Likes
5

Pretty sure the post refers to both. I know about the orchard tx spamming and I’m glad the topic is raised, I just don’t have much to add.

1 Like
6

good to know. but if they can take up so much block space for just 0.0001 ZEC, an attacker can too. actually, as @hanh says, it looks like whoever is doing the spamming, they don’t know that their way is not the most efficient in burning block space.

3 Likes
7

It’s spam for sure. The solution is simple. Decrease block limit or increase minimum fee unless you want to go down the BSV path

0.001-0.01 ZEC/tx until price caughts up. That would be 0.06-0.6 USD per tx. Totally fine

3 Likes
8

You are suggesting a change in the consensus rules. They are not simple to organize. Besides, even with the more expensive tx fee, one can create a tx that fills the entire block. Still cheap to spam.

9

Spam is just a reality for many major blockchains. It doesn’t reflect badly on this project or on other projects. It just means someone is willing to invest time and effort and some money into a not very effective attempt to make the user experience slower. I’m sure there’s a few people out there with an interest like that.

4 Likes
10

Hmmm… delaying everyone’s tx for several minutes for a few cents is quite effective. It seems to be something that a competing chain would likely be interested in.

Edit: Here’s a 1 MB tx https://zecblockexplorer.com/tx/6f4349efd20a850709217605aaed50606df9027365e175a7d68d82cda997ee41

Larger transactions were rejected by zcashd but I couldn’t find a consensus rule in the doc.

1 Like
11

“t1ZookoCopyrightedBoSLxxxxxxxvCY1xe”

Btw, the copyright issue with the BOSL license is fixed: Change copyright attribution for the LICENSE-BOSL file by daira · Pull Request #333 · zcash/orchard · GitHub (released in Orchard 0.2.0). The zcashd release that includes this license change will be v5.1.0. That release will also include a substantial improvement in Orchard transaction verification times, which will help to mitigate any performance issue with blocks full of Orchard transactions (spam or otherwise).

12 Likes
12

The only limit on the size of a transaction is that it must fit in a block, which is limited to 2 MB. There was a 100 KB transaction size limit at launch but it was removed in the Sapling network upgrade:

image
image1857×78 21.5 KB

Speaking for myself: I think fee policy cannot be a particularly effective anti-DoS measure. Fees would have to be too high (for normal usage) in order to work for that purpose. Fee policy could potentially help to some extent to buffer spikes in demand due to organic usage. For now, I think that the changes in v5.1.0 are likely to be sufficient to address any short-term performance problems with current transaction load.

Edit: no, the changes in v5.2.0 are needed as well to address the scan performance issue.

[Edit 2023-12-14: I was wrong about this, as ZIP 317 proved. I had changed my opinion between this post and a month later, around 2022-07-22 when Kris Nuttycombe proposed a variable-fee approach based on the sum of the numbers of shielded inputs and outputs.]

9 Likes
13

Toki, Can you call attention to what you are implying is on the border of insulting or derogatory?

“LARPing” ?

Rather than making an ambiguous sub-reply?

14

larping-noamchom

3 Likes
15

there are things I didn’t realize when writing the OP. I think the general state of affairs is worse than I thought:

  • I didn’t realize resources can be abused to such a degree in Zcash. if a simple transaction and a 1 MB transaction both costs 0.0001 ZEC, and let’s assume 1 MB the biggest transaction that’s feasible to create, then filling all block space costs just ~$15/day. basically it doesn’t matter if it’s a single programmer having fun or the World Economic Forum making sure you’ll own nothing and you’ll be happy, anyone can make the chain unusable at their will. that’s a big problem.

  • doing it through shielded transactions publicly demonstrates that anonymity sets in Zcash can be inflated/poisoned without substantial costs. by “inflating” I mean that they can make the set look big, which influences users’ assumptions about their level of anonymity. e.g. you think that the potential inputs for your transaction are 10,000 previous outputs, while they know which 9,900 outputs were created by themselves and the number of real potential origins is just 100. the poisoning aspect is mostly the same, but affects those who want to gain obfuscation by shielding ZEC, keeping it in the shielded pool, and then unshielding. these users will also be misled about the true size of the anonymity set (the number or organic shieldings or unshieldings to/from a shielded pool).

  • if this continues in a sustained manner, then yes, as @hanh suggests, this would require a hard fork. doing this spamming 2 weeks after a hard fork seems to be a malicious timing.

t1ZookoPAYDAiRAandSEANMoRExxxwGTRjm

@d3l so it seems that the spamming is the spillover of some conflict within the Electric Coin Company? it’s quite ironic then that @zooko even retweeted the transaction increase graph :man_facepalming: here are some other messages as vanity addresses: https://twitter.com/pokkst/status/1541480184641196034

not if the fee is not defined as a constant/transaction (see fee structures that make sense below).

it’s not really, and it does reflect badly. block space is a scarce resource in any decentralized blockchain, and the way you protect a chain from resource abuse is to have proper resource pricing mechanisms. without that, a blockchain’s resources can be abused and the chain made unusable (effectively censored).

I’m honestly shocked to read this from someone as smart as you and who works as a scientist on a public blockchain. why do you hold this view?

a proper fee mechanism is not a 100% guarantee that you won’t get spam, but it almost always ends up being effective because of the economic reality: requiring a sufficiently scarce resource in exchange for another one (the “almost” refers to heavily funded adversaries with extra-protocol incentives). Bitcoin requires you to pay for data written into the blockchain and allowing a first-price auction of the fee rate between participants. Monero does the same but lowers the fee rate as blocks get bigger. Ethereum is somewhat similar too, but you pay for unit of computation and there’s a minimum required fee rate that is the function of how full recent block were (I’m simplifying). these are just the most obvious fee mechanisms and these chains have been quite resilient against spam attacks for a long while. you could argue that transacting on them hasn’t always been the cheapest, but that’s simply the price of having censorship-resistance, and if you want cheaper transactions, there are various parameters to tweak in sensible fee mechanisms (there are many more beyond my list) to achieve that. but charging a static fee per transaction is just crazy, sounds like an ill-conceived strategy to market the chain as having cheap transactions. (proof: almost none of the pages on z.cash and electriccoin.co can resist the compulsion to mention it.)

saying that faster Orchard verification will solve this is pure copium, that doesn’t take the system’s general availability and node storage requirements into account at all. not to mention it looks like it’s at least as cheap to spam the chain with fully transparent transactions as with fully shielded Orchard ones.

1 Like
16

Cheap transactions seem to be one of the major selling points of zcash.

Private, fast and cheap transactions.

Of these three, zcash has achieved privacy. I am curious to know what is planned regarding the remaining two. There seems to be some urgency because, at this point, the system is under attack by a fairly simple DOS.

For the record, I created a 1.9 Mb transaction (relayed but not mined), then a 1.6 Mb tx.
txid: ff5e9e493936d424a71291646b2608e28bb4985c717aa99fd431431f2e9d0d01

It is fairly easy to build these but in any case, I don’t think we should rely on obfuscation.

Hmmm - at 60 $ / ZEC and 75 s per block, I think it comes at 0.70 $ per day

The standard fee is 0.01 mZEC (not 0.1 mZEC)

\frac{24 \times 60 \times 60}{75} \times (0.00001 \times 60) = 0.7

2 Likes
17

I’ve said it before and I’ll say it again: transaction fees are not an anti-DoS measure. We’ve never claimed that that’s their purpose or that they could be effective as such. It wouldn’t be a vulnerability if transaction fees were zero, except to the extent that miners wouldn’t be incentivized to include transactions.

The primary anti-DoS measures in Zcash are the block size and (for the mempool) ZIP 401. Our intention is that the worst-case resource usage for a block still allows it to be processed in a small fraction of the average block time. Whenever that has come anywhere near not being the case, we’ve made changes to fix it (e.g. limiting the number of inputs before Overwinter, the consensus change in Overwinter to fix quadratic hashing, and improvements to Orchard verification that will be in zcashd v5.1.0 and zebra 1.0.0-beta.12).

If other anti-DoS measures are needed in future, we’ll add them.

Here’s why that is wrong: the “almost” is precisely the case you need to worry about. DoS attackers can pay more than legitimate users are prepared to pay overall, because they usually have motivations that are not directly monetary. If you increase transaction fees then you’re putting an obstacle in the way of adoption without fixing the underlying problem. The way to fix this in the long term is to massively increase chain capacity by reducing how much needs to be put on chain.

No. I cannot help someone speculating about what I’m paid or should be paid in public messages. But a message to them if they care about my opinion at all: cut it out.

[Edit: there haven’t been any transactions using either of the two vanity addresses mentioned since 10th June, anyway. Those transactions were fully transparent and I’m not aware of any evidence that they are related to the Orchard ones that were filling blocks, or the later Sapling ones.]

10 Likes
18

Zcash is up against multiple technical crisis scenarios that will perpetually block it from mainstream adoption. The fee market problem described here, and the high supply emission rate that will continue to be an albatross around our necks until 2 more halvings pass.

A coin like ZEC will not retain value, or grow in relative value to its peers like BTC or ETH while the emission is absurdly high and the coins are absurdly available and cheap.

The network cannot scale up to mainstream use if it is so readily spammed. I do agree with Daira’s point that we should not make txs prohibitive by fee cost configuration because that deters mainstream scaling. I don’t have a strong opinion about what the fee vs spam solution is, but i defer to the reality that there is not a solution implemented yet.

The wildcard deterrent to going mainstream is our particularly transient Network hashrate (the security vector for Zcash; we are a Proof of Work, institutional ASIC farm dominated network = Bad). In the context of point #1 (price is depressed) we are not a target for 51% attack because it is not a favorable risk-cost equation for an attacker. If price were to climb up, I’d assert that Zcash could fill into the role that ETC kept for years - prior to their implementation of an anti-51% attack solution called MESS

20

Edit your original comments, adding more content as necessary

21

Will the encrypted memos onchain one day be removed? Or … will encrypted memos maybe be available for a time period before they are recursively rolled-up? Trying to read the tea leaves on what changes wallet devs and services like eg free2z, zecpages might have to navigate in the future.

2 Likes