-
Notifications
You must be signed in to change notification settings - Fork 115
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
messages from roothash mux app #2147
Conversation
8a43a38
to
2af53df
Compare
2af53df
to
56d2f56
Compare
56d2f56
to
976e4d9
Compare
Would it make more sense for the messages to be in the |
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.
Who will get slashed for reverting a round due to roothash messages not being accepted?
maybe transaction scheduler, if we would add a rule that it must know that the sent roothash messages will be satisfactory. |
dunno. I can't tell why there's even a separation between block and header |
Yeah that's a good point, so previously bulk data was in the block while the header only included hashes. I guess this doesn't really make sense and maybe we should just remove one of the two to make stuff simpler. From this standpoint just leave it in the header and maybe open an issue to remove/combine. |
I've opened #2241. |
a4b3ce8
to
1e9e0eb
Compare
Updates: now there's a prototype of loading an acceptable transfer peer policy from the genesis file. This adds a field that's a whitelist of runtime IDs. |
45dbf40
to
1f16a93
Compare
1f16a93
to
f5c67f6
Compare
Codecov Report
@@ Coverage Diff @@
## master #2147 +/- ##
=======================================
Coverage 53.79% 53.79%
=======================================
Files 263 263
Lines 28049 28049
=======================================
Hits 15088 15088
Misses 11430 11430
Partials 1531 1531 Continue to review full report at Codecov.
|
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 useful to have an end-to-end test for roothash messages, so that the whole pipeline is tested.
f5c67f6
to
611cf05
Compare
611cf05
to
d2ca69e
Compare
eeffcba
to
99a3f87
Compare
added an e2e test. please review |
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.
Just minor nits.
// acceptableTransferPeersKeyFmt is the key format used for the acceptable transfer peers set. | ||
// | ||
// Value is a CBOR-serialized map from acceptable runtime IDs the boolean true. | ||
acceptableTransferPeersKeyFmt = keyformat.New(0x55) |
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.
I assume the size of this map is expected to be small (on the order of number of runtimes)? Another option would be to have the entries be stored in the tree -- e.g., one key per entry:
keyformat.New(0x55, &signature.MapKey{})
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.
Right, that's the expectation. Thanks for posting another option. Let's keep that in mind so we can later support a large number of acceptable runtimes if we want to.
for _, result := range results { | ||
ioRoots = append(ioRoots, result.IORoot) | ||
stateRoots = append(stateRoots, result.StateRoot) | ||
|
||
// Merge roothash messages. | ||
// The rule is that at most one result can have sent roothash messages. |
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.
Added to list of slashing conditions for the transaction scheduler.
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.
thanks
|
This adds a "roothash messages" field to the compute pipeline. A runtime would be able to send them, and they propagate into a block header.
Roothash messages are stored inline in the block header, rather than in storage.
This implements the simple merging algorithm, where up to one compute committee can send roothash messages.
This adds the staking general balance adjustment message, which causes the staking mux app to adjust an account's general balance.
There's a dummy acceptable transfer peer policy to control what runtimes can send these staking general balance adjustment messages. It accesses a set of approved runtime IDs in the genesis document.
TODO:
blocks #2077
context https://github.com/oasislabs/private-rfcs/pull/144
fixes #2230
fixes #2231