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.

[PaulRBerg]

While working on Native Tokens, we have come to realize that implementing these opcodes will be challenging. Precompiles weren't designed to manipulate the state of the EVM, and this poses problems like this.

Moving this task from Genesis to Odyssey.