Overview

Payment for code needs to be securely tied to the code that is being paid for. If it is not, then the following attack is possible.  Suppose Alice wants to deploy code, but Bob, who is running a validator, wants to run something else without paying for it.  Alice provides to Bob code to run and a signature telling her wallet to deposit fees into the validator purse.  Bob replaces her code with his and uses Alice's signature to use her wallet to pay for running his code.  To prevent that, the payment code needs to compare deployment details. Because the userID signed the code, the payment code has the option of checking either the codeHash, or the userID. Checking the userID also means that the payment code itself hasn't been altered.

Note:

This means that it would be possible to include binary data as a part of the deployment and use a similar API to access the data.

We will provide the code hash, user id, and timestamp as an input api at `rho:deploy:params`. The wallet code will have a method that checks the signature over these items, and any other necessary paramaters for payment e.g. nonce and amount.

Detailed Design

Usage

This is a motivating payment snippet for this design:

new walletChan, paramsChan, lookup(`rho:registry:lookup`), getParams(`rho:deploy:params`) in {
	lookup!(`<registered wallet urn>`, *walletChan) |
	getParams!(*paramsChan) |
	for (@codeHash, @phloPrice, @userId, @timestamp <- paramsChan) {
		for (@walletMap <- walletChan) {
			// I'm still uncertain about where the payment should go and if it should be a param, or if the wallet should know about where to send it.
			@{walletMap.get("codePayment")}!(codeHash, phloPrice, userId, timestamp, <amount>, <nonce>, <sig>)
		}
	}
}

We will need two things for the above snippet to work.

• An implementation of rho:deploy:params
• The wallet with a method that handles code payments.

This design doc is focusing solely on the first.

Implementation

The Runtime object defined in Runtime.scala will contain an object with 3 mutable fields: codeHash, userId, and timestamp, as rholang terms.
They will initially be Nil.
Before running a deployment, the casper RuntimeManager will set the correct values in the mutable object.
The Runtime object will define an additional method to fetch the parameters to a return channel.
The new method will be made available at `rho:deploy:params`