There's a little ambiguity around the term "full node" here. In order to be an Eth2 validator, you require the following software components:

1. An eth1 node (geth, parity-ethereum, etc).
2. An eth2 "beacon node".
3. An eth1 "validator client" (if it doesn't happen to be included in your beacon node).

For (1), a fast-synced Geth node suffices for now. All eth2 requires from it are historical event logs from the deposit contract. Over time Geth may stop storing all historical event logs, however you certainly don't need a "full" eth1 node.

For (2), you won't necessarily need a beacon node that stores the entire history of the beacon chain. For phase 0 (and future phases) it's unclear as to how large the beacon node database will be, but I estimate it to be 1-100gb. I like to think we can keep it in single-digit GB.

For (3), I don't know of any client teams that have full/light distinctions for their validator clients. A validator client will likely store tens or hundreds of MB of historical votes to prevent slashings. This footprint is quite small compared to the risk of performing a double-vote and being slashed that I suspect validator clients will stay "full" for some time.

There's a little ambiguity around the term "full node" here. In order to be an Eth2 validator, you require the following software components:

1. An eth1 node (geth, parity-ethereum, etc).
2. An eth2 "beacon node".
3. An eth2 "validator client" (if it doesn't happen to be included in your beacon node).

For (1), a fast-synced Geth node suffices for now. All eth2 requires from it are historical event logs from the deposit contract. Over time Geth may stop storing all historical event logs, however you certainly don't need a "full" eth1 node.

For (2), you won't necessarily need a beacon node that stores the entire history of the beacon chain. For phase 0 (and future phases) it's unclear as to how large the beacon node database will be, but I estimate it to be 1-100gb. I like to think we can keep it in single-digit GB.

For (3), I don't know of any client teams that have full/light distinctions for their validator clients. A validator client will likely store tens or hundreds of MB of historical votes to prevent slashings. This footprint is quite small compared to the risk of performing a double-vote and being slashed that I suspect validator clients will stay "full" for some time.