# Aki Protocol: Technical Doc

We build Aki Protocol as an open infrastructural **multi-chain knowledge base** that provides oracle services and rewards data layer contributors.

This doc illustrates the mathematical design and technical solutions of Aki Protocol.

## 1. Mathematical Design
### 1.1 Aki Arc 1.0: Ordered Pairs

The model of this stage is a connected rooted graph, where there exists a directed path to every vertex from a distinguished root vertex. The root vertex are often the actionable definitions.

Define Aki Graph Data `G = (V , A)`, where

`V` is the set of vertices of actionable definitions(e.g. Fake Users)
`A` is the set of ordered pairs of vertices, called arcs.

> For example, we have
> `V = {X , Y , Fake User}`
> where `X` and `Y` are user addresses, and `Fake User` is an Aki defined concept
> `A = {(X , Y) , (Fake User , X)}`
> where `X` and `Y` have an association (e.g. friends), and `X` is a `Fake User`.
> Together, these two sets output a connected rooted graph, i.e. Aki Arc 1.0

> You can make a simple query to see who the fake users are on your list, so you avoid airdropping your valuable tokens to them. And you can also check if a certain address is directly associated with Fake Users vertex, or if it is associated with the root vertex within 3-arc range, so that you can make decisions based on the search results.

However, merely a list of actionable definitions are far from enough to portrait the world we are living in. Even the definitions themselves remain ambiguous at this point and will evolve along with the development of web3. Aki then aims to re-organize and maintain the relational data in a multi-dimensional fashion and makes it easy for everybody to retrieve such descriptional definition data from the blockchain.

---

Now, let's take some simple examples of how human language describes things in our everyday life.

"[Puma](https://en.wikipedia.org/wiki/Puma_(genus)) is a genus in the family [Felidae](https://en.wikipedia.org/wiki/Felidae) whose only extant species is the [cougar](https://en.wikipedia.org/wiki/Cougar)" (from [Wikipedia](https://en.wikipedia.org/wiki/Puma_(genus)#:~:text=Puma%20is%20a%20genus%20in,cougar%2Dlike%20cat%20of%20Eurasia's))

 

"In [mathematics](https://en.wikipedia.org/wiki/Mathematics), a [saddle point](https://en.wikipedia.org/wiki/Saddle_point) or minimax point is a [point](https://en.wikipedia.org/wiki/Point_(geometry)) on the [surface](https://en.wikipedia.org/wiki/Surface_(mathematics)) of the [graph of a function](https://en.wikipedia.org/wiki/Graph_of_a_function) where the [slopes](https://en.wikipedia.org/wiki/Slope) (derivatives) in [orthogonal](https://en.wikipedia.org/wiki/Orthogonality) directions are all zero (a [critical point](https://en.wikipedia.org/wiki/Critical_point_(mathematics))), but which is not a [local extremum](https://en.wikipedia.org/wiki/Local_extremum) of the function." (also from [Wikipedia](https://en.wikipedia.org/wiki/Saddle_point))


**We express human thoughts into descriptive language by organizing concepts in an ordered way.**

So, the pattern is as follows:
> A belongs to B, and A is of some characteristics C, D and E, where
> A could be a single element or a smaller set
> B is a larger set than A

### 1.2 Aki Arc 2.0: A Weighted Graph

Aki Library 2.0 is a weighted graph that evaluates the weight of each pair of connected vertices. At this stage, Aki not only tells whether two concepts are associated (discrete), but also how much associated they are (continuous), which should provide better insights in describing the graph and thus modeling based upon the graph.

The key idea is Aki first builds **a coordinate system of higher dimensions**, by evaluating the weight on each edge of pre-defined vertex of notions and concepts; then if putting any new user/notion/concept into this coordinate system, Aki could tell what it is by its relation (coordinates) to the existing vertex.

Let’s take a simple example to illustrate the statement above:

> Suppose we have a graph which represents the relations among a group of four people.
> `V = {a , b , c , d}`
> `A = {(a , b) , (a , c) , (b , a) , (c , d) , (d , a)}`
> Note that the elements `(a , b)` and `(b , a)` in set A are not the same, because set A is ordered.
>
> Now we assign a value to each ordered pair. Let's say,
> `(a,b) = 4; (a,c) = 5; (a,b) = (b,a) = 7; (c,d) = (d,a) = 16`
> The existing vertices `(a , b , c , d)` form a coordinate system
> Then we introduce a new vertex e, such that
> `(e,a) = 4, (e,b) = 5`
> The coordinate system `(a , b , c , d)` we previously built tells some of the characteristics of the new vertex e.

In a weighted graph, we assign a value to each edge. If the edge is not present, then it is assigned infinity or any large value that cannot be the weight of any edge in the graph.

## 2. Data Layer

The architecture and participants of our network:

* **The Data Contributors** (individual users and dApps) contribute their data and decide whether they want to preserve their privacy.
* **The Indexers** collect on-chain raw data from decentralized storages and blockchain networks (e.g. Ethereum, Solana, etc.), and also off-chain sources (e.g. Twitter, Youtube). The indexer then stores the data to a relational database.
* **The Indexers** also aggregate data stored in the relational databases, and transform and store them into graph databases. We might separate this job and give it to another group of participants in the future. Currently, we will keep it simple and straightforward.
* **The Curators** organize the data by signaling what to index.
* **Aki Protocol** define and maintain the concept wallet addresses which serves as the Root Graph
* **The Data Consumers** (individual users and dApps) use Aki’s API and query the data they need.

In a nutshell, the **Data Consumers** pay for the data they consume and the payment is split among all of the Data Network Contributors, including the **Data Contributors**, Indexers, Curators, and Aki Protocol.


## 3. Data Categories
### 3.1 User Data
* Availability: available and privacy-preserving (zkSNARK)
* Owner: individual users
* What is it: user information and their associations with other people (account association), projects (proof of interaction), and defined concepts (user categorization)


---


Scenarios:
* Alice and Bob are both fake users, and you can use this information to deny airdrops
* Bob is a bot that owns NFT, and this bot account may be used as a front for voting with anonymity if you want to create a privacy aware on chain community
* Carol is a bot and a super smart trader. You can do copy trading on top of the trades Carol performs or even front-run them.

### 3.2 Aki Defined Concepts
* Availability: public data, available to everyone
* Owner: Aki
* What is it: millions of concepts as on-chain addresses and made available to the public on Etherscan. These concepts are defined by Aki.
* For example, fake users, bots, gamers, diamond hands, influencers, reliable, etc.
* Associations between these concepts, and associations between concepts and users are made and maintained by Aki Protocol. For example, address 0xabcd is a Fake User.
* The associations between Aki Defined concepts serve as the base layer of the graph we are building, i.e. the root graph, which makes our data richer and more expressive.
* The data volume is huge, therefore it must be efficient.
* Go to ‘1. Mathematical Design section’ and ‘2. Data Network’ section for more illustrations.

### 3.3 Business Accounts

* Availability: public data, available to everyone
* Owner: business
* What is it: business pages that are reported to Aki, such as contracts, multisig, or company addresses, etc.
* These business accounts are treated as special entities. And the control of them is not maintained by Aki, but by their corresponding entities.
* We will allow these accounts to be claimed and maintained by address owners.


Scenarios:
* Contract X is a standard OpenZeppelin NFT contract which has been audited. So it would be safe to interact with for utility contracts for NFTs.
* Contract Y is an audited yield farm. Yield farm routers can check for audit status before routing funds there.
* Contract Z is a yield farm contract that has been flagged with possible rug pull. Yield farm aggregators can route funds away from these dangerous contracts with on chain checks.

## 4. Proof of Association

**Proof of association** is used to prove to a blockchain that something has happened either in web2 or web3

Most actions can be turned into two kinds of statements: 1) Alice interacts with Bob, or 2)Alice is a user of type X.
* For *Alice has interacted with Bob*, we think of them as **storing metadata, or interactions**, and we can look at how Facebook described its social network storage system, as associations between entities.
* For *Alice is a user of type X*, we think of associating Alice with X.

We think interaction data is valuable, small enough in terms of data that we need to store, and suitable to bring over to web 3. These are similar to off-chain rollups, but for general-purpose data.

Then, we categorize human actions into five types of association:

* **Account association**: association between users. Is Alice a follower of Bob?
* **User categorization**: association between a user and Aki defined concepts. Is Alice a bot?
* **Proof of interaction**: association between a user and a business. Has this person done enough work for me to claim an NFT?
* **Contract metadata**: association a project contract and Aki defined concepts. Can I trust this contract so that I can interact with it?
* **Business account categorization**: association between a business/project and Aki defined concepts. Is this address a business account for some organizations? Is this organization a special type of organization (creator, defi etc.)

See ‘3. Data Categories’ for more information.

## 5. Technical Solutions
### 5.1 zkSNARK to describe connections
* Goals: Scalability and privacy
* We compress all the relationships connected to an entity as a zero knowledge SNARK with Merkle Tree.
* We store the snark on chain, and then store the proof in Aki Protocol


### 5.2 EDSCA to secure proofs
* Prevent front-running attack.
* Different from Vitalik's design, more generalized but requires an agent to issue the proof.


### 5.3 Expressing complex graph query through combining nodes in graph

* Alice & Bob both interacted with Aki and Stepn, we can group them into the ‘Degen’ cluster
* Unifying all complex API people program into ‘is Alice associated with X’

### 5.4 Composability
Programmable data for nodes + programmable edges = any graph
Data for nodes
* Store data on IPFS for extra information for nodes
* Will collaborate with a crypto native Key-Value/SQL solution in the long run
* Data for edge in the graph
* Web 2 service providers can provide a URL for callback for verification

## 6. Reference
[1] Merkle, R. C. (1988). "A Digital Signature Based on a Conventional Encryption Function". Advances in Cryptology — CRYPTO '87. Lecture Notes in Computer Science. Vol. 293. pp. 369–378. [doi:10.1007/3-540-48184-2_32.](https://doi.org/10.1007%2F3-540-48184-2_32) [ISBN 978-3-540-18796-7.](https://en.wikipedia.org/wiki/Special:BookSources/978-3-540-18796-7)
[2] [NIST FIPS 186-4, July 2013, pp. 19 and 26](http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf)
[3] https://tornado.cash/Tornado.cash_whitepaper_v1.4.pdf
[4] [5 data breaches: From embarrassing to deadly](https://money.cnn.com/galleries/2010/technology/1012/gallery.5_data_breaches/3.html)
[5] [Improving front running resistance of x*y=k market makers](https://ethresear.ch/t/improving-front-running-resistance-of-x-y-k-market-makers/1281)
[6] [CertiK: Building Fully Trustworthy Smart Contracts and Blockchain Ecosystems](https://crebaco.com/planner/admin/uploads/whitepapers/6260310certik.pdf)
[7] [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html)