### Starting HyperBEAM

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/hacking-on-hyperbeam.md

Starts the HyperBEAM shell using rebar3, loading necessary modules and initializing the HTTP server. Environment variables can be set to configure the store, key, and port.

```shell
rebar3 shell
```

--------------------------------

### Example Workflows with Converge API

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/converge-http-api.md

Provides practical examples of using the Converge HTTP API with `curl` for common operations like retrieving routes, scheduling messages, running WASM executables, and managing process states.

```curl
Get current routes:
curl http://host:port/Routes
```

```curl
Set a route:
curl -X POST http://host:port/Routes -H "Priority: 10" \
    -H "Node: http://host:port" -H "Template: /Some/New/Path"
```

```curl
Schedule a message on a process:
curl -X POST http://host:port/ProcID/Schedule -H "Action: Transfer" \
    -H "Recipient: Address" -H "Quantity: 1337"
```

```curl
Run a WASM executable:
curl -X POST http://host:port/Init/Compute -H "Device: WASM-64/1.0" \
    -H "2.WASM-Function: fac" -H "2.WASM-Params: [10]" -d @test/test-64.wasm
```

```curl
Execute further messages on a WASM result:
curl http://host:port/Hashpath/Compute/Results -H "WASM-Function: fac" \
    -H "WASM-Params: [11]" -d @test/test-64.wasm
```

```curl
Assign a message from one process's outbox to another's schedule:
curl -X POST http://host:port/ProcID2/Schedule+Message= \
    (/ProcID1/Compute+Slot=1/Results/Outbox/1)
```

```curl
Load WASM computation from a hashpath:
curl -X POST http://host:port/Init/Compute \
    -H "1.WASM-Image|Resolve: /OldHashpath/Snapshot/WASM" \
    -H "2.WASM-Function: fac" -H "2.WASM-Params: [10]"
```

```curl
Fork a process to use a new device:
curl -X POST http://host:port/Schedule!Process/2.0/(/ProcID/Now)+Method=POST
```

```curl
Run multiple computations with separate headers:
curl -X POST http://host:port/Init/Compute/Compute -H "Device: WASM-64/1.0" \
    -H "2.WASM-Function: fac" -H "2.WASM-Params: [10]" \
    -H "3.WASM-Function: fac" -H "3.WASM-Params: [11]" \
    -d @test/test-64.wasm
```

```curl
Equivalent of multiple computations request:
curl http://host:port/Init+Device=WASM-64/1.0+Image=ID/Compute+ \
    WASM-Function=fac+WASM-Params=[10]/Compute+WASM-Function=fac&WASM-Params=[11]
```

```curl
Gather node's attestations on a process output:
curl http://host:port/ProcID/Compute+Slot=1/Results/Attestations
```

```curl
Dry-run a message on AO process state:
curl -X POST http://host:port/ProcID/Compute \
    -H "Action: Balance" -H "Recipient: Address"
```

--------------------------------

### Path Resolution Example

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/converge-protocol.md

Illustrates how paths are resolved in the Converge protocol by sequentially applying messages.

```APIDOC
/StartingID/Input1ID/Input2ID/Input3ID =>
	/{Converge.apply(StartingMsg, Input1)}/Input2ID/Input3ID =>
	/OutputID1/Input2ID/Input3ID =>
	...
	/Output3ID
```

--------------------------------

### Hashpath Derivation Example

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/converge-protocol.md

Illustrates how a hashpath is derived by applying a hashpath algorithm to previous hashpaths and message IDs. This demonstrates the Merklized structure of data in Hyperbeam.

```text
Message3/Hashpath :: Converve.apply(Message3/Hashpath-Alg, Message1/Hashpath, id(Message2))
```

--------------------------------

### Start Grafana and Prometheus Locally

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/gathering-metrics-locally.md

This snippet shows how to bring up Grafana and Prometheus using Docker Compose. After running these commands, Grafana will be accessible at http://localhost:3000 (default credentials: admin/admin) and Prometheus at http://localhost:9000.

```shell
cd ./metrics
docker-compose up -d
```

--------------------------------

### Packer Build Commands

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/DEPLOY-notes.md

Commands to initialize, validate, and build images using Packer.

```shell
packer init .
packer validate .
packer build .
```

--------------------------------

### Erlang Project Build Commands

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/DEPLOY-notes.md

Commands to clean, fetch dependencies, compile, and release an Erlang project using rebar3.

```shell
rebar3 clean
rebar3 get-deps
rebar3 compile
rebar3 release
```

--------------------------------

### GCP Instance Variables

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Defines environment variables used for configuring and creating GCP instances, including instance name, project ID, image, and zone.

```sh
export GCI_NAME=PETES-SEV-SNP-TEST-0
export GCI_PROJECT=arweave-437622
export GCI_IMAGE=packer-1730219529 
export GCI_ZONE=us-central1-a
```

--------------------------------

### GoTPM Attestation Dual-Layer Explanation

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Explains the necessity of providing both `--nonce` (for TPM attestation) and `--tee-nonce` (for TEE attestation) in the `gotpm attest` command when dealing with confidential VMs that support both TPM and TEE security layers.

