-
Notifications
You must be signed in to change notification settings - Fork 6
Description
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
contractproperty 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 aContractParameters
Other information that could be added to the invoke file
- CallFlags: If not provided,
EmitDynamicCalldefaults toCallFlags.All. Should we add acall-flagsfield to the dynamic call JSON object? - Signers: Today, NeoExpress generates a single signer for an invocation via the
Accountargument andWitnessScopeoption. 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:
HighPriorityandOracleResponse. 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. - Additional GAS fees: transactions in the mempool are ordered by
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.- Note, express
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 deprecated
- Note, express
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