티스토리 뷰

Blockchain/Hyperledger Indy

[Hyperledger Indy Docs] Indy Node: 1. Transactions

miiingo 2020. 2. 19. 14:20
반응형
이 글은 Hyperledger Indy의 공식 문서를 번역한 것입니다.
원본 사이트 : https://hyperledger-indy.readthedocs.io/projects/node/en/latest/transactions.html

 

General Information(일반 정보)

이 문서는 지원되는 트랜잭션 및 원장(즉, 내부 트랜잭션)에서의 표현에 관한 것입니다. 클라이언트의 request 형식(쓰기 및 읽기 모두)에 관심이 있는 경우 request를 살펴보십시오.

  • 모든 트랜잭션은 분산 원장에 저장됩니다(모든 노드에 복제됨).
  • 원장은 Merkle Tree를 기반으로 합니다.
  • 원장은 두 가지로 구성됩니다.:
    • key는 트랜잭션의 시퀀스 번호이고 value는 직렬화된 트랜잭션인 key-value 쌍의 시퀀스로 트랜잭션이 기록됩니다.
    • 머클 트리(leave와 node의 hash가 유지되는 곳)
  • 각 트랜잭션에는 시퀀스 번호(갭 없음)가 있습니다. - key는 트랜잭션 로그 안에 존재
  • 따라서 이것은 각 블록의 크기가 1인 블록 체인으로 간주될 수 있습니다.
  • 기본적으로 여러 원장이 있습니다.:
    • pool ledger: pool/네트워크 구성과 관련된 트랜잭션(모든 노드, 해당 key 및 주소 나열)
    • config ledger: pool 구성 트랜잭션과 pool 업그레이드 관련 트랜잭션
    • domain ledger: 모든 주요 도메인 및 응용 프로그램별 트랜잭션 (DID에 대한 NYM 트랜잭션 포함)
  • 모든 트랜잭션은 MsgPack 형식으로 직렬화됩니다.
  • 모든 트랜잭션(트랜잭션 로그 및 머클 트리 해시 저장소 모두)은 LevelDB에 저장됩니다.
  • read_ledger 스크립트를 사용하여 지정된 원장에 대한 트랜잭션을 읽을 수 있는 형식(JSON)으로 가져올 수 있습니다.
  • 역할(role) 및 역할 유형에 대해서는 역할 및 권한(roles and permissions)을 참조하십시오.

아래에서 지원되는 모든 트랜잭션의 형식과 설명을 찾을 수 있습니다.

 

Genesis Transactions(제네시스 트랜잭션)

Indy는 퍼블릭 허가형(permissioned) 블록 체인이므로 각 원장은 초기 pool과 네트워크를 정의하는 다수의 사전 정의된 트랜잭션을 가질 수 있습니다.

  • pool 제네시스 트랜잭션은 pool에서 초기 신뢰된 노드를 정의합니다.
  • domain 제네시스 트랜잭션은 초기 신뢰할 수 있는 trustee 및 steward를 정의합니다.

 

Common Structure(공통 구조)

각 트랜잭션은 메타 데이터 값(모든 트랜잭션 유형에 공통)과 트랜잭션 특정 데이터로 구성된 다음 구조를 갖습니다.:

