该项目旨在研究如何使验证者能够运行 Portal 网络客户端，而不是在他们的设置中使用执行层客户端。项目将专注于让验证者提出空块，通过研究 MEV 基础设施和其他形式的 PBS 如何将块发送给验证者，并开发 Trin 的原型，最终目标是构建一个工作原型，允许 Trin 连接到 CL 客户端。
Portal Network Validator (门户网络验证器)
使验证器能够运行轻客户端，而不是执行层客户端。
Motivation (动机)
在 EPF 之前，我一直在为 Lighthouse 贡献代码。有一次，我想对 beacon API 的一些更改进行基准测试，我需要在本地运行 Lighthouse 才能做到这一点。这很麻烦，因为我没有足够大的 SSD 来同时运行 Lighthouse 和执行层客户端。
我不得不依赖 Sigma Prime 的内部端点来访问 EL 节点。
这就是问题：如果我们想运行共识客户端，我们也需要资源来同时运行执行客户端。我很幸运能够访问 sigp 节点，但是在本地运行某些东西会更好。
解决这个问题将极大地帮助希望在资源受限的设备上运行其验证器的stakers。它还会帮助其他用户，比如 CL 贡献者，正如我几个月前了解到的那样，但是专注于 stakers 会给我一个更好的方向。
Project Description (项目描述)
我将研究如何使验证器在其设置上运行 portal 客户端，而不是执行层客户端。
Specification (规范)
可能会提出一些关于此设置的安全性和信任假设的问题。我认为这没有什么好担心的，Portal 数据已完全验证。但是，值得指出的是，此设置将是高度实验性的，并且可能在数月甚至数年内都无法达到生产级别质量。这是必须在项目文档中广泛警告的内容。
我的项目的输出将包括：
- Research Documents (研究文档)：我在其中详细解释了我发现的技术细节。
- Prototypes (原型)：我在其中实现我在研究过程中发现的可行功能。
我可以将我的研究重点放在两个领域：
这两个选项都带来了重大挑战：
当使验证器能够提议区块时，CL 客户端需要获得一个 ExecutionPayload。这里可以采取两种方法：a) portal 客户端构建区块，或者 b) 其他人构建区块，portal 客户端验证它并广播它（考虑 MEV-boost 或任何其他形式的 PBS）。
当使验证器能够证明区块时，事情变得更加棘手。要证明一个区块，普通的验证器必须执行该区块中的所有交易……使用它的 EL 节点。对于我的项目，这可以通过使用一些 Reth 模块作为库来实现，但是需要进一步调查。
为了使我的项目范围更小，我将专注于弄清楚如何使验证器能够提议外部构建的空区块。其他功能，比如证明、构建区块、处理非空区块以及提供 beacon API 数据，将留到以后处理。
原型将是对 Trin 的贡献。我将在 Trin GitHub 存储库上保留一个跟踪 issue。
Roadmap (路线图)
这项研究有很多影响，我希望随着我深入研究它来调整我的课程。这使得很难定义一个稳定的路线图，但我认为我必须遵循以下步骤：
-
Stage 1: Get Blocks (阶段 1：获取区块)
- 了解 MEV 基础设施和其他形式的 PBS 如何将区块发送给验证器。（我将专注于 Flashbots 的 MEV-Boost。）
- 研究 portal 客户端如何从该基础设施接收区块，并编写一个原型，允许 Trin 这样做。
-
Stage 2: Engine API (阶段 2：引擎 API)
- 研究提议区块需要哪些 Engine API 端点。
- 研究如何使用在前一阶段收到的区块来提供 Engine API 数据。
- 在 Trin 上原型化相关的 Engine API 端点。
-
Stage 3: Testing (阶段 3：测试)
- 研究哪些测试基础设施与我的原型相关。（例如，Portal hive, Glados, testnets, 等等）
- 实现所有相关的测试。
-
Stage 4: Bonus (阶段 4：额外)
- 允许验证器提议空区块是我的主要目标。但是，如果我有足够的时间 / 在 EPF 之后，我想做其他事情：
- 研究如何使用 Reth 模块从 portal 客户端执行交易（以启用证明）。
- 在 Trin 中实现剩余的 Engine API 端点。
- 研究如何从 Portal 客户端 + CL 客户端设置中提供 Beacon API 数据。
- 研究如何切换到非空区块。
我计划在 EPF 的第 8 周到第 16 周完成步骤 1 到 3。我希望在每个步骤上花费相同的时间，因此，每个步骤花费三周。
Possible Challenges (可能的挑战)
- 我的主要限制是时间。如果我在所提出的任何阶段遇到延误，这会使我面临无法按时完成项目的风险。
Goal of the Project (项目目标)
在三种主要情况下，我会认为我的项目是成功的：
- Research-only scenario (仅研究场景)：我的研究得出结论，engine API 数据在其当前阶段无法从 portal 网络提供。我撰写文章解释了为什么会这样，以及我们需要什么才能提供它。这些文章将帮助未来想要解决此问题的贡献者（包括我自己）。
- Optimal scenario (最佳场景)：我构建了一个工作原型，允许 Trin 连接到 CL 客户端。该原型经过了充分的测试，并具有广泛的文档 / 良好的研究文章，使未来的贡献者（包括我自己）可以轻松地继续朝着解决问题的方向努力。
- Optimist scenario (乐观场景)：我在最佳场景中完成所有工作，并对路线图的“奖励”阶段进行重要研究。
Collaborators (合作者)
Fellows (研究员)
Mentors (导师)
Trin 团队的其他成员也提供了反馈和指导（但他们未被列为 EPF 导师）：
Resources (资源)
