update schema to hold randomness entries and syscall results. #80
Conversation
raulk
left a comment
raulk
left a comment
There was a problem hiding this comment.
Let's hold off on this one until we have a better sense of where and how the randomness and the syscalls are actually used. It's possible we won't need to be so explicit. If we design this right, and couple it with concrete functions, we might be able to simplify and design a solution that's a lot more context sensitive.
alanshaw
left a comment
alanshaw
left a comment
There was a problem hiding this comment.
Please can we have a title and/or description for the new definitions in the JSON schema?
| "additionalProperties": false, | ||
| "properties": { | ||
| "name": { | ||
| "type": "string" |
There was a problem hiding this comment.
Is there a defined list of syscall names we can restrict this to?
| "$ref": "#/definitions/base64" | ||
| } | ||
| }, | ||
| "syscall": { |
There was a problem hiding this comment.
Just to clarify my understanding:
- Syscalls are calls that are expected to be made when a message is applied?
- Presumably they're not implementation specific? i.e. all implementations have the same syscalls with the same names.
- The driver in the implementation can optionally verify these calls were made during message application - correct?
- Some(all?) calls, like for randomness, must return a specific value, as defined in the
randomnesssection.
I think it would be useful to document the expected behaviour for driver implementers in the README, or perhaps we need a separate markdown file for this info?
There was a problem hiding this comment.
randomness may get used in some implicit contexts as well, which is why it's split out, it also should make sense that it's immutable for a requested epoch, rather than being memoized per request.
For the expected syscalls, we currently only stub out a minimal set in the lotus driver, but it seems like the full lotus runs with a larger set. I imagine there is a full enumeration of that expected surface area somewhere?
verification of order and calls seems like a thing the driver can/should do.
(1/3)
This extends the test-vector schema to allow messages to optionally list syscalls and expected return status, along with defined random values to respond when queried.
Once defined, the lotus driver in the pending 'conformance' PR can be extended to return these values when provided, then tests can begin populating the fields.