[[ ":$PATH:" != *":$HOME/.bky:"* ]] && export PATH="$PATH:$HOME/.bky"
ln -sf "$HOME/.bky/bky-as-v0.1.0-beta.13" "$HOME/.bky/bky-as"
git clone --branch main git@github.com:blocky/attestation-service-examples.git
cd attestation-service-examples/attest_fn_call
bky-c build --reproducible . ./main.wasm
cat fn-call.json | bky-as attest-fn-call > out.json

## Overview

We have successfully made an
[attested function call](/attestation-service/tutorials/attest-a-function) with the Blocky AS CLI and
received the function's purported output. Before we *trust* that output, however,
we should first verify that:

- it was our function that was executed and
- it was executed by a Blocky AS server and
- that server was running in a TEE


## Verify a WASM Function

1. Let's start by looking at the entirety of the output returned by
`bky-as attest-fn-call`:
jq -r '.' out.json
The JSON output consists of two main entities: an enclave attestation
containing the Blocky AS server's public key and a transitive attestation
containing our function's inputs and outputs. The enclave attestation is
used to verify the TEE platform and Blocky AS server code, whereas the
transitive attestation is used to verify our function call.
2. To verify the attestations, we need to provide `bky-as` with the
expected TEE platform and Blocky AS server code measurement. This information
is passed in via the `config.toml`:
cat config.toml
The TEE platform and code measures here are "plain" because our example is
configured to start and run a local non-TEE development server.
In production, however, you would specify a real Blocky AS server endpoint,
code measure, and TEE Platform (which we cover in
[Get a Developer API Key](/attestation-service/tutorials/developer-portal)).
3. Extract the enclave and transitive attestations from the output and pass
them to `bky-as verify-fn-call`, where it will use the values in our config
to validate the attestations.
jq '{
enclave_attested_application_public_key: .enclave_attested_application_public_key.enclave_attestation,
transitive_attested_function_call: .transitive_attested_function_call.transitive_attestation
}' out.json | bky-as verify-fn-call > verified.json
4. If both attestations are authentic and correct, `bky-as verify-fn-call` will
output the now verified function claims.
jq -r '.transitive_attested_function_call.claims' verified.json
5. The `bky-as verify-fn-call` only verifies that the enclave and transitive
attestations were made by a Blocky AS server running within a TEE. It is
your responsibility to use those transitively attested claims to verify
that the `hash_of_code`, `hash_of_input`, and `hash_of_secrets` match
your function code and call arguments.
openssl dgst -sha3-512 ./main.wasm
echo -n "" | openssl dgst -sha3-512
Since we did not pass any input or secrets to our function, an empty value
is used when calculating `hash_of_input` and `hash_of_secrets`.


## Next Steps

If you would like to learn more about TEEs and the attestation and verification
process, check out
[Trusted Execution Environments](/attestation-service/concepts#trusted-execution-environments)
in our Concepts section. Otherwise, continue on to the next section where we show
you how to get a free developer API key so that you can run your functions
on real Blocky AS servers and TEEs.

rm -rf attestation-service-examples