DArticle Disclaimer : The contents of this article are not reflective of the current state of the Peng Network.
The following article shows how a user would interact with Peng(a)v2 … once fully built.
The user opens the webapp at the web address, something like ; https: //220.69.420.777 after being directed by a link on the “formal website”, which would be something like; https ://penggenesis.com
The user inserts their address in the blank space and clicks “initialize”.
They are issued a set of 5 alphanumeric symbols that need to be “encoded” in their wallet, this means they send 0.00000000000#XMR “#” being any number, they send it to a network node’s address which is presented to them.
The network then verifies that the user interacting at the webapp is the owner, based on the fact they used the correct coded input (senders and receivers on Monero can see the amounts of their transactions and the description).
The user is then greeted with their balances.
The user’s balance is unknown until they make it known to the network.
So, first thing to explain is NFTs;
Each NFT is an address owned by the user or “pseudo treasury”, let’s go over the process of creating an NFT.
After clicking “create new NFT Pseudo-treasury” the user is then issued a coded input and needs to include the public view key for a new address (not the address they used to log-in) and put that in the description, the input (amount) for creating an NFT is 0.00000#####02XMR, the “#” is a random number which the nodes issue and also acts as a fee. Once they send this amount from a fresh address to a specified network address, it becomes a “pseudo treasury” specifically for NFTs. This also links the NFT pseudo treasury to the address they used to login.
(Please notice; when creating a new NFT the user will be asked to input a public view key inside the webapp [not in the transaction description])
The user can now create a new NFT and begin editing the network side json of their new NFT, setting the URI for the image and description.
So now let’s say the user wants to transfer that NFT, they click on the NFT’s little question mark thing and go to the little arrow thing;
And specify an NFT pseudo treasury they want to change the ownership to; what this does is it changes the json file’s ownership field to the new address.
(Notice; the nodes have the public view key of every NFT address)
To transfer an NFT, a user needs to send a coded input from their login address to an address presented by the webapp, this amount is 0.00000#####09XMR and has to be initiate in the same vein as previous transactions. Only the login address of an NFT pseudo-treasury can successfully pass this, and only when it has been initiated at the webapp with the destination address set.
Fungible tokens
Fungible tokens are more complex but overall, this is how they work;
Let’s say you have a token in your Fungible-tokens pseudo treasury, and the network verifies that the token is worth 0.001XMR to 1XMR, if you wanted to sell that token you would create a trade offer and another user of the network would send you a certain amount of XMR in exchange for ownership of those tokens, the network verifies each trade once started, so the moment the correct XMR amount is sent, the token balances are updated.
Each trade for each token is “queued”, this means no other trades can take place while it awaits the buyer’s transfer. Both parties’ view keys are known to the network so it can verify, the buyer has 30 seconds to send XMR, at which point it’s just up to waiting for miners to hash the transaction. (This process can be automated with client-side bots).
What the user-side market maker gains from this is a markup percent they set which cannot be greater than the “max fee” set by the token creator.
Now how do we handle prices? To do that we must start from creating a fungible token.
So, you go back to your main address page and create a new fungible token pseudo-treasury,
So now you can create a token;
With the above options you can set all the information for your token including the initial price. If the token is set to use “USD” that means it will use a USD price feed set by the (3) signatures of the “Arbiter” IDA.
Once the token is minted, the entire supply will be allocated to you, so if someone wants to buy the token you have to process that request, they send you a specific amount of XMR and the system sends them the token (this can be automated on the user-end).
So, each time a token is bought the price is updated based on the amount bought and vice versa. It calculates the initial price * supply to create “hypothetical adequate liquidity” (HyLiq). So, if the user set 6,000,000 tokens @ 1XMR each, they would have a HyLiq of 6,000,000XMR. This liquidity does not need to be supplied as it would be taken care of by the trade peers.
Price changes, based on token supply vs HyLiq, those balances are then corroborated with the previous price, the formula is;
Sell = H / TS — L
Buy = H / TS + L
“Sell” = HyLiq balance / token supply — Last price,
“Buy” = HyLiq balance / Token supply + last price,
HyLiq increases with each purchase proportional to how much was bought, and decreases with each sale the same way.
If someone were to buy 500,000 of a token with 6,000,000 supply and 450XMR HyLiq at 0.001XMR each, that is a HyLiq update of +25XMR equaling; 475XMR in the HyLiq. Making the price; 0.001075XMR.
Token supply is constant.
This is possible because the pseudo-treasury public view key is known to the network so it can verify that the correct funds are being sent.
***
That aside, here a few added utilities you will be able to make use of:
Multi-sigs; these function by requiring coded inputs from multiple addresses to transfer tokens. They do not work for transferring XMR.
Image : address box short, name under
Name NFTs; these route a searchable name to a particular fungible token pseudo treasury.
Side-networks; These are copies of the main network which can be used to create apps that would be otherwise too complicated to manage on a single network.
***
Now we should discuss the elephant in the room, how do network nodes profit from this? Simple, when a node is created, the operator inputs a public key and public view key, this public key can be changed later on and acts as their pseudo-treasury. The address a user is asked to send coded inputs to is the same address of the node serving them, this action is verified by other nodes who have a registry of all public keys and public view keys.
But this fee alone is not enough, so, trader profiles can only be created using a public key from an existing legitimate node, this means all traders are node operators, this boosts the network’s security and gives value to running a node.
User privacy
The network is inherently public, all transactions made have their public view key disclosed, this allows validation by the formal website. But privacy is always one transaction away i.e., sending XMR back to one of your private addresses.
Securing the network
The network is structured as a Hybrid line bus with peer-to-peer elements, springing from genesis. Client-side Requests are served by random nodes in the network. Each time a new node requests to join the network it becomes a child of the most recent node; this just means the parent node records when the child node joins or leaves either intentionally or by accident. Each node can only have 1 parent and one child.
communication is peer-to-peer but network management is hierarchical
All actions on the network require consensus between the node performing the action and the current root node, this means they must follow the right order and queue, if the root agrees that the right order was followed; then the action is valid and allowed to execute, if it disagrees then the rejected child node is kicked from the network.
Acting without consensus or acting on something different; warrants removal from the network. Child nodes can break away from a delinquent root and reconnect with the highest non-delinquent node. however, this means the IP address for the site would change, which is what the “formal website” is for, that will be hosted on IPFS as an immutable object. The “formal website” picks up the address of the new root node and uses that to direct clients.
If the root node is deactivated, the node directly below it will take its place.
The root decides (at random) which node serves a client. Departed roots no longer have the same privileges as they once did, meaning if/when they try to rejoin, they become a child node.
What this means for nodes on the line is; if one of the nodes goes offline, all its child nodes are no longer connected to the network, rather they split away assuming that the highest in their order is the new root. These nodes will then need to voluntarily leave their split network and rejoin the actual line. These split nodes would not be able to receive client requests from the formal website. (Rejoining the correct line can be automated using operator-side bots that will automatically check the formal site and note if the operator’s node is on a different line, it will then turn off the node and set the correct root IP for a rejoin process).
***
The foundation of this design is the formal website, so long as there is even a single node that is legitimate; the network will continue with that node as the root. Additional information can be found here.
How this is an improvement over existing networks
Currently (to my knowledge) there are no projects working on creating token systems on Monero directly on Layer 1, so that’s already a huge improvement.
How this is an improvement over Smart contract virtual machine (SCVM) chains is as follows;
- On SCVM or EVM on Ethereum, contracts are encrypted data stored in the SCVM, this presents a huge load for node operators. but on Pengv2a hosted data is unencrypted and carries very little weight overall.
- On SCVM chains each transaction is a complex input which is heavy and expensive to process, but on Pengv2a each input is just a fractional amount of XMR coded to mean something to the network nodes.
- On SCVM chains constant market algorithm is the go-to method for token swaps and pricing, I have explained how that can be exploited in my TeF article here. But on Pengv2a price is enforced directly into the contract and updated on each buy/sell rather than estimated.
- On SCVM chains token creators must supply liquidity for trades, on Pengv2a liquidity is handled by trade peers.
- “Not your keys, not your coins” on Pengv2a the keys are always in your possession, no “contract” has permission to access your keys or the funds inside.
- All internal transactions on Pengv2a cost the same to process, doesn’t matter if you’re minting 10 NFTs or sending $2 worth of USD tokens.
- This also solves the 51% attack problem, on Pengv2a, authority over ledger changes is in the custody of the root node, child nodes can reject a delinquent root, legitimate roots are ratified by the formal website and its many immutable instances.
***
With SCVM chains covered, some people may ask, “why not use something like IPFS”, but it would’ve been impossible to create this sort of setup on IPFS, here are the problems;
- IPFS uses a distributed file system, every time content needs to be fetched; the “pieces” need to be searched for and put back together before being presented. This is demonstrably slow.
- Immutability on IPFS would make it impossible for nodes to get rewards (i.e., node operators have to input their address inside the node software so users know where to send their fees).
- Due to the prior point; transactions would be free, yes, this is a problem. Whoever manages the site would have to depend on donations to keep it going.
- The security mechanism of nodes dropping off and roots being replaced would not work on IPFS, on IPFS once the root is down the site goes with it.
IPFS is still useful, which is why the “formal website” is going to be hosted there and anyone can create “formal websites” of their own using the open-source code. But node operator rewards are essential to the network’s survival, just as transaction fees are essential to the security of the Monero blockchain on which this system rests.
***
Full version of the design can be found here.
Extended Network info can be found here.
With that said I conclude my article, thanks for reading!
