The Blocky Compiler supports building with cached dependencies for faster compilation times. Additionally, the Blocky AS CLI provides a local non-TEE server that executes functions and returns mock attestations. Together, these functionalities allow developers to quickly and cheaply write functions for Blocky AS.
By using these mechanisms you are potentially creating inconsistent WASM binaries and fake TEE attestations. Do not use these mechanisms in your production pipelines.
The Blocky Compiler is configured to use cached dependencies by default. The first compilation may be slow if you do not already have the necessary dependencies on your system, but subsequent builds use those cached dependencies and as a result take less time. See for yourself by building one of our examples:
Clone the Blocky AS examples repository and navigate to the
attest_fn_calldirectory:git clone --branch main git@github.com:blocky/attestation-service-examples.git cd attestation-service-examples/attest_fn_callCompile main.go twice and use a tool such as
timeto capture how long each compilation takes:time -f $'Build completed in %e seconds\n' bky-c build . ./main.wasm time -f $'Build completed in %e seconds\n' bky-c build . ./main.wasmwhich outputs
Build completed in 11.97 seconds Build completed in 7.34 seconds
When you are finished developing and wish to use your function in production, you should recompile with the --reproducible flag. This forces the compiler to download all dependencies regardless of whether they already exist on your system.
bky-c build --reproducible . ./main.wasmThe Blocky AS CLI tool includes a non-TEE server implementation that provides the same WASM host functionalities that our real TEE-servers do. Our WASM environment allows your functions to log messages, make HTTP calls, verify attestations, and more. By using the local non-TEE server, you can test the behavior of your functions in our WASM environment without having to make calls to a real Blocky TEE server. To develop with a local non-TEE server, update the host string in your config to "local-server" as shown below:
# a set of acceptable server enclave measurements for CLI to interact with
acceptable_measurements = [
# a measurement that is valid for when the server is running on a non-TEE environment
{ platform = "plain", code = "plain" },
]
# token authorizing CLI's access to the server
auth_token = "BLOCKY AS API TOKEN"
# the server that the CLI interacts with.
# `local-server` is a special host value that will start a local attestation
# service server for testing and development. To interact with a production
# server, replace `local-server` with the appropriate server endpoint.
host = "local-server"Now when you invoke bky-as attest-fn-call, a local non-TEE server is started that handles your function call instead of a Blocky AS TEE server. After executing your function, the server returns a mock attestation containing the function output and exits. These mock attestations will successfully verify with bky-as verify-fn-call, but remember they are not real TEE attestations. They are provided to ease development and testing, but do not come with any of the security, integrity, or confidentiality guarantees associated with real TEEs.
The local server only works with the
attest-fn-callandverify-fn-callcommands. It does not work with theplumbingcommands.
You are now set up to quickly compile and test applications against a local Blocky AS server. For more information on our WASM runtime, see our Limitations page. Check out our examples repository to see the different types of applications you can build with Blocky AS.