Spacemesh Progress Update #2 — Oct 23

Dear Smeshers

Sorry for not communicating more frequently, last weeks has not been easy on us due to demand for mining Spacemesh exceeding our expectations, my team is seriously overworked as we struggle upholding such unexpected growth.

However there are some question on everyone’s mind i seek to better address:

1. Where are we?

Spacemesh mainnet has been running in production for 3 months, since July 14th 2023, without downtime nor other meaningful interruption of service, on the first attempt to run such a network in production ever. Moreover, organic demand for smeshing has been increasing superlinearly for 3 months now.

To achieve this, the Spacemesh team executed well and robustly for the past 18 months, committed and motivated, demonstrating uncompromising dedication to network liveliness, and the competence to respond quickly and effectively to real world circumstances.

GOT SMESH?

2. Lessons learned

Now that we have the benefit of seeing the fruit of our work running in the wild, there are also some takeaways to be learned. While the uptake of participating in the Spacemesh protocol has surpassed our expectations, we see underwhelming demand for the Spacemesh coin. This is not a huge surprise, as our plans for the Spacemesh Virtual Machine, our innovative execution layer, have yet to materialize. Spacemesh at the moment offers less programmability than other blockchains, making it less useful, so there’s little market demand for the coins that smeshers are rewarded with.

Our conclusion is that we should divert more resources from smesher-serving improvements to unlocking functionality that makes Spacemesh useful as a coin.

Even within the sphere of smeshing improvements, we’ve learned some important lessons. Consistent with our aspirations to be attractive to home smeshers, we’ve focused almost exclusively on that demographic.

Home Smesher

Our assumption was that whale-smeshers would have the resources to make their own code adjustments to serve their needs. We’ve learned that leaving this gap between the needs of some smeshers and the software we delivered created an opportunity for sophisticated actors to centralize these under-served groups around them.

Taking advantage of our blindspot, mining pools providers, such as H9, have created alternative smeshing software that’s better suited for larger smeshers with multiple GPUs and multiple disks. It also uses their inferior trust model to their advantage, by centralizing node operation in their datacenter — relieving smeshers of their client of the need to keep their node connected and running 24/7 at the cost of giving up their private key.

We must ensure that our secure smeshing software is competitive for all kinds of smeshers, big and small, to avoid pushing some cohorts into the hands of actors that weaken the system as a whole.

Best Potato Peeler 2023

2.1 Miners with large storage

At genesis, splitting your identity into multiple small miners makes it easier to perform the proof generation. We plan to deploy several improvements.

• Phased PoETs: For example, 14 PoETs such that one PoET starts on each day. If the miner fails to produce a proof, she can re-try in the next PoET phase and thus lose only a small amount of ticks.
• PoET with early exit points: Proof generation succeeds with higher probability if the miner starts from an early exit point.
• Delegated PoW: To avoid grinding there’s PoW component in the proof generation, which is burdensome for large miners. With delegation the miner can forgo a small portion of her reward to avoid the PoW computation altogether.
• Variable proof size: Large miners can create a larger proof (and pay a higher storage fee) that’s easier to produce.
• Fair reward formula: The wasted PoET ticks are taken into account when calculating the rewards (full spec is already available).

2.2 Pooled mining

Mining pools are prevalent in both PoW and PoStake blockchains. Spacemesh can do much better due to low expected time and variance until being rewarded (the mesh has many concurrent blocks), and undemanding work for miners (smart-contract execution is done only in rollup).

We plan to disincentive pools further:

• Educate users that giving away their private key is “voluntary identity theft”.
• Anti-delegation protocol rules: if the pool runs your network node on your behalf and collects your rewards, then it can steal your coins.
• Make it easier for miners to run the honest protocol (see above: phased PoET, early exit, delegated PoW, variable proof size, fair reward formula).
• Software improvements (multi-threads, efficient network processing, etc.)

3. SVM Vision

The Spacemesh Virtual Machine, SVM, is in development as a modular system, allowing users to control the behavior of their accounts with zero code, by selecting individual developer-deployed templates as the basis for their accounts.

This approach gives developers tools they can’t find elsewhere to serve their audience, and gives less tech-savvy users cheap and easy ways to get what they need from the blockchain.

Inviting developers to a green field with unprecedented tools at their disposal will start a chain reaction. The newly-introduced developer abilities will enable the development of new or significantly more efficient applications on top of the Spacemesh VM, drawing in users of those apps.

We’ve outlined some of the use-cases this unlocks and the technical details of how this is achieved below.

In high level, the SVM functional advantages are:

1. Decentralized and therefore censorship resistant sequencing.
2. Scalable execution layer, which doesn’t jeopardize decentralization.
3. Small computers don’t have to run txs to verify correctness, achieved without compromising on decentralization.
4. Spacemesh stands to benefit from existing best in class tech and being compatible with lots of tools. So if there is something that makes UX better — Spacemesh can make use of it.

