Hello world, I’d like to begin the post with an example: there are 2 builders working on 2 different applications (say, pTrade and pLending) for Incognito, it’s likely that there would be some overlapped feature between these. The obvious one is wallet management, it’s very inconvenient when a user must create/import/manage the same wallet twice for these two applications. And it would be a real pain if a user must do it hundreds of times for hundreds of applications. Additionally, it’s not optimized in terms of development effort when builders must implement the same functionalities while they deserve to have more time to work on creative and interesting features. So these are big problems I think.
In my design, it’s intending to solve those two problems above, specifically for 2 types of audience: end-user and developer.
While end-users are enabled to share the same wallet across all integrated privacy applications (pApps) with pStore platform so that they don’t need to repeat the same actions for each pApp, developers are enabled to build their own pApp for Incognito as easy as possible.
In this post, I wanted to introduce the general architecture of pStore platform as well as pMultisig - the first pApp integrated with the platform. Hopefully, after the post, any developers should also be able to build pApps as desired without any difficulty, thanks to pEthereum’s flexibility.
Basically, there are 4 main components in the architecture: pStore, pApps, end-user, and Incognito chain as the following figure.
I’m going to explain the role of the first 3 components and ignore Incognito chain since it’s out of the post’s scope (actually, due to my knowledge limitation)
The common functionalities would be operated by pStore which interacts with Incognito chain and Incognito contract
- Shield: turn public token into private token (pToken)
- Deploy: burn pToken on Incognito chain and record deployed token on Incognito contract. These deployed tokens may be used on any integrated pApps (*)
- Undeploy: remove deployed token from Incognito contract and mint back pToken to Incognito chain
- Unshield: turn pToken back into public token
- Transfer pToken over Incognito chain
Each pApp has unique functionalities and these should be implemented by those who want to build their own pApp. Although these pApps are separate applications hosting on different domain against pStore, they can still reuse the wallet (along with its balances) created/imported from pStore so that their users don’t need to repeat the same procedures for each pApp.
In the figure above, pMultisig is a sample pApp with specific functionalities:
- Create a new multisig wallet
- Fund for a particular wallet from the deployed token at step (*)
- Withdraw fund from a wallet when having sufficient signatures as the wallet’s require
In order to build a pApp, developers need to work on 2 things:
- An Ethereum smart contract. It’s been deployed on Ethereum Kovan network already so you can refer the contract source code here (https://kovan.etherscan.io/address/0xf21B4b088FE2b4D29F6eDb83B78438F5786B3017#code). Basically, the contract contains pretty simple functions respective with pMultisig’s functionalities listed above
- sendEtherFund / sendERC20Fund
- Your web app, something likes frontend (UI/UX), backend (APIs) and storage (Database)
End-user interacts with both pStore for common functionalities and pApp (i.e. pMultisig) for specific functionalities.
It depends on the functionality you want to build to have different business logic and process, but there would usually be a typical flow as follows:
Reflect from the general flow above to the pMultisig’s withdrawal specifically, it should be:
By applying the same process, you would be able to implement any functionalities for your pApp that would integrate seamlessly with Incognito chain and pStore platform.
Don’t worry if there is something you don’t follow. In the next post, I’m going to walk you through step by step of how to build a pApp with pStore platform.