MultiParty Protocol or MPP is introduced within the Vechain Thor blockchain to get around inefficiencies in user experience when interacting with decentralized apps (dapps) in terms of end-users having to pay for transaction fees.
MPP introduces a sponsorship model for all accounts (contracts or user addresses) in the Vechain Thor blockchain wherein an address can volunteer to sponsor an account based on a pre-determined initial credit plan and recovery rate. A master address would be in charge of selecting sponsors, adding/removing user addresses (which interact with the account), setting credit plans and setting a new master for an account.
The key terminology related to the MultiParty protocol is detailed below:
A master address as explained earlier, would be in-charge of key functionality related to accounts in the MPP model. Masters are able to call the following functions on behalf of accounts:
addUser()removeUser()selectSponsor()setCreditPlan()setMaster()
These functions are akin to 'admin' functions in a traditional context.
Sponsors are accounts holding VTHO (energy) to pay for credit plans for all users added to an account in MPP. Whenever a user sends a transaction to an account that has an active sponsor, the sponsor account would handle all the energy costs for the transaction.
A pre-requisite for an ideal user experience for a well architected MPP setup for a contract(s) would be an ideal amount of VTHO/energy set as initial credit (creditPlan) for the user based on interactions with the contract within manual test environments. As well as a recovery rate that would justify a fair daily estimate of usage for the contract(s) while keeping the cost for the daily amount of VTHO required in mind, while minimizing chances of users abusing the system to drain sponsors of their VTHO reserves.
For example, with the PlayDecent Quest contracts, for every possible write/state-changing function callable by a user, which would require a transaction be sent to the blockchain - the function either requires a DBET payment (paying for quests) or can only be called once (claiming refunds).
This leads to an ideal MPP architecture where users cannot game the system since they would effectively need to stake DBETs by actually playing quests, which in effect disincentivizes malicious entities from performing transaction spamming. Due to this, creditPlan and recoveryRate for the Quest contract can be set quite high since it'd be expensive for any user to abuse the system, which would also lead to additional upward pressure on DBET prices on spot markets as a side effect.
A user in an MPP context is an account whose transactions are sponsored when interacting with a sponsored contract. Users are added to the whitelisted list of users by account sponsors or masters using the following MPP functions:
addUser()removeUser()
Users for a sponsored account would be able to interact with the sponsored account without paying VTHO/energy for transaction fees based on the defined creditPlan and recoveryRate values for the account. If a user uses more than the defined creditPlan value in VTHO for the day, it would have to pay for transaction fees until it has recovered enough sponsored VTHO based on the accounts' defined recoveryRate.
In MPP, a credit plan for an account defines the initial amount of VTHO that a sponsor would pay on behalf of users of the account over a 24 hour period.
For example, if the credit plan for an account is set at 10000000000000000000000 wei, which would be 1000 VTHO - a user would be able to send transactions to the account for upto 1000 VTHO over a 24 hour period which would be sponsored by the account sponsor.
If the user uses up the 1000 VTHO, they would have to wait for their credit to recover (based on recoveryRate) before having their transactions sponsored again - until which they would have to pay for the VTHO themselves.
Note: For calculating VTHO requirements for a transaction, you would need to divide the gas field for a transaction by 1000 assuming a gas co-efficient of 0. If a gas co-efficient of 128 is used, you would multiply the gas field by 1.5 and by 2 if a gas co-efficient of 255 is used.
Recovery rate is defined as the amount of credit that is recovered per block for a user sponsored to interact with an account.
For example, if the recovery rate is set as (10000000000000000000000/86400)/10 wei, which would be 1000 VTHO over 10s intervals for a 24 hour time period, users would have their accounts recover their credit at a rate of 0.0011574074 VTHO per block (or 10 seconds).
The MPP contract is a built-in contract within the Vechain Thor blockchain, meaning it is deployed during genesis and always has the address 0x000000000000000000000050726f746f74797065 across all versions of the chain - main, test and solo.
The interface for the MPP contract can be found here.
For more details on contract functions, parameters and return types - refer to this document.
To simplify interaction with MPP on Vechain Thor, the node-mpp library has been developed to provide a simple and intuitive way to perform MPP based functionality on Vechain Thor contracts.
Refer to the readme, examples and tests for further implementation information.