Consider renaming fields and changing types in the broadcast JSON output files

[mds1]

Component

Forge

Describe the feature you would like

Right now in the broadcast logs there are two fields with names we should consider changing due to conflicts with language keywords.

1. function is a keyword in JS, solidity, and likely other languages. I'd suggest renaming this to functionSig since the full signature is shown
2. type is also a keyword in many languages. I'd suggest renaming to txType

There are also fields where the output types should be changed (I recall discussing this in the past but not sure if we're tracking anywhere so figured I'd mention it here). First, in the transactions array:

• transaction.type should be a number, currently it's a hex string
• transaction.gas should be a number, currently it's a hex string
• Addresses are not logged as checksummed but they should be (also tracked in https://github.com/foundry-rs/foundry/issues/2975)
• When a function argument is an address, the arguments array omits the 0x prefix but it should be included.
• When a function argument is a boolean, the arguments array contains a string of "true" instead of a boolean of true (same for false)

In the receipts array:

• transactionIndex can be a number, currently it's a hex string
• blockNumber can be a number, currently it's a hex string
• In the logs array, transactionIndex, logIndex, and transactionLogIndex can all be numbers, currently they are hex strings
• cumulativeGasUsed can be a number, currently it's a hex string
• gasUsed can be a number, currently it's a hex string
• Addresses are not logged as checksummed but they should be
• status is a hex string but should be either a boolean or a number of 1 or 0

The above list is not comprehensive and there may be other fields that should have a more readable type.

These suggestions deviate from the ethereum JSON RPC spec in the sense that all numbers are "quantities" which means they're returned from the node as hex strings with as few leading zeros as possible. However, this makes the data less readable and harder to parse, and I don't think there's a reason why these log files need to strictly follow the spec.

Additional context

No response