0Box: Erasure Coding: Hard limit?

I’ve recently been testing out the limits of allocations and the network in general and i’ve found something curious with erasure coding on 0box.
I can create an allocation with an erasure coding combination as large as I want, and I will be assigned blobbers, see this as an example of a 20/30 configuration.

However there seems to be a hard cap of 32 on the number of blobbers that can be written to via 0box. Any erasure coding combination that requires > 32 blobbers will have the following behaviour:

The 0box cli will correctly calculate the required number of shards (in the above example 50) but only 32 of them will be distributed to blobbers.
In the above example the other 18 shards will be discarded and a non deterministic combination of data/parity shards will be written.

This limit of 32 seems to be the result of using a 32 bit mask on the upload operation:

Is this expected behaviour? The upload mask suggests it is but in that case I don’t think allocations should be allowed to be created via 0box if they require > 32 blobbers and/or this limit should be otherwise disclosed.

For example, while many EC ratios requiring >32 blobbers will upload successfully, silently dropping shards, higher EC ratios (> 64 blobbers total) will always fail to meet the required blobber consensus and will always fail:

Apologies if I have misunderstood erasure coding or am ignorant in some other way, this is a steep learning curve.

issue raised: Erasure Coding: Hard limit · Issue #14 · 0chain/zboxcli · GitHub feel free to close if i’m mistaken

Thanks for raising this, it looks a valid concern and is a great example of an issue that may only get highlighted when testing at scale.

Certainly the EC technology supports higher ratios and I believe that we should be able to support more than 32 albeit if a hard limit is imposed it should be imposed gracefully.

Thanks again for taking the time to raise this.

No problem, agreed that tends to be the case and this always comes to mind: