Yes, beacon blocks after The Merge (when Proof of Stake replaces Proof of Work) will contain transactions.
Beacon blocks, up to and including Altair, have the following per
https://eth2book.info/altair/annotated-spec#beaconblockbody
class BeaconBlockBody(Container):
randao_reveal: BLSSignature
eth1_data: Eth1Data # Eth1 data vote
graffiti: Bytes32 # Arbitrary data
# Operations
proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
attestations: List[Attestation, MAX_ATTESTATIONS]
deposits: List[Deposit, MAX_DEPOSITS]
voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
sync_aggregate: SyncAggregate # [New in Altair]
With The Merge, an ExecutionPayload will be added per https://github.com/ethereum/annotated-spec/blob/master/merge/beacon-chain.md#beaconblockbody
class BeaconBlockBody(Container):
randao_reveal: BLSSignature
eth1_data: Eth1Data # Eth1 data vote
graffiti: Bytes32 # Arbitrary data
# Operations
proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS]
attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS]
attestations: List[Attestation, MAX_ATTESTATIONS]
deposits: List[Deposit, MAX_DEPOSITS]
voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS]
sync_aggregate: SyncAggregate
# Execution
execution_payload: ExecutionPayload # [New in Merge]
Yes, beacon blocks after The Merge will contain transactions. An ExecutionPayload per https://github.com/ethereum/annotated-spec/blob/master/merge/beacon-chain.md#executionpayload has:
class ExecutionPayload(Container):
# Execution block header fields
parent_hash: Hash32
coinbase: ExecutionAddress # 'beneficiary' in the yellow paper
state_root: Bytes32
receipt_root: Bytes32 # 'receipts root' in the yellow paper
logs_bloom: ByteVector[BYTES_PER_LOGS_BLOOM]
random: Bytes32 # 'difficulty' in the yellow paper
block_number: uint64 # 'number' in the yellow paper
gas_limit: uint64
gas_used: uint64
timestamp: uint64
extra_data: ByteList[MAX_EXTRA_DATA_BYTES]
base_fee_per_gas: Bytes32 # base fee introduced in EIP-1559, little-endian serialized
# Extra payload fields
block_hash: Hash32 # Hash of execution block
transactions: List[Transaction, MAX_TRANSACTIONS_PER_PAYLOAD]
Other helpful references:
The first reference contains this overview of how blocks look before and after The Merge:
Best Answer
Block time in Ethereum's Proof-of-Stake system (called Casper) is being conservatively targeted at around four seconds. Vlad Zamfir of the Ethereum Foundation believes the block time will ultimately end up being much lower (sub-second) while Vitalik is not as convinced on that front. Vlad discusses this in this excellent video explaining Casper: https://youtu.be/3g2CwTnn0Us
The block time is able to be lowered because validators aren't burning cash on electricity to mine, which makes producing uncles much less painful relative to the canonical block. Validators are rewarded on the basis of how they place their bets, and won't lose money so long as they always bet on blocks which make it into the security record. So their profit is slightly higher for betting on a canonical block relative to an uncle, but their cost is the same either way (and much reduced relative to PoW mining, as is the reward).
Casper therefore, in addition to its much-improved security properties relative to Proof-of-Work, is able to provide much lower confirmation latency. This does not mean, however, that we have improved Ethereum's underlying efficiency in terms of transactions per second. With Casper, Ethereum is still a single-threaded global computer, and any improvement in TPS will come from validators upgrading their hardware.
Sharding, not Casper, is Ethereum's proposed scaling solution for increasing TPS by orders of magnitude.