This week I've been a bit sick so I spent most of my time absorbing information passively by watching programming talks on Zig, Rust, and the recommended material in the EPF syllabus. I spent some time on non-EPF projects which were already spec'd out since that required less mental effort. I'm feeling a lot better now ahead of week 4 though! Zig Alongside programming talks by Andrew Kelly and Tigerbeetle I've been reading about Zig's build system; specifically using Zig as a C/C++ compiler. This is because I've shortlisted using software like Varnish (already mentioned in a previous update) or Squid -- which are written in C and C++ respectively -- as caches. If you didn't already know: Zig can compile C/C++ software with it's clang frontend and you'd want to do that because Zig's build system is written in... Zig and that's it! I like tools like make but with large and established C/C++ codebases I find it very hard to really grok the careful web of make, m4, autotools etc interactions and the inevitable tooling problems that arise. Having a single tool to do the builds would make the developer experience with that software better -- I should point out I haven't tried to build Varnish or Squid (yet). Anyway, Varnish has a lot of ways you can use it including as a library in which case the bindings would be done using Zig too hence this investigation. Week 4 Plan

JSON RPC This week I had plans to try and profile JSON RPC method usage but I quickly realised this isn't really feasible accross the ecosystem (to my knowledge) without a decent amount of reverse engineering and my curiosity there was mostly to identify patterns which platforms like Dune Analytics can better provide. In general I came to the conclusion that trying to identify those constraints now is probably premature optimisation due to how much work will have to go into analysing the data. I think it's better to get an actual MVP specification and middleware REST API wrapper for JSON RPC before adding on anything concluded from those potential analyses; one example would be a single REST method to deploy a contract instead of the multiple JSON RPC calls currently required. REST API One annoyance (beyond vague standardisation) of the JSON RPC API is its lack of statelessness. Libraries help here with abstraction, and it does make the API composable, but for a lot of operations this composability is required for what should feel like atomic operations (e.g. deploying a contract). Along this line, and for the REST API being actually stateless I've been re-reading up on HATEOAS principles. Discoverability about related data being a part of a query's response means there's no pre-knowledge required and also no (explicit) risk of statelessness, for example having to find the ID of a user by searching for their username to then use that ID to look up their detailed profile information.

I'm participating in EPF cohort four and this is my first week update. The goal for this week is to look at areas of interest and canvas ideas, either new or existing, to contribute to. Update I am prone to biting off more than I can chew, which is both good and bad, however given the structured nature of the EPF cohorts I figure it's a good idea for me to select something already proposed and if there's extra time, or after the EPF programme finishes I can take my learnings and understanding onwards to tackle a larger task. JSON RPC Looking at the proposed projects list the idea of a JSON RPC wrapper application stood out to me and this was mostly from the linked tweet. Reading the thread I discovered that apparently various execution clients have subtle differences between their JSON RPC implementations which is something I was not aware of before and is certainly a problem. Non-standard data schemas mean applications will gravitate to specific implementations which is the opposite of being agnostic to any specific client for effective decentralisation.