Architecture

Philosophy

The Chopin ("Blockchain Drop-in") Architecture is an approach to convert web applications into blockchains, while minimizing changes to the way that they are developed or used. The thesis behind this approach is that the tech industry has already adopted mature patterns for building web applications, and these established patterns are likely better than new ones invented by emerging blockchain companies. If is hard enough to launch a leading app framework on its own, a company trying to revolutionize app developer experience while simultaneously building a blockchain is likely to fail at both.

We do acknowledge that, from time to time, a powerful technology comes along and causes us to rethink processes from first-principles. Chopin Framework is therefore not, in principle, opposed to all changes to the conventional app development process. Instead, Chopin Framework empowers developers to choose how much they want to diverge from the conventional app development process.

Chopin Framework is an implemention of the ideas in the Chopin Architecture. It focuses on converting apps built with Next.js and other popular web frameworks into sovereign rollups. However, it is entirely possible to build an app using the Chopin Architecture that makes different tech choices than Chopin Framework. For example, one could adapt the Chopin Architecture to build a L1 instead of a rollup.

Historically, blockchains have been limited by data throughput. The amount of bandwidth needed for traditional web applications has been far higher than onchain capacity. Although there were other bottlenecks, such as execution, there have always been decent workarounds for these problems. Now that throughput is scaling to Gb/s levels, we are starting to see what is truly possible.

Concepts

Compute Environment

There are two types of compute environments: untrusted and trusted.

An untrusted environment can run arbitrary computations set by any user. A trusted environment must follow predefined rules set by the application developer. Typically, these environments are conceptualized as the frontend and backend, respectively.

Unlike most web3 frameworks, Chopin allows developers to define the code that runs in both environments (full stack). This is is referred to as enshrined frontends and infrastructure.

Transaction

In the Chopin Architecture, transactions are payloads of data that are constructed in an untrusted environment and processed in a trusted one. They are typically signed by a private key and typically ordered by a consensus mechanism.

In Chopin Framework, transactions are HTTP Requests signed by the end user. Hypothetically, though, a transaction could be something else such as a signed websocket, TCP, or IP packet. Chopin Framework opted to build on HTTP because it the official browser-native way to communicate between the frontend (untrusted environment) and the backend (trusted environment). By building on HTTP, apps build with Chopin Framework can run inside any web browser without requiring additional downloads or installations. Furthermore, it plays nicely with mobile which often relies on backends with HTTP interfaces.

Query

Queries are payloads of data that are constructed in a trusted environment and processed in an untrusted one. An example of a query would be an GET request to a REST API that does have any side effects. Navigating to the homepage of a Chopin-based web app in the browser would often be seen a query.

Queries can be accompanied by proofs that allow a third party to verify that the data did indeed originate from the trusted environment.

Address

Addresses are unique identifiers for a given account. They are typically derived from a public key. TODO

State

State is the set of all data that is stored in the application. It is typically stored in a database. TODO

Oracle

TODO

Middleware

Middleware can live either in the untrusted or trusted environment. It's purpose is ensure compatibility between the two environments. Chopin Framework uses two forms of middleware.

Sequencer

Sequencer middleware runs in the trusted environment and has the following responsibilities:

• Ordering transactions
• Managing consensus
• Verifying proofs and signatures
• Syncing the trusted environment with the network
• Running the oracle infrastructure

Wallet

Wallet middleware typically runs in the untrusted environment. Since web browsers do not natively support signing HTTP requests, the wallet middleware acts as a compatibility layer that intercepts HTTP requests and signs them on behalf of the user.

In Chopin Framework, wallet middleware runs in two places:

• The browser via a service worker. By doing this, it is able to sign transactions client-side in a manner fully managed by the end user.
• The server as a part of the sequencer middleware. Using a managed wallet service, like Para, the sequencer can sign transactions on behalf of the user. The benefit of this is that it is simple and robust, not requiring a service worker or other client-side middleware. The downside is that server-side embedded wallets are potentially not as secure as client-side wallets.

If you are building a Chopin app from scratch without relying on a web framework, you may not need wallet middleware. It is entirely possible to manually sign transactions using a library instead of introducing an intercepting middleware layer. This might be particularly appealing to native app developers.