Technical Whitepaper Update
Expanding Enterprise Adoption. Protecting Users’ Data Privacy.
Hello Airblocers! We’re so excited to release Version 2.0 of Airbloc’s technical whitepaper.
Lately, we have been working on the alpha version implementations ever since we released the first version of the whitepaper. During the time, we’ve made a lot of updates to the technical specifications of Airbloc Protocol to build a more feasible product that can eventually be adopted.
4 major motivations underpin this new technical update:
- Expanding Enterprise Adoption via Second Party Data Exchange
- Real-Time Data Query and Segmentation via Data Relayers
- Improving Scalability via Plasma Sidechain
- Protecting Users’ Data Privacy via Privacy Shield
Expanding Enterprise Adoption: Second-Party and Segment-Centric Data Exchange
We are expanding Airbloc Protocol to include not just third-party data, but second-party data as well to allow data trading between enterprises.
Previously in our previous version of the technical paper, we focused mainly on third-party data exchange between data owners and data consumers. Over the past few months, we have engaged in deep industry consultations with enterprises and we are convinced that there is indeed demand for second-party data exchange services.
The importance of second-party data is that there are companies that want to create synergy by exchanging with other enterprise data systems without revealing their data to the public. In the case of second-party data, we foresee that there will be high demand for such data exchange by large companies relying on Airbloc.
Airbloc Protocol now supports direct data exchange and segment-centric data exchange. Enterprises can trade data directly with other enterprises without having to trade the data on the public market, and they can also trade user segments— which only contains identity data of the users (e.g. Advertising ID of the 500 users who have installed application A)— instead of trading the full data.
Meanwhile, users can still track which of their data is traded transparently and the corresponding incentives. We believe that this move can expand the adoption of Airbloc significantly by enterprises.
Real-Time Data Query and Segmentation: Data Relayer
Originally, Airbloc Protocol only supported the purchase of static data sets created by data providers on the data marketplace. Now, we’re introducing Data Relayers to support a more dynamic form of data exchange which is user-centric and real-time.
Data Relayer is a node which supports data discovery by providing real-time data query services and segmentation. Data Relayer requires anonymized data from data providers to construct a queryable user profile.
A data consumer can query specific data filters (e.g. Users who are over age 20 and have been installed A application) to data relayers, and data relayers will return data IDs matched with the query in real-time.
Improving Scalability: Plasma Sidechain
Previously, we planned to use a side chain for computationally intensive tasks in Airbloc. Following this new technical paper update, we will be using Plasma, a layer-2 scaling solution for Ethereum.
Ethereum is currently not efficient to handle large amounts of requests due to the low transaction throughput and operational costs due to high transaction fees.
As such, we are developing our own implementation of Plasma sidechain. The plasma sidechain will be used for running our main business logic for data registration and data exchange in Airbloc Protocol.
We’re currently building our own sidechain called Aero. You can see the source code on Github.
Sidechain (Child chain) framework by Airbloc, with a 💙from Plasma - airbloc/aero
Protecting Users’ Data Privacy: Privacy Shield
Since Airbloc Protocol deals with personal data, the highest priority is placed in protecting data owners’ privacy because we consider privacy breaches as data asset theft.
To hide identity-related information about you on a public blockchain completely, we’re now introducing Anonymized ID (ANID) concept— an anonymous ID that prevents tracking of the user from unwanted third parties with malicious intent.
Here’s a simple explaination to how Anonymized ID (ANID) work:
- De-Identification: Users’ identity data is hashed upon data collection. This process prevents identity data (e.g. Email, Phone Number, SSN) from being used for malicious purposes (e.g. Spam Mails) outside of tracking and identification.
- Identity Masking: When anonymized data of the user is traded or referenced on the public blockchain (e.g. Data Exchange Log), Airbloc generates an Anonymized ID for the user. The ANID, rather than the actual user’s identity data is used during intermediate data trading processes by data relayers or data processors to prevent backtracking from unwarranted parties, thus protecting the user’s privacy.
- Private Identity Matching: The ANID of the user needs to be converted back to the real user’s identifier after the ANID is used. To prevent the user’s ID from being exposed to the public, Airbloc introduced Private Identity Matching. Powered by Zero-Knowledge Proofs.
Aside from the above mentioned points, there are also other updates such as data pipeline revamp, GDPR compliance, and redefined roles for stakeholders in Airbloc’s ecosystem.
New concepts such as Contribution Graph, Data Availability Challenge, Decentralized Data Warehouse and Re-Encryption Proxy have also been introduced. You can check the rest of the details in our new technical whitepaper.
You can check the new English technical whitepaper at:
Alternatively, you can visit our website at airbloc.org!