Next-generation architecture for the web

Scaffold moves the cloud to the client

main.js
lib.rs
build.sh
import { Scaffold, browserConfig } from 'https://github.com/scaffold/scaffold/raw/v1.0.0/index.ts';

// Connect to the scaffold network
const scaffold = new Scaffold(browserConfig);

// The hash of your WASM binary
const greeterContract = 'dda8ecfd22ea2b9fd670cd43cadd553ebfe35dac89a5552ab15fd1cf3eca21bd';

// Transparently load-balances between running (1) on the local device, (2) on a peer, or (3) on a server
scaffold.fetch(
  `scf://${greeterContract}/hello.from_str.World/to_str.body`,
  (response) => console.log(response), // Prints `Hello World!`
);

The web needs servers.

Right?

Nope.

We can move it all to the browser.

 
Why?
We created Scaffold to eliminate the hosting-related obstacles to building online services/platforms (commercial, social, multiplayer gaming, etc.). Traditional centralized hosting often demands significant financial resources, resulting in the need for ads or monetization, and in many cases even that is not enough (see Ello or Flattr for recent examples). By moving the cloud to the client, as long as there are users, there is service.
How does it work?
  1. Scaffold is a TS library that replaces fetch(). It connects to other users transparently using WebRTC and WebSockets.
  2. Your users' browsers trade compute power with each other and the entire Scaffold network, by running WASM lambdas inside web workers.
  3. Responses are transparently accompanied by collateral, which serves to incentivize verification and disincentivizes deception.
  4. Collateral is implemented by a transaction layer, reaching consensus as further work continues to be done.
Static data
Scaffold serves static data in its sleep. Peers compete to serve your users first and win a posted incentive. Static data verifies easily, by hash, signature, or even something more intricate if desired.
Dynamic lambdas
Scaffold can run any computation that compiles to WASM. Modules can use a number of ABIs, including WASI, Emscripten, or the raw Scaffold block interface. Your lambdas seamlessly load-balance between running on-device, on-peer, or on-server.
Cheap, fast, and scalable
  1. Stop paying GCP and AWS. Let your users be your cloud.
  2. From the beginning Scaffold's #1 design goal has been speed and simplicity. We don't compromise on this.
  3. Your users load balance automatically into the entire Scaffold network.
How does my server fit in?
Your server connects to the Scaffold network like any other client. You can use it as a source of truth, connecting to your database and responding primarily to infrequent/rare queries, while the Scaffold network handles the more recurring/common ones.
Is this a cryptocurrency?
It is built using similar concepts (distributed consensus; an emergent store of value); however,
  1. As stated in "Why?", Scaffold's #1 goal is computation. Not currency. The world has enough of those. However a store of value is necessary: to perform computations (as opposed to just returning easily-verifiable static content) on non-trusted platforms (browsers), you have to incentivize correct answers and disincentivize incorrect answers. This requires some kind of transferrable store of value.
  2. Many (if not all) of existing cryptocurrencies were created to achieve distributed consensus (usually to enable the creation of a token), at the cost of speed and throughput. We do the opposite - we prioritize speed first and consensus second. Large transactions will be finalized much more slowly, but this isn't a problem because we're using extremely small transactions to incentivize computation.
  3. It's not built using a blockchain (essentially a linked list), but a tree of computation results. No one will ever download or verify the entire tree. This means it's fast and energy-efficient.