State oracles: Unbounding a function from its functionality

1. Introduction
2. Unbounding states from applications
3. State oracles: Unbounding a function from its functionality

In order to achieve maximu flexibility in decentralization, we need states that do not depend on any particular dapp or platform. We need unbounded states. This means that any state can always be processed by any software. In return we get a variety of possible solutions to the situation.

However, we loose some important functionalities with unbounding states from applications. For instance, applications work as controllers that guarantee proper order of states during multi-hop state transitions. Applications also have methods that conduct a transition from one state to another (e.g. business logic in a model).

With state oracles we can manage a transition and keep proper order of unbounded states. State oracles are small programs (“microservices”) that guarantee a proper transition from one state to another (e.g. from a product to its order). Similar to current development patterns (e.g. MVC), some of oracles may manage the change of a view, some can act as controllers and some can conduct transitions that resemble a business logic.

However, we get more variety with state oracles: State oracles are many atomic kinds depending on the particular type of state they manage. We can use this atomicity to combine the state oracles in many kinds of new decentralized services. E.g. state oracles managing physical delivery can be incorporated into e-commerce services.

Another advantage is that state oracles enable to unbind a function from its functionality. For instance, state oracles conducting a state transition of the same type can still be an interface to different underlying technology for storage or consensus. Or from the other side: two state oracles can offer a different view of the same type of state.