Silent Data [Oracle] vs Chainlink (Part 2 of 2)

This forms part of a two-part blog, click here to read Part 1!

Handling private data will be the focus of this comparison given it is where the 2 tools overlap. The handling of users’ API keys is the primary challenge facing blockchain oracles when calling sensitive data. API keys cannot be published on-chain as data on chain is public. Meanwhile, trusting the API key to a blockchain oracle operator poses a serious security risk if the operator is hacked or acts maliciously.

As such, blockchain oracles must have appropriate security protocols. The approach of Chainlink Functions and Silent Data [Oracle] is primarily differentiated by their respective architecture and secrets management (handling of API keys).

Consult What is a Blockchain Oracle? for more explanation regarding these risks.

Architecture: Chainlink Functions vs Silent Data [Oracle]

With Chainlink Functions, user’s requests are carried out by a decentralised group of nodes. Meanwhile, Silent Data [Oracle] jobs are run within privacy-preserving hardware.

Chainlink Functions

source: Chainlink Functions Documentation

Chainlink Functions operates as a Decentralised Oracle Network (DON) and performs off-chain reporting (OCR). A user makes a request and multiple oracle operators within the Chainlink network perform the request, running the same code and consolidating their results in an off-chain report. Once the report is completed it is then posted on-chain.

Silent Data [Oracle]

The communication between users and Silent Data [Oracle] is handled within Intel hardware secure enclaves. Intel provides guarantees that Silent Data [Oracle] cannot access the data or API keys held within the enclaves.

An enclave is an encrypted region of memory, available on some Intel chips, analogous to a black box into which Silent Data [Oracle] *cannot see. The attestation created by Intel allows users to verify the results of the job and prove how it was performed without exposing sensitive data to the blockchain network. A Silent Data [Oracle] job is the equivalent of a Chainlink Functions user ‘request’.

*When enclaves are created, the CPU prevents any non-enclave access to the memory region regardless of privilege level. This means even Silent Data [Oracle] sysadmins cannot access the data processed in an SGX enclave.

See the Intel x Applied Blockchain white paper for more details regarding this confidential computing technology.

Secrets Management: Chainlink Functions vs Silent Data [Oracle]

Chainlink Functions

Chainlink Functions uses threshold encryption, whereby a so-called master secret key (MSK) is used to decrypt the user’s API key before usage and any other private credentials. This MSK is partitioned between the oracle nodes in the Chainlink DON. In order to perform a user’s request every node requires the participation of other DON nodes to decrypt the MSK. The MSK can then in turn be used to decrypt the API key or other user credentials.

The API key is encrypted at storage but decrypted at runtime so each node can call the API. This means at a given point in time all oracle nodes hold the API key and can keep a copy, and by extension so could some malware installed on a node.

Silent Data [Oracle]

When a user is editing a job configuration the secrets are only in the temporary state of the frontend application and would be lost on a refresh. When a draft is saved or a job is published the secrets are encrypted using a symmetric key derived from an ephemeral private key generated in the frontend code and the persistent public key of the enclave. The encryption process includes a hash of the job configuration as the Additional Authenticated Data (AAD) so that the secrets can only be decrypted and used for that job by the enclave. The encrypted secrets and corresponding ephemeral frontend public key are stored in the database.

This means Silent Data [Oracle] servers cannot access user secrets even at runtime, it also prevents [Oracle] developers and system administrators from editing a user defined job specification as a modified job will break the decryption process.

Storage

Chainlink Functions

User secrets can be stored in 2 ways. Either hosted by the DON directly, or self-hosted by the developer providing the DON with access via a HTTP(S) endpoint, with the data encrypted with the DON public key. With either method it is important to note that the secrets will be decrypted and accessible by the oracle nodes when making a request.

Silent Data [Oracle]

Given secrets never leave the enclave decrypted, Silent Data [Oracle] cannot access and decrypt users’ secrets nor can any potential hacker, thus protecting the sensitive information and protected by the secrets.

Want to know how all this is possible? Check out our intro to Silent Data.

Funding: Chainlink Functions vs Silent Data

Chainlink Functions

Chainlink Functions’ requests are funded using their native token, LINK. A user’s subscription is billed once their request is fulfilled. LINK tokens fluctuate in value based on market demand and speculation.

Silent Data [Oracle]

Silent Data [Oracle] jobs are funded by USDC which is redeemable 1:1 for US dollars. Jobs are funded on chain and USDC will be withdrawn on each trigger.

These are the core differentiators in the Chainlink Functions and Silent Data [Oracle] offering when calling private data on-chain. For more information consult their respective documentations.

Check out our blog page to discover various Silent Data [Oracle] use cases
Learn how Silent Data [Oracle] calls sensitive data without reading your private API keys!

‍