-
Notifications
You must be signed in to change notification settings - Fork 106
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
Use CheckTx in transaction scheduler #2502
Conversation
de8651c
to
26f1d72
Compare
b866af2
to
8db92a6
Compare
go/worker/txnscheduler/worker.go
Outdated
) | ||
continue | ||
} | ||
if rt.Capabilities.TEE, grr = workerHost.WaitForCapabilityTEE(w.ctx); grr != nil { |
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 found the reason for why SGX tests are not working in this PR. So all batches are being rejected due to the following error:
roothash/commitment: batch RAK signature invalid
This is because here you actually overwrite the RAK that is registered for the compute runtime (by the compute worker's RegisterRole
handler). And since each enclave has its own RAK this makes all signatures for the compute enclave invalid.
The solution is either to:
- Support multiple enclaves to be registered for the same runtime in the node descriptor (e.g., multiple RAKs per runtime per node), for different purposes (e.g., one for compute and another one for txnscheduler).
- Remove this for loop so that only the enclave for compute is registered. There is no need to register the txnscheduler's RAK in the registry as this runtime is only used for local checks and it doesn't actually sign any batches.
I would be in favor of option two as it is much simpler and the txnscheduler runtime is only used for CheckTx, which currently doesn't sign the results using RAK. If we later desired to verify that the scheduler actually performed CheckTx, we could do add this later.
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.
Ah, that makes sense! I'll fix it. Thanks for the help!
8db92a6
to
2521985
Compare
Codecov Report
@@ Coverage Diff @@
## master #2502 +/- ##
==========================================
+ Coverage 67.24% 67.25% +0.01%
==========================================
Files 328 328
Lines 30184 30262 +78
==========================================
+ Hits 20296 20352 +56
- Misses 7386 7398 +12
- Partials 2502 2512 +10
Continue to review full report at Codecov.
|
2521985
to
09df97e
Compare
09df97e
to
c5b3d61
Compare
go/worker/common/runtime_host.go
Outdated
n.commonNode.CrossNode.Lock() | ||
defer n.commonNode.CrossNode.Unlock() | ||
|
||
return *n.commonNode.CurrentBlock |
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.
This seems dangerous, what if the block is nil?
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.
The way it was used previously, this couldn't happen, I think, but I've now removed this code, since it's no longer needed, as CheckTx is done in the node code.
c5b3d61
to
b5106ee
Compare
@@ -128,6 +136,59 @@ func (n *Node) HandlePeerMessage(ctx context.Context, message *p2p.Message) (boo | |||
return false, nil | |||
} | |||
|
|||
// CheckTx checks the given call in the node's runtime. | |||
func (n *Node) CheckTx(ctx context.Context, call []byte) error { | |||
if n.commonNode.CurrentBlock == nil { |
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.
Accessing the CurrentBlock
requires holding the CrossNode lock if called outside of methods which assume the caller does so (e.g., the ones ending in Locked
).
// Interpret CheckTx result. | ||
resultRaw := resp.WorkerCheckTxBatchResponse.Results[0] | ||
var result transaction.TxnOutput | ||
cbor.MustUnmarshal(resultRaw, &result) |
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.
Why panic on unmarshal? It should log the error and return ErrCheckTxFailed
.
if n.checkTxEnabled { | ||
// Check transaction before queuing it. | ||
err := n.CheckTx(ctx, call) | ||
if err != nil { |
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.
Could be if err := n.CheckTx(...); err != nil { ...
.
b5106ee
to
84f9f98
Compare
Fixed! Ready for re-review :) |
84f9f98
to
25e1f50
Compare
Closes #1963.
TODO: