-
Notifications
You must be signed in to change notification settings - Fork 35
Ion Design
WIP
Ion is designed to provide a simple library, in the form of interfaces, that can be use to build cross-system interacting applications. The aim of Ion is two-fold:
-
Generalise interoperability. Generalised interoperability is the ability to connect two systems and allow them to interact in a meaningful manner. Facilitating such a connection is the design goal of Ion and achieving it without being opinionated on the target systems or the target use cases is the core of the Ion protocol. We abstract away the specifics and focus on the fundamental mechanisms via which a common language can be built.
-
Simplify the development of cross-chain applications. As a generalised interoperability protocol we hide the complexity of verifiably passing state cross-chain behind a set of generic interfaces. Separating the development of use cases from the core interoperability protocol should allow greater innovation of applications built. We see the primary motivation for Ion being the meaningful connection of separate siloed functional systems to enable creation of more value and utility in a distributed ecosystem. Thus easing the development process of these applications is an important goal of Ion.
The Ion protocol describes an architecture that separates the core of interoperability into two discrete layers. The implementation of this architecture in each instance of a required bilateral system interaction defines the interface that can be used to develop applications across the two systems.
Connecting disparate systems is hard. Doing so requires deep understanding of each network, the topology, motivations and purpose, and more depending on the networks themselves. Only until an understanding of each network intended to interoperate is gained can you begin to bridge them. Many solutions simplify this bridge through greater assumptions or constraints to the mechanism. We find these too restrictive and do not facilitate a generalised interoperability that can flexibly support a future interwoven mesh of systems that should be able to interact freely. Thus understanding each system deeply and creating deep bridges between them is the only way we see a truly interconnected future.
The complexities behind the individual system properties is what inhibits building applications or use-cases or innovating across different networks. In order to progress to a state where the meaningful interactions between chains is the focus we need to obfuscate the difficulties in bridging them. The Ion protocol aims to describe an architecture for a simple interface that encapsulates all the details and implication of connecting different systems to allow applications to be built upon.
Our two protocol layers:
- State Persistence
- State Validation
Disparate systems lie totally separate. In order to connect them there must be transmission of data from one to another. The state persistence layer handles the storage of data from one system on another.
As both systems are independent their data is also written in differing formats/encoding. Stored state must also be intelligible by the destination system and thus translation of source system data to destination system data formats is essential.
Crucially the data stored is also the data that will be leveraged by applications on the system to interact with the state from another. Thus this also becomes the interface through which application developers will access external state meaning the designing of this interface must be as minimal as possible.
As state transmission can be done arbitrarily from one system to another, there are no assumptions on how this data is sourced and submitted due to the abstraction of the protocol. Thus the ability to validate the state being submitted is paramount in ensuring the secure, trustless interaction between systems.
The validation layer aims to replicate the verification of the result of a system's state transition finality mechanism. For distributed systems this will be their consensus mechanism. For other systems this could be an authority's signature. In any case, there must be a way to validate that the incoming data is correct and was truly a valid state transition on the source system.
This layer ensures the validity and correctness of state, maintaining a reliable data source that can be used by the cross system applications.
Importantly though, this layer is the ultimate teller of finality. Once data leaves this layer to be stored by the persistence layer it is usable by applications. This means that this layer should not propagate data that has not been deemed as final which can be problematic for probabilistic consensus mechanisms. This process is simpler for deterministic finality mechanisms. Note that the definition of finality can vary wildly depending on the networks being connected and requires deep understanding of the systems involved. The combination of these layers means that we can achieve trustless interoperability without assumptions on use case or network properties.
State will primarily be passed to this layer, be checked for validity and then passed on to the persistence layer. To navigate this layer as a state propagator you must understand how the validation layer accepts data and validates it in order to transmit data correctly between systems.
Depending on the systems across which your application will bridge, you will require a specific interface. In this Wiki, we aim to list the specifications of all the implemented Ion interfaces across the systems that are supported. Using these specifications you can use them to access state as part of your application function.
Each interface will differ depending on how state is stored and accessed which will change how your application will leverage this.
Understand first how you will use the state from another system, and then understand how the target system that you are building your application for will use it.
Clearmatics :D