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/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/2022Background Terence first notifies us of an interesting bug he observes with the --enable-only-blinded-beacon-blocks feature flag Prater node, v2.1.4.rc1 No EL client Post bellatrix, but before the merge {"error":"could not fetch execution block with txs by hash 0x0000000000000000000000000000000000000000000000000000000000000000: timeout from http.Client","message":"Could not get reconstruct full bellatrix block from blinded body","prefix":"sync","severity":"ERROR"} hash=0 does not mean empty payload. We check with two means: TTD (which we don't have due to the EL being unavaibale) and empty payload (which we don't have due to the block being blind)
8/8/2022