Notoros Application Lenses
Notoros is a highly generalized protocol treats any deterministic state machine as an application running against the Notoros ledger. The ledger behaves as a pub-sub database wherein applications can selectively choose to subscribe to events published by other applications. All valid submissions to the ledger should be thought of as write-once read-many events.
Applications built directly on top of the Notoros ledger are called “Application Lenses”, or simply “Lenses”, because they selectively filter data from the underlying ledger. These are distinct from traditional decentralized applications (dApps) deployed to and run within a particular virtual machine like the EVM. In this way Notoros can have a multitude of virtual machines cooperating within the same ledger context as application lenses and each VM with many dApps running inside it. This architecture is illustrated below.
Virtual Machines are software execution environments that run directly on top of the Notoros ledger and are thus implemented as application lenses. These virtual machines are not baked into Notoros, but instead use the ledger as a common database to keep track of state transitions, prove their application state, and query its natively indexed data.
Lenses can be implemented as well-known virtual machines like the Ethereum Virtual Machine (EVM), RustVM, or LinuxVM, or as entirely custom VMs. Lens application states and their processing are performed off-chain in accordance to their own consensus. If a developer seeks to decentralize control over their lens application state they can form a decentralized state-proving network, which can operate much in the same way as a traditional validator group for a blockchain.
After initial registration, lenses are not obligated to post any data to the ledger except for the originating address and sequence associated with each state transition. All other data is optional. Lens developers may require application state proofs be posted periodically to the ledger. Compliance with this obligation may rely on data posted to the ledger, but can only be enforced by the state-proving network itself.
Notoros Lenses vs. Side-chains
Side-chains are a popular architecture for scaling blockchains and allowing them to use a variety of smart contract languages. Among others, Notoros lenses were also designed with these goals in mind. There are a variety of characteristics that make Notoros lenses different from side-chains in order to achieve greater security, flexibility, interoperability, and data availability.
In principle, side-chain architectures add additional blockchains to an initial “beacon” blockchain. Each side-chain must achieve its own consensus through its own set of validator nodes prior to submitting its state to the beacon chain. The beacon chain must come to consensus around the states of its various side-chains in order for them to be fully available to each other. The side-chain validator nodes may or may not coexist on the same servers as the beacon chain validator nodes. Note that in this architecture, trustless communication between side-chains can never be faster than the consensus of the beacon chain, and could be as much as the sum of the latency of each side-chain and the beacon chain.
Latencybeacon chain <= Latencycommincation between side-chains <= Latencyside-chain A + Latencyside-chain B + Latencybeacon chain
For the purposes of this comparison, a “parachain” is considered a type of side-chain. The primary distinction between a traditional side-chain and a parachain is that parachains use automata networks as their beacon chain rather than turing-complete networks.
Unlike the unpredictable latency of side-chains, Notoros lenses can communicate consistently in the time it takes for the underlying ledger to achieve consensus. This enables greater parallelization and eliminates the opportunity for inter-chain front-running or Miner-Extracted Value (MEV). Notoros lenses also share the security of the underlying Notoros ledger without the need for additional interchain interfaces. This cuts down on development time and operational complexity. Finally, because Notoros application states are not required to be propogated where they aren’t needed, Notoros lenses consume far fewer computational resources.
Notoros Lenses vs. State Channels
State channels are a different architecture for transferring state trustlessly on a need-to-know basis. Notoros lenses are similar in that they are only accessible to those who have the proper credentials, but otherwise are quite different in design from state channels.
In principle, a state channel is a trustless line of communication between two parties constituting a sort of quasi-temporary “micro-ledger” maintained only for the length of the relationship.
State channels are most typically used in payments infrastructure because they are well-suited for provable data between exactly two parties. Some distributed ledger technologies leverage state channels for more complex application states. While useful for fast and trustless communication between entities, state channels suffer from a number of limitations when it comes to complex applications.
As a result of a their bi-directional line of communication, state channels must store an exponetially increasing amount of data for each new party needing proof of state. This makes applications among more than three parties egregiously complex and inefficient.
Notoros application states can be shared by an unbounded number of nodes without increasing the computational cost of trustless communication. This is because the application state being proven on the Notoros ledger does not require a separate line of communication, only a filtering mechanism in the form of an application lens ID. Without the need to configure separate channels of communication between each pairing of nodes, Notoros lenses have a much broader applicability to complex use cases with a far lower configuration and computational cost. Notoros lenses are also able to integrate with legacy technologies without a needlessly complex setup.
Notoros Lenses vs. Rollups
Rollups are a cryptographic technique whereby data is bound together and losslessly compressed into a succinct proof that can later be unbound to operate on its contents. In the context of distributed ledgers, rollups allow transactions to be batched together into a single transaction, which reduces the burden on the ledger, increasing its effective throughput for trustless communication. Rollups typically come in two types, optimistic rollups and zero-knowledge rollups, or zk rollups.
Notoros lenses are similar to rollups in that they also reduce the impact on the ledger by reducing the quantity of data to be committed and verified by moving the majority of effort off-chain. Also like rollups, Notoros lenses share the same degree of security and trustlessness as the underlying ledger.
Unlike zk rollups, Notoros application lenses do not require corresponding smart contracts on ledger to interpret their submissions. In other words, lenses are registered in a generalized fashion, rather than “enshrined” specific to their design. This allows for a much more generalized and lightweight form of trustless communication between lenses than can be achieved through traditional rollups. Through this model, it’s much simpler to create inter-lens interoperability than it would be for rollups.
Notoros Lenses vs. zkVMs
Recent advances in blockchain technology have enabled rollups and similar technologies to achieve Turing-completeness on-chain, rather than being constrained to the purposes of token liquidity. This means that off-chain operations of a rollup can translate complex requests into functional outcomes on-chain at a low computational costs. STARKs, SNARKs, and PLONKs are just a few notable technologies in this category.
Notoros lenses are similar to zkVMs in that they reveal zero knowledge about the nature of the computations taking place in the virtual machine and instead reveal only a deterministic proof. Additionally, Notoros lenses achieve secure Turing-completeness off-chain, like zkVMs. Unlike zkVMs, Notoros lenses are not obligated to post a proof at every application state transition unless otherwise mandated by their state-proving network.