Alternate Frontends : Why and How - Censorship.wtf

What are those IPFS resources ? (4:42:30)

We've seen that decentralized front ends can be deployed using IPFS, with ENS resolution to map domains to the appropriate IPFS resources. However, the question is : what are those IPFS resources?

For front ends, we take large source code, build it to generate artifacts, and store those artifacts on IPFS in a decentralized way. However, upon closer inspection, these artifacts still contain links back to centralized services like APIs running on AWS

So while the front end artifacts themselves are decentralized on IPFS, they still rely on and link to traditional centralized services, thus defeating some of the purpose of a truly decentralized front end.

Some layers aren't decentralized (4:44:00)

Smart contracts can be decentralized on chain, but front ends often still rely on centralized APIs by default

Client code handles RPC calls, so decentralization of nodes and connections also matters

"Alternative" front ends provide backup if original project front end is forced to shut down, dev team loses interest, or bull market turns bear market

• Some DeFi projects have disappeared but liquidity still on chain - without a front end, difficult for users to withdraw though
• Alternative front ends allow users continued access even if original project front end abandoned

For those reasons, alternative front ends are important for resilience and protecting users

How can we trust these alternative front ends ? (4:45:50)

And the main question then is how can we trust these alternative front ends.

Even beyond the artifacts, the API, knowing that for a reason of client diversity, which will definitely help us resist censorship, we probably need not a redeployment of the original front end repos.

The key issue is trust

How easily can we trust frontends ? (4:46:20)

This is a simplified architecture with build artifacts connecting via SDKs and RPC/API to chain. Here, we have to trust :

• URL/ENS
• API
• RPC
• Frontend implementation itself

This gives us with 4 technical intermediaries we have to trust

What a real frontend looks like (4:47:10)

The Uniswap "add liquidity" page is 500+ lines of Javascript, without counting a lot of different libraries, SDK components, hooks, and so on. If we include all of them, we have thousands of lines of code just to build an interaction.

Lots of code means transaction semantics spread throughout, which makes it hard to verify what we compute to build and submit the transaction.

This code base evolves permanently, and each update needs audit to ensure safety

With thousands of projects, validating safety of every front end is extremely difficult

OKcontract's solution (4:49:25)

The idea is to build a common frontend engine instead of separate implementations for each project.

It handles things like fetching data from nodes, user interactions, building transactions generically rather than having custom implementations for each project

This Allows reuse, shared tooling/audits across projects, and can have multiple alternative implementations, but specifications passed to them are common

Minimalism

Specification of interaction semantics (4:50:30)

Transaction specifications are written in "lambdascript", a purely functional programming language to specify a transaction (think of a low-level intent or a high-level tx)

Lambdascript is an alternative to spreading transaction semantics across disparate parts of complex frontend code, and include high level details like target contract, parameters, computations for amounts. Futhermore, compiler can catch errors and users/auditors can easily verify correct behavior

On the verification and trust mechanisms :

• There is far less code to audit compared to entire custom UI code base
• Generic engine can be thoroughly audited once for all projects rather than redoing per project
• Community members can verify and digitally sign valid specifications that match intended interactions

On the on-chain signatures :

• This allows relying on a decentralized record rather than trusting any centralized frontend provider
• Signatures are tied to a specific hash, from a transparent and immutable reference

Automated interface generation for any transaction (4:53:20)

UI matters for the end-users even with a proper transaction definition and a verified runtime at the SDK level, the way they are assembled can impact security. Rather than custom UIs, standardized generation from transaction specs ensures less security issues than fully custom build artifacts.

Recent history shows frontend attacks can be very damaging, like BadgerDAO for $120M :

1. The attackers managed to inject some code in the front end to make approvals, in fact user tokens to their own addresses
2. In fact, people started approving tokens and they didn't do anything, they just kept the approvals and just watched the approval going
3. Then, the attackers reaped every approvals that they had

Other attacks via dependencies like Google Tag Manager in KyberSwap also exist.

Combine both above to have our program (4:55:30)

The proposed system is a compiled UI from concise semantics specs and common runtime. It reduces complexity and code for more trust, even if less UI customization

Screenshots above show generated UIs for actual interactions

Looking back

Trust & Minimalism are the way to build alternative frontends.

Alternative UI architecture (4:56:30)

The picture above is the proposed architecture has single alternative UI generated from transaction semantics definition

Deploy static builds (4:57:00)

We can deploy these static builds which can provide alternative UIs default front ends using generated UI and universal runtime and as well decentralized the API nodes. 

We can create a repository of interactions and alternate UIs for various DeFi/NFTs, and community can vet that definitions and runtimes are correct

How to contribute ? (4:57:45)

Next steps : Contribute to an EIP to standardize transaction specification

Projects can contact OKContract to join private beta, and we can contact via Twitter or new Telegram group to contribute or get involved

The final goal is to ensure projects have alternative front end options