Skip to content

Latest commit

 

History

History
32 lines (17 loc) · 4.08 KB

3.5.2-trusted-off-chain-computing.md

File metadata and controls

32 lines (17 loc) · 4.08 KB

3.5.2 Trusted Off-Chain Computing

Digital Asset Exchanges

The majority of digital asset transactions currently take place through centralized digital asset exchanges. While they are fast and cost-efficient, the trader risks losing all deposited tokens in the case of hacking or fraud. Decentralized exchanges (DEXs) have seen rapid growth recently, which enable users to trade without a centralized intermediary and retain custody of their digital assets. However, these benefits come at the cost of high fees at times of peak demand, and latency of at least a few seconds.

Centralized exchanges are fast and cost-efficient but vulnerable to security breaches. Ultimately, the trader needs to trust the exchange owner. Decentralized exchanges tend to lack scalability, which leads to volatile costs and slower transaction times. They suffer from front-running because bids are transparent and can be arbitrarily ordered by a validator.

Integritee enables a hybrid exchange design that combines the speed of a centralized exchange with the trust and control of a DEX. All balances are managed in a trusted execution environment. This prevents any third-party from accessing a trader’s digital assets. The order matching engine is kept off-chain, which reduces the risk of frontrunning by other market participants.

CDN Subscriptions

Integritee could be used to restrict (narrow- or broadband) content delivery to paying users. Examples could be blogs, articles, video streaming, video-on-demand or music streaming.

Subscriptions are managed on-chain, as are payments (can be flat subscription fees or pay-per-use). A integritee-worker holds the content-encryption key pair (CEK). Only the worker enclave(s) can read this RSA private key. No consumers or publishers nor operators have access. Publishers commit their content (encrypted with the CEK (RSA+AES)) to IPFS and register the content on-chain, providing the IPFS url. Consumers request content from the integritee-worker over a TLS channel (can be https, wss, json-rpc, REST), which authenticates the consumer and looks up subscription status on-chain, fetches the requested content from IPFS, decrypts the content, and sends the content to the consumer over the previously established TLS channel.

Because the private CEK is known to all worker enclaves and never needs to be known to publishers or subscribers we do not need to trans-encrypt content. It doesn't matter at what time a consumer subscribes. The worker can deliver all prior content to the subscriber. The subscription metadata can include restrictions on archive access.

Pay per use bears the risks of leaking private information. We'd suggest maintaining subscription balances within the worker enclave, not onchain. This way, the public doesn't learn detailed usage patterns.

NFT-based access management

Our technology could allow inheritance schemes like passing all your passwords to your children in the case of death. Instead of a notary confirming your death, you could use a “dead man switch”, a regular confirmation every few weeks that you are still alive.

Storing encrypted shards of the shamir secret sharing scheme inside multiple Intel SGX enclaves operated by different service providers and combining multiparty-computation (MPC) and trusted execution environments (TEE) allows to safely authorize data retrieval and transmission only to the NFT holders, thereby mitigating the risk of leakage of private data, even if a few SGX enclaves should be compromised.

Such storage is much more secure than Dropbox or iCloud, where the administrators of these platforms, or hackers who achieve privilege elevation, have full access to all data stored on their machines. Such architecture also allows the aforementioned transmission of data access in the shape of an NFT from one user to another.

Various other use cases

Trusted off-chain workers provide similar advantages to the sidechains, without the high speed and the low latency, which means for use cases that don't require high performance and transaction throughput, a Trusted off-chain worker might be a less complex option.
\