```APIDOC
GoTPM Attestation:

Command: `sudo gotpm attest --key <key> --nonce <nonce> --tee-nonce <tee_nonce> --tee-technology <tee_technology>`

Description:
Performs attestation on a confidential VM, validating both the Trusted Platform Module (TPM) and the Trusted Execution Environment (TEE) layers. This ensures the freshness and integrity of attestation reports from both security domains.

Parameters:
- `--key <key>`: Specifies the attestation key (e.g., AK).
- `--nonce <nonce>`: A 32-byte (64 hex characters) nonce for the TPM attestation layer. This parameter prevents replay attacks on the TPM quote.
- `--tee-nonce <tee_nonce>`: A 64-byte (128 hex characters) nonce for the TEE attestation layer (e.g., SEV-SNP or TDX). This parameter ensures the freshness of the TEE-specific attestation report.
- `--tee-technology <tee_technology>`: Specifies the TEE technology being used. Accepted values are `sev-snp` for AMD SEV-SNP or `tdx` for Intel TDX.

Rationale for Dual Nonces:
- The `--nonce` is crucial for the TPM attestation, which is a standard part of the attestation process and includes a TPM quote.
- The `--tee-nonce` is specifically required for the TEE attestation, providing a freshness proof for the hardware-isolated environment (SEV-SNP or TDX).
- Both nonces are necessary because the `gotpm attest` command generates a comprehensive attestation report that incorporates evidence from both the TPM and the TEE, requiring separate freshness proofs for each.

Example Usage:
```sh
sudo gotpm attest --key AK --nonce "a1b2c3d4e5f6..." --tee-nonce "0123456789ab..." --tee-technology sev-snp
```

Related Commands:
- `head -c 32 /dev/urandom | xxd -p -c 64` (for generating TPM nonces)
- `head -c 64 /dev/urandom | xxd -p -c 128` (for generating TEE nonces)
```

--------------------------------

### Create Intel TDX Confidential Instance

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Command to create a Google Compute Engine instance with Intel TDX confidential computing enabled. It specifies machine type, confidential compute type, image details, network configuration, and shielded VM settings.

```sh
gcloud compute instances create $GCI_NAME \
    --zone=$GCI_ZONE \
    --machine-type=c3-standard-4 \
    --confidential-compute-type=TDX \
    --maintenance-policy=TERMINATE \
    --image-family=ubuntu-2204-lts \
    --image-project=ubuntu-os-cloud \
    --project=$GCI_PROJECT \
    --network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=default \
    --tags=http-server,https-server \
    --shielded-secure-boot \
    --shielded-vtpm \
    --shielded-integrity-monitoring \
    --create-disk=auto-delete=yes,boot=yes,device-name=instance-20241030-131350,image=projects/$GCI_PROJECT/global/images/$GCI_IMAGE,mode=rw,size=20,type=pd-balanced
```

--------------------------------

### Create AMD SEV-SNP Confidential Instance

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Command to create a Google Compute Engine instance with AMD SEV-SNP confidential computing enabled. It specifies machine type, CPU platform, confidential compute type, image details, network configuration, and shielded VM settings.

```sh
gcloud compute instances create $GCI_NAME \
    --zone=$GCI_ZONE \
    --machine-type=n2d-standard-2 \
    --min-cpu-platform="AMD Milan" \
    --confidential-compute-type=SEV_SNP \
    --maintenance-policy=TERMINATE \
    --image-family=ubuntu-2404-lts-amd64 \
    --image-project=ubuntu-os-cloud \
    --project=$GCI_PROJECT \
    --network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=default \
    --tags=http-server,https-server \
    --shielded-secure-boot \
    --shielded-vtpm \
    --shielded-integrity-monitoring \
    --create-disk=auto-delete=yes,boot=yes,device-name=instance-20241030-131350,image=projects/$GCI_PROJECT/global/images/$GCI_IMAGE,mode=rw,size=20,type=pd-balanced
```

--------------------------------

### Run GoTPM Attestation

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Executes the `gotpm attest` command to perform attestation on a confidential VM. Requires a key, TPM nonce, TEE nonce, and the TEE technology type (sev-snp or tdx).

```sh
sudo gotpm attest --key AK --nonce <32 bytes (64 hex characters)> --tee-nonce <64 bytes (128 hex characters)> --tee-technology <sev-snp/tdx>
```

--------------------------------

### Connect to GCP Instance via SSH

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Command to establish an SSH connection to a Google Compute Engine instance. Requires the instance zone, name, and project ID.

```sh
gcloud compute ssh --zone "$GCI_ZONE" "$GCI_NAME" --project "$GCI_PROJECT"
```

--------------------------------

### List Available GCP Machine Types

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Lists all available machine types for a specified zone in Google Compute Engine. Useful for selecting appropriate instance configurations.

```sh
gcloud compute machine-types list --zones=$GCI_ZONE
```

--------------------------------

### UseDefinition for Key Requirements

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/converge-protocol.md

Defines the structure for `UseDefinition`, specifying which keys a device or a specific key within it requires for execution.

