feat: Randomness module

[hacheigriega]

Motivation

This PR fully implements the randomness module, which will be used as a source of randomness in SEDA protocol.

An example of a query:

$ seda-chaind query randomness seed
block_height: "7"
seed: 3e97ad3fea6ec9211b279fdf2bc26dd6b730fb3bc8a7f3400363e6500e4a86af

Explanation of Changes

The implementation takes advantages of two CometBFT ABCI methods: PrepareProposal, which is run only by the block proposer while building a block, and ProcessProposal, which is run by all validators while validating a block. In PrepareProposal the proposer computes the VRF proof by running VRF_Prove(secret_key, alpha), where secret_key is the consensus key and alpha, or the input message, is previous_seed || current_block_timestamp. The block proposer then signs and prepends the NewSeed transaction containing the VRF proof pi and the VRF hash output beta to the list of transactions in the block proposal.

Upon receiving this nicely prepared proposal in ProcessProposal, the validators first check if the first transaction in the list is the NewSeed sent by the current block proposer. If the check fails, they reject the block. If the check succeeds, the validators then run VRF_Verify(public_key, pi, alpha) with the public key obtained from the validator store. The validator accepts or rejects the block based on the verification result.

• Consensus key is now generated using secp256k1 instead of ed25519 so that it is compatible with our VRF library.
• Added a wrapper around x/staking message server to create a regular account based on the consensus key during create-validator transaction. A regular account is required when the block proposer signs and sends a NewSeed transaction.
• The process fails on average after a few hundred blocks due to a bug in the vrf-go repo. There seems to be something wrong with scalar arithmetics.

Testing

Tested on a local single-node chain deployed manually and a two-node chain in e2e testing. In a single-node setting, the only proposer gets stuck due to the VRF bug and blocks don't get produced after some point. In a multi-node setting, this problem is prevented by the next proposer successfully creating a valid block.

To run the e2e test, create .netrc file in the project root and add the credentials for GitHub private repository access:

machine github.com
        login <YOUR_USERNAME>
        password <YOUR_GITHUB_TOKEN>

Then run make test-e2e. (Currently not working due to a Cosmos SDK genesis JSON marshalling error.. Should be fixed soon. e2e works locally now but all CI tasks are failing due to issues with downloading the vrf-go repo, which is private.)

Related PRs and Issues

Closes #112

[gluax]

Comments on the .netrc stuff, otherwise LGTM.

[gluax]

Two things:

1. Do you know if this is secure? I.e., does no command print out the GitHub username/token from the container?
2. Can we not use a .env file instead?

Either way, an example file would be nice, like example.netrc or e2e.example.env. Then in the md you can link to the example file :).

[hacheigriega]

The build process doesn't print it out, and the container just contains the file. Probably not ideal, but it's not any less secure than other commonly suggested solutions.

[jim380]

In this case we probably wouldn't need to worry about the mempool at all. CometBFT is responsible for selecting txns from the mempool and proposing them in a new block. PrepareProposal then receives the proposed txns.

We are also already directly including the new seed txn in the proposal by which point we'd have bypassed the mempool already.

[jim380]

We definitely need to do some stateless checks here. We are using msg.Pi and msg.Beta below without checking their legitimacies first. If msg.Pi and/or msg.Beta is an empty string, hex.DecodeString will return an empty byte slice and no error. This would bypass the if err != nil {} checks and lead to a panic due to !bytes.Equal(beta, msgBeta).