Safeguarding secrets is a major challenge facing businesses in a data-driven era. Under ordinary circumstances, however, disclosing secrets appears unavoidable. For example, it would not be easy to get health insurance services without sharing your health data with the insurer or get a loan without divulging your credit score.
ZKPs are probabilistic techniques that verify secrets without sharing or disclosing the underlying secret. For example, ZKPs can prove that a user is healthy on all metrics without revealing the actual health information of such a user to the insurer.
The Analog network utilizes the zero-knowledge succinct non-interactive argument of knowledge (zk-SNARKs). These are non-interactive ZKPs that the network uses to transfer time data between applications without compromising the time data itself. The zk-SNARKs protocol ensures that private information remains hidden from the public view.
On public blockchains such as Bitcoin, the system validates transactions by chaining the sender’s address, recipient’s address, and input/output values on the ledger. Such a network cannot provide robust privacy guarantees because the transactions are recorded on a public ledger, from which much data can be inferred.
The Analog network uses zk-SNARKs to verify that all the conditions for valid transactions have been fulfilled without disclosing any crucial data such as the addresses or values involved. In this case, the sender (prover) constructs a proof to demonstrate that:
On this Page
- The input values in the transaction sum to the output values for each transfer.
- It has the private keys of the input notes, authorizing it to spend given cryptocurrencies.
- The private keys for the input notes have been cryptographically linked to the signature for the whole transaction so that another party cannot alter the transaction.
The recipient (verifier) validates that the following assertions are also correct:
- For each input note, it validates that a revealed commitment exists.
- The note commitments and nullifiers have been computed correctly.
ZKPs across Multiple Chains
Conventional smart contracts on public Blockchains such as Ethereum allow users to create multiple DApps between mutually distrusting parties, e.g., tracking systems for supply chains. However, because all network members can view all the business transactions, companies that want to hide their commercial activities from their rivals have avoided these Blockchains.
The public key/wallet address pseudonymity that users leverage on these Blockchains does not offer much privacy. After all, other parties can still analyze the transaction graph. While permissioned and consortium Blockchains may solve the privacy problem by isolating transactions to a smaller validator set, it comes at the expense of security.
Zerocash was the first-ever Blockchain to solve the privacy problem for Blockchains by introducing zk-SNARKs. However, Zerocash only addresses the original Blockchain’s use: value transfer. In a Zerocash-based transaction, there is a system state that represents account balances without making them public, as is the case with Bitcoin.
Many platforms have since leveraged Zerocash’s zk-SNARKs principles to implement smart contract platforms. However, what the Analog network is addressing is having private continuum smart contract DApps. For example, we can have a smart contract that seamlessly coordinates Uber and Marriot Hotel, where most transactional data remain hidden.
The continuum smart contract also ensures that parties within the ecosystem trust that all the transactions conform to agreed business logic. As a layer-0 protocol, we also want to ensure that such an implementation interoperates between various Blockchains. For example, if the platform for Uber is, say, Ethereum while that of Marriot is Cardano, then the Analog network should seamlessly link them together.
To achieve this, the Analog network extends the zk-SNARKs primitives to allow payments to be used as triggers for other actions in other smart contracts. For example, when a user receives ANLOG tokens on the platform after validating Uber’s time data, the payment triggers Marriott’s smart contract, which allows its staff to prepare a room prior to the tourist’s arrival.
This way, the Analog network uses the ANLOG payment system where the sender (a user on chain A) triggers actions for other services other chains (say chain B). With zk-SNARKs, the recipient node on chain B must precompute privately before the transaction takes place and time data gets appended to the Timechain.
This requires that users specify the smart contract in other chains about the time data created in the transaction. Consequently, both networks must allow their smart contracts to communicate seamlessly. In Analog’s case, the Timegraph API is sufficient to provide such an infrastructure.
