Randomness is critical to many application ranging from statistical sampling to games to cryptography. [Randomness](https://en.wikipedia.org/wiki/Randomness) is defined to be void of any predictability and sequential randomness should have no order. Yet, randomness is hard to come by to begin with and even more so in open, permissionless systems where we want not only randomness but verifiable randomness. In our [VRFun](../vrfun/) example, we illustrate how [Verifiable Random Functions](https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Pseudo%20Randomness/Verifiable_Random_Functions.pdf) can be used to satisfy this requirement. However, using the implemented VRF requires the user to provide (a one-time) secret key introducing a significant, and in most cases untenable, element of trust.
[Drand](https://drand.love/), a verifiable randomness beacon provided by the [League of Entropy](https://en.wikipedia.org/wiki/League_of_entropy) every 30 seconds, provides randomness as a decentralized service and is already utilized by the likes of [Filecoin](https://spec.filecoin.io/libraries/drand/) in production environments. Since Drand can greatly help Fluence developers to introduce proper randomness into their applications, we provide Marine wrappers for both the Drand HTTP API and verification logic.
Wrapping the Drand HTTP API with Marine is straight forward and only requires the [curl module](./services/curl_adapter/) as a dependency to our [drand service](./services/drand). As you can see when inspecting [main.rs](./services/drand/src/main.rs), the service closely follows the Drand HTTP API with some adjustments made in the return data structures. See the *test* section for usage examples.
You compile the service code with [build script](./services/scripts/build.sh), which places the Wasm files in the [artifacts](./services/artifacts/) directory. Once the Wasm modules are created, we can run the tests with the *cargo test* command in the [drand dir](./services/drand/). Recall that we are using the [marine test sdk](https://crates.io/crates/marine-rs-sdk-test), which requires the existence of the Wasm module(s).
Let's get the chain hash for good measure using one of the public endpoints provided by the Drand [developer documentation](https://drand.love/developer/http-api/#public-endpoints):
which gives us a list of (one) chain hashes we need in order to parameterize any of the subsequent HTTP calls. Feel free to work yourself up to the *latest* and *round* methods.
Now that we have a functional Wasm adapter for the Drand HTTP API, we can deploy our Wasm modules as services to one or more peers. Note that we deployed the following services which may or may not be available by the time you read this:
binds to the *chains* Wasm method we just explored with the local REPL. Take a minute and walk through the code and compare it to your REPL experiments. These functions give you the tools to build a randomness construct suitable to your use case and environment.
In the [examples](./aqua/drand_examples.aqua) file, we provide two Drand use examples. The *verified_randomness* function splits the randomness getter and verifier across different peer/service instances to further minimize the any peer shenanigans. Using the above services:
which gives us back the verification state, true, and the randomness from both the *latest* getter and the *verify* result, which we expect to be the same.
The second example, the *verified_randomness_plus* function, extends the previous example and explicitly gets the prior (to latest) round to validate the signature chain as an additional check. Recall, *previous_ signature* at round<sub>t</sub> is the *signature* at round<sub>t-1<sub>:
