Tessera

Hammer is a load testing tool designed for tlog-mirror servers. It generates write traffic according to the tlog-mirror specification to test both the correctness and performance of a mirror under load.

To use Hammer, the target mirror server must support POST requests at the following paths:

• /add-checkpoint
• /add-entries

By default, Hammer runs with an interactive text-based UI (TUI) in the terminal, allowing you to monitor status, logs, and adjust read/write traffic levels in real-time. For headless environments like CI pipelines, you should disable the UI using the --show_ui=false flag.

The POSIX MTC Mirror is a server implementation backed by Tessera's POSIX storage. It is designed to comply with the tlog-mirror specification.

A tlog-mirror serves two roles:

1. A regular tlog-witness server (which can optionally sign consistent log checkpoints).
2. An "extended" tlog-witness that signs a consistent checkpoint only after it has successfully stored a copy of the log content associated with that checkpoint.

WARNING

This binary and its internal packages are under active development, are considered experimental, and are not production-ready. They are outside the SemVer policy.

The AWS storage implementation for Tessera uses a hybrid approach to balance write coordination and read scalability:

• Transactional Storage: Uses Amazon Aurora (MySQL) to coordinate writes. New entries are held in transactional storage to be batched and assigned sequence numbers. This allows the Add API to return quickly with durably assigned sequence numbers.
• Long-term/Read Storage: Uses Amazon S3 for low-cost, low-complexity serving of read traffic. An asynchronous process derives entry bundles and Merkle tree structures from sequenced batches and writes them to S3.

Because entries are sequenced in chunks before being stored in the tree, all tree derivations are idempotent.

The CloudBuild pipeline is automatically triggered by commits to the main branch of the repository. Its primary responsibilities are:

1. Building the cmd/gcp/conformance Docker image from the main branch.
2. Provisioning a fresh conformance testing environment.
3. Executing conformance tests against the newly built Docker image.
4. Decommissioning (turning down) the conformance testing environment.

Tessera is a Go library designed to efficiently serve logs via the tlog-tiles API.

Because Tessera is a generic library, the code you write to integrate it into your specific ecosystem is referred to as a personality. When building a personality, your first decision is choosing a storage driver. The native drivers available are:

• GCP: Recommended for production in Google Cloud.
• AWS: Recommended for production in AWS.
• POSIX: Simplest for local development or environments where you already serve static files.

Cloud implementations (GCP/AWS) are generally easier to scale and operate for production use cases.

Tessera makes logs readable via the tlog-tiles API. How you serve this data depends on your storage driver:

• AWS/GCP: Data is written to object storage. The operator must ensure the object storage is publicly readable and set up a URL pointing to it.
• POSIX: The operator must serve the files (which are written according to the API spec) using an HTTP File Server.

Integration is a background process that begins once a Tessera lifecycle object is created. It takes entries that have been sequenced and merges them into the log.

An entry is considered integrated when:

• It becomes available via the read API at its assigned index.
• It has Merkle tree hashes that commit to its inclusion in the tree.

Conformance Personalities are server implementations built on top of Tessera that serve two purposes: providing simple deployment examples for different backends and acting as conformance/performance harnesses for Tessera using hammer.

Available implementations include:

• Local POSIX-compliant filesystem
• GCP
• AWS

Each personality exposes a POST endpoint at /add. When you send a request body to this endpoint, the contents are appended to the log, and the server returns the decimal index assigned to that newly sequenced entry.

Tessera on GCP uses a hybrid storage architecture to balance high-performance writes with low-cost, scalable reads:

1. Transactional Storage (Cloud Spanner): Used for coordinating the cluster and holding new entries temporarily. This allows the Add API to return quickly with durably assigned sequence numbers.
2. Long-term Storage (Google Cloud Storage - GCS): An asynchronous process derives entry bundles and Merkle tree structures from sequenced batches and writes them to GCS. This provides low-cost and low-complexity serving of read traffic.

Because entries are sequenced in chunks before being stored in GCS, all tree derivations are idempotent.