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 ){}
Last updated
