Support for EIP-2718 transaction envelope types beyond 1 and 2

[aaronmgdr]

Describe the Feature

I would like to be able to send and sign transactions which have types beyond null 1 and 2 and which may contain additional parameters.

Currently Ethers does not allow transactions with other types and actively removes any unknown object parameters making the use of alternative transaction types impossible.

My initial use for this will be using Celo's 0x7c ie type 124 which adds support the gasFeeCurrency parameter to transactions.

//////

I plan to do the work for this. But want to start a discussion about how ethers would prefer to address this.

I could just submit a PR to allow the specific use case I have. Alternatively perhaps ethers could support some sort of bring your own Transaction Envelope parser. As of yet I don't know how it would look or if it would actually have benefits in code size and understandability.

Code Example

sendTransaction({
 type: 124,
 to: EOA_ADDRESS,
 from: EOA_ADDRESS,
 value: 0 
 feeCurrency: CUSD_CONTRACT_ADDRESS,
 //etc
})

Other cases where alternative Transaction details are being requested

• Add arbitrum specific fields to tx receipt type #3505

[ricmoo]

My first thought would be to sub-class Transaction, and in the static from method, hijack the type you care about, creating a new CustomTransaction(params), which has all the extra properties you care about. And you can then override the *serialized methods, to use your serialization for your type, otherwise just call the super.

You can similarly override the inferTypes, clone and toJSON methods.

The built-in functions for parsing and serializing aren’t really exposed, but they are pretty trivial to work with using the decodeRlp and encodeRlp.

I’ve been considering adding custom network packages for non-standard networks. If you make any process, let me know and I can start that program earlier on. :)

[aaronmgdr]

Thanks for the quick reply.

I did some research a while back on Subclassing and as i went down the rabbit hole I kept needing to subclass and overwrite more methods. one issue was that copyRequest kept removing properties from the transaction object.

Im not sure what a moon-standard network is (although googling i learned The Moon is getting a G4 cellular network) I hope it means that the work im gonna do is helpful beyond my case

[ricmoo]

(updated: moon-standard -> non-standard)

Lol! Oh. Autocorrect.

I was contemplating the copyRequest function too, trying to think of a way to make it Network-specific or using the toJSON method if present and a function.

The reason I don’t want to ingrate anything too directly is that over the years, dozens of chains have wanted their “own logic” baked in. Many of those chains no longer exist (or I have never heard of them since). Some networks may use the same type for another format or such too. I’ve historically made separate packages for them, which various levels of success. For example, Aion required blake2b added because they use it for their hashes, which increases the library size for something no one else requires. Some networks required some large emscripten library of 1.2 megabytes of protocol buffers and whatnot just to compute the hash.

So, I target Ethereum and chains that don’t deviate too far. Part of v6 is to try making it easier to support non-standard networks (I like the term “strange networks”, meant as a fun term, but comes off more often as mean. :p)

So, I’m all ears if you have other suggestions.

I think if copyRequest works more universally, an otherwise unsupported chain shouldn’t require much more than a custom Transaction sub-class, a Network definition (possibly with custom NetworkPlugins) and possibly some custom Classes for the Provider objects (which the NetworkPlugins would coerce things into).

[aaronmgdr]

Definitely respect that and that you have kept ethers as small as it can be.

Ill Do some more research in the direction of enabling easier extension rather than adding specific features

[ricmoo]

I’ll also add a feature in the v6.1 that makes it easier to support Transaction subclasses.

[gastonponti]

What about adding a way to set delegators to handle different kind of txs. Something like, plug the type 0x14, and delegate it's calls to a specific class that has to cover the way you can serialize it, the extra data to be assigned and etc etc.
In a way every L2 or L1 ethereum like will need a way to create their own txs, maintaining the same compatibility with ethereum, but something like this could avoid projects to fork ethers, to instead plug their differentiators.
Ethersjs could be an agnostic library that others could also use, without forking and branching the community.

