# x-shard/meta-ee discussion
For background, read the following:

Writeup: https://ethresear.ch/t/an-even-simpler-meta-execution-environment-for-eth/6704/2
Casey’s Simple Explainer Doc: https://notes.ethereum.org/fkPBDSV_QiSePrrk5u-0Qg

## Example 2 normal EEs, 1 meta EE, 2 Shards

For simplification, lets define our block body as follows:

ShardBlock {
  shard: u32,
  transactions: Vec<ShardTransaction>,
}

ShardTransaction {
    data: Vec<u8>,
    ee_index: u32,
}

### Outgoing X-Shard
In this example, EE0 sends eth from shard 0 to EE0 on shard 1. EE1 also sends eth from shard 0 to EE1 on shard 1.

The example drastically simplifies things, but is a good exercise for determining the end-to-end process. This EE does not have users and we are ignoring the user perspective.

Current EE0 Matrix:

[3 , 0]
[0 , 0]

Current EE1 Matrix:

[3 , 0]
[0 , 0]

Transaction for EE0:

ShardTransaction {
    data: [{
        amount: 1eth,
        shard: 1,
    }],
    ee_index: 0,
}

Transaction for EE1:

ShardTransaction {
    data: [{
        amount: 1eth,
        shard: 1,
    }],
    ee_index: 1,
}

So far, our block looks like this:

ShardBlock {
    shard: 0,
    transactions: [
        ShardTransaction {
            data: [{
                amount: 1eth,
                shard: 1,
            }],
            ee_index: 0,
        },
        ShardTransaction {
            data: [{
                amount: 1eth,
                shard: 1,
            }],
            ee_index: 1,
        },
    ],
}

The above describes the inputs. Next, we need to show how the aux outputs may work. In order to accomplish this, we need to define a receipt-printing host function.

Let's assume that EE execution is ordered, i.e. that ShardTransaction blocks are processed sequentially. Any EE that wants to create an output to be later on consumed by the Meta-EE has to have access to a host function to do so.

`print_output(Vec<u8>)`

The host function would take the byte array, add the sender ee_id to it and write it to a temporary buffer.
For the sake of our simplified example we will assume that the arbitrary byte output conforms to the following structure:

Output {
  ee_id: u32,
  data: vec<u8>,
}

For illustrtion, lets give the data a structure:

data {
    shard_id: u32,
    amount: u64,
}

After the two ShardTransaction blocks ran, the temporary buffer would look like:

[
    Output {
        ee_id: 0,
        data {
            shard_id: 1,
            amount: 1,
        },
    },
    Output {
        ee_id: 1,
        data {
            shard_id: 1,
            amount: 1,
        },
    }
]

The Meta-EE would then run as the last transaction of the block. An example would be:

ShardTransaction {
    data {
        multiproof: ...,
        ee_ids: [u32],
    },
    ee_index: 2,
}

The Meta-EE would have to have access to a host function to get the outputs created by any specific EE, which we call `get_outputs(ee_id)`

With this, an example for a Meta-EE could look like:

def main(multiproof, ee_ids):
    load_multiproof(multiproof)
    for ee_id in ee_ids:
        outputs = get_outputs(ee_id)
        for output in outputs:
            if get_balance(ee_id) < output.data.amount:
                continue
            reduce_balance(ee_id, output.data.amount)
            increase_shard_balance(ee_id, output.data.shard_id, output.data.amount)

After processing the first output, EE0's matrix would look like this:

[2 , 1] (the Meta-EE only has this row)
[0 , 0]

Similarly, after processing the second output, EE1's matrix would look like this:

[2 , 1] (the Meta-EE only has this row)
[0 , 0]

Open Questions:

* How is the block proposer incentivized or forced to include the Meta-EE part into the block?
* Who pays for the Meta-EE execution?
* What happens if the block proposer instead decides to pack the block with transactions of other EEs and there is not enough room for the Meta-EE? This means outputs/receipts need to be referenced via a proof later on.
* Doesn't this already mimic enshrined behavior - why not just enshrine it?
* EE upgradeability has a number of issues and is not as simple as expected (a post/writeup on this soon)

## User Level Eth Transfers

