Protocol v2.0 proposal

[containerman17]

This document outlines the development of a new booking protocol for P2PCloud, designed to enable flexible virtual machine (VM) booking and significantly improve utilization rates.

Booking protocol V1

Entities

• Booking: A machine reservation created from an offer
• Offer: A proposal to create a booking with specific specifications and pricing

Workflow

1. Balance Deposit
   • Users deposit stablecoin into the contract
2. Offer Creation
   • Hosting providers register as providers and pay a fee
   • Providers create offers with specifications and availability
3. VM Lifecycle
   • Creation
     • User books a VM, generating a booking
     • Offer's availability decreases by 1
     • Funds equivalent to 7 days of booking price are locked in the user's account
   • Hosting providers can claim earned funds at any time or choose not to claim
   • Contract Termination
     • All due fees are paid if sufficient balance exists
     • Community contract receives 20% of each payment
     • User records the termination reason on the blockchain (e.g., satisfactory service or technical issues)
     • Offer's availability increases by 1
     • User's 7-day deposit is unlocked
4. Balance Withdrawal
   • Both users and hosting providers can withdraw their respective balances in full

Problems to be solved

1. Inflexibility leading to underutilization: Traditional cloud platforms can offer various VM combinations (e.g., 32x[1C+2GB] VMs or 16x[2C+4GB] VMs), while the current protocol requires predetermined compute power. Disk size and dedicated IP availability present similar challenges.
2. High gas fees for providers:
   • Payment claims for each VM must be made separately
   • Forced terminations require individual processing for each VM
   • Currently, every price update is recorded on the blockchain, which is unnecessary. Updates should be made on-chain, but only finalized after the contract has been established.
3. Lack of encrypted deals between hosting providers and clients, potentially unacceptable for real-world businesses
4. Absence of Know Your Customer (KYC) processes: P2PCloud sits between centralized cloud services (e.g., AWS) and fully decentralized projects (e.g., Golem) in terms of decentralization. Therefore, an optional, provider-enforced decentralization solution is necessary.

Solution:

1. Introduce flexible VM configurations
   1. Implement a dynamic allocation system that allows hosting providers to offer various VM combinations, increasing resource utilization.
   2. Allow users to select custom configurations based on their needs, improving overall user experience.
   3. Negotiate prices off-chain before the agreement is reached
2. Introduce a single updatable "agreement" concept
   1. To introduce a concept of an updatable agreement between customer and hosting provider. Instead of creating a new agreement for every single VM, a user and provider would just amment their single existing agreement.
   2. The agreement might be in clear or encrypted - by mutual desicion. Only the financial transactions are available for everybody.
3. Implement optional KYC processes:
   • Develop a modular, provider-enforced KYC system that can be easily integrated by hosting providers who require it, striking a balance between decentralization and regulatory compliance.
   • Provide Hosting Providers with the tools neccesary to run their own customuized KYC. Some examples of KYC policies would be:
     • From my country and not under sanctions
     • No KYC
     • Manually approved customers
     • Only verified students of Univercity of South Florida

V2 Protocol proposal

In v2 we are getting rid of "offer" and "booking" entities and intoducing a Provider Agreement - agreement between a user and a hosting provider on Broker smart contract.

1. Price inquiry
   1. Hosting provider registers at the platform and submits his URL for price inquiries
   2. User requests all hosting providers for their quotes on proposed VMs
2. Vm booking
   1. User checks for KYC requirements and goes through KYC if required
   2. User forms an ammendment - list of VMs and price increase
   3. User submits an ammendment to the hosting provider gor signature
   4. Hosting provider signs the ammendmend if KYC is ok and all resources are as agreed
   5. User submits the signed ammendmend on the blockchain, the signature is verified in the smart contract
3. Vm Deletion (the same as booking)
   1. User forms the amendmend to the provider agreement
   2. Send to the provider for signature
4. Breaking the Provider Agreement
   1. Both parties can break their contract at any time
   2. All VMs will be deleted and payments stoppped
   3. No agreement from ther party is needed
   4. Event of breaking the contract influences rating of the party breaking the contract
5. Money claim
   1. At any point of time, the hosting provider might claim money due for the whole subcontract in one transaction

Broker Smart Contract V2 Proposal

1. Deposit, Withdraw methods - deposit and withdraw a stablecoin.
2. GetProviderURL / SetProviderURL - set a clearnet address of the hosting provider used for off-chain communications.
3. SubmitAmendment - amend or create a new Provider Agreement.
   1. Arguments:
      1. uint16 amendmentNonce - ensures signatures are not reused, incremented by one for each amendment.
      2. int256 priceChange - a difference in price (can be negative).
      3. bytes32 agreementCid - a link to the amended IPFS hash of the agreement. The hash can contain plaintext or encrypted agreement, depending on the signing parties.
      4. address provider - address of a hosting provider involved in the agreement/amendment.
      5. bytes signature - a signature from the hosting provider verifying their agreement to the proposed changes. Raw data for the signature is composed of (amendmentNonce || priceChange || agreementCid || provider || client).
   2. Notes:
      1. All due fees must be paid at the time of amendment.
      2. The client must have enough funds to cover the next 7 days of rent to make the amendment.
      3. Sending signatures as bytes could be expensive and requires testing.
4. BreakContract - immediately destroys the contract. Can be called by either the user or the hosting provider, leaving an event on the chain.
5. ClaimPayment - transfers due fees from clients to the provider's address within the Broker contract.
   1. Automatically called on SubmitAmendment and BreakContract calls.
   2. If the client's balance is insufficient to cover all fees, the contract is broken, and an event is recorded.
6. RegisterProvider/IsRegisteredProvider - pay a fixed spam-prevention fee to become a provider. The fee is $100, sufficient to protect against spam but not a barrier for legitimate hosters.
7. AddNonWithdrawableBalance - transfer funds to another client without the option to withdraw. Required for free trials and money laundering prevention.
8. GetBalance - return free, locked, and non-withdrawable balances.

Hosting Provider's HTTP API

This document covers only new v2 methods. Attestation logic remains the same.

GetQuotes

Public method for retrieving filtered quotes.

• Request
  • MinCPUCores
  • MinRam
  • MinDiskGB
  • DesiredDiskType - Disk type: localSSD or networkSSD
• Response
  • List of 5 compute nodes
    • CPU
    • RAM
    • Min and Max disk
    • Price per minute
  • Price per GB of storage

ApproveAmendment

Authorized method to form amendment messages for users.

• Request
  • Price difference
  • New inventory
    • List of VMs
      • VmId (formed from client's address + unique integer)
      • Specs: CPU, RAM, disk
      • VM price
• Response
  • A signature

[containerman17]

EIP-712 would help in ApproveAmendment method

[jeremybeal11]

A few questions and comments:

Workflow:

Under VM lifecycle :

Funds equivalent to 7 days of booking price are locked in the user's account

You mean that the funds are locked into the broker contract, correct?

Hosting providers can claim earned funds at any time or choose not to claim

This should be claimable in 24hr increments to prevent clients from being rugged. For instance, when a client books a VM from a new provider on the marketplace and that provider shuts off its cluster and run it under a different address.

Under balance withdraw:

Both users and hosting providers can withdraw their respective balances in full

Is this the excess balance after its been locked in or the locked-in balance in the broker contract?

V2 Protocol proposal:

Breaking the Provider Agreement:

1. Event of breaking the contract influences rating of the party breaking the contract

What if both parties agree on breaking the contract? Is it possible for no penalty to mark on both parties report card?

Money claim:

1. At any point of time, the hosting provider might claim money due for the whole subcontract in one transaction

Can you clarify the subcontract and it's function?

[containerman17]

You mean that the funds are locked into the broker contract, correct?

Yes.

This should be claimable in 24-hour increments to prevent clients from being rugged. For instance, when a client books a VM from a new provider on the marketplace and that provider shuts off its cluster and runs it under a different address.

A new hosting provider has to pay a fee and would probably keep prices way below market. I assume this scenario doesn't make any economical sense. I might be wrong; it needs testing IRL.

Is this the excess balance after it's been locked in or the locked-in balance in the broker contract?

The locked balance is also used for payments. The whole point of the locked balance is to prevent a client from booking many VMs that they cannot afford.

What if both parties agree on breaking the contract? Is it possible for no penalty to be marked on both parties' report cards?

Good point! Users can choose a reason for breaking the contract: not needed anymore or quality issues.

Can you clarify the subcontract and its function?

A client and a hosting provider agree on the scope and price - I would call it a "contract." But it is all happening on a smart contract. We can call it an "agreement" or "subcontract" to avoid confusion with the smart contract.

[containerman17]

This proposal is unnecesarry comlicated. It will push us back in development for 3-4 weeks.

1. Inflexibility leading to underutilization: Traditional cloud platforms can offer various VM combinations (e.g., 32x[1C+2GB] VMs or 16x[2C+4GB] VMs), while the current protocol requires predetermined compute power. Disk size and dedicated IP availability present similar challenges.

Ideas:

• This can be done by getting rid of Offer entity and storing IPFS hash of the agreement in the booking.
• Store hashes separately and use an uint16 or uint32 index of this hash (basically bring back Offer). That will save a ton of gas.
• Get rid of IPFS layer and pack VM specs into bytes32
• Get even leaner and fit into bytes16.

2. High gas fees for providers:
   • Payment claims for each VM must be made separately
   • Forced terminations require individual processing for each VM
   • Currently, every price update is recorded on the blockchain, which is unnecessary. Updates should be made on-chain, but only finalized after the contract has been established.

Ideas:

• Get rid of Offers (of course)
• Account sum of all VM prices for hosting provider-client relationship in one variable and make claim a single call
• Allow batch terminations of multiple VMs
• Break the relationship between hosting provider and client in one flag

3. Lack of encrypted deals between hosting providers and clients, potentially unacceptable for real-world businesses

Ideas:

• We can stick to general rules of blockchain - everything is transparent on the level of the wallet, but the owner of the wallet stays private
• If we use IPFS hash as specs, there is no problem of encrypting it. But does it make sense to hide specs without hiding finantials?

4. Absence of Know Your Customer (KYC) processes: P2PCloud sits between centralized cloud services (e.g., AWS) and fully decentralized projects (e.g., Golem) in terms of decentralization. Therefore, an optional, provider-enforced decentralization solution is necessary.

Ideas:

• Implement it on the signed offer level. Here is a process proposal: request offers from anybody, request signed offer from selected provider, book the VM. The idea is - provider will reject offer signing for a client who doesn't comply with KYC policy (if present).
• Each provider has to run their own KYC. This will protect the system from self-censorship and excessive centralization.

P.S. Also keeping the VM list will allow software authors to check for licensing fees payments for every VM.

[containerman17]

This is an updated version of Protocol V2 proposal. It requires much less changes in the blockchain-integrated hypervisor.

Solution:

1. Negotiate offers off-chain
2. Keep VM specs (or link to specs) in every VM booking
3. Keep track of total cost for all VMs for a client-provider relationship to not waste gas on claiming every VM separately
4. Require all bookings to be approved by providers to be able to hook the KYC process

[containerman17]

V2 Protocol proposal

In v2 we are moving offers off-chain, replacing per-VM with a user-provider balance payment system, and require the provider's agreement for new VM bookings.

1. Provider URL request. A client asks for all registered provider URLS
2. Clients forms a VM spec request and asks providers for quotes using URL list from step 1
3. Each provider responds with an offer based on the requirements and KYC requirements (or signature if they are met)
4. Client selects a provider
5. Optionally, goes through a KYC process and re-requests an offer
6. Client submits a signed offer on the blockchain and gets a Booking
   • Before booking is added, all fees due are paid and balance re-evaluated
7. Provider gets his fees at any time for all VMs of a particular client in one transaction
8. Both provider and user can cancel bookings one by one

[jeremybeal11]

@solohin, what are your thought on creating a factory smart contract for individual bookings?

This will allow us to reduce having a single point of failure in the broker.sol contract since it will hold most of the funds being deposited. Having a factory contract can break up that single point of failure by making it a case-by-case, but we do hit a few issues with it as well:

1. Upgradability
2. Security vulnerability in the factory contract could jeopardize everyone else using it
3. High gas for deploying a contract.

This is something that came up when I was reviewing the smart contracts

[containerman17]

@jeremybeal11

1. Upgradability is managable
2. It doesn't have to be a factory contract, but rather a signaling contract.
3. Yeah, it's probably going to be 1.7m gas instead of 0.12m. I bet we can bring it down to 1m, but not less. Not impossible though.