...
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 the codehash it expects to pay for to the codehash that's actually being deployeddeployment 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.
...
| Code Block |
|---|
new walletChan, paramsChan, lookup(`rho:registry:lookup`), getParams(`rho:deploy:params`) in {
lookup!(`<registered wallet urn>`, *walletChan) |
getParams!(*paramsChan) |
for (@codeHash, @phlorate@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, phloratephloPrice, userId, timestamp, <amount>, <nonce>, <sig>)
}
}
} |
...