Design and Implementation

Polkacipher Documentation
Search…
Polkacipher Documentation
Introduction
Token
Target Audience
Social Media
Design and Implementation
PolkaCipher's primary function is to bridge the divide between decentralized applications and real-world data, and to do so through the use of an economic incentive model. 
PolkaCipher will be developed on a private cross-chain bridge and then migrated to Polkadot's cross-chain Substrate architecture in order to continuously improve the functions of the PolkaCipher oracle. PolkaCipher's overall design will be centred on three pillars: data interaction processes, system architecture, and interface integration.
​
DATA INTEGRATION 
When Decentralized applications (dapps) use the PolkaCipher in the data layer to facilitate the interaction of smart contracts with off-chain data, the following flows occur:
1.
The smart contract communicates with the proxy contract on the PolkaCipher chain to send data query requests.
2.
The proxy contract dispatches trigger events accompanied by query parameters
3.
PolkaCipher's chain enables the underlying component to continuously monitor the blockchain's defined events.
4.
PolkaCipher queries a set of off-chain nodes via rules, through web API or make web page requests, performs calculations, or executes configured scripts.
5.
Through the threshold signature algorithm, the off-chain nodes achieve "in-group" consensus and communicate the results to PolkaCipher's on-chain system. The group member identifiers and the performance of service quality evaluation parameters (responsiveness/accuracy, etc.) will be tracked and analyzed via the apps on-chain.
6.
By invoking the user contract's callback function, the PolkaCipher proxy contract notifies the smart contract that the result is ready.
​
SYSTEM ARCHITECTURE
As the entire interaction process is divided into on-chain contracts and off-chain nodes to complete cooperation, PolkaCipher is divided into two components: on-chain and off-chain. Each component contains the following core components:
1.
ON-CHAIN
The on-chain portion's primary components are the deployment of PolkaCipher-related smart contracts on the Polkadot substrate layer. The primary functions include request and response processing, result verification, node registration and mortgage, statistical monitoring, and payment processing. 
a) Proxy Contract 
The on-chain proxy contract provided by Polkacipher acts as a standard on-chain interface for smart contracts. Once the response is complete, it will be sent asynchronously to the contract that invoked the oracle.
b) Monitoring
The monitoring system is used to save off-chain records of PolkaCipher node indicators and network statistics, such as the total number of nodes, the number of times the node group is selected, and the uptime, among other things. Details on rewards, weight percentages, and callback and unprocessed query request delays will be monitored as well by the system. The node's service quality score, which includes the report result's correct rate and response rate are important to ensure monitoring of off-chain records are clean, sustainable and ready to be used by the network. The monitoring system will display the PolkaCipher network's status in real-time.
c) Registration Procedures 
To join the network, PolkaCipher nodes must mortgage and lock a predetermined amount of tokens as margin, as well as register their margin and payment addresses in the registration contract. The deposit can strengthen the system's defenses and enhance its security. Nodes will earn " mining " rewards and service fees by obtaining centralized results quickly and correctly. They will be fined if they do not meet the response time.
d) Payment System for Data Request 
These funds will be held initially in the payment contract and node operators will be able to monitor and withdraw their earnings.
​
      2. OFF-CHAIN