There are three innovative aspects of our medium-term SVM design:

3.1 — L1 with built-in rollup:

1. The execution layer is modular. Execution of Turing-complete smart-contact transactions is done only inside the rollup.
2. The consensus handling of the rollup is done by the core protocol.Censorship-resistance: L1 is responsible to collect rollup transactions that pay an adequate storage fee.
3. Efficient: precompiled templates for L1 contracts, and consensus-layer enforcement of the rollup state. See: https://spacemesh.io/blog/outline-of-the-spacemesh-vm-design/
4. Our innovative stateless rollup design:
   In the happy flow, full-rollup-nodes just execute the smart-contract transactions and commit to the resulting state tree (exactly the same as say Ethereum full-nodes, and unlike standard optimistic rollup that requires generating hash commitments for all the VM state transitions).
5. No finality (full self-healing, no lengthy waiting interval).
6. Generally, low coding complexity (no need to license 3rd-party components). Full description will be available within 2 weeks.

3.2 — Highly secure account model with abstraction and rollup-only accounts:

1. End-users can use just smart-contract accounts (no need for an externally-owned account).
2. Account abstraction with maximal efficiency (minimal fees due to single signature per transaction) and without making the consensus layer susceptible to any DoS attacks.
3. Motivation and full spec: https://community.spacemesh.io/t/gas-stations-for-rollup-only-accounts-and-with-support-for-account-abstraction/374
4. The account design will also be future-proof (e.g., for requiring accounts to pay rent for their storage).

3.3— Advanced VM language and low-fee execution:

1. We consider a modern VM with strong type-checking (less room for bugs, more elegant code).
2. It’s possible to make use of one of recent VM projects to reduce our R&D effort.
3. Our execution engine supports low-fee VM mode via static gas measurement (no dynamic gas metering). The consumed gas is calculated before executing the transaction, but only a restricted subset of the VM instructions can be used. This mode is enough for many popular use-cases (tokens, conditional swaps, ZK logic).

3.4 — Template-Account Design

The Spacemesh VM uses an innovative template-account design, where code is hosted separately from state. Many accounts can be instantiated from a single template, eliminating the redundant storage of the same code with every account that needs to use it and allowing for optimization of frequently used code.

Account addresses are generated offline. When coins are sent to an address for the first time it becomes a stub account (only the balance is known). To form a spawned account a special transaction reveals the template and constructor arguments.

3.5 — Account Abstraction

All Spacemesh accounts are created equal. The associated template code governs their behavior and all accounts can initiate transactions and fund gas fees. By separating validation functions and granting each of them access to different parts of the account state, we are able to give template designers ultimate control over the behavior of spawned accounts without sacrificing validator efficiency.

4. How does that affect how we operate?

Our company is now focused on 3 main activities.

1. Ongoing: Keep the network running smoothly. Respond to incidents and bug reports that threaten the security of the network or progress of consensus.
2. Short-medium term: Address the smesher experience of larger smeshers. The goal is to make the official client competitive for most smesher scenarios.
3. Longer term: Complete development of the Spacemesh Virtual Machine. Since attracting developers is the most important success metric of this project, we’ll get them in the loop early and make sure we develop a complete package — full and clear documentation, developer tools, example applications, etc.

5. Outro — Value:

In Spacemesh, since inception, we choose to do what we find to be the most responsible move at every junction. We choose longevity first so we’ll be proud of our legacy for many generations to come. So while we wish we had been further along faster for sure, and mostly regret not spending enough attention and energy to grow the community — we take pride in not making any compromise on our main tenets, the traits we’d hope for our industry to steward and embody.

1. Longest-time horizon preferences, an aim to make the most omniwin decision at any junction, standing highest chance to last and serve humanity’s common interest.
2. No compromise on security and robustness.
3. Deep faith and commitment in “doing the right thing and leaving the consequence to code” — e.g. Not buying ads with our investors’ money, out of genuine curiosity about price and size as a signal.

The Spacemesh team worked tirelessly during the past 5 years on things we believe history will grow to appreciate. We have made a commitment to minimizing investor/core-team footprint on chain, to resilience (and therefore stability) in the face of a world that is inherently chaotic, and to security via mathematical proofing. These commitments mean running slower so we can make optimal decisions. And we look eagerly to the future to teach us all how much it is worth.

We believe that, for our industry to thrive, we must accommodate such choices. That we must prioritize robustness and longevity rather than allowing success to be defined by rapid, unsustainable growth. For as long as we are playing “follow the winner”, some properties, however necessary for longevity and safety, simply cannot emerge spontaneously.