• #30

Background

We need to define a message which includes the smart contract address, payload and coins, along with the message’s unique ID. This message is to be used for the signing queue.

This differs from the “public” message where users define their jobs.

Done when

• Message is defined in the protobuf

1. Acceptance Criteria
   1. Ability to sign an arbitrary message w/ private key.

Background

There are a couple of usecases we need to solve for message signing from the runners perspective:

• Messages broadcasted to other chains (in this case Terra), need to be signed. We need a way to sign a CosmWasmExecute message from the runner’s perspective.
• We also need to sign messages in the CosmWasmExecuteMsg format that we are signing to get 2/3 of signatures back.
• And also, we need to sign the message to update the validator set to get a network concensus.

Done when

• We can sign any arbitrary sdk.Msg and also verify signatures
• We allow user to load keyring path in which they have their terra keys stored which is going to be used for message signing.

Background

Once user submits a message for execution, we need to have a way for all validators to get new messages that need to get signed, and a way for them to submit their signatures.

The validators also need an endpoint to get messages which have reached a consensus and are ready for execution.

Done when

• #50 and these tasks should be done together:
  • We have a query endpoint that can (given a validator’s address) return messages (emphasis on plurality) that need to be signed for the given validator.
  • We have a TX endpoint to which runners can submit signatures along with the messages that they have signed.
  • We have a query endpoint to query messages that have reached the consensus.
• A way to add message to the signing queue (for internal usage)
• A way to remove message from the signing queue (for internal usage)

Background

This is a top level ticket for runner configuration. Users should be able to customize their runners via configurations. Details should come in separate tickets.

Done when

• there is a configuration for runners and runners are using the said configuration
• the configuration is documented
• we can't know all configuration required right now, but should build a way to have a support for it in the future

As Volume, we want to have the right slashing parameters in place so that malicious behavior on the validator side is prevented, while risk for them is low enough to they remain engaged and are motivated to stake.

Acceptance Criteria

Slashing amounts / parameters / punishments

• 5% for signing a fake validator set or message, double sign, etc.
  • Will only be slashed once, then the validator should be jailed
• 5% for failure to sign a message or validator set

  • Will only be slashed once, then the validator should be jailed

• 1% for a downtime of 10k blocks (~13h)
  • → Jailing is very important in this case (as it preserves network uptime)
• Jailing

As a User I want to have control over my scheduled messages so that I can make sure my messages run optimally.
Acceptance Criteria
1. Submission of the new jobs
2. Pause
3. Resume
4. Modify
5. Delete

Acceptance Criteria

1. Functional UX
2. Mainnet
3. Basic functionality in place:
    1. Ability to define host chain
    2. Ability to define target chain
    3. Ability to submit payload
    4. Ability to execute

• #30
• #31
• #34
• #32
• #38
• #35

Depends on

• #83

Background

Once we have reached a consensus, we need to send those messages to our smart contract.
Should be done after #50

Done when

• this ticket is done: #50
• we execute a smart contract with those messages that have reached consensus

1. Acceptance Criteria
   1. Attestator Go Routine able to attest TXn on Terra Network
   2. Also needs ability to attest Txn NOT happening
   3. Sends report

Background

Define a message that’s used to update validator sets on our CosmWasm smart contract. The message needs to have a validator’s address and their staking power (in absolute terms).

Done when

• Message is created as a protobuf message.

Background

Given that we are doing polling from the runner’s perspective, we need to have the (so called) main loop, in which we can query messages for signing & broadcasting. This is the beating heart of a runner.
We also need to organize code a bit better. So far, the code has been written mostly as something that we are using to test the idea.

Done when

• When runner is started, the main loop is started as well.
• project is organized a bit better

1. Acceptance Criteria
   1. Broadcast Txn for execution of smart contracts
   2. Ability to Query Txn by ID

Background

As testing is really important, we don't want to submit any PR that breaks tests. We also don't want to merge broken PRs.

Done when

• we have a basic go test running on every branch
• disallow merging PRs without the test action passing

Background

Currently, we are using "raw" BroadcastTX when communicating with chains from the runner instance. We should take the GRPC server&client proto definition instead and communicate with the server like that. Same goes for running queries.

Done when

• we can execute transactions on other chain from runner via their grpc server
• we can query other chain from runner via their grpc server

V1 Features

Ability to

• Specify host chain
• Specify target chain
• Specify Target Contract
• Specify Message Payload
• Submit message

1. Acceptance Criteria
   1. Some sort of logic to assign Jobs to Validators (TBD)
   2. Ability to keep track of which jobs are active and which ones are inactive
   3. Given a list of active jobs find jobs which need to get executed next

Background

We need to communicate with the Terra chain from within our runners which are a part of a FedEx chain (a sidecar process/goroutine).

We need to have a chain to query and broadcast transactions over the wire to other chain.

Given that there already exists a library that does this (LENS, by Strangelove) we don’t need to implement this ourselves.

Done when

• we have imported lens library and verified that it works.

Background

We need to build a tool in the runner to query messages that need to be signed by the runner itself so that consensus can be reached. We also need to submit those signatures back to the chain to store them.

Done when

• we can query for messages from our chain that need to be signed from the runner
• we can submit signatures for messages that we have queried from the runner

1. Acceptance Criteria:
   1. Starting Runner Go routine when the validator starts
   2. Runner Go routine should print to screen that it’s up

Background

Currently, when running tests, go needs to download all dependencies. This takes about 1min and 40seconds on our CI.

Proposed solution

Add action/cache in between multiple runs to speed up the tests.

Background

When creating a new ChainClient using lens library, the keyring in background expects user to enter password.
This is all fine but this cannot work for our usecase because runners will be executed as a long running process
which should be able to restart itself if there ever is a failure. That would mean that validator/user would need to manually
enter their password every time.

Mind the "userInput" argument: https://github.com/cosmos/cosmos-sdk/blob/df8745909c9d973d3ddad7400140ec42ca17a316/crypto/keyring/keyring.go#L172
This asks user for password via stdin, and then stores the password in memory.

A proposal is to inject the password via ENV variable and store it in memory instead of user having to enter their password every time.

Done when

• user doesn't have to enter their password via stdin for runner to get access to keyring