PolkaCipher's off-chain component is managed by independent third-party operators who implement an L2 distributed peer-to-peer network composed of core protocol clients. PolkaCipher's off-chain nodes agree on the same API calls via a Byzantine protocol. Each round of the agreement uses a resource (VRF random seed) that no one can easily monopolize to elect a random leader. 
As long as the majority of participants are trustworthy and honest, the PolkaCipher system will achieve final, irreversible consensus. The protocol client contains a number of critical components, including event monitoring and chain adapters, node consensus components embedded in the chain, and request/computing task processing modules.
​
a) Node registration and Verification group selection
Nodes that are newly registered initially enter the pending state. Once the pending pool contains a sufficient number of pending nodes and waits a sufficient amount of time, they will be randomly selected to form the current request's threshold group. This section makes use of the VRF algorithm to generate random verification nodes. VRF is a function that generates random numbers, and this function is verifiable, meaning that when the same private key signs the same information, only one legal signature can be verified, in contrast to conventional asymmetric encryption algorithms.
Operation process of VRF is as follows:
1.
A pair of keys, public[PUBLICKEY] and private[PRIVATEKEY], are generated by the authenticator. 
2.
The authenticator generates a random value [RESULT], where [RESULT] is calculated as[RESULT=VRFHASH(PRIVATEKEY,INFORMATION)]
3.
The authenticator generates a random proof [PROOF], where [PROOF] is calculated as [PROOF=VRFHASH(PRIVATEKEY,INFORMATION)]
4.
The authenticator presents the validator with the random result and random proof. The validator must verify that [RESULT] and [PROOF] are identical.
5.
The validator provides the authenticator with the [PUBLICKEY] and [INFORMATION], and the validator determines whether the result is [1]. If [1], the verification is successful. If [0], then entire steps are repeated.
The seed will be used by the random algorithm. For instance, in encrypted PolkaCipher's lottery, the seed must be selected and disclosed randomly. This seed must be known to all participating nodes and is uncontrollable by adversaries. The seed generated in PolkaCipher round's "R" is determined by the seed generated in round "R-1" via VRF. Each proposed block includes this seed and the corresponding VRF proof. Once the nodes agree on the block for round "R-1", when round "R" begins, everyone knows the current round's pseudo-random seed "R". The initial participants calculate the initial seed value of 0 by combining multiple nodes to generate an absolutely unpredictable random seed. This way, the "destroyer" cannot predict or manipulate the seed.
​
b) Consensus Formation
Verifiers (including sub-verifiers) are aware that they were chosen in secret, but they only have credentials to demonstrate their verifier qualifications. They use their own private key to sign the seed and enter the hash function to obtain its their own credentials for each selected node. The hash function's nature indicates that the credential is a random string of 256 bytes in length, that node's credentials will differ, and that the distribution of credential strings is uniform. Similarly, a batch of candidate leader nodes is selected, and their credentials are arranged in alphabetical order. The leader node is chosen at random from a set of candidate leader nodes.
The verification node and the leader node collaborate on the Byzantine agreement calculation. At each stage and step of byzantine agreement, the node determines independently and in a non-interactive manner whether it is selected in the current step's committee. Byzantine consensus is a two-stage voting process. The verification node performs a hierarchical consensus on the candidate results received in the first stage and selects the candidate with the highest verification consensus. The second stage involves performing binary Byzantine judgement on the candidate results selected in the first stage. Consensus-based on Byzantine agreement must ensure that the number of honest nodes participating in the consensus is greater than two-third of the participation. 
If the randomly chosen set does not satisfy this condition, subsequent random elections are required. Consensus can be reached as long as the number of honest nodes participating in the consensus is greater than two-third of the participation. To expedite result confirmation, the verification nodes for each step of the byzantine agreement consensus are designated in parallel or randomly selected.
​
c) Reward/Penalties Distribution
Selected nodes are decentralized due to the introduction of the VRF algorithm. Thus, over time, the probability of each honest node being chosen and accepted as a submitter is comparable. The fee paid to the group that processes and verifies oracle data requests will be locked into the on-chain reward distribution contract, and node operators will have the ability to withdraw the reward fee assigned to them at any time. 
A malicious node may refuse to return a result to an on-chain contract or may return the incorrect result, but due to the introduction of the Byzantine Agreement, malicious nodes will fail on-chain verification, will be marked as an unqualified node above a certain threshold, and will be fined a certain margin, with a portion of the margin burned. In this case, the node is removed from the list of verification node candidates unless the fined deposit is repaid in order for normal operation to resume. 
Additionally, to avoid node laziness and to motivate participating nodes to provide higher-quality, low-latency network resources. If a time limit is exceeded and no results are returned for the current working group, the credibility of the nodes in the group as a whole is impacted. If a single node exceeds a certain threshold, it will also be marked as unqualified and subject to the economic penalties..
​
d) Synchronous Processing
For several requests, the node group selection and processing verification are performed concurrently, allowing the processing speed to be parallelized and the TPS to be expanded. Thus, as the number of nodes increases, the TPS improves, and as the actual use of TPS increases, the value of the entire system increases, forming a positive feedback loop.
​
INTERFACE INTEGRATION
Users who wish to query external data may do so via PolkaCipher's query system. The system interface compiles data from all currently valid data providers. And only when more than two-thirds of the system's effective data providers provide such data are the values valid. This enables the system to tolerate up to one-third of malicious data providers.
​
Products
Token
Last modified 6mo ago
Copy link