# Serving Engine API data from the Portal Network: Starting Ideas

There are two areas I could focus on:

- Enabling validators to propose blocks.
- Enabling validators to attest to blocks.

Both options provide significant challenges:

When **enabling validators to propose blocks**, we need to get an `ExecutionPayload`. There are two approaches that can be taken here: a) The portal client builds the block, or b) Someone else builds the block and the portal client validates it and broadcasts it (think about MEV-boost or any other form of PBS).

When **enabling validators to attest to blocks**, things get trickier. To attest to a block, a normal validator would have to execute all transactions in that block... using its EL node. Including some components of [reth](https://github.com/paradigmxyz/reth) in Trin, as libraries, could help solve this, but further investigation is needed.

To keep my project tightly scoped, I'll focus on figuring out how to enable validators to _propose empty blocks that were built by someone else_. Other features like attesting, building blocks, processing non-empty blocks and serving beacon API data will be left for later.