The Vending Machine Model

Trustless Payment for Scalable Smart Contracts

Background

We recently launched VeeDo 0.1 on Mainnet, and it is powered by a business model we refer to as the Vending Machine Model. We believe this business model can be put to good use in the blockchain space. It allows trustless payment for services rendered by scalable smart contracts: smart contracts that serve as a front-end for Layer-2 (L2) functionality running in the cloud.

Motivation

The need to scale blockchains — to move computation and storage off-chain, to the cloud, is well-understood — hence the great interest in L2 solutions. Outside the blockchain space, SaaS is the dominant business model for cloud-based services. Unfortunately, SaaS is not good enough for the blockchain ecosystem, which favors services with the following properties:

Trustless
The objective is to minimize trust assumptions for all participants.

• Users: spare them the need to trust their service providers to run the service, to perform computations correctly, etc..
• Service providers: spare them the need to trust their users (e.g. to make a periodic payment).

Permissionless

Render services without explicitly granting permission (e.g. by approving credit card details).

Censorship-Resistance

• Explicit censorship: blocking certain users from accessing a service.
• Implicit censorship: skewing the outcome of the service in favor of the cloud-service provider, or its customers.

Transactional
Render services at the single transaction level, without any longer term commitments or relationship.

We believe the Vending Machine model supports the delivery of trustless computing services by L2 solutions over blockchains.

The Vending Machine Model: “Trustless Computation, or your money back”

Let’s assume that Alice needs to compute a computation C on Ethereum, but it is unfeasible to do it on-chain due to high gas spending. We describe a model which allows Alice to outsource the computation to an Off-chain Service. The model ensures Alice that she will either get the correct result for the requested computation, or will get her money back.

1. Alice sends a request to perform a computation C to the Vending Machine contract, paying the contract in advance the required amount.
2. The off-chain service sees the computation request and decides whether to service it, based on the amount paid.

steps 1–2

3. The off-chain service submits (a) to the Verifier contract: a proof attesting to the validity of the result; (b) To the Vending Machine contract: the result of the computation.

4. If the Verifier accepted the proof, the Vending Machine sends the payment to the Ethereum address of the off-chain service.

steps 3–5

5. In case no valid result was submitted to the Vending Machine in a predefined time period, Alice gets her payment back.

The VeeDo Use Case

VeeDo, our STARK-based Verifiable Delay Function (VDF) service presented us with an interesting use case, and helped us crystalize the Vending Machine model. In VeeDo, Alice wants to compute the value of a delay function df() on an input (x,t), in order to use df(x,t) in her own smart contract. For example, it can serve as a trustless, robust, source of randomness. Performing this computation on L1 is prohibitively expensive, gas-wise. Bob can help Alice, by performing the computation off-chain and presenting its result, y, on-chain. The Vending Machine model allows Alice to consume the VeeDo service, and pay for it trustlessly. It allows Bob to trustlessly receive payment, thereby reducing his business risk.

Alice feeds the VeeDo smart contract on Ethereum with the required payment, and with her inputs (x,t). Bob tracks the state of the smart contract. Once he sees a payment has been made, he computes (x,t) in the cloud, and computes the STARK proof attesting to the correctness of df(x,t). He submits both the STARK proof and df(x,t) to the VeeDo smart contract. If the proof is verified, df(x,t) is stored, and the VeeDo smart contract transfer’s Alice’s payment to Bob.

The Road Ahead

Let us review some challenges and opportunities we see down the road.

L2 Decentralization

The Vending Machine model includes the smart-contract running on L1, and a service running on L2.

L1, at least on Ethereum, is already well decentralized. L2 isn’t properly decentralized just yet. The solution is obviously to improve the decentralization of L2 services. We, like many others in the ecosystem, view this as a gradual process, which culminates in a large number of permissionless L2 service providers. We believe the Vending Machine Model lends itself to having multiple service providers in the cloud, all competing to serve users, therefore promoting further decentralization of L2.

Applying the Vending Machine Model to Cairo

Cairo is our framework and language for producing STARK proofs for general (Turing-complete) computation. A Cairo Verifier smart contract is already deployed on Mainnet Ethereum (as it serves StarkEx 2.0, the latest release of StarkWare’s scalability engine).
One practical advantage that Cairo offers is having a single Verifier smart contract which can verify proofs for any Cairo program; there is no need to deploy a separate application-specific Verifier smart contract.

Applying the Vending Machine model to the Cairo Verifier smart contract could present an interesting business model for entities producing STARK proofs in the cloud. Pricing would depend on various Cairo program parameters (think: gas pricing for various opcodes on Ethereum). The STARK proof can include attestations regarding these parameters (“app_1’s transactions included in this batch: 10 multiplications, and 7 writes”), thus allowing the service to be rendered and consumed in a trustless fashion.

A Cairo Vending Machine can go beyond that: it can offer something uniquely interesting to the long tail of low-bandwidth applications. This can be achieved thanks to GPS (Generic Proof Service), which is part of the Cairo software stack. GPS allows bundling computations from multiple independent applications (e.g. separate batches of trades from dYdX, Immutable, DeversiFi) into a single STARK proof. The on-chain cost of verifying this proof can be jointly borne by these applications. Let us elaborate.

Computations performed by an application on L1, i.e. the blockchain itself, have some economic value v associated with them (e.g. fees generated for a transaction, or the selection of the winner of a lottery). The application cannot sustainably spend more than v on performing this computation. It follows that many lower-value computations will fall below an L1 economic viability threshold. In the Vending Machine model, this threshold is bounded by the cost of generating a STARK proof off-chain, plus the cost of verifying this proof on-chain. Thanks to GPS, costs can be amortized across the set of applications whose computations are aggregated in the proof. Consequently, it is the cumulative value behind these aggregated computations that needs to exceed the viability threshold. The trustless nature of the Cairo Vending Machine would allow these applications to coordinate payment in a fair and efficient manner.

To conclude, let us abuse the vending machine metaphor a bit further. What we have is nothing more than a buyer (an application, or a user) that wants to buy a single bottle (computation) from the vending machine, without having to single-handedly cover the cost of an expensive supplies delivery truck (the cost of generating and verifying a validity proof). GPS on top of Cairo makes all this possible.

Conclusion

The Vending Machine model allows the deployment of trustless services for scalable smart contracts, i.e. smart contracts powered by L2 services. By applying this model to a Cairo Verifier smart contract, the benefits of L2 scaling services can be brought to the long tail of decentralized applications.

Tom Brand & Uri Kolodny