• Specification
  • Validation Rules
    • Substrate
    • Particle
  • Quantized Substrates
  • Time
  • Decay
• Example Usage

⚠️ This specification is a work in progress.

A substrate is a cyberspace object that occupies all of cyberspace. It’s like a field in particle physics or a shader in computer graphics. It can be used for an infinite number of things, but I imagine it will be used first for video games, and it could be very useful for this purpose. A substrate could define loot drops or minable resources or enemy encounter locations or even level geometry. Below is my idea for how it could all work in the context of cyberspace.

§Specification

A substrate contains a function that may be executed on a given coordinate in cyberspace. The output of this function is called a particle.

The function input is always a cyberspace coordinate which is 256 bits. Additional arguments may be defined, such as the executor’s pubkey, timestamp, etc.

The function output contains binary data truncated to P bytes long, where P is the NIP-13 proof-of-work present on the substrate declaration event.

The binary data is published publicly in a particle event containing the result of the function as well as some verifying information.

The particle “exists” at the coordinate of the substrate execution.

The substrate declaration event is formatted like this:

• kind - 330
• content - a function whose first argument must be a cyberspace coordinate and whose return value must is some kind of byte array whose length is equal to the POW target in the nonce tag.
• pubkey - the substrate creator
• created_at - standard
• tags:
  • [“nonce”, <nonce>, <POW target>] with NIP-13 proof of work. Event’s id must have leading zeroes equal to POW target.
• id: leading zeroes are validation for the number of bytes returned from the function.

The particle event is formatted like this:

• kind - 329
• content - base64 binary data output of the function
• pubkey - of the avatar that executed the substrate
• created_at - standard
• tags:
  • [“e”, <substrate id>] - the event id of the substrate declaration
  • [“e”, <action event id>] - this is the event id of the action in the user’s action chain directly preceding the execution of the substrate.
  • [“C”, <cyberspace coordinate>, <argument 2>, ...] - these are the arguments to the function. The C tag is used because the first argument is always a Cyberspace coordinate and this allows searching.
  • [“S”, <sector id>] - for sector-based object queries
  • [“nonce”, <nonce>, <POW target>] - POW for distance between avatar and substrate execution coordinate
• id: standard

The decay event format is TBD.

§Validation Rules

§Substrate

1. The byte length of the function’s return value must equal the POW of the substrate declaration event.

§Particle

Note: games may ignore particle validation rules if they do not care about the particles being valid outside of their game. However, these rules are required for particles to be valid in cyberspace.

1. When a substrate is activated, the avatar who activates it exists at one coordinate and the substrate is activated at another coordinate; these may be the same coordinate or there may be a distance between them. If they are not the same, the avatar must publish POW on the particle event relative to the distance. The \(\text{POW}^3\) must be greater than or equal to the Manhattan distance of their coordinate and the particle coordinate. The user’s coordinate is derived from the action chain event referenced in the second e tag. The particle’s coordinate is the same as the first argument to the substrate function. This puts a thermodynamic limit on how far away an avatar may produce particles from their own location.

§Quantized Substrates

Because in d-space each coordinate is so small, it would make sense to create a substrate that quantizes space so that there is a less dense 3D grid of points from which particles could be spawned. For example, the substrate could quantize the coordinate input to yield a grid where there is 1 particle per \(1m^3\).

§Time

Each substrate execution will yield the same particle for the same coordinate unless other parameters are introduced besides the input coordinate. These could include the avatar’s pubkey, the current time, and attributes from the most recent particle at that same coordinate, or even neighboring particles from specific coordinates (if they exist).

§Decay

A Decay is an event published by the substrate owner which targets a particle event and alters its bytes, preserving the length of the byte array.

The ability for a substrate owner to publish decay events must be signaled in the substrate declaration event or it isn’t valid.

A decay event represents a single atomic operation on the byte array. Operations include:

• Addition: Add a constant value to each byte.
• Subtraction: Subtract a constant value from each byte.
• Multiplication: Multiply each byte by a constant value.
• Division: Divide each byte by a constant value.
• Modulus: Apply a modulus operation to each byte with a constant value.
• Bitwise Operations: Apply bitwise AND, OR, XOR, and NOT operations with a constant value or between bytes.
• Rotation/Shift: Rotate or shift bits in each byte to the left or right.

Additional decay events may be published, but each subsequent decay event must reference its preceding decay event to form a chain of operations such that anyone sampling the particle may find the most recent value and verify its history. The first decay event only references the particle.

The decay event id must contain POW equal to the binary hamming distance of the original byte array and the modified byte array.

Example usage: Games can put requests to a server to have the server publish a decay to alter a particle. The player can mine the POW for the decay event and send it to the server to be signed.

For example, if a particle represents a quantity of resources in a location, that quantity could be reduced by the publishing of a decay event that references the particle.

§Example Usage

1. DVMs (data vending machines)

A DVM could watch for particle events published that reference a given substrate and validate them. If the valid particle’s data matches the DVM’s internal conditions, the DVM will take action.

• It can publish an ephemeral giftwrapped event from a disposable keypair encrypted to the particle owner to transmit private data, as an example.
• It can publish a kind 1/X/? announcing that something was found so it is public.
• It could award a badge.

2. Game data

The resulting particle could be used in a game somehow, such as an RNG for generating encounters with a creature, or yielding a resource level in an area.