Option to embed ABI within contract wasm metadata

[austinabell]

Was planned/currently being experimented with by @miraclx, but we should consider some data on the size of each relative to understand whether it makes sense to have this as optional, default, or even supported.

cc @zcstarr

[zcstarr]

So my thoughts here would be to just get a ballpark of the typical WASM size on Near. Probably the super proper thing would be to look at the distribution of contract sizes on mainnet, and the measure that middle point.

Then that would be a benchmark for including the ABI directly within the wasm. The thought would be if we say 200kb-500kb is the ~size of a contract w/o abi, and ABI data is 20kb. we'd be looking at a 4-10% increase in wasm size.

I think for the ability to have connected contracts alot of developers would make that trade off. It would mean 0 maintenance on offering simple clients for users to use in their 3rd party projects.

So I took an open-rpc document fully specified an unoptimized(meaning only inlined json-schema no definitions) and including extensive documentation types. it clocked in at 25kb, if you gz compress it 3.6kb

So it's possible without much optimization (outside of a simple gz compressed data) you'd be looking at 0.07% - 1.8% increase in size.

That said I think the take away here is to just plot the numbers and see what is the actual state of contract size deployed to the network. I think that will inform everything.

[austinabell]

Then that would be a benchmark for including the ABI directly within the wasm. The thought would be if we say 200kb-500kb is the ~size of a contract w/o abi, and ABI data is 20kb. we'd be looking at a 4-10% increase in wasm size.

So it's possible without much optimization (outside of a simple gz compressed data) you'd be looking at 0.07% - 1.8% increase in size.

I agree this can be minimal relative to the contract size, but the contract size should and probably will be cut dramatically in the future. Current contract sizes are at least ~5-10x larger than what they can be.

Another thing we can do to really optimize the size of the ABI in the contract is instead serializing the ABI as some self-describing binary format like cbor before gz the bytes. CBOR vs JSON would be ~20-50% size decrease. Alternatively, if we really want to optimize, we can serialize it as borsh in some versioned way for an even more minimal footprint.