Thanks for sharing this here, very interesting stuff. There is a lot to chew on in the Fae docs, but one aspect in particular is relevant and I want to expand on it. Incidentally, thinking about this aspect was what first led me to “Phase One and Done”, but I wasn’t sure how to articulate it (I’m still not, as you’ll see, but please forgive me for rambling anyway). The data availability bridge was a second line of thought that I ended up writing down instead, but maybe this first take was the better one, lol.
Starting with excerpts of the relevant aspect from faeth-doc:
We will call an Ethereum transaction having an embedded Fae transaction of this form a “Faeth transaction”. Note that since the input is entirely occupied by data that is nonsensical to Ethereum
This is analogous to the data in shard blocks being nonsensical to Phase 1 validators; all data blobs are equivalent junk data and may as well be zero bytes as far as Phase 1 is concerned.
This allows Fae to quickly scan Ethereum transactions to find valid Faeth transactions.
“Quickly”, but it has to backward-scan the Ethereum chain back to the Faeth genesis block, in order to find all the Feath transactions, right? That would be a lot of data to download and process, so sounds like this would make Faeth light clients impossible.
Although everyone must process the Faeth transaction as an Ethereum transaction, this entails little work because the EVM is not run. The actual work, the Fae transaction, is only executed by Ethereum participants who happen to be “invested” in Fae and who care about the results of the transaction.
Again, analogous to a conception of the job of Phase 1 block proposers being to include data blobs but not execute them. Only Phase 2 executors do the actual work of executing transactions.
Note that Bitcoin itself does not allow a Faeth analogue because its transaction messages do not contain any uninterpreted fields in which to embed a Fae transaction.
Somewhat tangential, but isn’t OP_RETURN a field that meta-protocols on bitcoin can use to embed their meta-transactions (throwback Mastercoin thread for reference)?
All of this relates to a distinction between two approaches to execution, which was emphasized when the Phase 1 vs Phase 2 architecture was first proposed. At root is the fundamental difference between a “data availability consensus game” that is the ordering of blocks (which has a non-deterministic outcome), versus an “interactive verification game” that is the execution of transactions (which has a deterministic outcome, given an ordering). One approach is to couple execution with consensus (as in Ethereum 1.0). The other approach is to separate execution from consensus (as in Ethereum 2.0, Phase 1 vs Phase 2).
The approach of separating execution and consensus is mentioned in the Ethereum 1.0 whitepaper, as a “Metacoin” protocol. The meta-protocol works by attaching data to bitcoin transactions and then using a separate client to execute the data according to the custom transaction protocol (see the Metacoins section in the white paper). The primary downside, as argued in the whitepaper, is that it makes light clients impossible (“Hence, a fully secure SPV meta-protocol implementation would need to backward scan all the way to the beginning of the Bitcoin blockchain to determine whether or not certain transactions are valid.”) If it was just light clients as a user experience thing then it would not be so problematic; there are UX workarounds. The real downside to lack of true light clients (not explained in the white paper, but I’ll argue it here) is that it becomes difficult to imagine how a cross-chain protocol would work; the usual way to do cross-chain stuff is to imagine a contract on one chain being a light client of another chain (and if two contracts on two different chains can be light clients of each other, then trustless cross-chain atomic swaps become possible). This, among other reasons, motivated building Ethereum as its own chain (with execution coupled to consensus) rather than as a meta-protocol that piggybacks on data attached to bitcoin tx’s.
When the Phase 1, Phase 2 architecture was proposed, I liked it and agreed that decoupling Phase 2 from Phase 1 is a clean design (decoupled meaning Phase 2 Executors are a separate role from shard data blob proposers/validators). I also liked the decoupled design because my preferred conception of Phase 2 was also delayed execution (rather than “immediate execution” or whatever you want to call the conventional way as it works in Ethereum 1.0), mainly because under delayed execution it becomes much easier to imagine how synchronous cross-shard transactions would work. (I guess Faeth’s “lazy evaluation” sounds similar to delayed execution). Also relevant is something @benjaminion suggested at the Eth2 workshop back in November 2018 (before Devcon4), which stuck in my mind, “how about having multiple execution engines?”. If Phase 2 is actually decoupled from Phase 1, then indeed it does seem possible to have multiple execution engines, with Phase 2 execution engines being opt-in choices that Validators and/or Executors may or may not choose to run.
I suppose you can see where I’m going here. If Phase 2 is decoupled from Phase 1, wouldn’t that mean Phase 2 execution is ultimately a meta-protocol on Phase 1 data blobs? If so, then maybe there are ways to overcome the limitations of meta-protocols pointed out in the Ethereum 1.0 white paper, and it is an advantageous approach nonetheless. (I’ve been unable to do better than just wonder out loud as I’m doing here, and would be very interested if someone else articulates what I’m trying to get at. To be fully honest I’m a bit sheepish for not going full circle from the Ethereum 2.0 architecture back to the 1.0 white paper and asking this question much earlier; at least I can’t remember anyone else asking it explicitly).
On the other hand, if execution is not decoupled from Phase 1, meaning that shard block proposers are not indifferent to the data blobs but do interpret the data contained in shard blocks, then the Phase 2 vs Phase 1 description of the architecture is misleading and we should just call it execution in Phase 1 (or “Phase One and Done” which I hope catches on hehe). I guess “Phase One and Done” versus “Phase 2 decoupled from Phase 1” are two distinct approaches, roughly outlined, to execution on Eth2.