Esotere: an operating system for the blockchain

(name is placeholder)

0. Primer

Topology’s talk in STARKVietnam, covering 12 months of experimentations and learning that led up to the conceptualization of Esotere OS:

https://www.youtube.com/watch?v=fwqRqZ-2NaM&t=6150s&ab_channel=Topology

1. Lack of Abstraction

It is clear that Bitcoin represents the first hard drive for the human race, and Ethereum represents the first mainframe for the human race, yet they are both low-level systems. The lack of abstraction constrains programmer expressivity and exposes safety issues, which forbid more sophisticated applications and limit collective imagination. The lack of decentralization in the end-to-end runtime environment impairs censorship resistance [moxie's critique]. As of 2022, optimistic rollups and validity rollups begin to scale blockchain's computation capacity, data availability solutions are theorized to scale the blockchain's storage capacity, and bridging solutions arise to connect decentralized networks in increasingly trust-minimized approaches [Herodotus; SuccinctLabs]. It is critical to consider what new affordances they bring and what new abstractions are needed to materialize those affordances.

Below is a list of observations that indicate the lack of abstraction in blockchain programming environment:

• Programmers are used to manipulating low-level constructs, such as contract address and contract class hash in hexadecimal form.
• Technical artists in both L1 and L2 ecosystems have attempted manipulating and serving raw SVG strings and compressed Javascript libraries [Dom’s Rose; Pete Horne’s NFTC] directly from smart contracts by overloading functions whose signatures were defined for entirely different purposes originally.
• Attempts have been made to resolve and launch frontend app straight from decentralized storage solution to bypass centralised backend which is prone to censorship [Liam].
• Composability is primitive, which is enabled by a handful of contract interfaces agreed upon through slow community consensus; interface compliance rely only on programmer's own discretion and security auditing.
• There is a lack of code reuse on-chain; common libraries such as OpenZeppelin contracts are redeployed repetitively. This leads to state bloat and hurts long-term sustainability. This also limits value distribution and recognition on-chain for contributors of libraries.
• Libraries are hosted on centralized web services; version control and verification for source code is disjoint from programs deployed on-chain. Programmers rely on disassemblers, blockchain explorers, and various analytic tools to examine data and programs deployed on-chain.
• Program execution is restricted to chain-specific/rollup-specific resource allocation for a single transaction or a single block. For instance, program execution can not consume more than 2 million STARK trace steps on StarkNet as of writing. For complex computation that requires more steps, programmers must break up the computation into multiple parts, each part staying within per-transaction limits, and handle intermediary state caching, which requires additional storage writes and clearly constitutes abstraction leaks.
• Execution automation services (Gelato on Ethereum; Yagi on Starknet) are required to enable program behaviors as functions of time; these services partially fulfill the work of job scheduling in a typical operating system but is fairly inflexible.
• Contract patterns are proposed as standards to enable upgradeability (Proxy) and modularity (Diamond), exploiting contract-bind storage (Ethereum) or storage namespace (Starknet), which again indicate abstraction leaks and are cumbersome in their own right.

Particularly, with the advent of zkRollup, there is a desire to leverage the new capacity of verifiable computation to build more complex applications. For instance, storage proofs [Herodotus] leverage the cheapness of computing on L2 to verify state roots on L1, enabling trust-minimized bridging of states between L1 and L2. Rudimentary numerical simulations [Topology], small neural networks [Topology; Modulus Labs], logical circuit simulations [Topology], AI agent simulations [Topology], and statistics [Lyra Finance] have all been demonstrated on Starknet [note: the fact that references need to point to Github for source code instead of direct locations on-chain indicates the cumbersome fragmentation in the blockchain programming workflow].