Neo: InvocationTransaction max script size

[dicarlo2]

@erikzhang Looks like we're limited to [1] 65536 bytes for the script, which means contracts can only be 65536 bytes (well a little less in order to do the Neo.Contract.Create syscall). Any chance we can increase the limit? This seems like it might have been an unintended side-effect of the PublishTransaction deprecation because there is a much higher limit on the contract size created through PublishTransaction[2] - 2,147,483,591[3]. While I don't think that we should necessarily allow 2gb scripts, I think it would be reasonable to increase the limit from 65kb. I'm not sure what that limit should be, but perhaps 1mb?

[1] https://github.com/neo-project/neo/blob/master/neo/Core/InvocationTransaction.cs#L26
[2] https://github.com/neo-project/neo/blob/master/neo/Core/PublishTransaction.cs#L47
[3] https://github.com/neo-project/neo/blob/master/neo/IO/Helper.cs#L132

[erikzhang]

PublishTransaction is no longer in use and will be rejected by the network:

https://github.com/neo-project/neo/blob/cb3a4a75854bb218b7b085b7b8bdaff0c69d7e8c/neo/Core/PublishTransaction.cs#L92-L95

The limit of script size of InvocationTransaction can be increased if necessary. Can you propose a complete plan?

[shargon]

Can you give us one valid example for this?

[dicarlo2]

Can you describe what you mean by a valid example? The TypeScript compiler we're working on for neo-one emits a large amount of bytecode currently, so increasing the limit would help unblock releasing it.

Other platforms, Ethereum in particular, actually have a lower limit on the bytecode size than we currently have, BUT unlike Ethereum and other contract platforms, the cost of deploying contracts on NEO is very high. This means that it's not economical to deploy smart contracts with common library functionality, which eliminates the possibility for smaller contracts that rely on library code contracts. Instead, contract authors basically need to include all of the code they plan on running within their contract, even if it's duplicated library code.

[erikzhang]

So you think 1MB is the correct limit?

[dicarlo2]

Sorry, was off the grid for a bit. I will think on the implications of increasing the size limit and report back here with my thoughts.

[igormcoelho]

@dicarlo2 I have thought about those implications, and since JMP instructions use absolute reference for 2 bytes (max 65k), it would be nice to keep this limit now (unless there are strong reasons to increase it). Otherwise, jumps can also be mapped consecutively (JMP +65k falls in another JMP... until it reaches 1M, for instance).
I have also thought about a small project on AVM post-optimization, in order to reduce useless instructions (see this commit https://github.com/NeoResearch/neocompiler-eco/commit/25b41aa173b23776ea4004eceb91fa34a254dd39)
The first heuristic will aim at cutting NOP, then realigning and removing useless JUMPs. At least this part I know is easy and is already capable of removing many instructions.... perhaps this may help your typescript release to come sooner.

[igormcoelho]

Ok guys, I have a first prototype working, cutting a lot of NOPs.
https://github.com/NeoResearch/neon-opt

In a few time, it will be easy to remove many useless jumps also (as I have noticed), and do many workarounds on the AVM, one after another ;)

Results for C# ICO template with only NOP reduction strategy: operation reduction 9.31%; byte compression 3.51%

[dicarlo2]

@igormcoelho We don't emit NOPs or useless JUMPs in the typescript compiler. We just emit a lot of code. Certainly we could reduce it (and we plan to). We also noticed the issue with the limitation around JMP and currently split up our jumps to account for that (pretty much exactly as you described).

@all - sorry I haven't had a chance to reply with more concrete details/thoughts, I will get to this asap.

[igormcoelho]

@dicarlo2 what do you mean by a lot of code? push ? stack op ? I just noticed it's easy to reduce some stack operations ... that will help a lot the C# compiler, neon-opt project is evolving quickly.

[vncoelho]

@dicarlo2, is this discussion still a need or should we close it?
Is there any code in mind that is exceeding the current limit?

[erikzhang]

We can increase the limit. But we need to find a best value.

[dicarlo2]

We can close, we actually don't need it anymore - we emit much more efficient code since I posted this (both in total size and execution time).