{
    "ver": <...>,
    "txn": {
        "type": <...>,
        "protocolVersion": <...>,

        "data": {
            "ver": <...>,
            <txn-specific fields>
        },

        "metadata": {
            "reqId": <...>,
            "from": <...>,
            "endorser": <...>,
            "digest": <...>,
            "payloadDigest": <...>,
            "taaAcceptance": {
                "taaDigest": <...>,
                "mechanism": <...>,
                "time": <...>
             }
        },
    },
    "txnMetadata": {
        "txnTime": <...>,
        "seqNo": <...>,
        "txnId": <...>
    },
    "reqSignature": {
        "type": <...>,
        "values": [{
            "from": <...>,
            "value": <...>
        }]
    }
}
  • ver (string): 컨텐츠를 진화시킬 수 있는 트랜잭션 버전. 모든 하위 필드의 내용은 이 버전에 따라 달라질 수 있습니다.
  • txn (dict): 트랜잭션 별 페이로드(데이터)
    • type (enum number as string): 지원되는 트랜잭션 유형:
      • 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”
    • protocolVersion (integer; optional): 클라이언트-노드 또는 노드-노드 프로토콜의 버전. 각각의 새로운 버전은 요청/응답/데이터에 새로운 기능을 도입할 수 있습니다. 클라이언트와 다른 노드의 버전이 다를 수 있으므로 클라이언트와 노드 간의 역 호환성을 지원하려면 이 필드가 필요합니다.
    • data (dict): 트랜잭션 별 데이터 필드(각 트랜잭션 설명에 대해서는 다음 섹션 참조)
    • metadata (dict): request에서 나온 메타 데이터
      • from (base58-encoded string): 16 또는 32 비트 DID 값에 대한 base58 인코딩 문자열인 트랜잭션 작성자의 Identifier(DID)입니다. Identifier 대신 트랜잭션을 제출하는 endorser 필드와 다를 수 있습니다. endorser가 없는 경우 작성자(Identifier)는 endorser의 역할을 수행하고 자신의 request를 제출합니다. 또한 일부 요청(예: NYM)의 경우 dest 필드와 다를 수 있습니다. 여기서 dest는 타겟 Identifier(예: 새로 생성된 DID Identifier)입니다. 예:
        • identifier는 쓰기 권한이 없는 트랜잭션 작성자의 DID입니다. endorser는 Endorser 역할(즉, 쓰기 권한이 있는 사용자)의 DID입니다.)
        • 새로운 NYM 생성: identifier는 새로운 DID를 생성하는 Endorser의 DID이며 dest는 새로 생성된 DID입니다.
      • reqId (integer): 트랜잭션 request의 고유 ID 번호
      • digest (SHA256 hex digest string): 초기 request의 모든 필드에 대한 SHA256 해시 16진 다이제스트(서명 포함)
      • payloadDigest (SHA256 hex digest string): 초기 request에서 페이로드 필드의 SHA256 해시 16진 다이제스트. 서명 및 플러그인이 추가된 것을 제외한 모든 필드
      • endorser (base58-encoded string, optional): endorser의 identifier(DID)는 원본 작성자(identifier)를 대신하여 16 비트 또는 32 비트 DID 값에 대한 base58 인코딩 문자열로 트랜잭션을 제출합니다. endorser가 없는 경우 작성자(identifier)는 endorser의 역할을 수행하고 자신의 request를 제출합니다. endorser가 있는 경우 작성자(identifier)와 Endorser(endorser) 모두가 트랜잭션을 다중 서명해야합니다.
      • taaAcceptance (dict, optional): 트랜잭션 작성자 계약이 set/enabled 된 경우 Domain 및 플러그인 추가 원장의 모든 트랜잭션(쓰기 request)에는 최신 트랜잭션 작성자 계약에 대한 승인이 포함되어야합니다.
        • taaDigest (SHA256 hex digest string): 원장에 대한 최신 트랜잭션 작성자 계약의 SHA256 16진 다이제스트. 다이제스트는 TRANSACTION_AUTHOR_AGREEMENT의 version과 text를 연결하여 계산됩니다.
        • mechanism (string): 서명을 수락하는 데 사용되는 메커니즘. 원장의 최신 트랜잭션 작성자 계약 수락 메커니즘 목록에 있어야합니다.
        • time (integer as POSIX timestamp): 트랜잭션 작성자 계약 승인 시간
    • txnMetadata (dict): 트랜잭션에 첨부된 메타 데이터
      • version (integer): txnMetadata를 발전시킨 수 있는 트랜잭션 버전. txnMetadata의 내용은 버전에 따라 달라질 수 있습니다.
      • txnTime (integer as POSIX timestamp): 트랜잭션이 POSIX 타임 스탬프로 원장에 기록된 시간
      • seqNo (integer): 원장 트랜잭션의 고유한 시퀀스 번호
      • txnId (string, optional): State Trie key(주소 또는 설명 데이터)인 Txn ID. 원장 내에서 고유해야합니다. 일반적으로 Domain 트랜잭션에만 존재합니다.
  • reqSignature (dict): 트랜잭션 request에 대한 submitter의 서명(txn 필드)
    • type (string enum):
      • ED25519: ed25519 서명
      • ED25519_MULTI: 멀티서명 케이스의 ed25519 서명
    • values (list):
      • from (base58-encoded string): 16 바이트 또는 32 바이트 DID 값에 대한 base58 인코딩 문자열인 서명자의 Identifier(DID)
      • value (base58-encoded string): 서명 값

이러한 모든 메타 데이터 필드는 제네시스 트랜잭션에 없을 수 있음을 유의하십시오.

 

Domain Ledger(Domain 원장)

NYM

특정 사용자, endorser, steward 또는 trustee에 대한 새로운 NYM 레코드를 생성합니다. trustee와 steward만 새로운 endorser를 만들 수 있으며, trustee는 다른 trustee에 의해서만 생성될 수 있습니다(role 참조).

