Architecting an Application Lens
Please note: These docs are still in beta. In the near future there will be a variety of significant updates including the release of the Typescript Client Library, additional tutorials, and expansion of the terms wiki. You can keep up to date on all the latest changes by subscribing to the Notoros Newsletter or by checking out the News section on the Notoros Beta Dashboard. If you have specific questions or feedback regarding these docs, please reach out to info@notoros.io
It’s important to identify the purpose of your lens prior to launching it on the Notoros platform. To be successful, one must first recognize that all lenses are virtual machines, and a virtual machine is simply a series of opcodes that when given a set of expressions returns a predictable result. In other words, all virtual machines transition their state determistically as a direct consequence of the inputs fed into them. So for any given virtual machine, as long as the inputs are known, the outputs are known as well.
From an architecture perspective, developers should structure their code around the conditions in which they want to transition the state of their application. In Notoros lenses, a state transition is performed via the execute function. The execute function listens to resources throughout the Notoros ledger and determines how its off-chain application’s state should be updated. Updates to the application state are not requried to write to the ledger at all, but may do so by sending a new transaction.
Decentralizing State
Most distributed ledger technologies create a rigid relationship between the state of the application and the underlying immutable ledger. In Notoros, these layers can, but are not required to, have such a rigid binding. The choice as to what binds the application state to the ledger state is determined by the intentions of the application lens developer.
State-proving networks perform all of the operations necessary to compute an application state off-chain. These networks can be maintained by one or many nodes and can utilize whatever consensus mechanism with whatever degree of decentralization they see fit. The consensus of a state-proving network is generally indepedent from the consensus that maintains the Notoros ledger.
If a developer wants to make an application state rigidly bound to the state of the ledger, as is traditionally the case in blockchains, they must create a ruleset within the state-proving network that obligates its nodes to periodically submit state proofs to the ledger. To ensure continuity, the state-proving network would likely require the proofs it submits to be a function of previously submitted proofs read from the ledger.
The best practices for implementing these state-proving networks is still an area of research.