Follow up:


Meta (/ˈmɛtə/; noun): (of a work) referring to itself or to the conventions of its genre; self-referential.

Referring to transactions this would mean, a transaction meant to transact a transaction (!). Put differently, the original user (the one who wants to transact) passes on their intent to perform a transaction on the blockchain. Another user, picks it up and performs the transaction on behalf of the original user.

User Alice -> Signs on a function doSomething(params) (Note, the user signs on the function not a transaction) -> sigOfAliceToDoSomething. Alice here generates a signatured intent to perform the action. Some other user, say, Bob, takes the signature sigOfAliceToDoSomething -> unpacks it to verify Alice as the sender -> gets to the intent doSomething(params) -> performs the action (Note, the action doer here is Bob and not Alice) -> and does whatever it is to be done with the returned values.

Now, this entire architecture is vague and has a lot of areas that can be separately dealt with. Some of which are listed below:

  1. What exactly must Alice sign on?
  2. How does the signature reach Bob?
  3. Why would it be in Bob’s interest to perform the transaction?
  4. How does one get to the ‘true’ executor of the transaction (that is Alice) if it were delegated to Bob (assuming the signature was passed off-chain)? In other words, how to separate a transaction singer from a transaction deployer?

Now there might be multiple ways this problem statement can be formulated in, to focus on a particular aspect, or tackle a much bigger problem - and there in fact exist some, e.g., (chronologically arranged)