EIP901: Additional EVM Transaction Global Variables

[k06a]

EIP: 901
Title: Additional EVM Transaction Global Variables
Author: Anton Bukov <k06aaa@gmail.com>
Category: EVM
Created: 2018-02-23
Updated: 2019-04-20

Simple Summary

Some additional global variables are technically possible to be added but not yet added to EVM: tx.hash, tx.nonce, block.chain_id.

Motivation

1. tx.hash: Hash of the transaction can be used in Dapps (backendless solutions) to provide direct links to blockchain explorer to the concrete transaction. Transaction nonce can be used for something unknown to me at this moment.

2. block.chain_id: For example, need to implement replay protection to delegate transactions: https://github.com/bitclave/Feeless

Revisions

2018/02/23: First version 2018/04/23: Added block.chain_id 2019/04/20: Clarified why tx.hash couldn't be provided 2019/05/29: Reverted prev changes, sorry :)

[Arachnid]

I think this needs more concrete motivation than is provided. It's unclear what you mean by the first part, too - we can already link to blockchain explorers from backendless applications.

[k06a]

@Arachnid, for example, I wanna store tx.hash in smart contract to form URL in Dapp later: https://etherscan.io/tx/{tx.hash}

[nateawelch]

@k06a why does the dapp need to fetch this from the contract data itself? The dapp can just check the blockchain history for what transactions were sent to the contract.

[k06a]

@flygoing some Dapps to not have backend at all. They use Ethereum node (or INFURA.io) as backend.

[nateawelch]

@k06a it doesn't need a backend besides a node to do what I said. My point was that since the dapp has access to the blockchain, via the node, it can access contract logs. So the contract can log data and the dapp, when it fetches events, can grab the tx hash from the log.

[k06a]

@flygoing @Arachnid just added block.chain_id to the EIP, wanna know your opinion on this.

[Arachnid]

tx.nonce should probably not be added, since it will conflict with transaction abstraction work.

If you want to make this into an EIP, you'll need to specify the opcodes more rigorously.

Being able to access codehash without fetching the full code for a contract might also be a useful opcode to add.

[k06a]

@Arachnid what do you think about block.chain_id? Almost any signature-related stuff should require chain-id restrictions.

[Arachnid]

@k06a That seems like a reasonable idea to me.

[Arachnid]

Would you consider writing this up as a pull request (or preferably, several - one for each proposed opcode) in more details at the EVM level?

[rmeissner]

In some other EIPs tx.gas was also mentioned. I think it would make sense to add this in the same process. (tx.gas - Gas send with the transaction)

[rmeissner]

Is there anything I could help with, as these opcodes would be really interesting to me :)

[k06a]

@rmeissner we need to create several pull requests, one for each opcode. I'm going to dive in EVM tech details and try to create PR soon.

[nateawelch]

I'm totally for more proposals that put forward sensical opcodes, like this does, but I'm also against increased reliance on external transactions when my hope is that we move towards contracts as identities and external keys only as authorizations for those identities, and with account abstraction, a lot of that happens automatically anyway. That said, I do think a CHAINID opcode makes a lot of sense to include. I also think GASLIMIT makes sense, but only if it returns the gas limit of the current call, not the entire tx.

[rmeissner]

@k06a has there been any progress on this? It would be nice to bring this forward now to have a chance that this is picked up for the next hardfork

[k06a]

@rmeissner we need someone familiar with EVM codebase to add necessary opcodes first. Than add Solidity support.

[rmeissner]

@k06a Ohhh didn't see that :D https://ethereum.github.io/yellowpaper/paper.pdf starting page 28 you see all opcodes. Another way would be to look at an implementation (e.g. https://github.com/ethereumjs/ethereumjs-vm/blob/master/lib/opcodes.js)

I would change tx.gas to msg.gaslimitas @flygoing was proposing (to get the gas available for the current call)

Based on that I would propose the following opcodes:

block.chain_id

CHAINID: 0x46 with gas cost of 2 (G_base) Get the chain id of the chain where the block was mined.

msg.gaslimit

CALLGASLIMIT: 0x3f with gas costs of 2 (G_base) Get gas available for this execution.

tx.nonce

NONCE: 0xb0 with gas costs of 2 (G_base) Get nonce of the execution origination address.

Issue is a little that I would put the last two in the 0x30 range but it is full 😬 therefore I will propose the 0xb0 range to continue the closure state.

[k06a]

Nice 👍What do you think about adding also block.gaslimit?

[rmeissner]

That already exists. See https://solidity.readthedocs.io/en/latest/units-and-global-variables.html

[k06a]

@rmeissner thanks! Missed it for some reason.

[rmeissner]

@k06a will you create PRs for this? Else I would try to do that tomorrow.

@Arachnid are there any additional information necessary for the EVM part?

[k06a]

@rmeissner I think this PR should be yours according to the info you provided.

[KaiRo-at]

tx.hash: Hash of the transaction can be used in Dapps (backendless solutions) to provide direct links to blockchain explorer to the concrete transaction.

Is there an open (followup) proposal for this part?

[k06a]

@KaiRo-at I realized that tx.hash could not be provided inside the smart contract since this value is computed on top of transaction execution results. The only way is to make etherscan.io to have an API similar to this: etherscan.io/tx/<sender_addresss>/<nonce>

[KaiRo-at]

@KaiRo-at I realized that tx.hash could not be provided inside the smart contract since this value is computed on top of transaction execution results. The only way is to make etherscan.io to have an API similar to this: etherscan.io/tx/<sender_addresss>/<nonce>

I'm confused by that explanation as the tx.hash is actually known already when the transaction is broadcast, which is before the code is actually executed. Also, Etherscan is not available inside the contract, for one thing, and for the other, depending on external resources like Etherscan is nothing I'm too happy with in systems I work on, as it adds risk of e.g. outages and/or (future) paywalls. That said, I found a way around using this for my current use case by reliably having access to all event log history of my contracts, but I'd still would find it an interesting feature.

[k06a]

@KaiRo-at oh, thanks! My fail, it was about blockhash.

[aaronovz1]

Was there ever resolution on tx.hash being included? Is there an EIP for it?

[rmeissner]

The only EIP that was derived is the on for the CHAINID. Besides that there was not enough feedback to create any other.

[norwnd]

Here is an example of Dapp where access to tx.hash from Solidity will improve UX: https://github.com/decred/dcrdex/issues/1927