I might have missed this point in the EIP, but I am not yet certain if this new (abstract) transactions this EIP introduces are completely new transactions, or are also dependent upon older EIPs. For instance, should the new transactions also implement EIP-155? EIP-2930 seems to imply this is not the case, but I think it would make the EIP a bit clearer if it explicitly states that these are completely new transactions, and thus do not have to abide any “chain rules” or rules (EIPs) implemented by hardforks.
It is up to each new typed transaction what features they want. So far, the proposed typed transactions (EIP-2930 and EIP-1559) both have a chain ID field to prevent replay attacks across chains, which is what EIP-155 did for legacy transactions.
A future new transaction type could choose to not do this and allow replays across chains, or they could choose to implement replay protection in a different way, or perhaps in the same way that legacy transactions did via EIP-155.
Can you elaborate a bit more on this? EIP-155 is a transaction parsing/encoding/decoding rule, and each typed transaction gets to completely define how it is parsed/encoded/decoded aside from the 2718 envelope.
I took this EIP as a specific example. It seems that we thus only have to apply this EIP on Legacy transactions and thus that (by your response) by EIP-2718 each transaction can decide themselves how exactly they should be hashed, signed, etc.
- shall we consider the TransactionType field to be bit flags:
so for example:
Legacy == 1
Eip1559 == 2
AccessList == 4
then we can have a legacy with access list (5)
and eip-1559 with access list (6)
Having a separate bit for each transaction type would limit us to 8 bits per byte, and since legacy transactions set the top two bits in the first byte, and we would like to reserve the high bit for future expansion that leaves us with only 6 bits of usable space for the first byte and 7 bits for each subsequent byte (if we did naive length extension).
More importantly though, I think most future transaction types will not compose as nicely as access lists (which just adds a new optional field). Some will, like expiring transactions if that goes in, but other types like things that change signature scheme or things that greatly alter what fields a transaction has don’t compose nearly as well (like cancellation transactions).
1 Like
Heya! I am adding this to ethers right now and just wanted to add a quick suggestion.
Can we add to the EIP that transaction type 0x19 is reserved, so that this never interferes with EIP-191?
3 Likes
My hope is that we can create a list of transaction types in the eth1.0-specs repository. In there we can record the type for 2930, 1559, 3074, legacy transactions (2 bytes), and 0x19 for signed messages.
If we can do that, I will probably remove the mention of legacy transaction types from this EIP to keep all “consumed” types consolidated in the list.
Hi! Which tests in the ethereum/tests repo test the implementation for this EIP? I see that the 2930 ones test some of the functionality, but I am not sure if there are existing tests for the SHOULD re: signing the first transaction byte, or if I should be writing my own? I didn’t see a mention of this EIP in the tests repo, which is why I’m bothering people here 
Thanks!
EIP-2718 is a specification for how future new transaction types should be specified so there isn’t really anything to test for this EIP alone. In fact, you could code up 2718 and include it without a fork block back in a genesis client and you would be able to sync. 
The 2930 tests should cover everything about 2930, including how it is laid out and signed (which, according to its specification, should be a valid 2718 enveloping).
hello all. i have 3 somewhat random questions about eip-2718:
1 where can i find a list of all of the transaction types? so far i’ve figured out that 0 is legacy and 2 is eip-1559 but that’s it
2 eip-2718 what do “v", “r", and “s" stand for in this snippet: rlp([nonce, gasPrice, gasLimit, to, value, data, v, r, s])
3 compute-raw-transaction is this code supposed to be used on a tx that has not been sent yet, has been sent but not mined, or has been mined? i realize this isn’t specifically about eip-2718 but i guess it’s somewhat related to it
thanks in advance
At the moment there are:
Type 0: Placeholder for legacy transactions, but they are not actually encoded in consensus as “type 0” anywhere. Some tools will fill in the type field as 0 for legacy transactions just for consistency.
Type 1: EIP-2930 (access lists)
Type 2: EIP-1559
There are also a couple of other things that aren’t technically typed transactions, but would be useful to avoid collisions with such as 0x19 which is a prefix used to indicated a signed message.
v,r,s are the three parts of a secp256k1 signature. New transaction types are also signed with secp256k1 and also have an r and s to make up the signature, but instead of v (which is an incredibly complicated parameter in legacy transactions) they now just have a yParity which is a single bit (true or false) that gives enough additional information to allow for recovery of the address of the person that signed a transaction (along with the signature and the transaction being signed).
@ricmoo would better be able to answer this as they are the maintainer of ethers. My guess though is that it is used to create the “raw” (RLP encoded) transaction from a more traditional in-memory representation of it (which is usually JSON or a native object of some kind).
2 Likes
@prevail Here is the maintained list of signature prefixes: execution-specs/lists/signature-types at master · ethereum/execution-specs · GitHub
1 Like
I suspect that an irregular state change would not be considered acceptable to the core devs. We have discussed it before for situations like this where we have some critical upgrade we need to do but there are a small number of contracts out there that will break. This recurring problem is part of what makes EVM versioning something that many want, because it would allow us to change behavior of future contracts without changing the behavior of legacy contracts. That being said, since tx.origin reaches out of its call frame for data it isn’t immediately obvious that this would be handled cleanly by EVM versioning.
Can Etheria deploy a new contract and migrate users from old to new (either automatically via airdrop or via manual user migration)? Augur and several other things have done this in the past to deal with upgrades.
@cyrus Did you mean to post this in this thread? After reading back through the recent history, it seems unrelated to this EIP or the discussion at hand.
1 Like
I’ve deleted my comments and am withdrawing my concerns. We can work around this EIP if adopted. We are already advising owners to keep the NFTs in separate, cold accounts. “Don’t mine” and “don’t sponsor transactions” is basically the same advice.
I think that would be a good idea only if TransactionType i+j == TransactionType i ∪ TransactionType j makes sense.