SWIS contracts — a simpler demonstrator for blockchains and smart contracts
Author: Dr. Sebastian Bürgel, CTO, Validity Labs
TL;DR;
Simple wallet interface smart contracts (SWIS contracts) are a design paradigm for easy to use, yet fully decentralized applications (Dapps). SWIS contracts expose their core functionality via fallback functions and are thus accessible via simple Ethereum wallets that cannot call smart contract functions. A minimal SWIS gambling contract was deployed to easily engage a non-technical audience in smart contracts.
Motivation
While talking about, teaching and tinkering with blockchains and smart contracts at Validity Labs we are quickly facing a very important but difficult set of questions:
What is a smart contract really?
What can it do?
How does it feel like?
Can I touch it?!
Especially the last one seems extremely important. Often times a transition from “Bitcoin?! That scam money?!” to “Just this key allows me to do all that? Wow!” can be observed when exposing people to blockchain technology in a hands-on fashion. Unfortunately, hands-on examples of smart contracts that are accessible to a non-tech savvy audience and at the same time do not sacrifice the distributed nature of blockchain seem to be scarce. Currently available examples seem to focus on either end of the spectrum between user experience (UX) and decentralization:
Blockchain-in-a-box
A user-friendly web-interface is often times wrapped around an Ethereum smart contract. Such web-interfaces provide very intuitive user experience (UX) and typically connect to and rely on an Ethereum node via the web3 library. At the same time, however, this approach sacrifices the very nature of blockchain-based decentralized applications (Dapps) that we were struggling to build in the first place: If that very webserver is the only interface to a particular smart contract then this machine is a central point of failure, might not be available and could be subject to man-in-the-middle attacks.
Current Dapps
On the other end of the spectrum, we find true Dapps which ideally do not rely on any centralized infrastructure. These Dapps are currently of limited use outside of a small circle of crypto-hackers due to widely lacking tools providing access to an entirely decentralized software stack. One emerging tool is Ethereum’s Mist browser. An ideal Dapp browser would provide a native interface to IPFS, Ethereum’s Swarm and Whisper and the Ethereum blockchain. It would also run on the platforms that the majority of web users actually use. Observing the current trajectory of progress, I estimate that reliable Dapp browsers with acceptable UX on popular host systems are probably not going to be available in the near future (1–2 years).
SWIS contracts
Here we explore, for the first time, a new middle-ground design paradigm between fully-centralized web interfaces and advanced Dapp-browsers. We are targeting existing Ethereum wallets as the only required interface for our Dapps. Simple Ethereum wallets are available for most operating systems (e.g. JAXX) or even fully client-side in-browser (e.g. myetherwallet). Most of these simple wallets allow for transactions to a specific address but they do not provide an easy way of calling specific smart contract functions or sending additional data to that contract. Therefore, we introduce simple wallet interface smart contracts (SWIS contracts). SWIS contracts allow user interaction by just sending transactions to the smart contract address instead of calling specific functions.
Technically, SWIS contracts are heavily relying on fallback functions. Every smart contract can have maximally one fallback function which is implemented in Solidity as a function that does not have a name. This function is being called whenever the smart contract receives a transaction (more technically, this function is being called whenever no other matching function can be found at the contract behind the destination address but this is e.g. the case when we do not provide any further payload data).
Example: SWIS gambling contract
In our first example implementation we present a minimalistic gambling contract that has its entire game logic and a minimal state machine in the fallback function. It allows users to register to a game and, after a registration period elapsed, a random user is chosen which will receive the entire pot of the game (entire contract balance). Gaming therefore works as follows:
- Send X Ether to contract address A to create a new game and use X as pot for prize money.
- Users have S seconds to register for the game by sending a transaction to A. This transaction can send a value of zero Ether — the sender is thus only paying the gas fees.
- After the registration time S elapsed, one further transaction to address A calculates a pseudo-random number to obtain the winner amongst all registered addresses and transfers the entire pot to that winner. Finally, all registered player addresses are being deleted so that the next game can start.
While the game is very minimal and attackable in a number of ways (register same address or address controlled by same user many times, attack pseudo-random number generator, etc), it does show a SWIS contract as new minimal viable smart contract interaction scheme. Passing some status or very short piece of data to the contract could also be facilitated by a small number of Wei: e.g. the lowest 100000 Wei could encode a small value that could be used in this example to define the registration duration or set a limit of players.
While many existing contacts make extensive use of fallback functions, we propose SWIS contracts as a more general-purpose design paradigm where ease of use meets true decentralization in a transition period until Dapp-browsers are widely available.
Live contract: 0xca16790e9bb125392960e78befff1d4df4cb5b58
GitHub code: https://github.com/validitylabs/dgame
