Three Things #46: December 4, 2022
Spacemesh Design Rationale Part II
While there isn’t room here to fully explore every nook and cranny of Spacemesh, there are still a few important aspects of the project worth explaining that I couldn’t cover last week. I recommend starting with last week’s Part I if you haven’t already read it since it will be helpful context for this issue. This issue explains the rationale behind three more components of the design.
Thing #1: Economics
As I mentioned last week, the overarching design rationale behind Spacemesh is to start with the values and ethos of Bitcoin and introduce technological improvements that don’t detract from them. The economic model is a great place to see this rationale in action, and to see our values brought to life in math and code.
We initially announced the Spacemesh economic model about a year ago. Since then, we’ve continued to iterate on it and we made some small improvements and refinements (e.g., accounting for the effective genesis and more precisely calculating the half life). The final model can be found in this repository. It starts with the Bitcoin issuance model (block rewards that decay exponentially with a half life of approximately four years), increases the half life substantially (to about 31 years), and smooths out the decay function so that issuance decreases gradually every layer (rather than a sudden “halvening” every four years). The coins set aside for the early team and investors are placed in vaults that vest over the first four years; these coins represent 25% of the total issuance at the ten year mark and 6.25% of final, long-term issuance.
The main thing to note about the Spacemesh issuance model is that it’s slow. 99% of all Bitcoin that will ever exist will already have been mined within the next eight or nine years, or around 22 years post-genesis; the final Bitcoin will be mined around 2140. By contrast, it’ll take over 200 years to reach 99% of Spacemesh issuance and the final coins will be mined nearly 2000 years post-genesis. This is intentional: we’re designing and building Spacemesh to be sustainable over the very long term, not as a get rich quick scheme. While we need to respect the needs and expectations of our investors, we feel that it’s imperative that folks who join the Spacemesh project even far into the future can still earn a meaningful amount of coins in a credibly neutral fashion, i.e., by mining from home. We also want to make sure Spacemesh doesn’t run into the fee market issues that Bitcoin may soon encounter.
That’s all there is to say about Spacemesh economics for now. We’ve kept the design simple, predictable, and easy to understand: “sound money” in Bitcoin parlance. No additional coins will ever be created beyond those laid out in this design, although we may introduce a burn mechanism (akin to EIP-1559) in the future. We don’t know if Spacemesh coins will ever be considered a form of money, but we at least want to set up the economics correctly so that could come to pass.
Of course, the devil’s in the details and there are quite a few more details about which actors are rewarded for precisely which actions and how, how rewards are divided among miners, etc.. See the below links for more information.
For more: see this blog post, this spec, and this repository.
Thing #2: Proof of Elapsed Time
I described a bit about proof of spacetime last week and how it’s a hybrid of proof of work and proof of stake, but I didn’t have the space to go into detail about how it works. I’ll describe a bit more this week. To begin, there are two components to proof of spacetime. Care to guess what they are? 😀 Proof of space and proof of time.
The space component has two phases: an initialization phase and ongoing proving phase. In the initialization phase, a miner commits a certain amount of space—say, 256gb—to the protocol, and runs an algorithm that generates a very large data structure to fill that space. In the ongoing proving phase, the miner responds to a series of random challenges to convince a challenger that they still have all of the data. The miner doesn’t have to share all of the data with the challenger, as that would take too long and use far too much bandwidth, but if the challenger asks for enough random samples from the data, and independently verifies those samples (which they can do with the miner’s public key and the same algorithm used to generate the data), then they can be convinced probabilistically that the miner still has all of the data.
The time component is a bit more nuanced. It’s not enough for a miner to simply prove that they have the data at one point in time. Otherwise, they could generate many such proofs for later use, then delete the data. Each proof of space needs to include a proof of elapsed time (PoET, for short) to prove that a certain amount of time has elapsed since the last proof and that the miner still has the data.
How do you trustlessly prove that a certain amount of time has passed? We use a method called proof of sequential work: an algorithm that cannot be parallelized (since each step in the computation relies on the previous step) as a proxy for the passage of time. We run the computation on the fastest possible CPU to figure out how long it takes, then use that as the benchmark. E.g., if a very fast CPU can complete, say, one million operations per minute, then we can safely assume that a proof of having done one million operations means the miner ran the algorithm for at least one minute.
The astute reader may notice a contradiction here: as I pointed out last week, unlike proof of work, proof of spacetime doesn’t use much energy. But the time component requires doing a form of proof of work (basically, running a CPU at full throttle performing the proof of sequential work). The key insight here is that the PoET proof is not unique to a particular miner, and as a result many miners may share the same proof. So a single PoET server (which is really just a computer with a single fast CPU running a very simple algorithm) can serve many miners—potentially thousands. Amortized across all of those miners and all of that storage, it amounts to a protocol that’s still very energy efficient. (Users are free to run their own PoET if they wish, but Spacemesh will run several, and it’s expected that others in the community will also run them, so there is no need to run your own.)
To recap, the full spacetime proving process is as follows: First, a new miner initializes their storage space and generates an initial proof of space. Then they submit this proof to a PoET server and wait for it to return a proof of elapsed time. They stitch these two together and submit them to the network as a final proof of eligibility. Each epoch, they repeat the process: generate a new proof of space (which references the previous proof of elapsed time), submit it to the PoET server and get back a new proof of elapsed time, stitch together, submit, rinse and repeat.
A proof of spacetime proves that a miner has spent a scarce resource on the protocol: namely, the opportunity cost of that storage space for a meaningful amount of time. This is how the miner establishes eligibility to produce blocks epoch after epoch.
For more: See the protocol documentation on proof of elapsed time.
Thing #3: Account Unification
There are two types of accounts in Ethereum. The first, officially known as an externally-owned account (EOA), is an ordinary user account controlled by a public-private keypair. This includes the accounts you use in Metamask or any other standard wallet. In an EOA, the address is derived from the public key.
The second type of account is a smart contract account. Like an EOA, a smart contract account has a balance and a nonce, but unlike an EOA, it also has code (i.e., the bytecode for the smart contract that’s invoked when someone calls it). It’s not controlled by a keypair, cannot originate transactions or pay for gas, and the address is derived differently.
At first blush this distinction makes sense, but it also has some problems. For one thing, since both account types have the same address format, it’s not even immediately obvious that there are two types of accounts in Ethereum. It’s also not obvious why there needs to be two types of accounts―and why smart contracts cannot pay gas, for instance. And it’s annoying: many application vendors would like to allow their users gas-free transactions, so that first-time users don’t need to first acquire ETH before using the application. But this can’t be done at layer one, only with complex, additional infrastructure like layer two metatransactions.
To make things even more complicated, some of the data fields in the account do double duty, i.e., they have the same name in both account types but serve different purposes. The address, already mentioned, is one such example. Then there’s the nonce, which means different things in EOA and smart contract accounts. This is confusing, to put it mildly.
Finally, Ethereum’s account model also means that all EOAs must work exactly the same way. They’re single sig, i.e., associated with only a single keypair. They must all use the same, enshrined ECDSA cryptography in precisely the same way. And if you lose your private key, you’re hosed.
For years, Ethereum has considered an upgrade called account abstraction. It’s still on the latest roadmap (in the catch-all “Splurge” bucket), and I think it’s likely to eventually happen, but it’s a big upgrade and will require enormous changes both to the protocol and to downstream tooling like wallet software. As such it’s not an especially high priority or urgent upgrade, so even if it does happen, it likely won’t happen for years.
The basic idea behind account abstraction is to eliminate EOAs entirely in favor of smart contract accounts. Under account abstraction all accounts become smart contracts. Rather than an EOA, a simple, keypair-based user account becomes a single-sig wallet contract that emulates an EOA—but that also gives a user the option of adopting a multisig or other contract as their main wallet. Contract-based wallets, such as those already used by Argent and others, would allow users to rotate keys, delegate spending keys, and use many other useful patterns that aren’t possible with EOAs. It also means that smart contracts could, finally, pay for gas and originate transactions.
Spacemesh has adopted account abstraction (we call it “account unification,” which feels like a better name). This is a perfect example of the third category of exception I mentioned last week when talking about ways in which we want Spacemesh to differ from Ethereum: if a design that’s clearly better is on the table, we should leapfrog Ethereum and implement it now.
It turns out that account unification has some pretty profound, far-reaching implications on the protocol which made this task much harder than we expected (and is a big part of the reason Ethereum hasn’t gotten there yet). I won’t go into all of them here (I could and should do a separate issue on it), but one example is that it changes how the mempool is managed. In Ethereum, it’s trivially easy to figure out when one transaction conflicts with or invalidates one or more other transactions. With account unification, this becomes a NP-complete problem that requires some pretty clever heuristics to work around.
But it also has some very positive effects on user experience and developer experience. In addition to the benefits described above, it means Spacemesh will enable an entirely new level of programmability in smart contracts. Contracts in Spacemesh will have an unprecedented level of control over their execution context: they can define their own custom signature scheme or use elliptic curves that aren’t enshrined by the protocol. They can define custom nonce logic, allowing them to do very clever things around ordering, deduplicating, and rate-limiting transactions. They can define custom schemes for packing, encoding, and passing data. Expect to see a lot more on this soon as we finalize the Spacemesh programmability model.
All of these improvements should result in more flexible, secure, user-friendly applications that cost less gas (or possibly none at all!).
For more: See this SMIP for the Spacemesh take on account unification.