### Cross-Shard
In example above, auxiliary output would now need an extra field, `data_root`.

    Output {
        ee_id: 0,
        data {
            shard_id: 1,
            amount: 1,
            data_root: H256,
        },
    },

This additional field gives details on the actual account transfers aka receipt trie. As an oversimplified example, the leaves could be as follows:

Receipt {
    from: Address,
    to: Address,
    amount: u64,
    call_data: vec<u8>,
}

We now run into the same problem we had before, we need either a nonce/bitfield mechanism to manage protection against double-spends.

### Cross-EE
Cross-EE scenarios are practically identical to the cross-shard example. The major difference is that there needs to be a messaging standard for the receipt leaves or trie. As an example:

EE0 defines its Receipt as:

Receipt {
    from: Address,
    to: Address,
    total: u64,
    call_data: vec<u8>,
}

EE1 defines its Receipt as:

Receipt {
    from: Address,
    to: Address,
    amount: u64,
    call_data: vec<u8>,
}

These receipts are not compatible with each other and carry different syntax or keys. What happens if we want to upgrade a messaging standard/format? Maybe certain EEs offer priveleges to be called into?

Additionally, we also need a way to terminate reading receipts once the aggregate amount exceeds the amount passed through the meta-EE. For example, meta-ee output is:

    Output {
        ee_id: 0,
        data {
            shard_id: 1,
            ee_id: 1,
            amount: 3,
            data_root: H256,
        },
    },

Where the trie's leaves corresponding to the `data_root` are as follows:

[
    Receipt {
        from: Address,
        to: Address,
        amount: 2,
        call_data: vec<u8>,
    },
    Receipt {
        from: Address,
        to: Address,
        amount: 2,
        call_data: vec<u8>,
    }
]

You'll notice the aggregate total from the leaves send 4 eth while the meta-EE outputs only 3 eth.

The above are just a few examples of issues that may occur due to faulty EEs or EEs that follow different messaging standards.

## Upgradeability
We are choosing to pursue a meta-EE because we argue that moving upgradeability away from the core protocol is a major benefit. However, what does upgradeability even look like? It appears the meta-ee will likely need enshrined behavior, so doesn't this further complicate its upgrade path?

## VHEE

There exists an EE which holds balances for standardized accounts. It receives privileged behaviors (EEs can call synchronously into it).

Validator accounts deposit into VHEE via a receipt as described in Vitalik's proposal:

{
    "validator_index": uint64,
    "target": uint64,
    "data": bytes
    "pubkey": BLSPubkey,
    "signature": BLSSignature
}

The actual VHEE stores funds in 2 dimensions, `(shard, ee_id)`. EEs can call directly into their `(shard, ee_id)` pair and make whatever updates they want to the portion of the trie associated with the same ee_id.

In order to transfer funds between `ee_id`s, user can submit a direct transaction to the VHEE. Alternatively, we can support the netting style scheme for an integrated VHEE/meta-execution EE. Essentially, this standardizes the account model across EEs (which makes things like fee markets, etc. easier). But comes with the caveat of a less flexible system.

Could use P2SH scheme as mentioned by Dankrad, but does not work properly in a pull model (as it would make multiproofs between EEs reliant on each other)

## Synchronous Cross-EE communication
In a world where EEs can communicate synchronously with each other, concepts such as a VHEE simplify the system overall. EEs can also read and write directly to each other. The main issue with synchronous calls between EEs is on the state provider side. Here are three ways to accomplish this:

### Restricting dynamic state access (direct push model)
The direct push model could support complete synchronous communication between all EEs if we support an SSA model.

### Sequential Pull Model
Does not provide complete synchronous communication between all EEs. EEs executed later in a block may directly access the output of EEs executed earlier in a block. The BP in the pull model would have to acquire multiproofs for each EE in an ordered, sequential manner.

### State Providers Hold all State
Provides complete synchronous communication as in the direct push model. State providers are assumed to hold state for all EEs. Pull model or Relayed Push model could work. This particular approach is interesting, and if we assume state providers hold all the shard state, then it seems appropriate?

### Library Method
EE primitives (authenticated proof model, memory backend, etc.) are deployed on the beacon chain. When deploying an EE, you can reference these primitives. State providers are assumed to hold state for all EEs that share similar sets of primitives (proof, memory and cross-ee communication libraries).