이 트랜잭션은 새로운 DID 생성, 검증 키 설정 및 회전, 역할 설정 및 변경에 사용될 수 있습니다.

  • dest (base58-encoded string): 16 또는 32 바이트 DID 값에 대한 base58 인코딩 문자열인 Target DID. submitter의 DID인 from 메타 데이터 필드와 다를 수 있습니다. 이들이 동일한 경우(비허가형의 경우), 새로 작성된 verkey로 트랜잭션에 서명해야합니다.
  • 예: from은 새로운 DID를 작성하는 Endorser의 DID이고 dest는 새로 작성된 DID입니다.
  • role (enum number as integer; optional): NYM 레코드가 작성되는 사용자의 역할. 다음 값 중 하나
    • None (common USER)
    • "0" (TRUSTEE)
    • "2" (STEWARD)
    • "101" (ENDORSER)
    • "201" (NETWORK_MONITOR)
    • TRUSTEE는 Nym의 역할을 None으로 변경할 수 있으므로 더 이상 쓰지 못합니다(role 참조).
  • verkey (base58-encoded string, possibly starting with “~”; optional): base58로 인코딩 된 문자열인 Target 검증 키. "~"로 시작할 수 있습니다. 이는 단축된 verkey이고 디코딩 시 16 바이트 길이여야하고, 그렇지 않으면 디코드 될 때 32 바이트 길이의 전체 verkey입니다. 설정되지 않은 경우 target identifier(did)는 32 비트 암호화 CID(더이상 사용되지 않음)이거나 보호자가 있는 사용자입니다(아직 identifier를 소유하지 않음). verkey는 소유자가 "None"으로 변경할 수 있습니다. 즉, 이 사용자는 보호자 상태로 돌아갑니다.
  • alias (string; optional): NYM의 별칭

지정된 DID(did)에 대한 NYM 트랜잭션이 없는 경우 새 DID 생성으로 간주될 수 있습니다.

지정된 DID(did)가 있는 NYM 트랜잭션이 이미 있으면 해당 DID의 업데이트로 간주됩니다. 이 경우 원장의 현재 값과 일치하더라도 지정된 값이 업데이트로 처리되므로 업데이트 해야하는 값만 지정해야합니다. 지정되지 않은 모든 값은 변경되지 않습니다.

따라서 키 회전(key rotation)을 수행해야 하는 경우 DID 소유자는 did 및 verkey만으로 NYM 요청을 보내야합니다. role과 alias는 동일하게 유지됩니다.

예:

