[Rejected Design Concept] Peng Protocol : Peng(a) Design (Short)

O A Distributed Network for Creating Liquid Simple-Ledger-Tokens Using OP_Return Transactions verified by Digital Signatures on the BitcoinCash Blockchain.

Definitions

TxF; Transaction Fees
OPTx; Output Transaction (OP_Return)
SLg; Simple-Ledger
AqLiq; Adequate Liquidity
NFT; Non-Fungible Token
NEO; Node Endpoint Operator
HYPR; Hydra Protection
COIN; Bitcoin-Cash
D-Sig; Digital Signature
UTXO; Unspent transaction output
DRM; Digital Rights management
TeF; Test by finality

Protocol

~ Basics ~

A network of web-based bots secured by HYPR and absolute consensus, who perform OPTx’s to smart contracts that allow users to deposit/withdraw COIN and make use of custom tokens on a simple-ledger which are fully liquid. Peng is not a layer 2, it is an intermediary for Layer 1 transactions.

~ Bots ~

Provision for ‘Bots’: The ‘Peng’ Network will operate using distributed bots listed as follows; ‘Oversights’ ‘Viewports’ ‘Bailiffs’ and ‘issuers’ whose actions will function on D-Sig + ‘Absolute consensus’ to prevent fraud, and use ‘HYPR’ to prevent tampering.

~ Absolute Consensus ~

Integration of ‘Absolute Consensus’: Absolute Consensus ensures that 100% consensus is required to perform an action on a network, each request has to already be verified by a digital signature (Normally this would be enough to validate that an action absolutely originated from the address in question and is not being faked, but ‘Absolute Consensus’ assumes that the node verifying this request is lying).
A random node is selected from the network and presented with an encrypted message verified by D-Sig, the node has to verify that the D-Sig is correct, it then requests no more than 6 other nodes to verify it as well, if even 1 node rejects it; consensus cannot be reached. All the affected nodes are kicked from the network and the process restarts.

A situation where consensus is never achieved is a “Cascade Shutdown”.
For the purpose of ‘Peng’, several other protective measures exist to prevent even a single node from agreeing with invalid transactions.

~ HYPR ~

Provision for ‘Hydra Protection’: HYPR is a proposed DRM software that works by seizing control of the computer at root level, on top of distributing the guarded program library to 19 heads in separate folders across a computer and restricting the user from accessing them, if one of the “heads” is tampered sufficiently; the HYPR will delete all “guarded” files plus any files which may appear similar to the guarded files.

~ Viewport ~

Provision for ‘Viewports’: These bots will host the web view; they provide an interface through which users can view balances and initiate transactions. Users can only view the balance of the wallet they own, this (+ any other action) is verified by D-Sig, every “login” with a complete transaction is cached for a few days. The Viewports encrypt and decrypt OPTx’s which make up entries in the Simple-ledger.

~ Oversight ~

Provision for ‘Oversights’: These bots will accept transactions from ‘viewports’ after the prior have achieved consensus, ‘Oversights’ cannot decrypt messages, they simply execute them into OPTx once they have achieved consensus and verified the D-Sig.

~ Issuer ~

Provision for ‘Issuers’: These bots will create new smart contracts and tokens, they cannot decrypt messages, they simply execute them into OPTx or contract creation once they have achieved consensus and verified the D-Sig.

~ Bailiff ~

Provision for ‘Bailiffs’: These bots execute ‘kick’ orders once queued and after achieving consensus, ‘Bailiffs’ have the final say in removing a NEO from the network. ‘Bailiffs’ manage checking a NEO when they need to join/rejoin the network.

~ Simple Ledger ~

