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 hashoperation property is a string that indicates the operation to invokeargs 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
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
ContractParameterParserclass parses one or more objects that map toScriptBuilder.EmitDynamicCall. The object properties map to the EmitDynamicCall parameterscontractproperty is parsed into theUInt160contract script hashoperationproperty is a string that indicates the operation to invokeargsproperty is an optional array of JSON values that are parsed into aContractParametersOther information that could be added to the invoke file
EmitDynamicCalldefaults toCallFlags.All. Should we add acall-flagsfield to the dynamic call JSON object?Accountargument andWitnessScopeoption. However, this is only a fraction of transaction signing flexibilityHighPriorityandOracleResponse. Express already has anoracle responsecommand, so there shouldn't be any need to specify this directly.HighPriorityis used for ordering transactions in the mem pool, so is conceivably interesting. However,HighPrioritytransactions MUST be signed by the NEO committee, so they are of limited use by rank-and-file developers.FeePerByteand thenNetworkFee, 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.contract invokehas an--additional-gasargument, 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 deprecatedIMO, 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 runcommand as well ascontract 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