Notoros Resources

Background

Distributed ledgers, like blockchains, must maintain identical copies of their data across a collection of nodes spread across the internet. This requirement is extremely expensive, but is essential for maintaining the validity, resilience, and decentralization of the ledger. The resulting storage and computational costs have substantially slowed the adoption of DLTs and have been cause for concern that the technology may not even be worth its expense. This problem is only made worse by the fact that the vast majority of blockchains store an ever-growing application state that compounds exponentially with the complexity of their applications.

Ethereum is one example of a blockchain that is well-suited for single-threaded computation, but is incapable of processing a significant number of requests in parallel. This is because Ethereum cannot advance any part of its state until all the dependencies and outcomes of all the transactions in a block are fully accounted for. This approach forces each block in the chain to wait for the conclusion of their predecessor before having any impact, even if there are no mutual dependencies between them. The result is a state-access paradigm that is slow, computationally expensive, and difficult to paralllelize that looks like the Number Line Diagram below.

With this in mind, Notoros has distilled down the requirements of distributed ledger technology to identify the minimum amount of information required on-ledger, or “on-chain”. Transactions in Notoros have a relatively constant impact on the ledger regardless of the complexity of computing or storing application state. This architecture maintains the same level of validity, resilience, and decentralization as the most robust DLTs while offering new dimensions for parallelization, like those created at the foundations of mainframe computing

The Resource Grid

The Notoros ledger is essentially an immutable resource grid combined with an immutable data store (sometimes called the transaction database). Transactions successfully submitted to the ledger are assured via cryptographic proofs. As transactions enter the ledger, they are ordered sequentially. Transactions may depend on one or many different resources, and likewise may update one or many resources across the sharded network.

The diagram above illustrates the structure of the Notoros Resource Grid. This grid acts a multi-dimensional index for accessing transaction data across time and space in the data store. There are a multitude of shards in the Notoros ledger, each containing a multitude of slots. Each resource can be found in a specific shard at a specific slot.

(Shard, Slot) = Resource

Notoros segregates the dependencies of different transactions and their respective read-write requirements. This means resources for independent transactions can be updated simulatenously without interference. This architecture allows the network to achieve parallelization within each shard while providing a global ordering of events across shards.

Anatomy of a Resource

Each Notoros Resource maintains a single logical clock counter, or simply a “counter”. A logical clock counter is an integer variable that increments by one each time it’s updated. In Notoros, these logical clocks represent the version number of a particular resource.

(Shard, Slot, Counter) = Resource Version

In the Notoros Resource Diagram below you can see the latest version increment represented by the highlighted box on the top of the column.

Resource Policies

For each transaction, the exact resources updated and relative ordering those updates are specified in its Resource Policies. Transactions are committed to the distributed ledger based solely on whether they have a proper ordering of Resource Policies, the requisite signatures, and the necessary consensus-specific metadata.

Resources Policies combine the concepts behind a URI and the logical clock counters used in the Lamport’s Bakery Algorithm. Each Resource Policy includes a hostname dictating in which network shard the entry is recorded, a slot indicating the resource being operated on, a logical clock counter specifying the version of the resource, and an optional increment to that logical clock counter. If the logical clock is incremented, the policy represents a “write” operation that will update its version, otherwise the policy represents a parallelizable “read” operation.

The Resource Policies of a transaction are used to determine whether the transaction is valid and its relative ordering during consensus. Conveniently, logical clock counters also provide native indexing for transactions and can be used to extrapolate application states, making it easy to trace transactions and state changes across multiple applications. More information on how a policy is formatted in a transaction can be found in the Transaction Policies section