For Blockchain Developers
If you think about the modern web from a blockchain lens, you might conceptualize it like this: Each website or app is a sovereign appchain using a Proof of Authority (PoA) consensus algorithm. There are no light nodes, and running a full node is permissioned and gatekept. Instead of private keys and trust-minimized bridges, authentication and interoperability (respectively) are acheived through centralized oracle services.
While that might sound horrible, it's not all bad. The World Wide Web allows developers to permissionlessly share their apps by simply maintaining a connection to the Internet. It even comes with a globally distributed name service and communications security protocol. It protects users by sandboxing untrusted code running on their machine, while also incrementally streaming the UI to conserve resources. It comes pre-installed on every device, owned by every person, ever. And it does all of this while maintaining a healthy level of web browser client diversity.
Chopin Framework uses recent breakthroughs in blockchain technology to fix the bad parts of the web, while building on top of the good parts that are already well established. For the rest of this document, we will lay out how we can incrementally improve all of the negative security properties of web apps—ultimately bringing them on par with state-of-the-art blockchains applications.
Public Key Cryptography
Most websites today do not use public key cryptography for authentication. However, without users signing the data they are submitting to the network, there is no way to build a trustless or verifiable system on top of it.
For example, go to x.com/chopinframework and look at our latest posts. There is no proof that we ever sent that content to X. You just have to trust them.
Chopin Framework fixes this by signing requests before they are sent to the server. In other words, Chopin treats HTTP requests like they are transactions.
Chopin Framework can technically work with any wallet, including Metamask, Ledger, Wallet Connect, and your phone's secure enclave. However, it has an MPC-based embedded wallet built-in.
Embedded wallets provide an ideal UX for non-crypto native users. Users shouldn't need to install anything in order to start interacting with an app, nor should they be required to fill out extra forms or click extra buttons. It should just work.
Chopin Framework uses Capsule for its wallet infrastructure. You can find more information about their security assumptions here. And if Capsule isn't suitable for a given power user, they are able to use whichever wallet they would like instead.
Crypto-Economic Security
So we can prove that users signed their HTTP requests (also known as transactions), however, we don't know what order they came in—or if we have a complete set of all transactions.
If we were able to determine a canonical ordering for all included transactions and ensure that they were made publicly available for anyone to download, we would have everything we need to build a fully verifiable web app.
Although Chopin-based apps could be built on top of any consensus algorithm. Chopin Framework uses Celestia by default. Chopin stores an ordered list of transactions on Celestia and therefore inherit Celestia's ordering and liveness properties.
Non-Determinism
The biggest issue that web developers will face when building apps with Chopin Framework is non-determinism. These include data fetching from remote websites, getting the current time, and generating random numbers.
Although there are better ways of handling this problem, Chopin's initial approach is to simply let sequencer set the value arbitrarily. Trust-minimized methods of resolving this type of data will be introduced in the future. In the meantime, developers should not depend on things like fetch requests for important state transition.
Decentralized Sequencing
Like many prominent rollups, Chopin-based apps use a centralized sequencer. This is because L1 block times are too long (for now) and shared sequencer networks are not yet in mainnet. In the future, using a shared sequencer or running as a based rollup will be an option. Forced L1 inclusion is also possible and on the roadmap.
Running a Validating Node
Now that we have a complete, ordered list of all requests—all of which lead to fully deterministic state transitions—we should be able to simply replay that list from start-to-finish to rebuild the state of the application. This is called pessimistic validation.
Users can run full nodes to validate the state of any Chopin app for themselves.
Validity and Fraud Proofs
Ideally, users will be able use light nodes to verify the state of the Chopin-based apps. Just like any other blockchain app, a web app can be conceptualized as a state transition function.
In this case, the would be the state of the database before the request, while would be the state of the database after, and would be the content of the POST request.
There is no technical reason why this computation cannot be proven. However, introducing proofs would likely reduce Chopin's flexibility and broad compatibility with many tools, while also making it more expensive to scale.
As a result, the options are being carefully considered and community suggestions are quite welcome.
Open Problems
From proofs, to settlement, to oracles, and more—we are looking for help finding the best solutions. If this interests you, please check out our open problems section on GitHub.