Skip to content

Latest commit

 

History

History
91 lines (61 loc) · 4.21 KB

4.6.2-tocw-demo.md

File metadata and controls

91 lines (61 loc) · 4.21 KB

4.6.2 TOCW demo

The offchain-worker demo shows indirect invocation with 2 offchain-worker instances running. The demo sets up an Integritee Node (layer 1 chain) and runs 2 workers that both execute transactions submitted to the layer 1 chain (parentchain) - which is called indirect invocation.

The CLI client (called by a script) is then used to perform transactions and query state for the Alice and Bob accounts. Transactions like balance_transfer are encrypted and then submitted to the parentchain. An offchain-worker then imports the parentchain block (upon finalization), decrypts and executes any transactions it finds. Both offchain-workers execute these transactions in parallel, there is no exchange of state or transaction information (like there is for the sidechain validateer).


The sequence in the demo is as follows:

  1. Create incognito accounts for Alice and Bob, these are not disclosed to the public
  2. Shield funds on Alice's account, i.e. moving funds from Alice's public, on-chain account to her incognito account
  3. Transfer a fraction of the funds on Alice's incognito account to Bob's incognito account
  4. Un-shield the remaining funds on Alice's incognito account, moving them back to Alice's on-chain account
  5. Check balances on Alice's public on-chain account and her incognito account

The demo executes this sequence twice and verifies the balances are correct after each run.

For those who are interested in the demo script, can find it here.

Run the off**-**chain-worker demo

The demo is executed in docker to set up the the Integritee node and the workers, but it essentially runs the demo_indirect_invocation.sh script to interact with the off-chain workers.

In order to run the demo, clone the worker repository:

git clone https://github.com/integritee-network/worker.git

Change directory to

cd docker

Build all necessary images in the docker-compose setup, with (takes upwards of 10 minutes, depending on your hardware):

{% code overflow="wrap" lineNumbers="true" %}

COMPOSE_DOCKER_CLI_BUILD=1 DOCKER_BUILDKIT=1 docker compose -f <(envsubst < docker-compose.yml) -f <(envsubst < demo-indirect-invocation.yml) build --build-arg WORKER_MODE_ARG=offchain-worker --build-arg ADDITIONAL_FEATURES_ARG=dcap --build-arg SGX_MODE=SW

{% endcode %}

Run the demo in the docker-compose setup

{% code overflow="wrap" lineNumbers="true" %}

export ADDITIONAL_RUNTIME_FLAGS="--skip-ra"
export FLAVOR_ID=offchain-worker 
docker compose -f <(envsubst < docker-compose.yml) -f <(envsubst < demo-indirect-invocation.yml) up demo-indirect-invocation --exit-code-from demo-indirect-invocation

{% endcode %}

You will see log output from the two workers and the demo service. First worker 1 will startup and initialize. Worker 2 waits until worker 1 is fully up and running and then starts up. The demo service again waits for worker 2 to be fully up before running. This whole process can take a couple of minutes and will automatically shut down once the demo script ran through.

Output like

integritee-worker-2    | 2022/07/20 13:50:56 Waiting for http://integritee-worker-1:4645/is_initialized: unexpected HTTP status code: 404.

is to be expected, it results from the service integritee-worker-2 polling and waiting until integritee-worker-1 is initialized (the same will appear for the demo service, with respect to worker-2).

To see the logs of a specific container, use

docker logs fd-integritee-worker-1--1 -f
docker logs fd-demo-indirect-invocation-1 -f

A successful demo run will show

fd-demo-indirect-invocation-1  | -----------------------
fd-demo-indirect-invocation-1  | ✔ The second test passed!
fd-demo-indirect-invocation-1  | -----------------------

at the end of the log output, before the docker containers are stopped.

Use

{% code overflow="wrap" lineNumbers="true" %}

docker-compose -f <(envsubst < docker-compose.yml) -f <(envsubst < demo-indirect-invocation.yml) down

{% endcode %}

to clean up all the container context (including logs).