Introduction One of our current OKRs is to implement Beacon API endpoints using an HTTP server. This will remove a lot of complexity, because currently we have to transform HTTP requests/responses, which conform to OpenApi specification, into gRPC-compliant structures. This results in complex middleware code that we have to maintain. To make this task easier, it would be nice to be able to automatically generate server code from the Beacon API specification. I spent some time searching for the right tool and unfortunately couldn't find anything suitable. Tool overview https://github.com/go-swagger/go-swagger go-swagger does not support OpenApi 3.0. It provides a flatten utility, which I hoped to use before applying another tool, but unfortunately flattening a 3.0 spec does not produce a valid format. https://github.com/deepmap/oapi-codegen
1/17/2023Background In Prysm, we have two main kinds of tests: e2e and unit tests. For the most part, unit tests have a very complex setup especially in critical files such as the state transition, forkchoice, and the sync service. Even these complex examples tend to mock a lot of the blockchain's functionality by populating the database themselves or using mock versions of services for simplicity. Most recently, we had a situation where we had a bug at runtime in one of the caches used during block processing here, and the resolution was pretty simple but actually almost impossible to test with our current testing suite. This triggered a discussion about why it was hard to test this code and if we could do anything about it. It turns out we don't have test harnesses powerful enough to give us a meaningful test aside from our end-to-end suite, and that immediately triggered some concerns. This document designs a new test harness for testing chain functionality in Prysm with minimal mocking, and helps us test different behaviors of block processing that are hard to set up otherwise outside of e2e. Existing blockchain test harnesses When testing blockchain behavior, we care about the following situations:
10/28/2022This documents the necessary steps to run Prysm beacon client and validator client for MEV extraction. It's important to keep in mind that these are prototypes so expect breakages and bugs. The instructions will likely change later and we'll update them along the way. With that said, we are months away from the merge, and now is a crucial time to begin testing MEV as an end-to-end product from validator to beacon node to mev-boost to relayer and to a builder. Optional readings on the why what and how https://writings.flashbots.net/writings/beginners-guide-mevboost/ https://writings.flashbots.net/writings/why-run-mevboost/ lightclient - Extracting MEV After the Merge Bulder API spec Prysm images To build from source. Please use latest develop branch
10/18/2022Background In EIP4844, BlobsSidecar was introduced to accept "blobs" of data to be persisted in the beacon node for period of time. These blobs bring rollup fees down by magnitude and enable Ethereum to remain competitive without sacrificing decentralization. Blobs are pruned after ~1 month. Available long enough for all actors of a L2 to retrieve it. The blobs are persisted in beacon nodes, not in the execution engine. Alongside these blobs, BeaconBlockBody contains a new field blob_kzg_commitments. It's important that these kzg commitments match blob contents. Note that on the CL, the blobs are only referenced in the BeaconBlockBody, and not encoded in the BeaconBlockBody. Instead of embedding the full contents, the contents are propagated separately in BlobsSidecar above. The CL must do these three things correctly: Beacon chain: process updated beacon blocks and ensure blobs are available P2P network: gossip and sync updated beacon block types and new blobs sidecars Honest validator: produce beacon blocks with blobs, publish the blobs sidecars In this doc, we explore the spec dependencies between BlobsSidecar and BeaconBlockBody loosely coupled and implementation complexity due to them being loosely coupled.
8/17/2022