pStore Architecture

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.

pStore’s approach

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.

Architecture

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)

pStore

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

pApps

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:

  1. 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
  • initMultiSigAddress
  • sendEtherFund / sendERC20Fund
  • withdrawFund
  1. Your web app, something likes frontend (UI/UX), backend (APIs) and storage (Database)

End-user

End-user interacts with both pStore for common functionalities and pApp (i.e. pMultisig) for specific functionalities.

Typical process

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.

Happy building!

7 Likes

Are there API calls to use your platform?
Specifically interested in

  • Wallet Creation | Public/Private Keys
  • Private Key Wallet Importation | With pCoin Value Checks
  • pCoin Transactions | Sending from private key
  • PCoin Transactions | Listing transactions by coin and ID
  • pCoin Transactions | Listing memo’s by transaction ID
3 Likes

Hey @Revolve, thanks for your interest, actions that you mentioned are mostly related to secret/private key. For security reasons, these should not be exposed as public APIs but should be operated directly at client-side (aka browser) so users don’t need to disclose their private key to any external parties. Fortunately, Incognito SDK is open-sourced and it did support everything we need such as wallet creation/importation, transaction creation at browser, balance calculation, etc… in order to preserve trustless philosophy that both Incognito and pStore platform are intending…

Additionally, one of pStore’s goals is to provide a platform where developers can build their own pApp in the easiest way so I prefer to expose APIs that make devs’ life easier. For example, signature data preparation which satisfies Incognito contract’s execute function as in Typical Process aforementioned in the post, I think such operation is not usually trivial for developers to figure out (to be honest, it took me 2 days or so)

By the way, APIs along with their documentation will be published soon, hopefully, you will like it.

2 Likes