Procedural Smart Contract Frontends: Future of Ethereum DApps
Imagine a procedural smart contract explorer good enough that most smart contracts don't need a custom frontend to use them.
No, I don't mean writing another Medium post with step-by-step screenshot instructions of how to use Etherscan's contract explorer.
Imagine something that is good enough to pass for a native interface, producing specialized widgets for common contract interfaces: Tokens, NFTs, Swap routers, DAOs, and even administrative like Roles/Ownable, and upgradeable Proxies.
Imagine a world where 80% of smart contracts don't bother building their own bespoke frontend, but rather encourage consumers to use procedural frontends.
What are some benefits of this world?
Local commodity frontends
Today, we regularly rely on app.uniswap.org to swap some tokens, or opensea.io to move some NFTs, or trustme.notscam.xyz to approve some permits.
What if we had an open source local frontend we could run that was more than good enough to do these common usecases?
It could be an IPFS-pinned immutable hash. It could be accessible through ENS or Tor. It could be packaged up as a simple webview container with WalletConnect. Even wallets could include an embedded version of it.
If we do a great job on it, the attack surface area could be made small and we could avoid updating it too often.
Safer against phishing attacks
Today, building a bespoke frontend for a contract means that we're training our consumers to trust some third-party website as an interface for the contract.
Anyone can make a website that claims to be a legitimate frontend for our contract, and trick our consumers to use a malicious frontend.
If we had a procedural frontend that we used for our contract interactions, then we reduce N (number of contracts we ever interact) interfaces and opportunities to get phished into just one instance.
Safer against censorship
Frontends are the main point of censorship that smart contracts experience, because almost all frontends today are provided as a SaaS (Software as a Service) where some corporation is responsible of how their consumers use their service.
Whether it's corporate pressure, or regulatory pressure, or totalitarian control of information through Internet filtering -- frontends are vastly more vulnerable to censorship than The Blockchain.
Enabling consumers to rely on their own locally hosted frontends removes an unnecessary intermediary.
... and more?
Better for privacy: Local tooling doesn't need to share everything you're doing with a centralized provider.
Opportunity for better integrated tooling: Rather than limiting tooling to wallets and bespoke frontends, we have a new point of integration between these two. Imagine transaction simulation, decentralized contract curation lists and warnings, interaction with MEV and account abstraction mechanisms, and more.
Reduce duplication of effort: Every developer writing the same contract frontend over and over, with the same multi-wallet sign-in flow, input validation, error handling... or worse: Without any of these things.
Raise the bar for bespoke contract frontends: If it's not going to be at least as good as a procedural frontend, don't bother making a frontend.
Is it boring that contract experiences look too similar? Should we be able to white-label procedural contracts?
One approach is to have additional theme annotations in contract source code (as comments), which procedural frontends can use to generate appropriate look and feel to match the rest of the apps.
Impossible to cover 100% of use cases?
Contracts come with varying degree of complexity. It's easy to imagine covering typical token-like contracts, but what about more complicated things like multi-step state machines, or things that require custom client-side logic like Tornado Cash?
Similar to the themeing approach, we can imagine including some declarative association between fields in the contract source code that the frontend could derive a state machine from. But at some point, we just need to accept that some contracts will require a bespoke frontend. The bet here is that most should not.
Tricky contracts are still tricky
We can get rid of tricky frontends lying about what they're doing, but we're still left with contracts that have functions claiming to do one thing (via function signature, NatSpec, etc) and in reality does something different.
This can be tackled with a combination of better local transaction simulation and better static analysis of EVM bytecode.
How do we get there?
A rough roadmap towards a procedural future:
Prototyping
Extract structured metadata from EVM bytecode using static analysis.
See: WhatsABI
Minimum Viable Product (something better than Etherscan):
Make a basic read/write procedural frontend from contract metadata.
Build specialized interfaces for common usecases and ERC standards.
Deploy immutable stand-alone version (IPFS pinned stable release, with ENS pointer)
Any ENS should be able to point to the IPFS release and get an automagic procedural frontend rendering for itself.
Polished Product (frontend good enough for 80% of contracts):
Extract metadata from verified source code.
Annotate unstructured fields with NatSpec from source code.
Inline type checking and conversion (for things like token decimals).
Support theme overriding from verified source code, maybe generate procedural themes using the deploy address as a seed by default.
Specialized interfaces for less common usecases (non-ERC standards).
Future Ideas:
Decentralized curation: Allow safe overrides for structured annotations from a chosen curator (part of the URL?). This can include things like additional instructions, or grouping/ordering of fields, or even custom widgets.
Alternative implementations that are not necessarily web-based (e.g. TUI).
More sophisticated plugins for contracts requiring programmatic frontends. One idea is a WASM module with state machine transition hooks that can mutate the procedural frontend fields.
Procedural Smart Contract Frontends: Future of Ethereum DApps
Imagine a procedural smart contract explorer good enough that most smart contracts don't need a custom frontend to use them.
No, I don't mean writing another Medium post with step-by-step screenshot instructions of how to use Etherscan's contract explorer.
Imagine something that is good enough to pass for a native interface, producing specialized widgets for common contract interfaces: Tokens, NFTs, Swap routers, DAOs, and even administrative like Roles/Ownable, and upgradeable Proxies.
Imagine a world where 80% of smart contracts don't bother building their own bespoke frontend, but rather encourage consumers to use procedural frontends.
What are some benefits of this world?
Local commodity frontends
Today, we regularly rely on
app.uniswap.orgto swap some tokens, oropensea.ioto move some NFTs, ortrustme.notscam.xyzto approve some permits.What if we had an open source local frontend we could run that was more than good enough to do these common usecases?
It could be an IPFS-pinned immutable hash. It could be accessible through ENS or Tor. It could be packaged up as a simple webview container with WalletConnect. Even wallets could include an embedded version of it.
If we do a great job on it, the attack surface area could be made small and we could avoid updating it too often.
Safer against phishing attacks
Today, building a bespoke frontend for a contract means that we're training our consumers to trust some third-party website as an interface for the contract.
Anyone can make a website that claims to be a legitimate frontend for our contract, and trick our consumers to use a malicious frontend.
If we had a procedural frontend that we used for our contract interactions, then we reduce N (number of contracts we ever interact) interfaces and opportunities to get phished into just one instance.
Safer against censorship
Frontends are the main point of censorship that smart contracts experience, because almost all frontends today are provided as a SaaS (Software as a Service) where some corporation is responsible of how their consumers use their service.
Whether it's corporate pressure, or regulatory pressure, or totalitarian control of information through Internet filtering -- frontends are vastly more vulnerable to censorship than The Blockchain.
Enabling consumers to rely on their own locally hosted frontends removes an unnecessary intermediary.
... and more?
What are some shortcomings?
Every contract experience looks the same?
Is it boring that contract experiences look too similar? Should we be able to white-label procedural contracts?
One approach is to have additional theme annotations in contract source code (as comments), which procedural frontends can use to generate appropriate look and feel to match the rest of the apps.
Impossible to cover 100% of use cases?
Contracts come with varying degree of complexity. It's easy to imagine covering typical token-like contracts, but what about more complicated things like multi-step state machines, or things that require custom client-side logic like Tornado Cash?
Similar to the themeing approach, we can imagine including some declarative association between fields in the contract source code that the frontend could derive a state machine from. But at some point, we just need to accept that some contracts will require a bespoke frontend. The bet here is that most should not.
Tricky contracts are still tricky
We can get rid of tricky frontends lying about what they're doing, but we're still left with contracts that have functions claiming to do one thing (via function signature, NatSpec, etc) and in reality does something different.
This can be tackled with a combination of better local transaction simulation and better static analysis of EVM bytecode.
How do we get there?
A rough roadmap towards a procedural future:
The future is procedural.