Implement `NTCALL` opcodes for NTs

[PaulRBerg]

Tasks

• Implement the NTCALL, NTCALLVALUE, and NTDELEGATECALL opcodes to take a variable number of token IDs and token amounts instead of a single ETH amount.
• Refactor the existing CALL, CALLCODE, CALLVALUE, and DELEGATECALL opcodes to act as "stand-ins" to the new opcodes. Each existing opcode would fall back to its newer counterpart by passing a pair of (BASE_TOKEN_ID,value).

Spec

The proposed spec for NTCALL (analogous logic applies to the other opcodes) expects the token IDs and values to be put on the stack:

• Delete the value input at position 3 (alternatively, turn this value into a no-op; more research required)
• Add a new value called tokensLength, which signifies the number of token transfers
• If tokensLength == 0, do nothing; this call does not transfer any tokens
• Add tokensLength pairs of (token_id,value) pairs

Notes

• Since the stack can support only up to 1024 elements, a limited number of tokens can be transferred (but this should be high enough for all practical use cases)
• In practice, we should set the upper limit for tokensLength to something like 512 to make it difficult for the callee to run afoul of the stack limit
• See this StackExchange post

References

• Stack-based proposal for re-implementing CALL opcodes to support MNTs #22
• Problem: How can the token values be passed in contract calls? #19 (comment)
• EVM codes
• EtherVM

[IaroslavMazur]

Thanks for the Spec, @PaulRBerg!

---

Delete the value input at position 3 (alternatively, turn this value into a no-op; more research required)

I don't see why we'd have the value opcode argument alongside the new, MNA-specific ones. Especially given that we're talking about the completely new opcodes that won't need to try to be backwards-compatible.

[PaulRBerg]

You're right. It should be fine to remove the value input.