Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return V2FileContractRevision in RPCLatsetRevision rather than V2FileContract #122

Closed
wants to merge 1 commit into from

Conversation

ChrisSchinnerl
Copy link
Member

Ran into a little blocker on the rhp4 revision broadcast PR SiaFoundation/renterd#1698

Basically I can't broadcast the revision since the renter doesn't keep track of every revision and the host doesn't return the state element required to broadcast one.

This PR is obviously incomplete without the corresponding core update but before opening that as well I wanted to draw attention to the issue.

Essentially this PR changes the Contract field on the response to Revision and adds a ChainIndex as well.

@n8maninger
Copy link
Member

n8maninger commented Nov 26, 2024

Why not track and update the state element in the renter database? Relying on the host seems counterintuitive. The renter knows the ID during formation. During consensus updates: loop through the v2 file contract elements, add any confirmed or revised v2 state elements, then update the proofs.

@ChrisSchinnerl
Copy link
Member Author

Why not track and update the state element in the renter database? Relying on the host seems counterintuitive. The renter knows the ID during formation. During consensus updates: loop through the v2 file contract elements, add any confirmed or revised v2 state elements, then update the proofs.

Mostly because it is very consistent with what we already have in the protocol. Where the renter doesn't need to know anything about revisions and the host provides all the information (e.g. proofs) to revise contracts.

Storing works as well of course. Just with the minor downside of only the participants of the contract formation being the ones who can broadcast a revision versus anyone.

@n8maninger
Copy link
Member

Where the renter doesn't need to know anything about revisions and the host provides all the information (e.g. proofs) to revise contracts.

The renter tracks contract status in the chain indexing, adding state elements to that is not that big of a change. Relying on the host for Merkle proofs means the renter won't be able to get their funds back if the host is offline at expiration.

Just with the minor downside of only the participants of the contract formation being the ones who can broadcast a revision versus anyone.

That's not really different from how it works today.

@lukechampine
Copy link
Member

lukechampine commented Nov 26, 2024

I am sympathetic, but I think I side with Nate. Including the proof seems to make life easier for lightweight us-style renters — but lightweight renters necessarily need to rely on 3rd party services like shard and muse. In that vein, I imagine that there will be a 3rd party service (perhaps the explorer?) that provides the Merkle proof for any requested element.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants