-
Notifications
You must be signed in to change notification settings - Fork 167
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
PublishBlob #2014
PublishBlob #2014
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @andresilva91 and the rest of your teammates on Graphite |
3255a2b
to
d32dcc5
Compare
Graphite Automations"Assign reviewers" took an action on this PR • (05/14/24)6 reviewers were added to this PR based on Andre da Silva's automation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Servers must never trust blob IDs that were submitted by a client. In my view the safest way to do this is to not make them part of the serialized block proposal or certificate request.
979622e
to
9e44e1a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll also need to store the pending blobs associated with the client's pending block in the wallet, together with the block, to be able to re-propose it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to test a few cases on a multi-owner chain (can be in a different PR):
- Client A makes a block proposal with a blob. One validator is down. The other three validated the block but don't confirm it. Now the validator comes back up but another one goes down. Client B (who doesn't have the blob) then re-proposes that block in the next round.
- Client A proposes a block with a blob, and it gets confirmed, but one of the four validators is down and doesn't learn about it at all. Then that validator comes back up but another goes down (so now only two are up and have the blob). Client B proposes a child of that block.
In both cases client B should succeed, and update the validator as needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to have the tests in a separate PR.
Motivation
Currently users are able to upload bytecode that can be used to create applications. Other chains have to subscribe to the publisher chain to be able to use the bytecode. We want to generalize this so that:
Proposal
This PR implements the
PublishBlob
operationTest Plan
Unit test
Release Plan
Since we're adding a new
SystemOperation
, I'm guessing we have to do this: