Background on Original Rakis

Take ChatGPT as a point of reference. It is a one giant Large Language Model (LLM), run by OpenAI on their powerful server. ChatGPT is close-sourced and centralized.

Rakis follows an open-sourced and decentralized approach:

• Open-sourced: there are many open-sourced LLMs, each is significantly smaller than ChatGPT LLMs, but they are sufficient for normal usage. Each such small open-sourced LLM can be run on a PC.
• Decentralized: Rakis allows a browser (also called “node”) to download a small open-sourced LLM and run it locally on the PC. When there are many such browsers/nodes connected in a peer-to-peer style, then we have a Rakis network.

In Rakis network, any user can send in a prompt. That prompt is broadcasted to a number of nodes. Each node receiving that prompt will come up with an answer using the locally run small open-sourced LLM. Those nodes then go through a consensus to arrive at a final answer.

AIE-DeBIN

1. Additional features:

   Rakis deals with locally-run small LLMs.

   We can extend that story (bluffing for now, no implementation yet) to have additional features:

   • If a node does not want to run a small LLM, and the owner of that node has ChatGPT subscription (i.e., high-quality close-sourced LLM), the node can forward the prompt it received from some requester in AIE-DeBIN to the ChatGPT server, get the result from ChatGPT server and return to the requester.
   • We can extend the same concept to Large Vision Model (LVM) for image generation.
   • Peel-off the consensus component of the original rakis, maybe turning it to first-serve-first-rewarded, some kind of gig-economy.

   One difference between ours and other DePIN out there is that we don’t aim for any pooling of hardware to make one super-computer. Instead, each node independently comes up with an answer by itself (either by running a local AI engine, or forward the prompt to close-sourced engine under its subscription), and one answer among the nodes will be picked and returned to the requester

2. Integrating with AIE Chain

   We don’t do brower extension for now, but instead staying with a webpage accessible directly on a browser (i.e., required a browser tab opened).

   The user is required to login using telegram/twitter/gmail… just like Genesis and RizzAI. After login, the browser is tied up with a wallet address on AIE Chain.

   For every prompt that browser works on, it will receive some DeBIN tokens (on-chain tokens).

   When we do mainnet and TGE, we will airdrop some $AIE to that wallet based on its DeBIN token balance. The ratio/conversion rate is determined later.

Deployment Timeline

1. Trial Deployment to make sure we can make use of the open-source codebase: done
2. Login/Wallet creation: ETA 2-3 days.
3. AIE-themed UI/Front-End: ETA 3-4 days.
4. DeBin tokens sent to the node when it processes some prompt: ETA 7-8 days.
5. Later may implement it in form of browser extension, so it runs in the background of the browser: No estimation on how tough it is yet.

Making use of Google Cloud Credit for this

We will figure out a way to run many AIE-DeBIN nodes on Google Cloud (free credit we have) for the following purpose:

• Making sure the service is always available: if user sends in a prompt, she will receive answer.
• Prop-up the # wallets, and # transactions on AIEChain.

Besides, we are contracting some AI fellows to deploy image models on Google Cloud. Once those models are up, we can use them together for Genesis and RizzAI to save expense, and work out a way to make it as if our DeBIN can do with images too (refer to the 2nd additional feature in section 2.a. above)

Potential Node Sell

Come up with some story like to make sure every node works correctly and faithfully, we require the nodes to post a security deposit. Nodes that are detected to misbehave will have their deposit slashed.

Nodes will be rewarded with AIE tokens. These come from the ecosystem portion of AIE tokenomics.