{
    "ver": 1,
    "txn": {
        "type":"1",
        "protocolVersion":2,

        "data": {
            "ver": 1,
            "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

NYM 레코드에 속성을 추가합니다.

  • dest (base58-encoded string): 16 또는 32 바이트 DID 값에 대한 base58 인코딩 문자열로 속성을 설정한 Target DID. submitter의 DID인 from 메타 데이터 필드와 다릅니다.
  • 예: from은 DID의 속성을 설정하는 Endorser의 DID이며, dest는 속성을 설정한 DID입니다.
  • raw (sha256 hash string; mutually exclusive with hash and enc): raw 속성 데이터의 Hash. raw 데이터는 JSON으로 표시되며 어기서 key는 속성 이름이고 value는 속성 값입니다. 원장은 raw 데이터의 해시만 저장합니다. 실제(해시되지 않은) raw 데이터는 별도의 속성 저장소에 저장됩니다.
  • hash (sha256 hash string; mutually exclusive with raw and enc): 클라이언트가 보낸 속성 데이터의 Hash. 속성 저장소에는 아무것도 저장되지 않습니다.
  • enc (sha256 hash string; mutually exclusive with raw and hash): 암호화된 속성 데이터의 Hash. 원장은 해시만 포함합니다. 실제 암호화된 데이터는 별도의 속성 저장소에 저장됩니다.

예:

{
    "ver": 1,
    "txn": {
        "type":"100",
        "protocolVersion":2,

        "data": {
            "ver":1,
            "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

Claim의 schema를 추가합니다.

기존 schema를 업데이트 할 수 없습니다. 따라서 schema를 발전시켜야하는 경우 새 버전 또는 새 이름을 가진 새로운 schema를 작성해야합니다.

  • data (dict): Schema 데이터가 포함된 사전
    • attr_names: 속성 이름 문자열의 배열
    • name: schema의 이름 문자열
    • version: schema의 버전 문자열

예:

{
    "ver": 1,
    "txn": {
        "type":101,
        "protocolVersion":2,

        "data": {
            "ver":1,
            "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

issuer가 특정 claim schema에 대해 만들고 게시하는 claim definition(특히, 공개 키)를 추가합니다.

  • data (dict): clain definition 데이터가 있는 사전
    • primary (dict): 기본 claim 공개 키
    • revocation (dict): 해지 claim 공개 키
  • ref (string): claim definition이 작성되는 schema 트랜잭션의 시퀀스 번호
  • signature_type (string):claim definition의 유형(claim 서명). CL(Camenisch-Lysyanskaya)은 현재 유일하게 지원되는 유형입니다.
  • tag (string, optional): 동일한 DID에서 발급한 동일한 Schema 및 유형에 대해 여러 개의 공개 키를 갖는 고유한 태그. 지정하지 않으면 기본 태그인 tag가 사용됩니다.

예:

{
    "ver": 1,
    "txn": {
        "type":102,
        "protocolVersion":2,

        "data": {
            "ver":1,
            "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

Issuer가 특정 Claim Definition에 대해 생성 및 게시하는 해지 레지스트리 정의를 추가합니다. 여기에는 공개 키, 레지스트리에 포함할 수 있는 최대 credential 수, Claim Def에 대한 참조 및 일부 해지 레지스트리 특정 데이터가 포함됩니다.

  • value (dict): 해지 레지스트리 definition 데이터가 있는 사전:
    • maxCredNum (integer): 해지 레지스트리가 처리할 수 있는 최대 credential 수
    • tailsHash (string): tails file 요약
    • tailsLocation (string): tails file 위치 (URL)
    • issuanceType (string enum): credential 해지 전략 정의. 다음과 같은 값을 가질 수 있습니다.:
      • ISSUANCE_BY_DEFAULT: 모든 credential은 처음에 발급된 것으로 간주되므로 해지할 때만 해지 레지스트리를 업데이트(REVOC_REG_ENTRY txn 전송)해야합니다. 해지 레지스트리는 이 경우 해지된 credential 인덱스만 저장합니다. 예상되는 해지 조치 수가 예상되는 발행 조치 수보다 적은 경우 사용하는 것이 좋습니다.
      • ISSUANCE_ON_DEMAND: 초기에 발급된 credential이 없으므로 발급 및 해지마다 해지 레지스트리를 업데이트(REVOC_REG_ENTRY txn 전송)해야합니다. 이 경우 해지 레지스트리는 발급된 credential 인덱스만 저장합니다. 예상되는 발행 조치 수가 예상 해지 조치 수보다 적은 경우 사용하는 것이 좋습니다.
    • publicKeys (dict): 해지 레지스트리의 공개 키
  • id (string): 해지 레지스트리 Definition의 고유 identifier(현재 상태 trie의 키가 사용됨)
  • credDefId (string): 해당 Credential Definition의 고유 identifier(현재 상태 trie의 키가 사용됨)
  • revocDefType (string enum): 해지 유형. CL_ACCUM(Camenisch-Lysyanskaya Accumulator)은 현재 유일하게 지원되는 유형입니다.
  • tag (string): 동일한 Credential Definition 및 동일한 DID에서 발급한 유형에 대해 여러 해지 레지스트리 Definition을 갖는 고유한 태그.

예:

{
    "ver": 1,
    "txn": {
        "type":113,
        "protocolVersion":2,

        "data": {
            "ver":1,
            '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

새 누산기 값과 발행/해지된 인덱스를 포함하는 RevocReg 항목입니다. 이것은 전체 목록이 아닌 인덱스의 델타입니다. 따라서 새로운 claim이 발행/해지될 때마다 전송될 수 있습니다.

  • value (dict): 해지 레지스트리 데이터가 있는 사전:
    • accum (string): 현재 누산기 값
    • prevAccum (string): 이전 누산기 값; 현재 값과 비교되며 txn이 일치하지 않으면 거부됩니다. dirty write 및 누산기 업데이트를 피해야합니다.
    • issued (list of integers): 발행된 인덱스의 배열(유형이 ISSUANCE_BY_DEFAULT이면 부재/비어있을 수 있음); 이것은 델타입니다.; state에 누적됩니다.
    • revoked (list of integers): 해지된 인덱스 배열(델타; state에 누적됨)
  • revocRegDefId (string): 해당 해지 레지스트리 Definition의 고유 identifier(현재 state trie의 키가 사용됨).
  • revocDefType (string enum): 해지 유형. CL_ACCUM(Camenisch-Lysyanskaya Accumulator)은 현재 유일하게 지원되는 유형입니다.

예:

{
    "ver": 1,
    "txn": {
        "type":114,
        "protocolVersion":2,

        "data": {
            "ver":1,
            '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"
        }]
    }
}

 

Pool Ledger(Pool 원장)

NODE

pool에 새로운 노드를 추가하거나 pool의 기존 노드를 업데이트합니다.

  • data (dict): 노드와 관련된 데이터:
    • alias (string): 노드의 별칭
    • blskey (base58-encoded string; optional): base58로 인코딩된 문자열인 BLS 다중 서명 키(BLS 서명 및 상태 증명 지원에 필요)
    • client_ip (string; optional): 노드의 클라이언트 리스너 IP 주소, 즉 클라이언트가 읽기 및 쓰기 요청을 보낼 때 노드에 연결하는 데 사용하는 IP(TCP를 사용한 ZMQ)
    • client_port (string; optional): 노드의 클라이언트 리스터 포트, 즉 클라이언트가 읽기 및 쓰기 요청을 보낼 때 노드에 연결하는 데 사용하는 포트(TCP를 사용한 ZMQ)
    • node_ip (string; optional): 다른 노드가 이 노드와 통신하는 데 사용하는 IP 주소; 여기에는 클라이언트가 허용되지 않음 (TCP를 사용한 ZMQ)
    • node_port (string; optional): 다른 노드가 이 노드와 통신하는 데 사용하는 포트; 여기에는 클라이언트가 허용되지 않음 (TCP를 사용한 ZMQ)
    • services (array of strings; optional): 노드의 서비스. VALIDATOR는 현재 유일하게 지원됩니다.
  • dest (base58-encoded string): 16 또는 32 바이트 DID 값을 위한 base58 인코딩 문자열인 Target Node의 verkey. identifier 메타 데이터 필드와 다르며, 여기서 identifier는 트랜잭션 submitter의 DID(Steward의 DID)입니다.
  • 예: identifier는 새로운 노드를 작성하는 Steward의 DID이며 dest는 이 노드의 verkey입니다.

지정된 Node ID(dest)의 NODE 트랜잭션이 없는 경우, 새로운 NODE 작성으로 간주될 수 있습니다.

지정된 Node ID(dest)의 NODE 트랜잭션이 있는 경우, 이는 기존 NODE의 업데이트입니다. 이 경우 재정의하려는 값만 지정할 수 있습니다. 지정되지 않은 모든 값은 동일하게 유지됩니다. 따라서 Steward가 BLS 키를 회전시키려면 dest와 새로운 blskey를 사용하여 NODE 트랜잭션을 보내는 것으로 충분합니다. 다른 모든 필드를 지정할 필요는 없으며, 기존과 동일하게 유지됩니다.

예:

{
    "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(Config 원장)

POOL_UPGRADE

Pool을 업그레이드하는 명령(Trustee가 보냄). 지정된 Node(Pool의 모든 노드 또는 특정 노드)를 업그레이드합니다.

  • name (string): 사람이 읽을 수 있는 업그레이드 이름
  • action (enum: start 또는 cancel): 업그레이드를 시작하거나 취소합니다.
  • version (string): 업그레이드를 수행하는 indy-node 패키지의 버전. 기존의 버전보다 커야합니다(또는 reinstall 플래그가 True인 경우도 가능).
  • schedule (dict of node DIDs to timestamps): 각 노드에서 업그레이드를 수행할 일정. 이것은 Node DID가 key이고, 업그레이드 시간이 value인 map입니다(아래 예 참조). force 플래그가 False이면 각 업그레이드 간의 시간 차이가 5분 이상이어야합니다(각 Node에 충분한 시간을 제공하고 업그레이드 중에 전체 Pool이 다운되지 않도록 해야합니다).
  • sha256 (sha256 hash string): 패키지의 sha256 해시
  • force (boolean; optional): 이 트랜잭션의 합의(consensus)를 기다리지 않고 트랜잭션(스케줄 업그레이드)을 적용해야하는지 여부. false인 경우 트랜잭션은 원장에 작성된 후에만 적용됩니다. 그렇지 않으면 합의의 결과에 관계없이 적용되며 각 Node의 업그레이드 schedule에는 제한이 없습니다. 따라서 True로 설정하면 전체 Pool을 동시에 업그레이드할 수 있습니다. 기본적으로는 False입니다. 정당한 이유 없이 True로 설정하지 마십시오.
  • reinstall (boolean; optional): 동일한 버전을 다시 설치할 수 있는지 여부. 기본적으로 False.
  • timeout (integer; optional): 각 Node에서 업그레이드 시간을 제한합니다.
  • justification (string; optional): 이 특정 업그레이드에 대한 선택적 정렬 문자열

예:

{
    "ver": 1,
    "txn": {
        "type":109,
        "protocolVersion":2,

        "data": {
            "ver":1,
            "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

각 Node의 업그레이드 상태(업그레이드 된 각 Node에서 전송)

  • action (enum string): in_progress, complete 또는 fail 중 하나.
  • version (string): 노드가 업그레이드 된 indy-node의 버전.

예:

{
    "ver":1,
    "txn": {
        "type":110,
        "protocolVersion":2,

        "data": {
            "ver":1,
            "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

Pool 구성을 변경하는 명령

  • writes (boolean): pool에서 쓰기 요청을 처리할 수 있는지 여부(false인 경우 pool은 읽기 전용 상태가 됨). 기본적으로 true.
  • force (boolean; optional): 이 트랜잭션의 합의(consensus)를 기다리지 않고 트랜잭션(스케줄 업그레이드)을 적용해야하는지 여부. false인 경우 트랜잭션은 원장에 작성된 후에만 적용됩니다. 그렇지 않으면 합의의 결과에 관계없이 적용됩니다. 기본적으로는 False입니다. 정당한 이유 없이 True로 설정하지 마십시오.

예:

{
    "ver":1,
    "txn": {
        "type":111,
        "protocolVersion":2,

        "data": {
            "ver":1,
            "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

인증 규칙을 변경하는 명령. 내부 인증 규칙은 key-value 사전으로 저장됩니다.: {action} -> {auth_constraint}

작업 목록은 정적이며 auth_rules.md에서 찾을 수 있습니다. 모든 작업에 대한 기본 인증 제약(Auth Constraint) 조건이 있습니다(auth_rules.md에 정의어있음).

AUTH_RULE 명령으로 인증 제약(Auth Constraint)을 변경할 수 있습니다. 따라서 이 명령으로 새로운 작업을 등록할 수 없습니다. 그러나 지정된 작업에 대한 인증 제약(Auth Constraint) (values)을 재정의할 수 있습니다.

GET_AUTH_RULE 출력의 목록 요소는 AUTH_RULE에 대한 입력(필요한 변경 사항)으로 사용될 수 있습니다.

다음 입력 매개 변수는 auth_rules.md의 인증 규칙과 일치해야합니다.

  • auth_type (string enum): 인증 제약(Auth Constraint)을 변경할 트랜잭션 유형. (예: "0", "1", ...). txn 유형 enum 값을 찾으려면 트랜잭션 설명을 참조하십시오.
  • auth_action (enum: ADD or EDIT): 이것이 새 트랜잭션을 추가하는지 또는 기존 트랜잭션을 편집하는지 여부.
  • field (string): 주어진 특정 필드를 편집하는 인증 제약(Auth Constraint)을 설정. *는 모든 인증 규칙이 모든 필드에 적용되도록 지정하는 데 사용할 수 있습니다.
  • old_value (string; optional): 필드의 이전 값으로 new_value로 변경할 수 있습니다. auth_action에만 EDIT이 표시되어야합니다. *는 이전 값이 중요하지 않은 경우에 사용할 수 있습니다.
  • new_value (string): 필드를 채우는 데 사용할 수 있는 새로운 값. *은 이전 값이 중요하지 않은 경우에 사용할 수 있습니다.

constraint_id 필드는 작업에 대해 원하는 인증 제약(Auth Constraint)을 정의할 수 있는 위치입니다.:

  • constraint (dict)
    • constraint_id (string enum): 제약 유형(Constraint Type). 현재 다음과 같은 제약 유형이 지원됩니다.:

      - 'ROLE': 주어진 role 중 몇 개의 서명이 필요한지 정의하는 제약 - 'OR': auth_constraints의 모든 제약 조건에 대한 논리적 분리 - 'AND': auth_constraints의 모든 제약 조건에 대한 논리적 연결

    • 'constraint_id': 'OR' 또는 'constraint_id': 'AND'인 경우의 필드:
      • auth_constraints (list): 제약 조건 목록. 여러 개의 중첩 제약 조건이 재귀적으로 지원됩니다.
    • 'constraint_id': 'ROLE'인 경우의 필드:
      • role (string enum): 누가(어떤 role) 작업을 수행할 수 있을 것인가. 역할 코드와 이름 간의 매핑에 대한 NYM 트랜잭션 설명을 살펴보십시오.
      • sig_count (int): 작업을 수행하는 데 필요한 서명 수
      • need_to_be_owner (boolean): 사용자가 트랜잭션의 소유자여야 하는지 여부를 확인하는 플래그(예: 트랜잭션을 변경하려면 steward가 노드의 소유자여야 함). owner의 개념은 모든 인증 규칙마다 다릅니다. 자세한 내용은 auth_rules.md를 참조하십시오.
      • off_ledger_signature (boolean, optional, False by default): 원장에 없는 key에 대한 서명이 필요한 수의 유효한 서명을 검증하는 동안 승인되는지 여부. True로 설정될 수 있는 예는 비허가형(permissionless) 모드에서 새로운 DID를 작성하는 것입니다. 즉, 원장에 identifier가 없고 새로 작성된 verkey가 서명 확인에 사용되는 경우입니다. 다른 예는 암호(identifier는 verkey와 동일)로 서명하지만 아직 지원되지 않습니다. 이 필드의 값이 False(기본값)이고 필요한 서명 수가 0보다 큰 경우 트랜잭션 작성자의 DID(identifier)가 원장에 있어야합니다(NYM txn에 해당).
      • metadata (dict; optional): 제약 조건의 추가 매개 변수에 대한 사전. 플러그인에서 추가적인 제한을 설정하는 데 사용할 수 있습니다.
    • 'constraint_id': 'FORBIDDEN'인 경우의 필드: 필드가 없습니다.

예:

NODE 트랜잭션의 service 필드 값을 [VALIDATOR]에서 [](노드 수준 내리기)로 변경하는 예를 살펴보겠습니다. Auth Constraint를 설정하여 두 개의 TRUSTEE 또는 이 트랜잭션의 소유자(원래 작성자)인 하나의 STEWARD만 작업을 수행할 수 있습니다.

{  
   '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

하나의 트랜잭션으로 여러 AUTH_RULE을 설정하는 명령. 트랜잭션 AUTH_RULES는 몇 가지 AUTH_RULE 트랜잭션으로 나뉘지 않으며 요청에 포함된 전체 규칙 세트를 사용하여 하나의 트랜잭션으로 원장에 기록됩니다. 내부 인증 규칙은 key-value로 사전에 저장됩니다.: {action} -> {auth_constraint}

작업 목록은 정적이며 auth_rules.md에서 찾을 수 있습니다. 모든 작업에 대한 기본 인증 제약(Auth Constraint) 조건이 있습니다(auth_rules.md에 정의어있음).

AUTH_RULES 명령으로 인증 제약(Auth Constraint)을 변경할 수 있습니다. 따라서 이 명령으로 새로운 작업을 등록할 수 없습니다. 그러나 지정된 작업에 대한 인증 제약(Auth Constraint) (values)을 재정의할 수 있습니다.

GET_AUTH_RULE 출력의 목록 요소는 AUTH_RULES의 rules 필드에 대한 입력(필요한 변경 사항)으로 사용될 수 있습니다.

  • rules 필드에는 인증 규칙 목록이 있습니다. 하나의 규칙에는 auth_rules.md의 인증 규칙과 일치해야하는 다음과 같은 매개 변수 목록이 있습니다.:
    • auth_type (string enum): 인증 제약(Auth Constraint)을 변경할 트랜잭션 유형. (예: "0", "1", ...). txn 유형 enum 값을 찾으려면 트랜잭션 설명을 참조하십시오.
    • auth_action (enum: ADD or EDIT): 이것이 새 트랜잭션을 추가하는지 또는 기존 트랜잭션을 편집하는지 여부.
    • field (string): 주어진 특정 필드를 편집하는 인증 제약(Auth Constraint)을 설정. *는 모든 인증 규칙이 모든 필드에 적용되도록 지정하는 데 사용할 수 있습니다.
    • old_value (string; optional): 필드의 이전 값으로 new_value로 변경할 수 있습니다. auth_action에만 EDIT이 표시되어야합니다. *는 이전 값이 중요하지 않은 경우에 사용할 수 있습니다.
    • new_value (string): 필드를 채우는 데 사용할 수 있는 새로운 값. *은 이전 값이 중요하지 않은 경우에 사용할 수 있습니다.

constraint_id 필드는 작업에 대해 원하는 인증 제약(Auth Constraint)을 정의할 수 있는 위치입니다.:

  • constraint (dict)
    • constraint_id (string enum): 제약 유형(Constraint Type). 현재 다음과 같은 제약 유형이 지원됩니다.:
  - 'ROLE': 주어진 role 중 몇 개의 서명이 필요한지 정의하는 제약
  - 'OR': auth_constraints의 모든 제약 조건에 대한 논리적 분리
  - 'AND': auth_constraints의 모든 제약 조건에 대한 논리적 연결
  - 'FORBIDDEN': 허용되지 않는 작업에 대한 제약
  •  
    • 'constraint_id': 'OR' 또는 'constraint_id': 'AND'인 경우의 필드:
      • auth_constraints (list): 제약 조건 목록. 여러 개의 중첩 제약 조건이 재귀적으로 지원됩니다.
    • 'constraint_id': 'ROLE'인 경우의 필드:
      • role (string enum): 누가(어떤 role) 작업을 수행할 수 있을 것인가. 역할 코드와 이름 간의 매핑
      • sig_count (int): 작업을 수행하는 데 필요한 서명 수에 대한 NYM 트랜잭션 설명을 살펴보십시오.
      • need_to_be_owner (boolean): 사용자가 트랜잭션의 소유자여야 하는지 여부를 확인하는 플래그(예: 트랜잭션을 변경하려면 steward가 노드의 소유자여야 함). owner의 개념은 모든 인증 규칙마다 다릅니다. 자세한 내용은 auth_rules.md를 참조하십시오.
      • off_ledger_signature (boolean, optional, False by default): 원장에 없는 key에 대한 서명이 필요한 수의 유효한 서명을 검증하는 동안 승인되는지 여부. True로 설정될 수 있는 예는 비허가형(permissionless) 모드에서 새로운 DID를 작성하는 것입니다. 즉, 원장에 identifier가 없고 새로 작성된 verkey가 서명 확인에 사용되는 경우입니다. 다른 예는 암호(identifier는 verkey와 동일)로 서명하지만 아직 지원되지 않습니다. 이 필드의 값이 False(기본값)이고 필요한 서명 수가 0보다 큰 경우 트랜잭션 작성자의 DID(identifier)가 원장에 있어야합니다(NYM txn에 해당).
      • metadata (dict; optional): 제약 조건의 추가 매개 변수에 대한 사전. 플러그인에서 추가적인 제한을 설정하는 데 사용할 수 있습니다.
    • 'constraint_id': 'FORBIDDEN'인 경우의 필드: 필드가 없습니다.

예:

{  
   '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'
}

 

TRANSACTION_AUTHOR_AGREEMENT

pool에 대한 트랜잭션 작성자 계약을 설정(enabling/disablig)합니다. 트랜잭션 작성자 계약이 설정되면 Domain 원장(트랜잭션)에 대한 모든 쓰기 요청에는 트랜잭션 작성자가 서명한 최신 트랜잭션 작성자 계약의 다이제스트를 가리키는 추가 메타 데이터가 포함되어야합니다.

트랜잭션 작성자 계약이 설정되어 있지 않거나 disabled 된 경우 추가 메타 데이터가 필요하지 않습니다.

빈 텍스트로 계약을 설정하면 트랜잭션 작성자 계약을 disabled 처리할 수 있습니다.

각 트랜잭션 작성자 계약에는 고유한 버전이 있습니다.

TRANSACTION_AUTHOR_AGREEMENT txn을 제출하기 전에 원장에 최소 하나의 TRANSACTION_AUTHOR_AGREEMENT_AML을 설정해야합니다.

  • version (string): 트랜잭션 작성자 계약의 고유 버전
  • text (string): 트랜잭션 작성자 계약의 텍스트

예:

{
    "ver":1,
    "txn": {
        "type":4,
        "protocolVersion":2,

        "data": {
            "ver":1,
            "version": "1.0",
            "text": "Please read carefully before writing anything to the ledger",
        },

        "metadata": {
            "reqId":1513945121191691,
            "from":"L5AD5g65TDQr1PPHHRoiGf",
            "digest":"6cee82226c6e276c983f46d03e3b3d10436d90b67bf33dc67ce9901b44dbc97c",
            "payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
        },
    },
    "txnMetadata": {
        "txnTime":1513945121,
        "seqNo": 10,
    },
    "reqSignature": {
        "type": "ED25519",
        "values": [{
            "from": "L5AD5g65TDQr1PPHHRoiGf",
            "value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
        }]
    }
}

 

TRANSACTION_AUTHOR_AGREEMENT_AML

트랜잭션 작성자 계약에 대한 수락 메커니즘 목록을 설정합니다.

트랜잭션 작성자 계약이 수락되어야하는 각 쓰기 요청은 원장의 최신 목록에 있는 메커니즘을 가리켜야합니다. 선택된 메커니즘은 쓰기 요청 작성자(트랜잭션 작성자 계약 다이제스트와 함께)에 의해 서명됩니다.

각 수락 메커니즘 목록에는 고유한 버전이 있습니다.

  • version (string): 트랜잭션 작성자 계약 수락 메커니즘 목록의 고유한 버전
  • aml (dict): 수락 메커니즘은 <acceptance mechanism label>: <acceptance mechanism description> 형식으로 데이터를 나열합니다.
  • amlContext (string, optional): 수락 메커니즘 목록에 대한 컨텍스트 정보(외부 자원의 URL일 수 있음)

예:

{
    "ver":1,
    "txn": {
        "type":5,
        "protocolVersion":2,

        "data": {
            "ver":1,
            "version": "1.0",
            "aml": {
                "EULA": "Included in the EULA for the product being used",
                "Service Agreement": "Included in the agreement with the service provider managing the transaction",
                "Click Agreement": "Agreed through the UI at the time of submission",
                "Session Agreement": "Agreed at wallet instantiation or login"
            },
            "amlContext": "http://aml-context-descr"
        },

        "metadata": {
            "reqId":1513945121191691,
            "from":"L5AD5g65TDQr1PPHHRoiGf",
            "digest":"6cee82226c6e276c983f46d03e3b3d10436d90b67bf33dc67ce9901b44dbc97c",
            "payloadDigest": "21f0f5c158ed6ad49ff855baf09a2ef9b4ed1a8015ac24bccc2e0106cd905685",
        },
    },
    "txnMetadata": {
        "txnTime":1513945121,
        "seqNo": 10,
    },
    "reqSignature": {
        "type": "ED25519",
        "values": [{
            "from": "L5AD5g65TDQr1PPHHRoiGf",
            "value": "4X3skpoEK2DRgZxQ9PwuEvCJpL8JHdQ8X4HDDFyztgqE15DM2ZnkvrAh9bQY16egVinZTzwHqznmnkaFM4jjyDgd"
        }]
    }
}

 

Actions(액션)

action은 원장에 기록되지 않으므로 트랜잭션이 아니라 명령일 뿐입니다.

 

POOL_RESTART

POOL_RESTART는 "datetime" 필드(Trustee가 보낸)에 지정된 시간에 모든 노드를 다시 시작하는 명령입니다.

  • datetime (string): datetime  형식의 재시작 시간. 가능한 빨리 다시 시작하려면 "datetime" 필드 없이 메시지를 보내거나 이 값을 "0" 또는 ""(빈 문자열) 또는 이 장소의 과거 날짜를 입력하십시오. 재시작은 즉시 수행되며 Reply로 응답을 받을 수 있는 것은 아닙니다.
  • action (enum: start or cancel): Restart를 시작하거나 취소합니다.

예:

{
     "reqId": 98262,
     "type": "118",
     "identifier": "M9BJDuS24bqbJNvBRsoGg3",
     "datetime": "2018-03-29T15:38:34.464106+00:00",
     "action": "start"
}

 

 

반응형
저작자표시 비영리 동일조건

'Blockchain > Hyperledger Indy' 카테고리의 다른 글

[Hyperledger Indy Docs] Indy Node: 3. Default AUTH MAP Rules  (0) 2020.02.19
[Hyperledger Indy Docs] Indy Node: 2. Requests  (0) 2020.02.19
[Hyperledger Indy Docs] Indy SDK: 9. Contributing  (0) 2020.02.10
[Hyperledger Indy Docs] Indy SDK: 8. Design Documents  (0) 2020.02.10
[Hyperledger Indy Docs] Indy SDK: 4. Building Indy SDK  (1) 2020.02.10
댓글
반응형
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
TAG more
«   2024/05   »
일 월 화 수 목 금 토
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함