QPQ-AG/public-wiki
11
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update GRIDS

Craig Everett
2026-05-13 16:30:10 +09:00
parent 70643184c3
commit fbd888aa6e
1 changed files with 254 additions and 271 deletions
Download Patch File Download Diff File Expand all files Collapse all files
GRIDS.md
+18 -35
@@ -1,4 +1,3 @@
# GRIDS: Gajumaru Remote Instruction Dispatch System v1
- **Document Created**: 2025-01-17
@@ -27,39 +26,24 @@ Gajumaru ecosystem:
## The Problem
In computing there is a strong tradeoff between usability and security. In the
cryptocurrency world this is compounded by the inherent complexity of the
systems involved. This has resulted in a common pattern of developers coding
wallet features directly into the local execution environments of the
applications they wish to integrate with a cryptocurrency system (typically a
blockchain).
In computing there is a strong tradeoff between usability and security.
In the cryptocurrency world this is compounded by the inherent complexity of the systems involved.
This has resulted in a common pattern of developers coding wallet features directly into the local execution environments of the applications they wish to integrate with a cryptocurrency system (typically a blockchain).
For example, it is common for games based around on-chain tokens to integrate
wallet features directly into the game client itself. This prevents the user
from having to leave the game, open another application (their wallet), sign a
transaction, and then return to the game.
For example, it is common for games based around on-chain tokens to integrate wallet features directly into the game client itself.
This prevents the user from having to leave the game, open another application (their wallet), sign a transaction, and then return to the game.
As another example, it is overwhelmingly common for developers to write
wallets as browser plugins that interact directly with in-page applications
running in the same browser.
As another example, it is overwhelmingly common for developers to write wallets as browser plugins that interact directly with in-page applications running in the same browser.
In both cases the incentives for bad actors to compromise the execution
environment itself in order to capture private key data or seed phrases is
overwhelming. Separation of signature and app execution context is needed.
Separating the execution context requires a way for apps requesting signatures
and apps capable of providing signatures to communicate not only across
execution environments on a single system, but also across completely separate
systems.
In both cases the incentives for bad actors to compromise the execution environment itself in order to capture private key data or seed phrases is overwhelming.
Separation of signature and app execution context is needed.
Separating the execution context requires a way for apps requesting signatures and apps capable of providing signatures to communicate not only across execution environments on a single system, but also across completely separate systems.
GRIDS defines a way to to combine communication of limited, known transaction
types (such as simple spends) with a way to convey arbitrarily complex
transaction data that may require out-of-band communication with a signature
client.
GRIDS defines a way to to combine communication of limited, known transaction types (such as simple spends) with a way to convey arbitrarily complex transaction data that may require out-of-band communication with a signature client.
## The Schema
The GRIDS schema is very similar to HTTP/HTTPS, and even translates directly
to an HTTP request URL in the case of a dead-drop instruction.
The GRIDS schema is very similar to HTTP/HTTPS, and even translates directly to an HTTP request URL in the case of a dead-drop instruction.
The basic schema is:
@@ -220,16 +204,15 @@ The response to the initial GET request takes the form of a JSON object with thi
- The `"network_id"` is necessary for the client (and end-user) to verify that
activity is occurring where expected and binds the resulting signature to
that specific network.
- The `"type"` may be `"message"`, `"tx"` or `"ack"`. A `"message"` signature
is used either for verifiable messages or login schemes. An `"ack"` is an
optional response to a `"tx"` or `"message"` response POST.
- The `"public_id"` can either be a public key (on-chain account) or the
**boolean** `false` (note absence of quotes).
- The `"type"` may be `"message"`, `"binary"`, `"tx"` or `"ack"`.
- A `"message"` signature is a UTF-8 string used either for verifiable messages or login schemes.
- A `"binary"` signature is the same as a `"message"` signature, but is performed over binary data encoded as base64.
- A `"tx"` is a request for signature of a transaction (usually call data or contract deployment).
- An `"ack"` is an optional response to a `"tx"` or `"message"` response POST.
- The `"public_id"` can either be a public key (on-chain account) or the **boolean** `false` (note absence of quotes).
- If the `public_id` is `false`, then it is up to the client to pick a key to
use (and then populate this field).
- If an ID is specified, then the client should select that account or fail if it is not available.
- The `"payload"` is the data to be signed. In the case of a
`"tx"` request (a contract call, for example), this data
will be transaction data encoded according to the Gajumaru
@@ -237,7 +220,7 @@ The response to the initial GET request takes the form of a JSON object with thi
understand how to interpret and handle this data. In the
case of a `"message"` request, this will typically be a
simple string in plain text that the client interprets as a
binary string, appends the prefix (Erlang binary notation)
binary string, prepends the binary string (Erlang binary notation)
`<<"Gajumaru Signed Message:\n">>`, and then signs.
Prefixing message request payloads with this string prevents
attackers from disguising transaction signature requests as