Browserbook
Browserbook was a credited research project at the University of Zurich that investigated the feasibility of a completely in-browser cryptocurrency exchange. Together with two other researchers we successfully prototyped a completely decentralized in-browser trading protocol that facilitated token trading without any centralized ledger.
As the name suggests, Browserbook was completely run in the user's browser, there was no server component used to run any of the interactions. Orders were exchanged between peers over WebRTC; special validator nodes would combine orders and send them to the blockchain for fulfillment and persistence. A full pdf report with more information is available here.
Tech Stack
Overview
Intuitive Dashboard
Browserbook boasted a smooth, intuitive, and professional UI not typically demonstrated by academic projects.
Token Creation
Browserbook allowed users to create and exchange their own tokens on the decentralized internet.
Token Trading
Browserbook orders were routed between peers using a special gossip protocol offered by libp2p.js. The trading interface offered immediate feedback to order status.
Token Dividends
Token administrators could also issue dividends to token holders directly via the application.
Delegated Signing
To validate orders in a decentralized manner, special peers could elect to match orders and communicate those matches further. Peers were reward for providing their compute power, and measures were put in place to prevent validtor peers gaining an unfair trading advantage. Here our novel technique delegated signing played a key role in providing an excellent UX. See below for more details on this technique.
System Architecture
Browserbook boasted a completely decentralized architecture. Peers communicated amongst themselves in the browser via WebRTC. Orders were settled on the blockchain via special validator nodes. Even the client code itself was not stored on a centralized server but rather IPFS.
Front-End State Flow and Blockchain Communication
Our front-end state flow followed the "Elm" or "Redux" model, with middleware handling the communication with the Ethereum blockchain.
Delegated Signing
Browserbook also pioneeered a completely novel signature technique in blockchain applications which we termed delegated signing. In essence, delegated signing is a method for performing transactions on a user's behalf without the need for them to manually approve transactions. The process works in the following way:
- We can generate a separate signing key-pair for the user in order to sign transactions on their behalf. The user can send Ether to this signing key-pair to be used for signing transactions.
- The private key of the signing key-pair is only stored in memory as a security measure. Upon process restart (i.e. refreshing the browser), the private key would be lost, and the Ether sent to the signing key-pair irrecoverable.
- To get around this problem, we encrypt the private key of the signing key-pair using the user's public encryption key, utilizing a little-known Metamask API to do so. Thus we can encrypt the private key and store it on chain.
- Now when we need to restart the signing process, we can retrieve the appropriate encrypted private key, request the user to decrypt it, and continue processing transactions on the user's behalf.
The above concepts were discovered prior to the Beacon chain merge in late 2022. Nonetheless, the concepts map to the PoS nature of Ethereum today.
My Responsibilities
I was project lead on the entire project. I led all front-end interface work as well as the development of the smart contract backend and its testing harness. Many of the key concepts and breakthroughs, especially delegated signing were my innovations.