Competitive Edges

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:

1. Anonymous currency, represented by Zcash, Monero, etc. They mainly meet the need of anonymous payment.

2. 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.

3. 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
Ruby	Functional Encryption	Layer 1 middleware，focusing on access control with privacy	Yes	Yes	Yes
Oasis	Trusted Execution Environment	Layer 1 public chain for encryption Apps	No	No	No
PlatON	The Mix of Multiparty Computation, Zero-Knowledge Proof, Verifiable Computing, Secret Sharing, Homomorphic Encryption	Layer 1 public chain for encryption Apps	No	No	No
Phala	Trusted Execution Environment	Layer 1 public chain for encryption Apps	No	No	No
Enigma	Secret Sharing and Multiparty Computation	Layer 1 public chain for encryption Apps	NO	NO	No
ARPA	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.