Arguably, that's exactly the one action that will need to be hash-pinned, since all the consecutive actions will at least be verified against the lockfile.
If you have a privilege to replace the kernel or bootloader, you effectively have all privileges on that system. Therefore, there's no need to complicate the access limitations when you get full access anyway.
> how all the popular dynamic languages have slowly become statically typed
Count the amount of `Any` / `unknown` / `cast` / `var::type` in those codebases, and you'll notice that they aren't particularly statically typed.
The types in dynamic languages are useful for checking validity in majority of the cases, but can easily be circumvented when the types become too complicated.
It is somewhat surprising that dynamic languages didn't go the pylint way, i.e. checking the codebase by auto-determined types (determined based on actual usage).
> the client is not packaging up all its logic and sending a single blob that describes the fully-chained logic to the server on its initial request. Right
See "But how do we solve arrays" part:
> > .map() is special. It does not send JavaScript code to the server, but it does send something like "code", restricted to a domain-specific, non-Turing-complete language. The "code" is a list of instructions that the server should carry out for each member of the array
That 'tapping phones' could also be used to facilitate key exchange verification, making that chore technically useful.
Then again, that would be better done in an open-source app and not tied to any particular domain.