Transactions¶
General Information¶
This doc is about supported transactions and their representation on the Ledger (that is, the internal one). If you are interested in the format of a client’s request (both write and read), then have a look at requests.
All transactions are stored in a distributed ledger (replicated on all nodes)
The ledger is based on a Merkle Tree
The ledger consists of two things:
transactions log as a sequence of key-value pairs where key is a sequence number of the transaction and value is the serialized transaction
merkle tree (where hashes for leaves and nodes are persisted)
Each transaction has a sequence number (no gaps) - keys in transactions log
So, this can be considered a blockchain where each block’s size is equal to 1
There are multiple ledgers by default:
pool ledger: transactions related to pool/network configuration (listing all nodes, their keys and addresses)
config ledger: transactions for pool configuration plus transactions related to pool upgrade
domain ledger: all main domain and application specific transactions (including NYM transactions for DID)
All transactions are serialized to MsgPack format
All transactions (both transaction log and merkle tree hash stores) are stored in a LevelDB
One can use the
read_ledgerscript to get transactions for a specified ledger in a readable format (JSON)See roles and permissions for a list of roles and they type of transactions they can create.
Below you can find the format and description of all supported transactions.
Genesis Transactions¶
As Indy is a public permissioned blockchain, each ledger may have a number of pre-defined transactions defining the initial pool and network.
pool genesis transactions define initial trusted nodes in the pool
domain genesis transactions define initial trusted trustees and stewards
Common Structure¶
Each transaction has the following structure consisting of metadata values (common for all transaction types) and transaction specific data:
{
"ver": <...>,
"txn": {
"type": <...>,
"ver": <...>,
"protocolVersion": <...>,
"data": {
<txn-specific fields>
},
"metadata": {
"reqId": <...>,
"from": <...>,
"endorser": <...>,
"digest": <...>,
"payloadDigest": <...>,
"taaAcceptance": {
"taaDigest": <...>,
"mechanism": <...>,
"time": <...>
}
},
},
"txnMetadata": {
"txnTime": <...>,
"seqNo": <...>,
"txnId": <...>
},
"reqSignature": {
"type": <...>,
"values": [{
"from": <...>,
"value": <...>
}]
}
}
ver(string):Transaction version to be able to evolve content. The content of all sub-fields may depend on this version.
txn(dict):Transaction-specific payload (data)
type(enum number as string):Supported transaction types:
NODE = “0”
NYM = “1”
TXN_AUTHOR_AGREEMENT = “4”
TXN_AUTHOR_AGREEMENT_AML = “5”
ATTRIB = “100”
SCHEMA = “101”
CLAIM_DEF = “102”
POOL_UPGRADE = “109”
NODE_UPGRADE = “110”
POOL_CONFIG = “111”
REVOC_REG_DEF = “113”
REVOC_REG_DEF = “114”
AUTH_RULE = “120”
AUTH_RULES = “122”
JSON_LD_CONTEXT = “200”
RICH_SCHEMA = “201”
RICH_SCHEMA_ENCODING = “202”
RICH_SCHEMA_MAPPING = “203”
RICH_SCHEMA_CRED_DEF = “204”
RICH_SCHEMA_PRES_DEF = “205”
ver(string)Transaction’s payload version as defined in the input request. If the input request doesn’t have the version specified, then default one will be used. Some transactions (for example TRANSACTION_AUTHOR_AGREEMENT) have non-default transaction payload version defined in source code as a result of evolution of business logic and features.
protocolVersion(integer; optional):The version of client-to-node or node-to-node protocol. Each new version may introduce a new feature in requests/replies/data. Since clients and different nodes may be at different versions, we need this field to support backward compatibility between clients and nodes.
data(dict):Transaction-specific data fields (see following sections for each transaction’s description).
metadata(dict):Metadata as came from the request.
from(base58-encoded string):Identifier (DID) of the transaction author as base58-encoded string for 16 or 32 bit DID value. It may differ from
endorserfield who submits the transaction on behalf ofidentifier. Ifendorseris absent, then the author (identifier) plays the role of endorser and submits request by his own. It also may differ fromdestfield for some of requests (for example NYM), wheredestis a target identifier (for example, a newly created DID identifier).Example:
identifieris a DID of a transaction author who doesn’t have write permissions;endorseris a DID of a user with Endorser role (that is with write permissions).new NYM creation:
identifieris a DID of an Endorser creating a new DID, anddestis a newly created DID.
reqId(integer): Unique ID number of the request with transaction.digest(SHA256 hex digest string): SHA256 hash hex digest of all fields in the initial requests (including signatures)payloadDigest(SHA256 hex digest string): SHA256 hash hex digest of the payload fields in the initial requests, that is all fields excluding signatures and plugins-added onesendorser(base58-encoded string, optional): Identifier (DID) of an Endorser submitting a transaction on behalf of the original author (identifier) as base58-encoded string for 16 or 32 bit DID value. Ifendorseris absent, then the author (identifier) plays the role of endorser and submits request by his own. Ifendorseris present then the transaction must be multi-signed by the both author (identifier) and Endorser (endorser).taaAcceptance(dict, optional): If transaction author agreement is set/enabled, then every transaction (write request) from Domain and plugins-added ledgers must include acceptance of the latest transaction author agreement.taaDigest(SHA256 hex digest string): SHA256 hex digest of the latest Transaction Author Agreement on the ledger. The digest is calculated from concatenation of TRANSACTION_AUTHOR_AGREEMENT’sversionandtext.mechanism(string): a mechanism used to accept the signature; must be present in the latest list of transaction author agreement acceptane mechanisms on the ledgertime(integer as POSIX timestamp): transaction author agreement acceptance time. The time needs to be rounded to date to prevent correlation of different transactions which is possible when acceptance time is too precise.
txnMetadata(dict):Metadata attached to the transaction.
version(integer): Transaction version to be able to evolvetxnMetadata. The content oftxnMetadatamay depend on the version.txnTime(integer as POSIX timestamp): The time when transaction was written to the Ledger as POSIX timestamp.seqNo(integer): A unique sequence number of the transaction on LedgertxnId(string, optional): Txn ID as State Trie key (address or descriptive data). It must be unique within the ledger. Usually present for Domain transactions only.
reqSignature(dict):Submitter’s signature over request with transaction (
txnfield).type(string enum):ED25519: ed25519 signature
ED25519_MULTI: ed25519 signature in multisig case.
values(list):from(base58-encoded string): Identifier (DID) of signer as base58-encoded string for 16 or 32 byte DID value.value(base58-encoded string): signature value
Please note that all these metadata fields may be absent for genesis transactions.
Domain Ledger¶
NYM¶
Creates a new NYM record for a specific user, endorser, steward or trustee. Note that only trustees and stewards can create new endorsers and a trustee can be created only by other trustees (see roles).
The transaction can be used for creation of new DIDs, setting and rotation of verification key, setting and changing of roles, setting and changing of DID documents.
dest(base58-encoded string):Target DID as base58-encoded string for 16 or 32 byte DID value. It may differ from the
frommetadata field, wherefromis the DID of the submitter. If they are equal (in permissionless case), then transaction must be signed by the newly createdverkey.Example:
fromis a DID of a Endorser creating a new DID, anddestis a newly created DID.role(enum number as integer; optional):Role of a user that the NYM record is being created for. One of the following values
None (common USER)
“0” (TRUSTEE)
“2” (STEWARD)
“101” (ENDORSER)
“201” (NETWORK_MONITOR)
A TRUSTEE can change any Nym’s role to None, thus stopping it from making any further writes (see roles).
verkey(base58-encoded string, possibly starting with “~”; optional):Target verification key as base58-encoded string. It can start with “~”, which means that it’s an abbreviated verkey and should be 16 bytes long when decoded, otherwise it’s a full verkey which should be 32 bytes long when decoded. If not set, then either the target identifier (
did) is 32-bit cryptonym CID (this is deprecated), or this is a user under guardianship (doesn’t own the identifier yet). Verkey can be changed to “None” by owner, it means that this user goes back under guardianship.alias(string; optional):NYM’s alias.
diddocContent(json string; optional):The diddocContent item is stored directly in the ledger state and has a maximum size of 10 KiB (10 x 1024 bytes).
version(integer; optional):The NYM transaction version specifies the required level of validation of the relationship between the namespace identifier component of the DID and the intial public key (verkey). This field is optional, but if the NYM transaction version is provided, it must be set upon creation and cannot be updated. The accepted values are as follows:
0 or NYM transaction version is not set: No validation of namespace identifier and initial verkey binding is performed. 1: Validation is performed according to the did:sov method, in which the DID must be the first 16 bytes of the Verification Method public key. 2: Validation is performed according to the did:indy, in which the namespace identifier component of the DID (last element) is derived from the initial public key of the DID, using the base58 encoding of the first 16 bytes of the SHA256 of the Verification Method public key (did = Base58(Truncate_msb(16(SHA256(publicKey))))). This DID is considered self-certifying.
If there is no NYM transaction for the specified DID (did) yet, then this can be considered as the creation of a new DID.
If there is already a NYM transaction with the specified DID (did), then this is is considered an update of that DID.
In this case only the values that need to be updated should be specified since any specified one is treated as an update even if it matches the current value in ledger. All unspecified values remain unchanged.
So, if key rotation needs to be performed, the owner of the DID needs to send a NYM request with
did and verkey only. role and alias will stay the same.
Example:
{
"ver": 1,
"txn": {
"type":"1",
"ver": 1,
"protocolVersion":2,
"data": {
"dest":"GEzcdDLhCpGCYRHW82kjHd",
"verkey":"~HmUWn928bnFT6Ephf65YXv",
"role":101,
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId": "N22KY2Dyvmuu2PyyqSFKue|01"
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
ATTRIB¶
Adds an attribute to a NYM record
dest(base58-encoded string):Target DID we set an attribute for as base58-encoded string for 16 or 32 byte DID value. It differs from
frommetadata field, wherefromis the DID of the submitter.Example:
fromis a DID of a Endorser setting an attribute for a DID, anddestis the DID we set an attribute for.raw(sha256 hash string; mutually exclusive withhashandenc):Hash of the raw attribute data. Raw data is represented as JSON, where the key is the attribute name and the value is the attribute value. The ledger only stores a hash of the raw data; the real (unhashed) raw data is stored in a separate attribute store.
hash(sha256 hash string; mutually exclusive withrawandenc):Hash of attribute data (as sent by the client). The ledger stores this hash; nothing is stored in an attribute store.
enc(sha256 hash string; mutually exclusive withrawandhash):Hash of encrypted attribute data. The ledger contains the hash only; the real encrypted data is stored in a separate attribute store.
Example:
{
"ver": 1,
"txn": {
"type":"100",
"ver": 1,
"protocolVersion":2,
"data": {
"dest":"GEzcdDLhCpGCYRHW82kjHd",
"raw":"3cba1e3cf23c8ce24b7e08171d823fbd9a4929aafd9f27516e30699d3a42026a",
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId": "N22KY2Dyvmuu2PyyqSFKue|02"
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
SCHEMA¶
Adds a Claim’s schema.
It’s not possible to update an existing schema. So, if the Schema needs to be evolved, a new Schema with a new version or new name needs to be created.
data(dict):Dictionary with Schema’s data:
attr_names: array of attribute name stringsname: Schema’s name stringversion: Schema’s version string
Example:
{
"ver": 1,
"txn": {
"type":101,
"ver": 1,
"protocolVersion":2,
"data": {
"data": {
"attr_names": ["undergrad","last_name","first_name","birth_date","postgrad","expiry_date"],
"name":"Degree",
"version":"1.0"
},
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf1|Degree|1.0",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
CLAIM_DEF¶
Adds a claim definition (in particular, public key), that Issuer creates and publishes for a particular claim schema.
data(dict):Dictionary with claim definition’s data:
primary(dict): primary claim public keyrevocation(dict): revocation claim public key
ref(string):Sequence number of a schema transaction the claim definition is created for.
signature_type(string):Type of the claim definition (that is claim signature).
CL(Camenisch-Lysyanskaya) is the only supported type now.tag(string, optional):A unique tag to have multiple public keys for the same Schema and type issued by the same DID. A default tag
tagwill be used if not specified.
Example:
{
"ver": 1,
"txn": {
"type":102,
"ver": 1,
"protocolVersion":2,
"data": {
"data": {
"primary": {
...
},
"revocation": {
...
}
},
"ref":12,
"signature_type":"CL",
"tag": "some_tag"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"HHAD5g65TDQr1PPHHRoiGf2L5AD5g65TDQr1PPHHRoiGf1|Degree1|CL|key1",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
REVOC_REG_DEF¶
Adds a Revocation Registry Definition, that Issuer creates and publishes for a particular Claim Definition. It contains public keys, maximum number of credentials the registry may contain, reference to the Claim Def, plus some revocation registry specific data.
value(dict):Dictionary with revocation registry definition’s data:
maxCredNum(integer): a maximum number of credentials the Revocation Registry can handletailsHash(string): tails’ file digesttailsLocation(string): tails’ file location (URL)issuanceType(string enum): defines credentials revocation strategy. Can have the following values:ISSUANCE_BY_DEFAULT: all credentials are assumed to be issued initially, so that Revocation Registry needs to be updated (REVOC_REG_ENTRY txn sent) only when revoking. Revocation Registry stores only revoked credentials indices in this case. Recommended to use if expected number of revocation actions is less than expected number of issuance actions.ISSUANCE_ON_DEMAND: no credentials are issued initially, so that Revocation Registry needs to be updated (REVOC_REG_ENTRY txn sent) on every issuance and revocation. Revocation Registry stores only issued credentials indices in this case. Recommended to use if expected number of issuance actions is less than expected number of revocation actions.
publicKeys(dict): Revocation Registry’s public key
id(string): Revocation Registry Definition’s unique identifier (a key from state trie is currently used)credDefId(string): The corresponding Credential Definition’s unique identifier (a key from state trie is currently used)revocDefType(string enum): Revocation Type.CL_ACCUM(Camenisch-Lysyanskaya Accumulator) is the only supported type now.tag(string): A unique tag to have multiple Revocation Registry Definitions for the same Credential Definition and type issued by the same DID.
Example:
{
"ver": 1,
"txn": {
"type":113,
"ver": 1,
"protocolVersion":2,
"data": {
"id": "L5AD5g65TDQr1PPHHRoiGf:3:FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag:CL_ACCUM:tag1",
"credDefId": "FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag"
"revocDefType": "CL_ACCUM",
"tag": "tag1",
"value": {
"maxCredNum": 1000000,
"tailsHash": "6619ad3cf7e02fc29931a5cdc7bb70ba4b9283bda3badae297",
"tailsLocation": "http://tails.location.com",
"issuanceType": "ISSUANCE_BY_DEFAULT",
"publicKeys": {},
},
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf:3:FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag:CL_ACCUM:tag1",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
REVOC_REG_ENTRY¶
The RevocReg entry containing the new accumulator value and issued/revoked indices. This is just a delta of indices, not the whole list. So, it can be sent each time a new claim is issued/revoked.
value(dict):Dictionary with revocation registry’s data:
accum(string): the current accumulator valueprevAccum(string): the previous accumulator value; it’s compared with the current value, and txn is rejected if they don’t match; it’s needed to avoid dirty writes and updates of accumulator.issued(list of integers): an array of issued indices (may be absent/empty if the type is ISSUANCE_BY_DEFAULT); this is delta; will be accumulated in state.revoked(list of integers): an array of revoked indices (delta; will be accumulated in state)
revocRegDefId(string): The corresponding Revocation Registry Definition’s unique identifier (a key from state trie is currently used)revocDefType(string enum): Revocation Type.CL_ACCUM(Camenisch-Lysyanskaya Accumulator) is the only supported type now.
Example:
{
"ver": 1,
"txn": {
"type":114,
"ver": 1,
"protocolVersion":2,
"data": {
"revocRegDefId": "L5AD5g65TDQr1PPHHRoiGf:3:FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag:CL_ACCUM:tag1"
"revocDefType": "CL_ACCUM",
"value": {
"accum": "accum_value",
"prevAccum": "prev_acuum_value",
"issued": [],
"revoked": [10, 36, 3478],
},
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"5:L5AD5g65TDQr1PPHHRoiGf:3:FC4aWomrA13YyvYC1Mxw7:3:CL:14:some_tag:CL_ACCUM:tag1",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
JSON_LD_CONTEXT¶
Adds a JSON LD Context as part of Rich Schema feature.
It’s not possible to update an existing Context. If the Context needs to be evolved, a new Context with a new id and name-version needs to be created.
id(string):A unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the
contentfield)content(json-serialized string):Context object as JSON serialized in canonical form. It must have
@contextas a top level key. The@contextvalue must be either:a URI (it should dereference to a Context object)
a Context object (a dict)
an array of Context objects and/or Context URIs
rsType(string):Context’s type. Currently expected to be
ctx.rsName(string):Context’s name
rsVersion(string):Context’s version
rsType, rsName and rsVersion must be unique among all rich schema objects on the ledger.
Example:
{
"ver": 1,
"txn": {
"type":200,
"ver":1,
"protocolVersion":2,
"data": {
"id": "did:sov:GGAD5g65TDQr1PPHHRoiGf",
"content":"{
"@context": [
{
"@version": 1.1
},
"https://www.w3.org/ns/odrl.jsonld",
{
"ex": "https://example.org/examples#",
"schema": "http://schema.org/",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
}
]
}",
"rsName":"SimpleContext",
"rsVersion":"1.0",
"rsType": "ctx"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf1|Degree|1.0",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
RICH_SCHEMA¶
Adds a Rich Schema object as part of Rich Schema feature.
It’s not possible to update an existing Rich Schema. If the Rich Schema needs to be evolved, a new Rich Schema with a new id and name-version needs to be created.
id(string):A unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the
contentfield)content(json-serialized string):Rich Schema object as JSON serialized in canonical form. This value must be a json-ld, rich schema object. json-ld supports many parameters that are optional for a rich schema txn. However, the following parameters must be there:
@id: The value of this property must be (or map to, via a context object) a URI.@type: The value of this property must be (or map to, via a context object) a URI.@context(optional): If present, the value of this property must be a context object or a URI which can be dereferenced to obtain a context object.
rsType(string):Rich Schema’s type. Currently expected to be
sch.rsName(string):Rich Schema’s name
rsVersion(string):Rich Schema’s version
rsType, rsName and rsVersion must be unique among all rich schema objects on the ledger.
Example:
{
"ver": 1,
"txn": {
"type":201,
"ver":1,
"protocolVersion":2,
"data": {
"id": "did:sov:HGAD5g65TDQr1PPHHRoiGf",
"content":"{
"@id": "test_unique_id",
"@context": "ctx:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"@type": "rdfs:Class",
"rdfs:comment": "ISO18013 International Driver License",
"rdfs:label": "Driver License",
"rdfs:subClassOf": {
"@id": "sch:Thing"
},
"driver": "Driver",
"dateOfIssue": "Date",
"dateOfExpiry": "Date",
"issuingAuthority": "Text",
"licenseNumber": "Text",
"categoriesOfVehicles": {
"vehicleType": "Text",
"vehicleType-input": {
"@type": "sch:PropertyValueSpecification",
"valuePattern": "^(A|B|C|D|BE|CE|DE|AM|A1|A2|B1|C1|D1|C1E|D1E)$"
},
"dateOfIssue": "Date",
"dateOfExpiry": "Date",
"restrictions": "Text",
"restrictions-input": {
"@type": "sch:PropertyValueSpecification",
"valuePattern": "^([A-Z]|[1-9])$"
}
},
"administrativeNumber": "Text"
}",
"rsName":"SimpleRichSchema",
"rsVersion":"1.0",
"rsType": "sch"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf1|Degree|1.0",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
RICH_SCHEMA_ENCODING¶
Adds an Encoding object as part of Rich Schema feature.
It’s not possible to update an existing Encoding. If the Encoding needs to be evolved, a new Encoding with a new id and name-version needs to be created.
id(string):A unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the
contentfield)content(json-serialized string):Encoding object as JSON serialized in canonical form.
input: a description of the input valueoutput: a description of the output valuealgorithm:documentation: a URL which references a specific github commit of the documentation that fully describes the transformation algorithm.implementation: a URL that links to a reference implementation of the transformation algorithm. It is not necessary to use the implementation linked to here, as long as the implementation used implements the same transformation algorithm.description: a brief description of the transformation algorithm.
testVectors: a URL which references a specific github commit of a selection of test vectors that may be used to provide assurance that a transformation algorithm implementation is correct.
rsType(string):Encoding’s type. Currently expected to be
enc.rsName(string):Encoding’s name
rsVersion(string):Encoding’s version
rsType, rsName and rsVersion must be unique among all rich schema objects on the ledger.
Example:
{
"ver": 1,
"txn": {
"type":202,
"ver":1,
"protocolVersion":2,
"data": {
"id": "did:sov:HGAD5g65TDQr1PPHHRoiGf",
"content":"{
"input": {
"id": "DateRFC3339",
"type": "string"
},
"output": {
"id": "UnixTime",
"type": "256-bit integer"
},
"algorithm": {
"description": "This encoding transforms an
RFC3339-formatted datetime object into the number
of seconds since January 1, 1970 (the Unix epoch).",
"documentation": URL to specific github commit,
"implementation": URL to implementation
},
"test_vectors": URL to specific github commit
}",
"rsName":"SimpleEncoding",
"rsVersion":"1.0",
"rsType": "enc"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf1|Degree|1.0",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
RICH_SCHEMA_MAPPING¶
Adds a Mapping object as part of Rich Schema feature.
It’s not possible to update an existing Mapping. If the Mapping needs to be evolved, a new Mapping with a new id and name-version needs to be created.
id(string):A unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the
contentfield)content(json-serialized string):Mapping object as JSON serialized in canonical form. This value must be a json-ld object. json-ld supports many parameters that are optional for a rich schema txn. However, the following parameters must be there:
@id: The value of this property must be (or map to, via a context object) a URI.@type: The value of this property must be (or map to, via a context object) a URI.@context(optional): If present, the value of this property must be a context object or a URI which can be dereferenced to obtain a context object.schema: Anidof the corresponding Rich Schemaattributes(dict): A dict of all the schema attributes the Mapping object is going to map to encodings and use in credentials. An attribute may have nested attributes matching the schema structure. It must also contain the following default attributes required by any W3C compatible verifiable credential (plus any additional attributes that may have been included from the W3C verifiable credentials data model):issuerissuanceDateany additional attributes
Every leaf attribute’s value is an array of the following pairs:
enc(string): Encoding object (referenced by itsid) to be used for representation of the attribute as an integer.rank(int): Rank of the attribute to define the order in which the attribute is signed by the Issuer. It is important that no tworankvalues may be identical.
rsType(string):Mapping’s type. Currently expected to be
map.rsName(string):Mapping’s name
rsVersion(string):Mapping’s version
rsType, rsName and rsVersion must be unique among all rich schema objects on the ledger.
Example:
{
"ver": 1,
"txn": {
"type":203,
"ver":1,
"protocolVersion":2,
"data": {
"id": "did:sov:HGAD5g65TDQr1PPHHRoiGf",
"content":"{
'@id': "did:sov:5e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
'@context': "did:sov:2f9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
'@type': "rdfs:Class",
"schema": "did:sov:4e9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"attribuites" : {
"issuer": [{
"enc": "did:sov:9x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 1
}],
"issuanceDate": [{
"enc": "did:sov:119F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 2
}],
"expirationDate": [{
"enc": "did:sov:119F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 11
}],
"driver": [{
"enc": "did:sov:1x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 5
}],
"dateOfIssue": [{
"enc": "did:sov:2x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 4
}],
"issuingAuthority": [{
"enc": "did:sov:3x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 3
}],
"licenseNumber": [
{
"enc": "did:sov:4x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 9
},
{
"enc": "did:sov:5x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 10
},
],
"categoriesOfVehicles": {
"vehicleType": [{
"enc": "did:sov:6x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 6
}],
"dateOfIssue": [{
"enc": "did:sov:7x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 7
}],
},
"administrativeNumber": [{
"enc": "did:sov:8x9F8ZmxuvDqRiqqY29x6dx9oU4qwFTkPbDpWtwGbdUsrCD",
"rank": 8
}]
}
}",
"rsName":"SimpleMapping",
"rsVersion":"1.0",
"rsType": "map"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf1|Degree|1.0",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
RICH_SCHEMA_CRED_DEF¶
Adds a Credential Definition object as part of Rich Schema feature.
Credential Definition is considered as a mutable object as the Issuer may rotate keys present there. However, rotation of Issuer’s keys should be done carefully as it will invalidate all credentials issued for this key.
id(string):A unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the
contentfield)content(json-serialized string):Credential Definition object as JSON serialized in canonical form.
signatureType(string): Type of the ZKP signature.CL(Camenisch-Lysyanskaya) is the only supported type now.mapping(string): Anidof the corresponding Mappingschema(string): Anidof the corresponding Rich Schema. Themappingmust reference the same Schema.publicKey(dict): Issuer’s public keys. Consists ot primary and revocation keys.primary(dict): primary keyrevocation(dict, optional): revocation key
rsType(string):Credential Definition’s type. Currently expected to be
cdf.rsName(string):Credential Definition’s name
rsVersion(string):Credential Definition’s version
rsType, rsName and rsVersion must be unique among all rich schema objects on the ledger.
Example:
{
"ver": 1,
"txn": {
"type":204,
"ver":1,
"protocolVersion":2,
"data": {
"id": "did:sov:HGAD5g65TDQr1PPHHRoiGf",
"content":"{
"signatureType": "CL",
"mapping": "did:sov:UVj5w8DRzcmPVDpUMr4AZhJ",
"schema": "did:sov:U5x5w8DRzcmPVDpUMr4AZhJ",
"publicKey": {
"primary": "...",
"revocation": "..."
}
}",
"rsName":"SimpleCredDef",
"rsVersion":"1.0",
"rsType": "cdf"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf1|Degree|1.0",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
RICH_SCHEMA_PRES_DEF¶
Adds a Presentation Definition object as part of Rich Schema feature.
Presentation Definition is considered as a mutable object since restrictions to Issuers, Schemas and Credential Definitions to be used in proof may evolve. For example, Issuer’s key for a given Credential Definition may be compromised, so Presentation Definition can be updated to exclude this Credential Definition from the list of recommended ones.
id(string):A unique ID (for example a DID with a id-string being base58 representation of the SHA2-256 hash of the
contentfield)content(json-serialized string):Presentation Definition object as JSON serialized in canonical form.
rsType(string):Presentation Definition’s type. Currently expected to be
pdf.rsName(string):Presentation Definition’s name
rsVersion(string):Presentation Definition’s version
rsType, rsName and rsVersion must be unique among all rich schema objects on the ledger.
Example:
{
"ver": 1,
"txn": {
"type":205,
"ver":1,
"protocolVersion":2,
"data": {
"id": "did:sov:HGAD5g65TDQr1PPHHRoiGf",
"content":"{
TBD
}",
"rsName":"SimplePresDef",
"rsVersion":"1.0",
"rsType": "pdf"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"endorser": "D6HG5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
"taaAcceptance": {
"taaDigest": "6sh15d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"mechanism": "EULA",
"time": 1513942017
}
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
"txnId":"L5AD5g65TDQr1PPHHRoiGf1|Degree|1.0",
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
Pool Ledger¶
NODE¶
Adds a new node to the pool or updates an existing node in the pool
data(dict):Data associated with the Node:
alias(string): Node’s aliasblskey(base58-encoded string; optional): BLS multi-signature key as base58-encoded string (it’s needed for BLS signatures and state proofs support)client_ip(string; optional): Node’s client listener IP address, that is the IP clients use to connect to the node when sending read and write requests (ZMQ with TCP)client_port(string; optional): Node’s client listener port, that is the port clients use to connect to the node when sending read and write requests (ZMQ with TCP)node_ip(string; optional): The IP address other Nodes use to communicate with this Node; no clients are allowed here (ZMQ with TCP)node_port(string; optional): The port other Nodes use to communicate with this Node; no clients are allowed here (ZMQ with TCP)services(array of strings; optional): the service of the Node.VALIDATORis the only supported one now.
dest(base58-encoded string):Target Node’s verkey as base58-encoded string for 16 or 32 byte DID value. It differs from
identifiermetadata field, whereidentifieris the DID of the transaction submitter (Steward’s DID).Example:
identifieris a DID of a Steward creating a new Node, anddestis the verkey of this Node.
If there is no NODE transaction with the specified Node ID (dest), then it can be considered as creation of a new NODE.
If there is a NODE transaction with the specified Node ID (dest), then this is update of existing NODE.
In this case we can specify only the values we would like to override. All unspecified values remain the same.
So, if a Steward wants to rotate BLS key, then it’s sufficient to send a NODE transaction with dest and a new blskey.
There is no need to specify all other fields, and they will remain the same.
Example:
{
"ver": 1,
"txn": {
"type":0,
"protocolVersion":2,
"data": {
"data": {
"alias":"Delta",
"blskey":"4kkk7y7NQVzcfvY4SAe1HBMYnFohAJ2ygLeJd3nC77SFv2mJAmebH3BGbrGPHamLZMAFWQJNHEM81P62RfZjnb5SER6cQk1MNMeQCR3GVbEXDQRhhMQj2KqfHNFvDajrdQtyppc4MZ58r6QeiYH3R68mGSWbiWwmPZuiqgbSdSmweqc",
"client_ip":"127.0.0.1",
"client_port":7407,
"node_ip":"127.0.0.1",
"node_port":7406,
"services":["VALIDATOR"]
},
"dest":"4yC546FFzorLPgTNTc6V43DnpFrR8uHvtunBxb2Suaa2",
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
Config Ledger¶
POOL_UPGRADE¶
Command to upgrade the Pool (sent by Trustee). It upgrades the specified Nodes (either all nodes in the Pool, or some specific ones).
name(string):Human-readable name for the upgrade.
action(enum:startorcancel):Starts or cancels the Upgrade.
version(string):The version of indy-node package we perform upgrade to. Must be greater than existing one (or equal if
reinstallflag is True).schedule(dict of node DIDs to timestamps):Schedule of when to perform upgrade on each node. This is a map where Node DIDs are keys, and upgrade time is a value (see example below). If
forceflag is False, then it’s required that time difference between each Upgrade must be not less than 5 minutes (to give each Node enough time and not make the whole Pool go down during Upgrade).sha256(sha256 hash string):sha256 hash of the package
force(boolean; optional):Whether we should apply transaction (schedule Upgrade) without waiting for consensus of this transaction. If false, then transaction is applied only after it’s written to the ledger. Otherwise it’s applied regardless of result of consensus, and there are no restrictions on the Upgrade
schedulefor each Node. So, we can Upgrade the whole Pool at the same time when it’s set to True. False by default. Avoid setting to True without good reason.reinstall(boolean; optional):Whether it’s allowed to re-install the same version. False by default.
timeout(integer; optional):Limits upgrade time on each Node.
justification(string; optional):Optional justification string for this particular Upgrade.
Example:
{
"ver": 1,
"txn": {
"type":109,
"ver":1,
"protocolVersion":2,
"data": {
"name":"upgrade-13",
"action":"start",
"version":"1.3",
"schedule":{"4yC546FFzorLPgTNTc6V43DnpFrR8uHvtunBxb2Suaa2":"2017-12-25T10:25:58.271857+00:00","AtDfpKFe1RPgcr5nnYBw1Wxkgyn8Zjyh5MzFoEUTeoV3":"2017-12-25T10:26:16.271857+00:00","DG5M4zFm33Shrhjj6JB7nmx9BoNJUq219UXDfvwBDPe2":"2017-12-25T10:26:25.271857+00:00","JpYerf4CssDrH76z7jyQPJLnZ1vwYgvKbvcp16AB5RQ":"2017-12-25T10:26:07.271857+00:00"},
"sha256":"db34a72a90d026dae49c3b3f0436c8d3963476c77468ad955845a1ccf7b03f55",
"force":false,
"reinstall":false,
"timeout":1,
"justification":null,
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
NODE_UPGRADE¶
Status of each Node’s upgrade (sent by each upgraded Node)
action(enum string):One of
in_progress,completeorfail.version(string):The version of indy-node the node was upgraded to.
Example:
{
"ver":1,
"txn": {
"type":110,
"ver":1,
"protocolVersion":2,
"data": {
"action":"complete",
"version":"1.2"
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
POOL_CONFIG¶
Command to change Pool’s configuration
writes(boolean):Whether any write requests can be processed by the pool (if false, then pool goes to read-only state). True by default.
force(boolean; optional):Whether we should apply transaction (for example, move pool to read-only state) without waiting for consensus of this transaction. If false, then transaction is applied only after it’s written to the ledger. Otherwise it’s applied regardless of result of consensus. False by default. Avoid setting to True without good reason.
Example:
{
"ver":1,
"txn": {
"type":111,
"ver":1,
"protocolVersion":2,
"data": {
"writes":false,
"force":true,
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"digest": "4ba05d9b2c27e52aa8778708fb4b3e5d7001eecd02784d8e311d27b9090d9453",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
},
},
"txnMetadata": {
"txnTime":1513945121,
"seqNo": 10,
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}
AUTH_RULE¶
A command to change authentication rules.
Internally authentication rules are stored as a key-value dictionary: {action} -> {auth_constraint}.
The list of actions is static and can be found in auth_rules.md. There is a default Auth Constraint for every action (defined in auth_rules.md).
The AUTH_RULE command allows to change the Auth Constraint.
So, it’s not possible to register new actions by this command. But it’s possible to override authentication constraints (values) for the given action.
Please note, that list elements of GET_AUTH_RULE output can be used as an input (with a required changes) for AUTH_RULE.
The following input parameters must match an auth rule from the auth_rules.md:
auth_type(string enum)The type of transaction to change the auth constraints to. (Example: “0”, “1”, …). See transactions description to find the txn type enum value.
auth_action(enum:ADDorEDIT)Whether this is adding of a new transaction, or editing of an existing one.
field(string)Set the auth constraint of editing the given specific field.
*can be used to specify that an auth rule is applied to all fields.old_value(string; optional)Old value of a field, which can be changed to a new_value. Must be present for EDIT
auth_actiononly.*can be used if it doesn’t matter what was the old value.new_value(string)New value that can be used to fill the field.
*can be used if it doesn’t matter what was the old value.
The constraint_id fields is where one can define the desired auth constraint for the action:
constraint(dict)constraint_id(string enum)Constraint Type. As of now, the following constraint types are supported:
- "ROLE": a constraint defining how many siganatures of a given role are required - "OR": logical disjunction for all constraints from `auth_constraints` - "AND": logical conjunction for all constraints from `auth_constraints`
fields if
"constraint_id": "OR"or"constraint_id": "AND"auth_constraints(list)A list of constraints. Any number of nested constraints is supported recursively
fields if
"constraint_id": "ROLE":role(string enum)Who (what role) can perform the action Please have a look at NYM transaction description for a mapping between role codes and names.
sig_count(int):The number of signatures that is needed to do the action
need_to_be_owner(boolean):Flag to check if the user must be the owner of a transaction (Example: A steward must be the owner of the node to make changes to it). The notion of the
owneris different for every auth rule. Please reference to auth_rules.md for details.off_ledger_signature(boolean, optional, False by default):Whether signatures against keys not present on the ledger are accepted during verification of required number of valid signatures. An example when it can be set to
Trueis creation of a new DID in a permissionless mode, that is whenidentiferis not present on the ledger and a newly createdverkeyis used for signature verification. Another example is signing by cryptonyms (where identifier is equal to verkey), but this is not supported yet. If the value of this field is False (default), and the number of required signatures is greater than zero, then the transaction author’s DID (identifier) must be present on the ledger (corresponding NYM txn must exist).metadata(dict; optional):Dictionary for additional parameters of the constraint. Can be used by plugins to add additional restrictions.
fields if
"constraint_id": "FORBIDDEN":no fields
Example:
Let’s consider an example of changing a value of a NODE transaction’s service field from [VALIDATOR] to [] (demotion of a node).
We are going to set an Auth Constraint, so that the action can be only be done by two TRUSTEE or one STEWARD who is the owner (the original creator) of this transaction.
{
"txn":{
"type":"120",
"protocolVersion":2,
"data":{
"auth_type": "0",
"auth_action": "EDIT",
"field" :"services",
"old_value": [VALIDATOR],
"new_value": []
"constraint":{
"constraint_id": "OR",
"auth_constraints": [{"constraint_id": "ROLE",
"role": "0",
"sig_count": 2,
"need_to_be_owner": False,
"metadata": {}},
{"constraint_id": "ROLE",
"role": "2",
"sig_count": 1,
"need_to_be_owner": True,
"metadata": {}}
]
},
},
"metadata":{
"reqId":252174114,
"from":"M9BJDuS24bqbJNvBRsoGg3",
"digest":"6cee82226c6e276c983f46d03e3b3d10436d90b67bf33dc67ce9901b44dbc97c",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
}
},
"txnMetadata":{
"txnTime":1551785798,
"seqNo":1
},
"reqSignature":{
"type":"ED25519",
"values":[
{
"value":"4wpLLAtkT6SeiKEXPVsMcCirx9KvkeKKd11Q4VsMXmSv2tnJrRw1TQKFyov4m2BuPP4C5oCiZ6RUwS9w3EPdywnz",
"from":"M9BJDuS24bqbJNvBRsoGg3"
}
]
},
"ver":"1"
}
AUTH_RULES¶
A command to set multiple AUTH_RULEs by one transaction.
Transaction AUTH_RULES is not divided into a few AUTH_RULE transactions, and is written to the ledger with one transaction with the full set of rules that come in the request.
Internally authentication rules are stored as a key-value dictionary: {action} -> {auth_constraint}.
The list of actions is static and can be found in auth_rules.md. There is a default Auth Constraint for every action (defined in auth_rules.md).
The AUTH_RULES command allows to change the Auth Constraints.
So, it’s not possible to register new actions by this command. But it’s possible to override authentication constraints (values) for the given action.
Please note, that list elements of GET_AUTH_RULE output can be used as an input (with a required changes) for the field rules in AUTH_RULES.
The
rulesfield contains a list of auth rules. One rule has the following list of parameters which must match an auth rule from the auth_rules.md:auth_type(string enum)The type of transaction to change the auth constraints to. (Example: “0”, “1”, …). See transactions description to find the txn type enum value.
auth_action(enum:ADDorEDIT)Whether this is adding of a new transaction, or editing of an existing one.
field(string)Set the auth constraint of editing the given specific field.
*can be used to specify that an auth rule is applied to all fields.old_value(string; optional)Old value of a field, which can be changed to a new_value. Must be present for EDIT
auth_actiononly.*can be used if it doesn’t matter what was the old value.new_value(string)New value that can be used to fill the field.
*can be used if it doesn’t matter what was the old value.
The
constraint_idfields is where one can define the desired auth constraint for the action:constraint(dict)constraint_id(string enum)Constraint Type. As of now, the following constraint types are supported:
- "ROLE": a constraint defining how many siganatures of a given role are required - "OR": logical disjunction for all constraints from `auth_constraints` - "AND": logical conjunction for all constraints from `auth_constraints` - "FORBIDDEN": a constraint for not allowed actions
fields if
"constraint_id": "OR"or"constraint_id": "AND"auth_constraints(list)A list of constraints. Any number of nested constraints is supported recursively
fields if
"constraint_id": "ROLE":role(string enum)Who (what role) can perform the action Please have a look at NYM transaction description for a mapping between role codes and names.
sig_count(int):The number of signatures that is needed to do the action
need_to_be_owner(boolean):Flag to check if the user must be the owner of a transaction (Example: A steward must be the owner of the node to make changes to it). The notion of the
owneris different for every auth rule. Please reference to auth_rules.md for details.off_ledger_signature(boolean, optional, False by default):Whether signatures against keys not present on the ledger are accepted during verification of required number of valid signatures. An example when it can be set to
Trueis creation of a new DID in a permissionless mode, that is whenidentiferis not present on the ledger and a newly createdverkeyis used for signature verification. Another example is signing by cryptonyms (where identifier is equal to verkey), but this is not supported yet. If the value of this field is False (default), and the number of required signatures is greater than zero, then the transaction author’s DID (identifier) must be present on the ledger (corresponding NYM txn must exist).metadata(dict; optional):Dictionary for additional parameters of the constraint. Can be used by plugins to add additional restrictions.
fields if
"constraint_id": "FORBIDDEN":no fields
Example:
{
"txn":{
"type":"120",
"protocolVersion":2,
"data":{
rules: [
{"auth_type": "0",
"auth_action": "EDIT",
"field" :"services",
"old_value": [VALIDATOR],
"new_value": []
"constraint":{
"constraint_id": "OR",
"auth_constraints": [{"constraint_id": "ROLE",
"role": "0",
"sig_count": 2,
"need_to_be_owner": False,
"metadata": {}},
{"constraint_id": "ROLE",
"role": "2",
"sig_count": 1,
"need_to_be_owner": True,
"metadata": {}}
]
},
},
...
]
"metadata":{
"reqId":252174114,
"from":"M9BJDuS24bqbJNvBRsoGg3",
"digest":"6cee82226c6e276c983f46d03e3b3d10436d90b67bf33dc67ce9901b44dbc97c",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
}
},
"txnMetadata":{
"txnTime":1551785798,
"seqNo":1
},
"reqSignature":{
"type":"ED25519",
"values":[
{
"value":"4wpLLAtkT6SeiKEXPVsMcCirx9KvkeKKd11Q4VsMXmSv2tnJrRw1TQKFyov4m2BuPP4C5oCiZ6RUwS9w3EPdywnz",
"from":"M9BJDuS24bqbJNvBRsoGg3"
}
]
},
"ver":"1"
}
LEDGERS_FREEZE¶
Freeze deprecated ledgers (default ledgers such as the domain, config, pool, and audit ledgers cannot be frozen). If a ledger is frozen it can be used for reading but not for writing. Frozen ledgers will not be caught up by new nodes and they can’t be unfrozen. Frozen ledgers can be removed without breaking consensus, but this would prevent third parties from auditing the ledger history. More information is in the Indy Plenum documenation.
Example:
{
"ver": 1,
"txn": {
"type":9,
"protocolVersion":2,
"data": {
"ver": 1,
"ledgers_ids": [1,2,3,4],
},
"metadata": {
"reqId":1513945121191691,
"from":"L5AD5g65TDQr1PPHHRoiGf",
"digest":"6cee82226c6e276c983f46d03e3b3d10436d90b67bf33dc67ce9901b44dbc97c",
"payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
},
},
"txnMetadata": {
"txnTime":1577836799,
"seqNo": 10,
},
"reqSignature": {
"type": "ED25519",
"values": [{
"from": "L5AD5g65TDQr1PPHHRoiGf",
"value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
}]
}
}