Technical Architecture

Kylin’s vision is to solve the Web3 Data Gap is a configurable data framework that allows for

• Democratically creating and managing oracle system entities

• Service level agreement (SLA) between the providers and consumers of data

• Multi-level oracle data agglomeration allowing to balance security, authenticity, persistency, and speed

• Democratization of the data management process

• Transparency and traceability of data provenance

• Free data market

• A voting system allows for assessing and strengthening the validity of a vote.

Solutions

To actualize the envisioned future of bridging the Web3 chasm, the Kylin network is building a number of components that make up the DeData infrastructure. This includes

• The Kylin Oracle Pallet & API

• Dynamically & Statically Sized Oracles

• Democracy Pallet

• An Enhanced Voting System

• Dynamic NFTs & DeData Marketplace.

• The Kylin Oracle Pallet & API

The Kylin Oracle nodes are collators to the PCHU parachain, which is validated by the relay chain to the Polkadot network. Our API allows us to save to a Postgres database the results of calls to built-in or custom endpoints.

The aim of Kylin Network is to create a configurable Oracle to give users a sense of assurance and responsibility to the consumer about selected choices. The creators of a data feed of the oracle can specify what their oracles are and which algorithms they are using so the consumers of this feed can freely choose if they want to consume the data with the full knowledge of their choice. Systemizing knowledge and dividing oracles into modules can enhance security and manage user expectancies.

Oracle System Manifest

Given that the Kylin Network will be a Multi-level Oracle Data agglomeration, a procedure is required to keep track of ownership, source of data, and other pertinent information. Keeping track of who owns the data, where the data comes from, when it was collected, and which algorithm was used to treat it can be recorded in this manifest that can be published with each block. This implies that the data sources are known before the feed is published in the primary oracle.

Service level agreement (SLA) This contract is necessary to ensure that a data consumer gets what was ordered. A service-level agreement (SLA) is a contract between a service provider and its customers that documents what services the provider will furnish and defines the service standards the provider is obligated to meet. More specifically, in the context of the Kylin configurable oracle system, it is an agreement that the user accepts the configuration the provider selected when creating the data feed. This agreement can be renewed with each block and can take the form of a Ricardian contract or JSON object. The user can opt-out of this contract by subscribing to a different feed. A Ricardian contract is a digital contract that functions as a legally binding agreement between two parties based on agreed-upon terms and conditions. The contract is cryptographically signed and verified using the blockchain but is readable by both people and machines.

Adherence to standards

Although this effort is in the early stages, efforts from a community of oracle builders have been made to promote best practices, collaboration, and interoperability by putting forward standards through EIP-2362. https://github.com/adoracles/EIPs/blob/851003d89e255492aa6c3cabb3dc8520f2e71d45/EIPS/eip-2362.md

Best practices will be found here:

https://github.com/adoracles/OracleBestPractices

And will consist of:

• Failure cases

• API/Data specs

• Dispute considerations

• Admin Control

• Aggregator architecture

• Repository of know oracle hacks

• Liveness

• Usage

• Audits

Aggregation and validation of oracle results

• Input Data types As mentioned in section 3.1, the system should provide for data types other than numerical. The basic needs for running the iteration of this paper are:

- Numerical

The input/output type specified in EIP-2362 is int256 • Small string Initially 256 Bytes • Light bytecode Initially 256 Bytes Data is kept small in size for the chain buffer for storage and computation considerations. Limitations may be disregarded for the buffers residing on the OCW. The data must conform to the format specified in the SLA.

• Output Data types EIP-2362 contains specifications for returning numerical values as: 1 returns ( int256 value , uint256 timestamp , uint256 statusCode );

Since the substrate is coded in rust, this function will now be in the case of a string: 1 fn returns ( value : String , timestamp : u32 , statusCode : u32 ){}

In the case of an integer value: 1 fn returns ( value : u32 , timestamp : u32 , statusCode : u32 ){}

In the case of bytecode: 1 use bytes ::{ BytesMut , BufMut }; 2 fn returns ( value : bytes , timestamp : u32 , statusCode : u32 ){}