feat: native tokens

[PaulRBerg]

Context

A big PR that closes #5, #74 and #145.

This PR is a replacement for #14 and #148, which we have closed as a result of (i) multiple conflicts due to an in-flight merge and (ii) the name change from MNAs to MNTs.

Feedback

I slogged through the rebase, reviewing your work @IaroslavMazur in the process.

Feedback and changelog:

• Misc improvements, e.g.
  • Keep only drain_balances because this function is needed only for the DAO hardfork
  • Use increase_base_balance_saturating instead of set_base_balance(get_base_balance().saturating_add())
• Swapped the order of the parameters for BALANCEOF; as mentioned in the spec, the token id comes first
• Refactored "Native Assets" to "Native Tokens"
• The opcodes should be defined close to each other in order to (i) minimize rebasing conflicts and (ii) avoid accidental overlaps with planned EIPs
• Undid the NTCALL, NTDELEGATECALL, and NTCREATE implementations because we're not planning on supporting smart contracts in Genesis (besides MNTs themselves).
• Undid all SELF-DESTRUCT logic removal; even if we decide to remove this logic, it'd be better to do it in a separate PR.
  • For the future: we don't need an NTCALLCODE opcode, just an NTDELEGATECALL because CALLCODE is a deprecated version of DELEGATECALL.

Rebasing

I will create a separate discussion about our REVM rebasing strategy.

[IaroslavMazur]

Swapped the order of the parameters for BALANCEOF; as mentioned in the spec, the token id comes first

Either way is fine, as long as on the opposite side (i.e. when the opcode arguments are being input), the items are being pushed in the reverse order. Stack is LIFO-based.

Note that in the balance() function, where balance_of() is being called from, the token id is being pushed to the Stack first, and the address - second.

Therefore, either the address must be popped first in balance_of() - or the pushing order in balance() needs to be reversed, as well.

[PaulRBerg]

Either way is fine

Yeah, either way works technically, but this is a matter of consistency and logical flow.

The balances (in the state) are mapped from token IDs to amounts, so it makes sense to have the opcode and the precompile follow the same order.

either the address must be popped first

Yes. Happy to pop the address first, because that's an internal operation that end users need not about.

[IaroslavMazur]

Yes. Happy to pop the address first, because that's an internal operation that end users need not about.

After having taken a closer look at the other EVM opcodes and how they're implemented in revm, for the sake of consistency, I suggest we follow the existing example of the EXTCODECOPY opcode. In its implementation, the opcode arguments are being popped in their "logical" order.

The above would mean:

1. popping the token_id, first, and the address - second in balance_of() and
2. pushing them in reverse order (address, followed by token_id) in balance()

If you agree, I can include this change with the rest of the things I've got to move on top on this PR branch.

[PaulRBerg]

sounds good

[IaroslavMazur]

@PaulRBerg, the PR is ready to be reviewed

[IaroslavMazur]

As discussed privately, I'm integrating this PR without @PaulRBerg's review.