To let you buy and sell compute in the future, we built a ledger that records who owns every node-hour of every cluster we manage.
Simulated order fills based on buyer behavior on SFC over the last 120 days: most trades are small and bought within the hour, and a few long blocks bought far in advance carry most of the node-hours.
Every trade on SFC exchanges money and compute. Any other commodity exchange works the same way, except that most do not care about a time of delivery. When a cluster is sold out three years in advance, it's not only important how many node-hours each buyer gets, but also when their access starts and ends. This means you must model time, something that is hard to do with ledgers built for money.
We still want the other guarantees a typical ledger provides:
- Full auditability, with every movement on record
- No account can spend what it does not hold
- Every unit is held by exactly one account
- Cross-currency atomic transactions
A normal ledger can do all of this if the balance is a schedule over time instead of a number.
In a normal ledger an account holds a balance of some currency, a posting is an entry that records a change to a balance, and a transaction is a collection of postings that are applied together or not at all. The sum of the postings in a single transaction is always 0. This ensures that no value is ever created or destroyed, only transferred.
Most accounts cannot go below zero. If a posting would make an account's balance negative, the whole transaction is rejected and nothing is written. The exception is a handful of special accounts that run negative by design. When a user deposits credits (our dollar-denominated unit of balance), the credits enter the ledger from one of these special accounts.
A compute account also holds a balance, but the balance of a compute account is a schedule instead of a single value. For example: 128 nodes from January to June, then 48 from July to December. A posting adds or removes nodes available over a window of time.
In mathematics, both compute schedules and single values (integers) form partially ordered Abelian groups.1 Like integers, any two schedules can be added or subtracted, and any schedule can be checked for whether it is greater than or equal to zero.
| Dollars | Schedule | |
|---|---|---|
| A value | $120,000 | 128 nodes Jan–Jun, 48 Jul–Dec |
| Zero | $0 | 0 nodes always |
| Add | $120,000 + $30,000 = $150,000 | (128 Jan–Jun) + (48 Jul–Dec) = 128 Jan–Jun, 48 Jul–Dec |
| Negate | −$30,000 | −16 nodes Mar–Apr |
| Subtract | $120,000 − $30,000 = $90,000 | (128 Jan–Jun) − (16 Mar–Apr) = 128 Jan–Feb, 112 Mar–Apr, 128 May–Jun |
| At or above zero? | $90,000: yes | 112 Jan–Mar, −8 Apr: no |
Because clusters are not interchangeable due to differing hardware, locations, internet speeds, etc., we model each cluster as its own currency. A handful of special accounts run negative by design, just as in a money ledger. When we onboard a new cluster, its node-hours enter the ledger through a special account.
Trading compute for money between any two parties is a transaction with two legs: credits to the seller, compute to the buyer. These operations are performed atomically such that it is impossible for a buyer to have paid but not have received compute in return.
Parties can agree to trades through an order book, or by any other means: a negotiated contract, a reservation, a compute transfer to a friend. The ledger settles all of them the same way.
The schedule's value at the current time is the maximum number of nodes the account can use. SFC's control plane reads this number and enforces the limit. Hold 64 nodes for June, and all 64 can run from the first minute of June. Hold none for July, and your instances stop when July begins.
We hold every cluster to our published standards, but at the scale we operate GPU faults are unavoidable. Planning for these faults is a large part of our job.
A provider that fails to deliver a node-hour is responsible for the shortfall. By delivery day that hour may have changed hands several times, at a different price each time. What price do we use to calculate the shortfall?
Accountants have answered the same question for physical stock. When a business buys identical units at different prices, they use a cost formula to decide which purchase a unit comes from when it leaves stock.
International Accounting Standard 2 (IAS 2) prescribes first in, first out (FIFO) or weighted average for interchangeable items. US Generally Accepted Accounting Principles (GAAP) also allow last in, first out (LIFO). Internal Revenue Service (IRS) Publication 550 applies the same idea to shares: when taxpayers report a gain, a rule decides which lot they sold.
The ledger lets us do the same for compute. We can trace every node-hour back to the purchase it came from through its postings, and then apply a cost formula to pick the price to refund the purchase at.
Because every change of ownership is a posting, the ledger can also answer other questions:
- How many times a node-hour changes hands before it is delivered, which we call contract velocity
- How far ahead of delivery each cluster sells out
- What share of a customer's spend comes back through resale
The 25% average realized discount we previously reported was calculated using Abel.
Clusters can take a year or more to build, and are mostly financed by contracts signed before they exist. We can issue the capacity ahead of time and allow resale of parts of the cluster long before the hardware exists.
Customers can commit to a cluster before it is built and resell what they will not use.
We're hiring people who have built a market before or find markets interesting. Check out the job postings.
Footnotes
-
Named after the Norwegian mathematician Niels Henrik Abel, the namesake of our ledger. ↩
