Skip to content

Roadmap Runtime

François-René Rideau edited this page Feb 18, 2022 · 3 revisions

Persistence

We want to be able to run Glow from the CLI without a browser, and even the Web UI needs a local server to connect to blockchain services. Therefore, we want all storage to be managed by the CLI using a local database. We historically have used LevelDB, but may upgrade to SQLite instead; or maybe to Postgres at some point in the future for the sake of database replication.

In the long run, we want all user data to be logged in a replicated non-repudiable monotonic database, i.e. a "private blockchain". Whether the user uses his Web UI on his laptop or his desktop, his CLI on a his server, or his Android or iOS UI on his cell phone, he will always be able to access the same data. Local changes appear as "pending" until they are confirmed or rejected. Conflicting changes may be automatically resolved by a CRDT, or manually merged via a editor (as in git merge), or winners may be picked and losers pushed to a "reject" queue that the user can later inspect. Thus, we want a first-class representation (and UI support for) not just of the user state, but also of those state changes that may be confirmed, unconfirmed or rejected.

  • (2021Q3) Replace leveldb with SQLite or Postgres, but restrict ourselves to IndexedDB-compatible API.
  • (2021Q4) Persist Continuations
  • (2022Q2) Distributed persistence with replication in multiple data centers
  • (2022) Encrypt all the data in databases. See also Wallet Roadmap

Reflection

We want our runtime to use reflection in a principled way, as per FRR's thesis; see his LambdaConf 2018 presentation.

  • (2022) Have compiler support first-class implementation protocol, enabling dynamic code instrumentation at runtime.
  • (2022) Implement said runtime instrumentation, for e.g. debugging, monitoring, performance tracking, etc. --- also, when we do verification of VM computations, for automatic working graph extraction.

Software isolation and Capabilities

  • (2022) DApps to be isolated, each in their own VM — if possible reuse infrastructure from Spritely, Agoric, GuixSD and/or Qubes.
  • (2022) Compute and enforce sensible size limits on each VM
  • (2023) Capability-based computations, with linear types

Secure Clients

  • (2025?) Work with some secure hardware providers, secure operating system developers, and formal verification experts on some framework for secure applications that end-users can trust.
Clone this wiki locally