Integration of ‘Simple Ledgers’: The ‘Simple ledger’ is a system of encrypting and decrypting messages stored in OPTx’s sent to a smart contract on a blockchain. Each message is a ledger entry, the details of each message is account information involving balances, when a transaction on the ‘simple ledger’ occurs it simply means that a new entry is made with an updated “nonce” and balance details. The auditors of this ledger always read the entry with the highest “nonce”.
Each token is an account unto itself, they are discerned by number and what smart contract their balance is stored in, every user’s balance has clauses for every token on the smart contract they deposit to, meaning the token balance can be updated from a single OPTx.
The liquidity for tokens is stored as the token account’s main balance and can be changed by a “swap protocol” which allows every user (with funds on the particular smart contract) to exchange their COIN for the token and vice versa.

~ Main Ledger ~

Provision for ‘Main Ledgers’: ‘Main Ledgers’ are smart contracts which obey specific OPTx’s, users deposit funds into the ‘Main ledger’. New ‘Main ledgers’ can be created once the maximum number of tokens for one ‘main ledger’ is reached. This has to be done by user request.

~ Balances ~

Each OPTx is a full balance of the user’s SLg COIN and all tokens on the particular ‘main ledger’. Different balances exist for ‘Tokens’ and ‘Users’. Each user balance has “Token” fields, which are empty slots by default, only when a token’s account is “activated” and its “Token-self” field is filled; does it becomes active, the “Token-self” field is the supply of the token and is at first blank but updated by a user’s request. The Token’s SLg COIN balance is its liquidity and can be swapped to or from using the “swap protocol”. Tokens cannot be created without “adequate liquidity” which is 105% of the token’s supply * initial price set by the user.
All tokens have a liquidity fee which is set by the user and billed on each sell, payout of fees only occurs when liquidity is above 105% of the token’s price * supply, payout is calculated by deducting [fee] from each token sell order, the difference is returned to the user’s SLg COIN balance. Once a token has adequate-liquidity; all sell order deductions are instead sent to the “creator”, which is the public key that activated the token and defined its fields. Token names are stored on the ‘viewports’, the actual token name is “Token #” @ xxx…xxx address.

~ Non-fungibility ~

NFTs can be created by using a second type of OPTx which does not have a COIN balance or “Token-self” balance, but instead has an “owner”, “metadata” and other fields which allow trading.

~ Allocation ~

Each NEO is entitled to an allocation as reward for being part of the network, these rewards come from TxF and token creation fees and are held within their node’s ‘Oversight’ wallets until being sent to the NEO owner’s public key.

~ Fees ~

There will be two tiers of fees; transaction fees, which are billed based on miner fees + 10%, and TeF which is an intricate algorithm that allows fees to go up when prices are low and go down when prices are high, it does this without an oracle or price checking (Because oracles can be subject to losses in connection or seizure in the data source).

~ Genesis ~

‘Genesis’ Refers to starting up the network for the first time, this is achieved by booting up a ‘Bailiff’ from the “genesis key”, the ‘Bailiff’ hosts the Proto-viewport pending the creation of ‘Viewports’, and generates the web address (no domain name), then other bot sub-groups need to join, once there are 6 of each bot sub-group the network can begin transacting. The “genesis key” is an offline version of the bot installer, it still makes use of “Bailiff checks”. The “genesis key” cannot be used once the network is in full swing.

~ Cascade Shutdown ~

A Cascade shutdown is a hypothetical situation wherein “kicked” NEO’s do not rejoin, where only one set of ‘Bailiffs’ remain and they fail to achieve consensus, the system “shuts down” as ‘Bailiff’s’ kick one another off the network. Normally HYPR would prevent fake nodes from being created, but it is possible to exploit it.

~ Monetization ~

Implementation of Peng Vanity Addresses: There will be a collection of 99,999,999 possible vanity addresses. Each vanity address can be named and will act as an account that exists purely within the Peng SLg; these can be used remotely to carry out transactions anonymously. Each vanity address will cost (Apx $5) in TeF-COIN, which will be shared equally between the NEO that processes the transaction and the 4 users who own “Peng Genesis” NFTs.

Full design paper available on my google drive.

Responses to questions about HYPR can be found here.