Competitive Edges
Last updated
Last updated
Data privacy is always high on the agenda when it comes to the Crypto community. Since 2015, different projects have been working to improve that in three directions:
Anonymous currency, represented by Zcash, Monero, etc. They mainly meet the need of anonymous payment.
The privacy projects for crypto payment and transaction, represented by Tornado, zkSync, Starkware, Raze Network, etc. They mainly meet the privacy needs of smart contracts.
Data-based privacy computing projects, represented by Ruby Network, Oasis, and PlatON. They mainly meet the privacy computing needs of the data transaction market.
On the track of data privacy computing, Ruby’s main competitors are Oasis, PlatON, Phala, Enigma, ARPA, etc. Ruby’s main differentiated advantage lies in proposing a privacy computing solution based on user data attributes for Functional Encryption computing. Users can have fine- grained control of their data so that data buyers can obtain the computing results while the user’s specific data content remains private.
Project Name
Encryption Tech
Value Position
Whether Fine-Grained
Built Data Marketplace
Owner
Centric
Functional Encryption
Layer 1 middleware，focusing on access control with privacy
Yes
Yes
Yes
Trusted Execution Environment
Layer 1 public chain for encryption Apps
No
No
No
The Mix of Multiparty Computation, Zero-Knowledge Proof, Verifiable Computing, Secret Sharing, Homomorphic Encryption
Layer 1 public chain for encryption Apps
No
No
No
Trusted Execution Environment
Layer 1 public chain for encryption Apps
No
No
No
Secret Sharing and Multiparty Computation
Layer 1 public chain for encryption Apps
NO
NO
No
Multiparty Computation
Layer 1 public chain for encryption Apps
No
No
No
The aforementioned projects are mostly based on cryptographic solutions. There also exist several projects, such as Mintlayer [Mintlayer] or lit protocol [litprotocol], that try to implement access control based on non-cryptographic solutions such as access control list (ACL). However, there are mainly two problems with ACL-based solutions:
First, it does not provide confidentiality protection on the access control policy. On the other hand, functional encryption not only can enforce confidentiality requirements on the underlying message but also guarantee the secrecy of the access control policy.
It is also hard to extend the access control policy to the real world beyond blockchain platforms given most of these ACLs can only be implemented as smart contracts that run on the smart contract platforms. In contrast, a functional-encryption-based solution can be adjusted to the access control policy that is defined on terms outside of the blockchain world. For instance, a user of TradFi can obtain secret keys corresponding to a certain KYC information from a TradFi institution to authenticate his/her identity to a DeFi app. In other words, functional encryption is a perfect tool to build a private data management middle-layer bridging the Web 2.0 world and Web 3.0.
It is relatively hard to upgrade smart contracts corresponding to the ACL. A smart contract is a program executed in a highly decentralized environment. Any time a smart contract code is upgraded, it means all the participants in the system have to be aware of the upgrade and execute the necessary upgrade simultaneously, which could be a challenging task in a decentralized system. On the other hand, the revocation mechanism of attribute-based encryption or functional encryption can be achieved by adding an additional time dimension to the original attribute universe. All the keys will be naturally revoked once a specific time period passes.