Having to split payloads that are large into multiple transactions becomes tiring to work with.

[cryptobench]

When I was working on the CoinMarketCap clone, I noticed that if payloads exceeded around 60 KB, transactions would fail due to gas/size limits. To work around this, I had to manually split the payload into multiple transactions.

Ideally, the SDK could handle this automatically. It would save time and reduce complexity if I could simply pass in my full JSON payload and let the SDK handle splitting it into valid chunks behind the scenes, depending on size.

The goal is to get as close as possible to something like sendTransaction(allMyData) instead of having to write logic like if payload > 60kb followed by custom splitting and transaction handling.

[krzysiekfonal]

First of all - we should report it to GolemBase as it seems the issue in the core side.

But another thing I'd like to suggest/discuss here.
if sendTransaction(...) can be internally split then we might get receipt or receipts what might be confusing and not consistent with the name (the fact we can get one or many receipt from single sendTransaction).
So if we consider changing a bit the interface - I would suggest to replace sendTransaction with sth more data/entity centric.
All other methods are entity-centric, createEntities, updateEntities, queryEntities etc but this one sounds more blockchain-centric. Maybe we should change the name and response type to by like mutateEntities with result as list of IDs of deleted, created, updated?
Alos maybe getStorageValue we should rename to getEntityPayload ?