TRXID opcode
nmushegian opened this issue · 12 comments
There are a number of interesting primitives that can be constructed if you can get a handle on the "current atomic interaction" aka "current transaction"
TRXID could be a simple increasing global nonce, or could be sha3(origin,nonce).
The closest you can get right now to a unique ID is (origin,block) plus enforcing one-origin-per-block which is awkward and incomplete.
May be an OP_TXNONCE is better idea... This way you can put a condition filled only when two consecutive transactions happen.
This way you can put a condition filled only when two consecutive transactions happen.
Interesting...
Maybe even just call it OP_TXNUMBER?
There are a number of interesting primitives that can be constructed if you can get a handle on the "current atomic interaction" aka "current transaction"
Can you enumerate some of them?
One use case for this is the "asynchronous oracle pattern", alluded to in ethereum/btcrelay#44 which discusses how REVERT + RETURNDATA can undermine synchronous oracles.
For an asynchronous oracle (i.e. oracle contract is first sent a payment and request for data, then a callback tx is sent to get the return data), the oracle contract needs to to ensure that the payment call and the callback call originate from different tx's. Otherwise, the payment call could be reverted after the return data is received.
Currently the only way for contracts to distinguish the transaction scope of two incoming calls is to check the block NUMBER or BLOCKHASH in each call; there's no way to distinguish whether two calls originate from a single tx or from two different tx's within the same block. A TRXID opcode would enable contracts to check that two different calls are from two different tx's, so that an oracle contract could securely allow both the payment tx and the callback tx to occur within the same block.
Had not heard of that example @cdetrio, that's great.
My main goal here has to do with tokens and allowing temporarily negative balances within a transaction
Personally out of all of the above I favor TXNUMBER. It's cleanest and simplest.
@vbuterin Should TXNUMBER be the index of the transaction inside the block?, or should it be a global index that does not starts from zero on each block and goes always incrementing?
I think global index is more useful, but (blocknum, tx_in_block) is also fine if anyone can think of reasons to care about per-block index
You can adopt RSK TXINDEX implementation, which is very similar to the one discussed here. You can check RSK's TXINDEX here:
https://github.com/rsksmart/rskj/blob/master/rskj-core/src/main/java/org/ethereum/vm/VM.java#L849
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
Hi github robot helper, no it looks like this is still not implemented but maybe a good suggestion! Thanks for the bump!
@nmushegian If you want to pursue this idea, you should either create an EIP following instructions in EIP-1 or create a thread in the Ethereum Magicians forum to discuss it further.
Closing this for now as this repository is no longer the right place for discussions like this.