SIP: 4
Title: Contract Transfers and Renewals
Author: Gordon Hall <[email protected]>
Braydon Fuller <[email protected]>
Status: Active
Type: Standard
Created: 2016-10-26
The SIP introduces a new RPC method to the Storj protocol to enable renting actors on the network to instruct the custodians of their data to modify certain contract terms for a given shard.
This addition solves two immediate problems:
- Efficiently renewing existing contracts without the neccessity of publishing entirely new ones to extend the length of storage time.
- Providing an upgrade path for HD Identity transfer from a standard Node ID.
We propose a new RPC method, RENEW
, which may be issued to a farming node at
any time to modify the terms of a contract for which the issuing party is
authorized. In addition to the standard required parameters, the RENEW
RPC
includes 3 more:
- contract - the new modified/updated contract data
- renter_id - the Node ID authorized for the original contract
- renter_signature - the new contract signature by the original Node ID
When a renting node wishes to modify the terms of a given storage contract,
it issues a RENEW
RPC message to the farmer including the required
parameters. Not all contract parameters may be modified in a contract renewal,
the allowed modifications are limited to:
- renter_id
- renter_hd_key
- renter_hd_index
- renter_signature
- store_begin
- store_end
Recipient farmers must take care to validate the modifications to prevent loss of future payments. In the example below, a renting node is instructing the farming node to transfer the authorization/ownership to a new SIP32 based identity as well as extending the contract period by an additional 90 days.
{
"method": "RENEW",
"params": {
"renter_id": "43144cac0a406eb72f4d3be7292438ac15725e1d",
"renter_signature": "3045022100de2e162d017a1e9d0ebfe2a94df3fc847b68281a...",
"contract": {
"version": 0,
"renter_id": "608939ffcaac7d8019ab43bd097124025d3c47e9",
"renter_hd_key": "xpub6AMzSjSPt3Dc3Z1nziingqQcbHFLtKMsVjYXW1HSPDFihcj...",
"renter_hd_index": 0,
"renter_signature": "3045022100de2e162d017a1e9d0ebfe2a94df3fc847b6828...",
"farmer_id": "8d225ed9aec6e2dfb74d51c84c58ff13d11cfa79",
"farmer_signature": "3045022100de2e162d017a1e9d0ebfe2a94df3fc847b6828...",
"data_size": 8388608,
"data_hash": "e6114b9763d433808f6fdf632c00b919a439bc97",
"store_begin": 1477505878758,
"store_end": 1485281902724,
"audit_count": 3,
"payment_storage_price": 0,
"payment_download_price": 0,
"payment_destination": "1DL5N2ayoUxHwgD2NEZ4ifq1wVRVLVQyk2"
},
"contact": {
"address": "10.0.0.2",
"port": 1337,
"nodeID": "89cc3ddb4209c6e7e301c10c0257adf4fd85f253",
"protocol": "0.7.2"
},
"nonce": 1455216323786,
"signature": "3045022100de2e162d017a1e9d0ebfe2a94df3fc847b68281a9882..."
},
"id": "7b6a2ab35da6826995abf3310a4875097df88cdb"
}
Upon receipt of a RENEW
RPC, the farmer must inspect the contract and
perform a local lookup of any contracts associated with the given data_hash
.
If a contract is found for the shard and the original renter_id
, then the
farmer must verify the signature from the original identity and validate the
contract modifications - including signature verification for the new identity.
If these checks pass, the farmer must sign the new contract and respond to the request with it's updated copy after updating it's own local record.
{
"result": {
"contract": {
"version": 0,
"renter_id": "608939ffcaac7d8019ab43bd097124025d3c47e9",
"renter_hd_key": "xpub6AMzSjSPt3Dc3Z1nziingqQcbHFLtKMsVjYXW1HSPDFihcj...",
"renter_hd_index": 0,
"renter_signature": "3045022100de2e162d017a1e9d0ebfe2a94df3fc847b6828...",
"farmer_id": "8d225ed9aec6e2dfb74d51c84c58ff13d11cfa79",
"farmer_signature": "3045022100de2e162d017a1e9d0ebfe2a94df3fc847b6828...",
"data_size": 8388608,
"data_hash": "e6114b9763d433808f6fdf632c00b919a439bc97",
"store_begin": 1477505878758,
"store_end": 1485281902724,
"audit_count": 3,
"payment_storage_price": 0,
"payment_download_price": 0,
"payment_destination": "1DL5N2ayoUxHwgD2NEZ4ifq1wVRVLVQyk2"
},
"contact": {
"address": "api.storj.io",
"port": 4001,
"nodeID": "98dc026fa01ae26822bfb23f98e725444d6775b0",
"protocol": "0.7.2"
},
"nonce": 1455216323786,
"signature": "904502207e8a439f2cb33055e0b2e2d90e775f29d90b3ad85aec0c..."
},
"id": "7b6a2ab35da6826995abf3310a4875097df88cdb"
}
Upon receipt of the response, the renting node, must update it's local record of the storage contract once more, to include the updated signature from the farming node. Once this exchange is completed, the contract has been successfully transferred and/or renewed.