The Notoros Protocol
The Notoros Protocol builds on the Uniform Resource Identifier (URI)1 specification, Lamport’s Bakery Algorithm2, and the latest cryptography standards.
Transactions in Notoros are composed of a set of arbitrary Messages, a set of cryptographic signatures, a set of Resource Policies, as well as any metadata needed by the consensus algorithm. The flow by which a transaction is submitted and processed in the Notoros Protocol is described below.
(1) A transaction is ready to be submitted to the Notoros ledger once it has been correctly formatted and cryptographically signed. Each transactions submitted the Notoros ledger is queued for processing in the order it arrives. If the transaction has the proper ordering of Resource Policies, requisite signatures, and the necessary consensus-specific metadata, it will be committed to the distributed ledger. During this process may refer to some Notoros Resources and update others while the Transaction Messages are committed to the Transaction Database (aka Data Store).
(2) Applications, which run off-chain, poll the ledger for changes to its state via the Notoros API or client libraries. Applications subscribe to specific Notoros Resources across the ledger to track when their counters increment and recieve the corresponding transaction messages. These messages are interpreted via lazy execution and can be used to trigger state changes in the off-chain application and its databases. This architecture provides applications unbounded processing time without impacting the consensus latency of the ledger. So long as the application is deterministic, its output application state will also be deterministic.
(3) The third step is entirely optional. Given a recent change to its application state, the application may choose to submit a new transaction to the ledger, beginning the transaction flow again at step 1 with this application as the new source.
This architecture allows applications across the entire spectrum of privacy, from fully private to totally public, to operate alongside one another in the same ledger context in both centralized and decentralized fashions. Independent applications can decide to process a message differently based on their social consensus. This could be used for regulatory compliance, as applications can internally blacklist certain transactions or accounts while maintaining the complete integrity, immutability, and decentralization of the ledger.
Consensus In Notoros
Notoros is a consensus-agnostic protocol that abstracts ledger states from application states. In any implementation, the consensus mechanism for Notoros is used maintain a trustless ledger state for a global ordering of events. Notoros garauntees efficient consensus because only simple matrix operations are needed to validate logical clock counters that make up the ledger state. This ledger state can be used to deterministically derive state changes for an off-chain application.
Currently the Notoros Beta network uses a sharded Proof of Authority (PoA) consensus. Other consensus algorithms have been implemented and are being explored for different use cases, including a future decentralized Notoros Mainnet.
Decentralizing Application State
Each Notoros application lens can be implemented in a decentralized fashion using a consensus mechanism chosen by its developers and maintained by a state-proving network. Decentralized applications may choose to periodically submit proofs of their state back to the ledger. This architecture minimizes data exposure and reduces attack surfaces from bugs. More information on decentralized application states can be found in the Notoros Lenses and Architecting a Notoros Lens sections.
[1] Berners-Lee, T. “RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax.” Internet Engineering Task Force. August, 1998. https://www.ietf.org/rfc/rfc2396.txt [2] Lamport, Leslie “A New Solution of Dijkstra’s Concurrent Programming Problem.” Communications of the ACM. vol. 17, no. 8, August 1974, pp.453-455