```APIDOC
UseDefition :: [Key] |
	#{
		read => [Key],
		write => [Key]
	}
```

--------------------------------

### Generate Random Nonces for Attestation

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/GCP-notes.md

Generates random byte sequences for use as nonces in the `gotpm attest` command. Includes a 32-byte nonce for the TPM layer and a 64-byte nonce for the TEE layer.

```sh
# 32-byte Nonce (for --nonce):
head -c 32 /dev/urandom | xxd -p -c 64

# 64-byte TEE Nonce (for --tee-nonce):
head -c 64 /dev/urandom | xxd -p -c 128
```

--------------------------------

### Converge HTTP API Semantics

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/converge-http-api.md

Describes the core semantics and syntax of the Converge HTTP API. It explains how paths, query parameters, and special characters are interpreted to manipulate computation graphs.

```APIDOC
Converge HTTP API Semantics:

- Base Hashpath: All computation paths start with a base hashpath (e.g., `GET /hashpath1/...
`).
- Chained Resolution: Path segments are interpreted as keys to resolve messages sequentially. `GET /hashpath1/key1/key2` is equivalent to `GET /hashpath(hashpath1, key1)/key2`.
- Implicit Base Message: If the first key is not a base64URL encoded string, the request message is its own base.
- Query Parameters as Headers: Query parameters are treated as equivalent to headers and are present in all messages in the path unless specified otherwise.
- Path Segment Delimiters:
  - `+`: Delimits a key from an optional message dictionary. Example: `GET /hashpath1/key1+dict1=val1/key2`.
  - `N.KeyName`: Interpreted as `KeyName` in the message dictionary for the Nth key resolution (in headers or query parameters).
  - `Key!DevName`: Interprets the message with the `Device` set to `DevName`.
  - `Key|Type`: Interpreted as a type annotation for `Key`, used for parsing values with HTTP Structured Fields (RFC 8941).
  - Parentheses `()`: Indicate the result of an enclosed path invocation. Example: `GET /hashpath1/path2+key1=(/hashpath2/key2)`.
```

--------------------------------

### Device Info Function Exports

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/converge-protocol.md

Details the structure and purpose of the `info` function within Hyperbeam device modules, used to signal environment requirements.

```APIDOC
info([Message, [Env]]) -> #{
	handler => Function,
    default => Function,
    exports => [Key],
    variant => <<"Variant/VersionID">>,
    ...
}
```

--------------------------------

### Re-building HyperBEAM In-Place

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/hacking-on-hyperbeam.md

Rebuilds the HyperBEAM project in-place by invoking rebar3 to compile any changed modules.

```erlang
hb:build()
```

--------------------------------

### Converge Protocol Types and Functions

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/converge-protocol.md

Defines the fundamental types and functions within the Converge protocol, illustrating how messages are structured and applied.

```APIDOC
Types:
    Permaweb :: [Message]
    Message :: Map< Name :: Binary, (Message?) => Message > | Binary

Functions:
    Message1(Message2) => Message3 :: Converge.apply(Message1, Message2) => Message3
    Converge.apply(Message1[Device], Message2, RuntimeEnv? :: Message) => Message3

Invariants:
    ∀ message ∈ Permaweb, ∃ (<<"ID">> ∈ Message)
    ∀ message ∈ Permaweb, ∃ (<<"Keys">> ∈ Message)
    ∀ message ∈ Permaweb, ∃ (<<"Device">> ∈ Message ∨ Converge.apply(Message, <<"Device">>) => <<"Message">>)
```

--------------------------------

### Running HyperBEAM Tests

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/hacking-on-hyperbeam.md

Executes all built-in tests for HyperBEAM using rebar3 eunit. Supports filtering tests by module or specific test cases.

```shell
rebar3 eunit
```

```shell
rebar3 eunit --module=list,of,mods
```

```shell
rebar3 eunit --test=your_module:your_test
```

--------------------------------

### Controlling Log Output with HB_PRINT

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/hacking-on-hyperbeam.md

Demonstrates how to set the HB_PRINT environment variable to filter log messages by module names or topics.

```shell
HB_PRINT=hb_path,hb_converge,converge_result rebar3 eunit --module=your_mod
```

--------------------------------

### WASM pow_calculator.wasm - Power Calculation

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/test/README.md

The pow_calculator.wasm file exports a function 'pow/2' that calculates the power of a number. It relies on the 'my_lib:mul/2' function for multiplication operations within a loop to achieve the power calculation.

```wasm
Exports:

- pow/2 takes a base and exponent and returns power of the number. Calls the `my_lib:mul/2` function in a loop in
    order to perform pow calculation

Imports:

- `my_lib:mul(arg1, arg2) -> arg1 * arg2`
```

--------------------------------

### Event Logging and Debugging

Source: https://github.com/samcamwilliams/hyperbeam/blob/main/docs/hacking-on-hyperbeam.md

Utilizes the ?event/1 macro for logging debug prints. Log output can be controlled via hb_opts or the HB_PRINT environment variable.

```erlang
?event(term())
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.