I'm not saying that you are the only ones that should do that, haha, but maybe a "could ethersjs accept to add a module that allow others to plug their txs without changing their code"

[aaronmgdr]

I did a read thru of code for spots where there could be issues. #3751

Maybe its helpful maybe its not.

[aaronmgdr]

I was looking at the work done on Plugins and I think this could be a great way to handle extendability rather than Transaction subclasses as not every thing that needs to be extensible is part of that class and often most of the body for Transaction methods should remain.

export class TransactionEnvelopePlugin<TXType> extends NetworkPlugin {

    readonly eip2178type: number
    readonly serialize: (tx: TXType, sig?: Signature) => string
    readonly parse: (tx: Uint8Array) => TXType
    readonly extraTXProperties: string[]

    constructor(
        eip2178type: number,
        serialize: (tx: TXType, sig?: Signature) => string,
        parse: (tx: Uint8Array) => TXType,
        extraTXProperties: string[] // properties in the tx obj this type supports beyond the ones supported in type 1 and 2
        // alternatively a copyRequest function. 
    ) {
        // should the type be part of name?
        super("org.ethers.plugins.network.txe");

        this.eip2178type = eip2178type
        this.serialize = serialize
        this.parse = parse
        this.extraTXProperties = extraTXProperties
    }

    clone(): TransactionEnvelopePlugin<TXType> {
        return new TransactionEnvelopePlugin(this.eip2178type, this.serialize, this.parse, this.extraTXProperties);
    }

}

[ricmoo]

The problem is Plugins are mainly asynchronous in nature. And the Transaction operations are all synchronous. You don't always have a Network object, but should still be able to process Transactions...

But I was imagining, for a given network it would have code that looks like:

import { ethers } from "ethers";

// This Transaction class is a sub-class of ethers.Transaction, and should be used when the
// envelope types are necessary
import { CeloNetwork, Transaction } from "@ethers-ext/celo";

// The CeloNetwork would certainly have a bunch of plugins though, to handle custom
// block properties, transactions, etc.

const provider = new JsonRpcProvider(url, CeloNetwork);

The problem with global registration is that various bundlers and other tools really do not play well with global registration things. Especially if there are 2 different versions of ethers in use (such as when using hardhat for testing), as the registration only happens against the version where the registration happened explicitly, which then means it either works in the app and not in the tests or works in the tests and not in the app.

A bigger issue, is that it is complicated to use in ESM projects, since import is always async, things like this are confusing and really don't work how people expect them to:

// SetupCelo/index.js
import { ethers } from "ethers"; 
ethers.Network.networks.celo = "foobar";


// main.js
import "SetupCelo"
import { ethers } from "ethers";

// Things done here operate before all imports are SetupCelo is resolved
console.log(ethers.Network.networks.celo);
// undefined

setTimeout(() => {
  // Now things are fine, but developers are (justifiable) confused... And also have to wrap
  //  all their code to execute in the event loop
  console.log(ethers.Network.networks.celo);
  // "foobar"
}, 0);

There are a lot of little gotchas, that have gotcha-ed me over the years. :)

[aaronmgdr]

Thanks for talking this out. 😊

I agree its best to avoid global registration.

The problem is Plugins are mainly asynchronous in nature. And the Transaction operations are all synchronous.

Maybe I just haven't understood how you intend for plugins to be used but I don't see anything inherently async about them.

I saw AbstractProvider has access to a attachPlugin function. I realized later that ProviderPlugins are different than NetworkPlugins. But had been thinking the TransactionEnvelopePlugin would be attached to the provider and then since signers have access to provider either the entire class or the relevant method could be passed as an optional argument to functions like populate. and copyRequest

Probably has issues still. 🤔

Do you think the idea of some object that given a tx type number can say ok "parse with this, serialize with this, these are the allowed/needed properties" is a good way to encapsulate allowing alternative tx types? ?