calimero-context

Crates.iocalimero-context
lib.rscalimero-context
version0.8.0-rc.10
created_at2025-08-31 15:27:41.121169+00
updated_at2025-09-17 14:03:50.982612+00
descriptionCore Calimero infrastructure and tools
homepage
repositoryhttps://github.com/calimero-network/core
max_upload_size
id1818644
size236,575
Sandi Fatic (chefsale)

documentation

README

Calimero Contexts

A context in Calimero is an instance of a deployed application where members share a synchronized state.

Contexts are identified by a 32-byte key, which is randomly determined when each context is created. As of now, this key is not necessarily cryptographically secure, nor is it a dependency of cryptographic operations, but it is unique enough to mitigate collisions. Worth noting that this is likely to change in the future.

All state mutations within a context performed by members will be broadcasted to all other members.

Context Lifecycle

Following the creation of a context, the only member is the creator. The creator can invite other members to join the context, and members can leave the context at any time.

Context State

The state of a context is a key-value store, where the key is a 32-byte identifier and the value is a byte array. The state is synchronized across all members of the context, since all state mutations are broadcasted to all members.

State Mutations

A state mutation is an operation that changes the state of the context. As of the time of writing, state mutations are represented as transactions that define the application method to be called, and it's input (arguments). We make no assumptions about the application, nor it's inputs and outputs, as long as it's clients agree on the schema & serialization method.

All members of the context, following the reception of a transaction, will execute the transaction on their local copy of the state to advance it to the new state.

The unfortunate downside of this approach is that we're unnecessarily executing the same transaction on all nodes without using that information to achieve trustless consensus. We're currently working on a solution to this problem, which reimagines consensus.

Context Membership

Invitations

Alice wants to invite Bob to join the context. Alice shares the context ID with Bob. Bob can now make a catchup request, which will be responded to by Alice. Eventually, Bob receives all transactions required to make up the complete state, at which point he is considered a full member of the context and can proceed to make mutations.

Leaving

Bob wants to leave a context. He deletes the context from his local storage and no longer tracks the state of the context although the context still exists and other members can continue to make mutations. Bob is no longer considered a member of the context.

Encryption

As of the time of writing, all messages are sent in plaintext. But we're currently working on encrypting all messages using distinct, yet, deterministic keys by employing the double-ratchet algorithm, which provides forward secrecy, and post-compromise security. We'll revise this document once this, among other features, is implemented.

Context Deletion

There's no way to "delete a context" for all members outside of the scope of all members leaving it.

Commit count: 1062

cargo fmt