Skip to content

Invoke file updates #66

@devhawk

Description

@devhawk

I've got a branch where I'm working on updates to invoke file parsing. As part of this work, should we consider updates to the .neo-invoke file format?

Today, the ContractParameterParser class parses one or more objects that map to ScriptBuilder.EmitDynamicCall. The object properties map to the EmitDynamicCall parameters

  • contract property is parsed into the UInt160 contract script hash
  • operation property is a string that indicates the operation to invoke
  • args property is an optional array of JSON values that are parsed into a ContractParameters

Other information that could be added to the invoke file

  • CallFlags: If not provided, EmitDynamicCall defaults to CallFlags.All. Should we add a call-flags field to the dynamic call JSON object?
  • Signers: Today, NeoExpress generates a single signer for an invocation via the Account argument and WitnessScope option. However, this is only a fraction of transaction signing flexibility
    • a transaction can have multiple signers
    • a signer must have an account hash and WitnessScope, but also supports allowed contracts, allowed groups and witness rules. Today, express has no mechanism to allow the developer to specify this additional signer information.
  • TransactionAttribute: Transactions can have zero or more attributes. Today, there are only two defined attributes: HighPriority and OracleResponse. Express already has an oracle response command, so there shouldn't be any need to specify this directly. HighPriority is used for ordering transactions in the mem pool, so is conceivably interesting. However, HighPriority transactions MUST be signed by the NEO committee, so they are of limited use by rank-and-file developers.
  • Additional GAS fees: transactions in the mempool are ordered by FeePerByte and then NetworkFee, thus there are scenarios for increasing the network fee paid for preferential mempool ordering. However, since neo express runs locally, there aren't typically a large number of transactions in the mempool, so it's not clear how much use this would be.
    • Note, express contract invoke has an --additional-gas argument, but that adds to SystemFee not NetworkFee. This is actually a hold over from Neo N3 beta timeframe where there were bugs in the system fee calculation engine. This argument should probably be deprecated

IMO, we should consider providing a mechanism to encode complete singer information in JSON for use in invoke file scenarios. I'm actually thinking this should be a separate file (.neo-signers maybe?). The current invoke file mirrors invocation script generation so adding signer information would break some backwards compatibility. Additionally, a separate file would enable use in contract run command as well as contract invoke.

We should also add CallFlags property to the dynamic call object. It's not used often, but it's also fairly easy to add. Unlike other properties like account and contract, parsing a CallFlags string -> enum value is straightforward and requires no outside information

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions