Intro to building on NTS

️⚠️

NTS is in active development and currently unstable. It is open to select early developers for exploration but is not yet suitable for production use. Follow developer updates for the latest changes, as performance is not at production level.

This article is a brief introduction to NTS, and the core concepts you need to know to get started.

NTS within N1

N1 is separated into two layers: the Execution Layer and the Settlement Layer. The Execution Layer is where your app runs. The Settlement Layer is where the app state gets settled, stored, and secured. For the purpose of app development, we will focus on the Execution Layer.

There are two types of application containers in N1:

Shared App Container
- A shared container allows multiple apps to run within the same environment. The EVM, SVM, and N1’s NTS are examples of shared containers, as they support multiple apps running in the same environment.
Dedicated App Container
- A dedicated container is a container that is dedicated to a single app. Nord is an example of a single app-specific VM. NTS, EVM, and SVM can also be modified to exclusively support a single app.

Since N1’s execution layer is horizontally scalable, it can support infinitely many app containers.

Currently, N1 development is limited to NTS (which is a shared TS app container), and Nord (which is an app-specific dedicated container for exchange-type apps).

We’re working on expanding to more shared containers like EVM and SVM, as well as making it permissionless to launch dedicated containers.

State in NTS

At a high level, NTS is one large shared state and database. All apps access that same database. Smart contracts (‘apps’ in N1 terms) can read from and write to that database.

The state in NTS is organized using a key-value store model, where:

Keys are strings that identify specific pieces of data
Values can be any serializable TypeScript/JavaScript data structure
Each app has its own namespace to prevent conflicts
State changes are atomic and consistent across the network

Namespacing

To prevent conflicts between different apps, each app’s state is automatically namespaced. Only the app that owns the state can write to it. All apps however can read from every other app’s state (that’s the point of a shared state computer afterall!).

State Persistence

All state changes in NTS are:

Persistent: Data remains available until explicitly deleted
Consistent: All nodes in the network see the same state
Ordered: State changes are processed in a deterministic order
Atomic: State operations either completely succeed or fail

⚠️

Remember that all state in NTS is public. Never store sensitive information like private keys or unencrypted personal data in the state.

Transactions

Transactions are how you interact with NTS apps. Each app exposes functions (endpoints) that can be called via transactions.

Transaction Atomicity

Transactions in NTS are atomic, meaning:

All state changes in a transaction either succeed together or fail together
If any part of the transaction fails, all state changes are rolled back
Other transactions cannot see partial state changes

Cross-App Communication

NTS supports cross-app communication. We’re still writing out the implementation details, stay tuned.