Crown Platform Core General Specification 1.0

First Edit: October 16, 2017

Last Edit: July 23, 2018

Status: Draft

Editors: Artem Brazhnikov

Note: All diagrams contain links to the original images

Table of Contents

1. Overview

1.1 Purpose and Scope

1.2. Terminology

Common Blockchain Terms

The Lexicon (Crown Terms)

1.3. Crown Platform Overview and Examples

Identity Registration

Crown Agent Empowering

Application Service Subscription

1.4 Conformance Statements

2. Functional Requirements

3. Non-Functional Requirements

4. Registry Subsystem

4.1. Introduction

4.2. Deposit Model

5. Decentralized Public Key Infrastructure (DPKI)

5.1. Introduction

5.2. Crown Platform Keys/Addresses Generation

5.3. Crown Platform Addresses Formats

6. Crown Platform Operational Codes

6.1. Introduction

6.2. Registration Opcodes

6.3. Signing Opcodes

7. Identities Management

7.1 Identity Registration & Verification

7.2 Identity Update

7.3 Identity Cancellation (Initiated by the owner)

7.4 Identity Revocation (Initiated by the agents)

8. Systemnodes Management

8.1 Systemnode Licensing

8.2 Systemnode User Agreement Registration

8.3 Systemnode User Agreement Signing

9. Applications Service Management

9.1 Application Service Registration & Verification

9.2 Application Service Subscription

10. Crown Platforms Agents Management

10.1 Identity Verification Agent Registration

10.2 Identity Verification Agent Revocation

10. Crown Platform Evolution of CDGP (Agents)

11. Crown Platform Core API

11.1 JSON-RPC API

11.1.1 Key Generation for specific entity type

11.1.2 Registration Commands

11.1.3 Signing Commands

11.1.4 Services Subscription

1. Overview

1.1 Purpose and Scope

This section is informative

In order to create a platform for building classic and decentralized applications it’s necessary to build a core and framework which will be the foundation for this platform.

This specification, Crown Platform General Specification 1.0, defines mechanisms and features of the Crown Platform: registry subsystem, data formats for registries, protocols of interactions between actors and applications; rules for building decentralized public key infrastructure (DPKI); Crown opcodes and transaction workflows; extension of CDGP, Crown API etc.

1.2. Terminology

Common Blockchain Terms

This specification adopts terms defined by Bitcoin project and terms defined by Dash project. The most commonly used terms in this specification include:

The Lexicon (Crown Terms)

The following terms are defined by this specification:

Crown Platform

A distributed blockchain cloud platform for building new economy applications.

Crown Platform Core (Ex-Atomic)

A system and framework of Crown platform for the development of classic and decentralized applications. Crown Platform consists of registry subsystem, Crown opcodes, DPKI, applications layer, extension of CDGP, new consensus mechanism, distributed storage, system services (NTP, multisignature communication protocol (MCP) etc.), API and it utilizes Masternodes and Systemnodes infrastructure.

Application Service Provider

A business providing computer-based services to customers over a network; such as access to a particular software application. Systemnodes can act as Application Service Providers.

Crown Platform Application Developer

A person, company or another entity which develops software using Crown development framework to run it on Crown platform.

Application Service Subscriber/User

An application service consumer which pays a subscription price to have access to the service running on Crown platform for some period of time (day, week, month, year etc.). The payment is processed via Crown blockchain.

Crown Platform Registry Subsystem

A subsystem of the Crown Platform which provides cryptographic registration infrastructure for building blockchain registries and decentralized public key infrastructure (DPKI).

Decentralized Public Key Infrastructure (DPKI)

Blockchain Registry

A set of entities with common properties registered and curated by a defined protocol in the blockchain database.

Blockchain Registry Entry/Record

A member of one of the Crown Platform registries, usually it’s a hash of the registered entity and information associated with it. It can be published, verified, updated, tracked, unregistered (revoked/released) etc.

Registry Entity

The preimage of the registrable hash and information associated with it. Usually some valuable data: an identity public key and its metadata, legal contract and its metadata etc.

Crown Address

Or simply address, is an identifier of alphanumeric characters formatted with base58 encoding. It’s similar to a physical address or an email. It’s also a hash of the public key in the pair of keys generated by Crown users to digitally sign transactions (see Public Key). There are Crown Payment Addresses and Crown Registration Addresses.

Crown Payment Address

A Crown Address begins with the number 1(P2PKH) or 3(P2SH), that represents a possible destination for a Crown payment.

Crown Registration Address

A registered Crown Address that represents a public key in the Registry subsystem. It must have various prefixes to distinguish addresses from different registries (Identity Registry etc.) Such addresses can also receive CRW as payment addresses but it’s not encouraged if there is no logical reason for that.

Crown Platform Public Key

A large numerical value generated using asymmetric-cryptography algorithms and used to protect and secure assets like CRW tokens, identities, applications, titles etc. A public key is represented as a byte stream and used as pre-image for Crown Addresses.

Crown Platform Registrant

An entity (usually person or company) who publishes, updates and removes its entry in/from one of the Crown Platform registries. Authenticity and validity of the registrants is verified by the agents.

Crown Platform Agent

A verified registrant which is empowered by CDGP to perform some useful work for the Crown Platform ecosystem. Usually, it’s verification, licensing or another process to approve or empower other registrants. To apply for agent role the registrant must be verified by the Crown Network via CDGP.

Crown Platform Eligible Voter

An actor who has a right to vote for or against empowering an agent candidate, verify a registrant if necessary, or vote about another decision in the Crown Platform ecosystem. To be an eligible voter one must prove ownership of a defined amount of tokens. Masternode Operators are eligible voters.

Crown Platform Сonsumer

A class of actors who interact with the Crown Platform system from outside of the registration lifecycle. The consumers can trust identity owners based on the information from the registry, or make sure that a legal contract has been signed by two or more entities. Application Service Subscriber is an example of the consumer.

Registry Entry Owner

An actor (usually person or company) who owns the registered entry. The ownership is determined by holding the corresponding private key. If the registered entity is a public key, then the owner’s key is a parent to the registered key. Usually, it’s the same actor as the registrant and publisher.

Registry Entity Publisher

An actor (usually person or company) who writes a new entity for the very first time into one of the Crown Platform registries. Usually, it’s the same actor as the registrant and registry entry owner.

Registry Entity Publication

The process of writing a new record representing the entity into one of the Crown Platform registries, e.g. identity publication.

Registry Entity Verification

The process of checking and approval the published entity by empowered actors (agents).

Registry Entity Registration

The two-step process of interaction with one of the Crown Platform registries which includes publication and verification.

Registration Deposit

A defined amount of coins locked in one of the Crown addresses in order to register a new entity.

Public Key Registration

Registration of an entity which is represented by a public key.

Legal Contract Registration

Registration of an entity which is represented by a legal contract.

Registered Key Signing

The process of signing a registered public key using Crown opcodes by one or more actors.

Legal Contract Signing

The process of signing a registered legal contract using Crown opcodes by one or more actors.

Identity Registry

A set of identities registered and curated by the defined protocol in the blockchain database.

Identity Verification Agent

The agent which is empowered to verify and approve new identities, their updates and revoke them if necessary.

Identity Verification

The process of confirmation that registrable identity is valid and authentic, and hence can be trusted by other Crown actors.

Identity Owner

An entity (usually person or business) which holds private key of the registered identity public key and can prove its authenticity.

Crown Server Node Licensing

The process of signing the licensing agreement between the node operator and the Crown Network.

Application Services Registry

A set of application services registered and curated by the defined protocol in the blockchain database.

Application Service Verification

Review a published application service to determine whether the service is reliable, performs as expected, does not contain malicious code, and approve the service after that, so other Crown actors can trust to run the service in their environment.

Application Service Verification Agent (App Verifier)

The agent which is empowered to verify and approve published application services.

Asset Securitization/Tokenization

Asset Custody

Asset Transfers

Verification Multisignature Transaction

Crowns Decentralized Governance Proposal System (CDGP)

The system for managing and funding the Crown Project and its ecosystem. The proposals system allows Masternodes to vote for or against any proposals, which are submitted by the Crown community. Crown uses 10% of the block reward to fund its own development. More.

Tron Masternode

A Crown Server that performs services for the network and is paid a portion of the block reward (45 %). Masternodes require proof-of-ownership of 10000 CRW.

They also provide additional level of security and stability, power InstantSend technology, the Budget System and serve as a basic layer for the Crown Platform. More.

Masternode Operator

An entity (usually person or company) responsible for a masternode instance.

Systemnode

A Crown Server on the Crown network that is secured by collateral (500 CRW) and provides services that support applications and services registered via the Crown Platform API. The operator of a Systemnode will be rewarded a portion of the block reward in return for providing those services.

Systemnode Operator

An entity (usually person or company) responsible for a systemnode instance.

1.3. Crown Platform Overview and Examples

This section is informative

Crown Platform is a Blockchain-as-a-Service cloud platform for building any new economy businesses or applications to participate in a resilient, efficient ecosystem. Crown Platform is a project to take Crown on to the next level. So, what kind of platform is that?

In the modern world, cloud computing is a very useful paradigm which enables access to shared pools of configurable resources like servers, storage, network etc. Different cloud computing providers offer different models on a “as a service” basis: Software-as-a-Service, Platform-as-a-Service, Infrastructure-as-a-Service etc. Below we show how responsibilities are divided between consumers and providers:

The Crown platform is similar to the Platform-as-a-Service approach, where Masternodes and Systemnodes provide infrastructure (virtualization, servers, storage, networking etc.) that enforces integrity and resilience and Crown Platform Core and SDKs provide software tools (middleware, runtime) to enable the creation of new economy applications. Since there is no central unit which manages all the servers, this infrastructure allows businesses to build a distributed cloud platform for development of classic and decentralized application services on top of it, using the Crown Platform.

In the simplest use case, Systemnodes act as Application Service Providers. This business model for providing services is good for a limited number of users. But such model does not scale, is not fault-tolerant and does not have other properties of the “as-a-service” approach. That’s why another, more progressive, use case is to use Systemnodes as clustered hosting providers or gateways to the Crown Platform, where they act as cluster managers or load balancers. Technologies like Docker Swarm can be used in order to create clusters behind the gateway and dynamically manage the load. Multiple Systemnodes can be connected to the same application service. Such design will let Crown act as a distributed blockchain cloud platform.

The next figure shows different components of Crown Platform Core.

There are different user stories defined here (outdated). These use cases can be combined to cover broader use cases. Some of them are represented on the next pages.

Identity Registration

To register an identity a registrant MUST follow these steps:

  1. An identity owner (or identity verifier) publishes Crown Identity address and identity information associated with it.
  2. Crown Network validates and includes the publication transaction into the ledger.
  3. The identity owner sends a notification to the identity verification agents that a new publication needs their approval (It’s not necessary if an identity verifier is a publisher of the identity).
  4. The identity verifiers check the publication, create and sign a verification transaction to finalize the registration process.
  5. The identity owner also MAY sign the verification transaction.
  6. Crown Network validates and includes the identity verification transaction into the ledger.

After the identity verification transaction has enough confirmations, it’s considered authentic and can be trusted by other actors. The next figure shows the identity registration process as an activity diagram.

Crown Agent Empowering

To run application services registered on the Crown Platform, a Systemnode operator must be verified and MUST sign the licensing agreement first. Identity Verification Agents are responsible for this job. The identity verification permission can be assigned to a candidate who applies to this role. To become an agent, the candidate should follow these steps:

  1. An agent candidate MUST have its identity registered.
  2. Create a proposal to assign an Identity Verification Agent role to himself and in some cases for funding a non-profit business associated with the identity.
  3. Crown Network validates and includes proposal transaction into the ledger.
  4. The agent candidate submits proposal for voting
  5. Eligible voters check the agent candidate and its identity, study the proposal and vote for or against empowering the agent
  6. If the proposal has enough votes the identity registrant becomes an agent.

Application Service Subscription

To subscribe to a service, user follows these steps:

  1. A user initiates an application service subscription.
  2. The application service or a 3rd party sends an API request to a licensed Systemnode.
  3. The licensed Systemnode generates a payment request for the user.
  4. The user confirms the payment.
  5. Crown Network validates and includes the payment transaction into the ledger.
  6. The application service owners verifies the payment.
  7. The application service owner provides access to the service.

The user now is subscribed to the service and can use it for the paid period of time. The next figure shows the subscription process as an activity diagram.

The whole ecosystem of the Crown Platform and interactions between different parts is represented in the next figure.

1.4 Conformance Statements

The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].

All sections of this specification are normative except where identified by the informative status label "This section is informative". The application of informative status to sections and appendices applies to all child content and subsections they may contain.

All examples in this specification are informative.

2. Functional Requirements

3. Non-Functional Requirements

4. Registry Subsystem

4.1. Introduction

This section is informative

To become a part of the Crown ecosystem, an application service must be registered in with Crown. In order to do this the Crown Platform provides cryptographic registration infrastructure. It allows not only a way to build a set of application services but also creates an opportunity to build other sets with common properties. Each of these set members becomes a part of the Crown blockchain and hence, cannot be removed from the history or modified without permissions of the set member owner(s). These sets can be named blockchain registries or just simply registries. The set members are registry entries or records. Crown Platform provides an opportunity to build Application Services Registry, Identities Registry, Titles Registry etc.

The registries architecture is the natural development of the Skeleton Keys ideas described in the Introduction & Features Crown paper. Each registry entry can be identified by a hash. It may also contain other information associated with a hash, like name and metadata. The most important part in building registries is hash preimage. It can be a public key or a contract in any jurisdiction, or almost anything else that needs to be registered in the blockchain. The real power of this mechanism appears when hash preimage is a public key. It creates an opportunity to create associative public keys model which can be utilized to build a decentralized public key infrastructure (DPKI) in the future. The public keys registered on the blockchain can be represented as Crown addresses, but to differentiate them from the original ones, they should have a special prefix that represents their belonging to that registry. To distinguish one address type from another it’s important to introduce two notions: Crown Payment Address and Crown Registration Address. Crown Payment Address — is an ordinary Crown address. Crown Registration Address — is a registered hash of a public key (Crown Public Key). It can also receive payments as an ordinary address, but it’s not encouraged if there is no logical reason for that.

4.2. Deposit Model

This section is informative

In order to create a new record in one of the Crown Platform registries, a publisher must make a deposit in Crown tokens (CRW). The deposit must be sent to a multisignature address or another Crown address which will be the owner of the new registry entry. The deposit also can be named — a locked amount of the tokens. It must never go lower than the defined number during the registry entry lifetime. Value of the locked tokens should be specified for each registry. If the amount is too small, the registry transaction will be rejected. The deposit must be high enough to prevent the system from bad actors and DDoS attacks, but not too big to be unaffordable for consumers. It can be released anytime when the owner does not need the registered entry in the blockchain anymore and sent to any address. The entry will stay in the history, but won’t be active. The registries architecture provides an ability for the agents to revoke registered keys and deregister other hashes, if their owners start behaving dishonestly. During the revocation process, they also withdraw the deposit from the locked address and distribute it between agents’ addresses. It has two implications. First: a publisher will lose the deposit if he/she is trying to register malicious/”bad” entry (e.g. fake identity). An attacker knows that and won’t publish knowingly invalid/fake data because his financial assets will be forfeited. And second: this model incentivizes verification agents to deliberately check published entities (e.g. identities, application services etc.) for intentionally or unintentionally invalid data. If the registrant’s entity is malicious (e.g. fake identity, malicious application service etc.) it will be rejected and the locked CRW will be withdrawn to the agents’ addresses for their efforts (they also can be incentivized by the Crown budget and verification fees, so there are different business models that can attract businesses to become Crown Platform agents). If a registrant puts invalid data into a registry accidentally, it can be fixed by the owner and re-verified by the agents. The revocation/deregistration can be performed at any stage of a registry entry lifecycle.

Another possible DDoS attack vector (flood attack) is a massive generation of publication and deregistration transactions without a heavy financial loss for the adversary. If he/she holds big enough amount of Crown tokens, it’s possible to send many spamming transactions at the same time with a minimum transaction fee. The deposits can be locked, unlocked and then reused in another spamming round. Even though, presumably, the attacker will run out of money sooner or later and “good” transactions will be prioritized by time to be included in a block, it makes sense to add another protection level. The solution is to raise transaction fee that it is affordable for “good” users and a crucial loss for the adversary. The fee can be 10% of the deposit amount for the publication and deregistration transactions and can be distributed between the verification agents. This is a low fee for a registrant who wants to register one or several entities, but it will kill any DDoS attack.

For example, it is unlikely that one entity (e.g. individual or business) will need to register more than one identity. Let’s say the deposit for such registry is set to 100 CRW. This is a small amount for one registration, but it’s a big number for an adversary to perform a DDoS attack or try to publish fake identities. 10% of this deposit is 10 CRW on the publication and 10 CRW on the deregistration stage. Every individual or business can afford to pay this one time fee, but an attacker will run out of tokens very fast. In this case, a publisher must deposit at least 110 CRW. Eventually, in a normal workflow, a registrant will get 90 CRW back.

This deposit model also will make registrants release locked tokens if they don’t use the registered entity anymore, but at the same time, they won’t deregister it without a good reason because of the high transaction fee. It will help keeping registered entities active in the system which are really in use and help to deactivate unused entities which just wastes computational resources.

Access to this infrastructure is provided to application developers via the Crown Platform API.

5. Decentralized Public Key Infrastructure (DPKI)

5.1. Introduction

This section is informative

One of the most important things about building registries using public keys is utilizing their cryptographic nature. Any of the agents who are empowered to do some job in the network can convey their will by signing a transaction in the blockchain. In the common case when a registrant publishes a new public key entity to be verified by the agents, it needs to assign it to specific agents. After the verification process, the agents express their decision by signing the entry in the registry. If the quorum has been reached, the entity is considered verified and it can be trusted by other parties. The owner of the registry entry is usually also a part of the quorum. It’s used for proving ownership of the entity, initiate and verify modifications, and have the opportunity to initiate deregistration process. The quorum needed for approval is defined by a multisignature N-of-M. The higher the N number the more decentralized decision is. In the real world though it’s necessary to find a trade-off between ultimate decentralization and a sufficient number of agents.The starting point could be 3-of-5 multisignature and 2-of-3 for the testing period.

Another separate use case is when a registrant publishes a new entity and assigns it just to itself. To verify that publication, only the signature of the registry entry owner is necessary. An entity registered that way should not be trusted by other parties unless that entity is an empowered agent. It can be used for testing purposes or for agent registration. It can be thought of like a self-signed certificate in a classic public key infrastructure.

It’s important to note that a registry entry owner and a publisher can be different entities. Anyone can publish a new entity and assign it to someone. But only after the verification process can it be considered authentic and valid.

Entities with common properties can compose registries where public keys are used to identify and prove ownership of these entities. Other cryptographic properties can also be utilized in different ways. As mentioned earlier, it’s possible to create an associative model of public keys based on cryptographic registration infrastructure. A public key from one registry can be associated with a key from another one in order to build a PKI without central authorities. Instead, a decentralized mechanism is used where a key to be trusted needs to be signed by a defined number of the agents, who in its turn are empowered and certified by the whole Crown Network. The agents’ public keys can be thought of as root certificates in classic PKI, but they cannot certify other keys in isolation from other agents. It’s important to note here that agents are usually empowered to certify only a specific class of registrants’ public keys — the keys from one registry. It’s possible to assign rights to sign keys from multiple registries, but the concentration of power of the same agents is not encouraged. It can be used in the beginning though when the network of the agents is not big enough.

For example, Identities Registry can be constructed by registering public keys and identity metadata associated with it. They are verified by a defined number of the agents. It creates a layer for building PKI trees where certified identity keys act as root keys. Public keys from other registries can be associated with identities, e.g. application service can be published as a child key to an identity key. To be verified the service key must be signed by the identity and agents empowered for application verification. It creates a structure where entities from different registries can be certified in a decentralized way and compose a tree where a person or a business can always be identified and proved by cryptographic mechanisms. It constructs a good foundation and infrastructure for transparent, lawful and secure operations for businesses on top of blockchain technology.

The next picture shows relationships between keys in the Crown registration transactions in order to build DPKI.

5.2. Crown Platform Keys/Addresses Generation

The Crown Platform addresses generation MUST meet following properties:

  • Crown Platform addresses can be generated at no cost by any user of Crown, in the similar way as Crown Payment addresses.
  • Unlike the payment addresses, Crown Platform addresses are not intended to be unique for each transaction, but instead SHOULD be generated only for each publication transaction.
  • To include a Crown Platform address into DPKI, it MUST be derived from a registered public key.
  • In order to build a trustful public keys tree, root key SHOULD be a registered identity key

5.3. Crown Platform Addresses Formats

  • Each Crown Platform address MUST have its role and belonging to a registry, e.g. Application Services Registry, Identities Registry, Titles Registry etc.
  • Crown Registration addresses MUST have various prefixes to distinguish them from Crown payment addresses and from each other (different registries).
  • Crown Platform addresses SHOULD use Base58Check encoding to represent hashes of registrable public keys.
  • Crown Platform addresses MUST meet following format criteria:

Address type

Hex prefix

Leading symbols

Address example

Identity Address

0174F5

CRP

CRP7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

Identity Test Address

017ACD55

tCRP

tCRP7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

App Service Address

0174D5

CRA

CRA7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

App Service Test Address

017ACD35

tCRA

tCRA7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

Title Address

0174FF

CRT

CRT7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

Title Test Address

017ACD5F

tCRT

tCRT7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

Standard Payment Address

017506

CRW

CRW7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

Standard Payment Test Address

017ACD66

tCRW

tCRW7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

6. Crown Platform Operational Codes

6.1. Introduction

This section is informative

The Crown Platform operational codes (opcodes) are building blocks of cryptographic registration infrastructure. They are used in the creation of the transactions to operate on registry entries. The opcodes provide an ability to register (publish/verify), unregister (release/revoke), sign, track registry records. There are two types: registration and signing opcodes. The first one is used to form and curate registries. The second one is an auxiliary mechanism, which is used for signing registered entities.

6.2. Registration Opcodes

Each of the next opcodes MUST be implemented in Crown Core in order to build cryptographic registration infrastructure.

OP_REG_NEW

Motivation: Opportunity to publish new registry entities in the blockchain, and then verify, track, update, release, revoke them etc.

Opcode: <Owner Address(es)> OP_REG_NEW (hash/address, name, data)

Workflow Rules: Inputs: 0 OP_REG on this hash → Output: OP_REG_NEW → Next Output: OP_REG_VERIFY | OP_REG_UPDATE | OP_REG_DUP | Unregister Entity

OP_REG_VERIFY

Motivation: Verify/approve (by signing a new registry entry). Need to sign the registered entity by its owners. OP_REG_UPDATE also can be used to verify the entity, but the data will be duplicated in this case.

Opcode: <Owner Address(es)> OP_REG_VERIFY (hash/address, hash(name, data))

Workflow Rules: Inputs: 1 OP_REG_NEW on this hash → Output: OP_REG_VERIFY → Next Output: OP_REG_UPDATE | OP_REG_DUP | Unregister Entity

Note: Verification step can be skipped if all the entity owners (including verifiers) have signed the OP_REG_NEW transaction

Note: The same instruction number as OP_REG_DUP.

OP_REG_DUP

Motivation: Can be used to duplicate previous OP_REG output in case if OP_REG tx output needs to be spent but keep the registered entity without any changes. OP_REG_UPDATE also can be used to verify the entity, but the data will be duplicated in this case.

Opcode: <Owner Address(es)> OP_REG_DUP (hash/address, hash(name, data))

Workflow Rules: Inputs: 1 of OP_REG_NEW | OP_REG_VERIFY | OP_REG_UPDATE | OP_REG_DUP on this hash → Output: OP_REG_DUP → Next Output: OP_REG_UPDATE | OP_REG_DUP | Unregister Entity

Note: The same instruction number as OP_REG_VERIFY.

OP_REG_UPDATE

Motivation: Update name, or/and data, or/and hash (if it’s not an address) of the registered entity. Verify/approve changes of the registered and verified entity.

Opcode: <Owner Address(es)> OP_REG_UPDATE(hash/address, name, data)

Workflow Rules: 1 of OP_REG_NEW | OP_REG_VERIFY | OP_REG_UPDATE | OP_REG_DUP → OP_REG_UPDATE → OP_REG_UPDATE | OP_REG_DUP | Unregister Entity

Unregister Entity (key/hash)

Motivation: Unregister registered entities (remove a hash from the list of tracked entities), release tokens locked in the Owner Address(es). Possible reasons: cancel by issuer before verification, release by owner, revoke by agents etc.

Opcode: Ordinary Crown payment transaction which releases locked coins.

Workflow Rules: Inputs: 1 of OP_REG_NEW | OP_REG_VERIFY | OP_REG_UPDATE | OP_REG_DUP on this hash → Unregister Entity

OP_REG opcodes technical workflow.png

OP_REG opcodes logical workflow.png

6.3. Signing Opcodes

Each of the next opcodes MUST be implemented in Crown Core in order to build cryptographic registration infrastructure.

OP_SIG_NEW

Motivation: Opportunity to publish new signings (contract signings/keysignings) of registered entities, and then sign, track, update, terminate them etc.

Opcode: <Owner Address(es)> OP_SIG_NEW (registered_entry)

Workflow Rules: Inputs: 0 OP_SIG on this entity → Output: OP_SIG_NEW → Next Output: OP_SIG_VERIFY | OP_SIG_UPDATE | OP_SIG_DUP | Unregister Signing

OP_SIG_VERIFY

Motivation: To verify/sign the published signings (contract signings/keysignings).

Opcode: <Owner Address(es)> OP_SIG_VERIFY (registered_entry)

Workflow Rules: Inputs: 1 OP_SIG_NEW on this entity → Output: OP_SIG_VERIFY → Next Output: OP_SIG_UPDATE | OP_SIG_DUP | Unregister Signing

Note: Verification step can be skipped if all the signing owners have signed the OP_SIG_NEW transaction.

Note: The same instruction number as OP_SIG_UPDATE and OP_SIG_DUP.

OP_SIG_DUP

Motivation: Can be used to duplicate previous OP_SIG output in case if OP_SIG tx output needs to be spent but keep the registered signing without any changes.

Opcode: <Owner Address(es)> OP_SIG_DUP (registered_entry)

Workflow Rules: Inputs: 1 of OP_SIG_NEW | OP_SIG_VERIFY | OP_SIG_UPDATE | OP_SIG_DUP on this entity  → Output: OP_SIG_DUP → Next Output: OP_SIG_UPDATE | OP_SIG_DUP | Unregister Signing

Note: The same instruction number as OP_SIG_UPDATE and OP_SIG_VERIFY.

OP_SIG_UPDATE

Motivation: Re-sign contract signing/keysigning if the registered entry has been changed.

Opcode: <Owner Address(es)> OP_SIG_UPDATE(registered_entry)

Workflow Rules: 1 of OP_SIG_NEW | OP_SIG_VERIFY | OP_SIG_UPDATE | OP_SIG_DUP → OP_SIG_UPDATE → OP_SIG_UPDATE | OP_SIG_DUP | Unregister Signing

Note: The same instruction number as OP_SIG_DUP and OP_SIG_VERIFY.

Terminate Contract/Unregister Signing

Motivation: Terminate a contract/unregister a signing (remove from the list of tracked signings), release coins locked in the Owner Address(es).

Opcode: Ordinary Crown payment transaction which releases locked coins.

Workflow Rules: Inputs: 1 of OP_REG_NEW | OP_REG_VERIFY | OP_REG_UPDATE | OP_REG_DUP on this entity → Unregister Signing

OP_REG opcodes logical workflow.pngOP_SIG opcodes technical workflow.png

7. Identities Management

7.1 Identity Registration & Verification

  1. Identity owner creates a transaction Tx1.
  2. At least one output Tx1.Out1 MUST contain OP_REG_NEW opcode with a new Crown Identity Address. The recipient in that output MUST be a Multisignature address.The multisignature must require at least 2-of-3 signatures. It SHOULD be expanded to 3-of-5 or more in the future to achieve better security and decentralization.
  3. In case of 2-of-3 multisig, exactly one key MUST be the same Crown Identity Address, and two other keys MUST be Identity Addresses of ID Verification Agents
  4. The Identity Publisher MAY also create another output with a Change Address.
  5. The transaction MUST be broadcasted to the network.
  6. The holders of the Agents’ Identity Verification Keys MUST receive a notification in their wallet, or in some other way that a new identity needs their verification.
  1. In the 1st iteration of the algorithm the Identity Publisher MUST contact Identity Verifiers directly and send them Tx1 transaction id or a partially signed transaction.
  1. The Identity Verifiers look at the transaction Tx1 in the ledger and perform necessary steps to verify the registered identity (request ID card, initiate webcam session etc.). For now the Identity Owner must provide this information directly to the Identity Verifier via secure channel.
  2. If authenticity of the identity has been proved, the Identity Verifiers both create new transactions Tx2Ver1 and Tx2Ver2 separately, connected to Tx1.Out1.
  3. Exactly one output in these transactions MUST contain OP_REG_VERIFY opcode and the same Identity Key: Tx2Ver1.Out1 and Tx2Ver2.Out1.
  4. Crown Platform Identity Keys are not transferable, so the recipient in these output MUST be the same Multisignature address.
  5. The Identity Verifiers also MAY add outputs to take payment for identity verification services: Tx2Ver1.Out2 and Tx2Ver2.Out2 with their Payment Address.
  6. Both Identity Verifiers MUST sign transactions Tx2Ver1 and Tx2Ver2 with their private keys corresponding to the Agents Identity Verification Keys and send the partially signed transactions to the Identity Owner.
  7. The Identity Owner MUST verify the transactions and sign one of them which looks the most profitable to him/her.
  8. The signed transaction MUST be broadcasted to the network.
  9. After the transaction is included into the blockchain and has enough confirmations, the Identity is considered verified.

An example of an ID registration using JSON-RPC API:

register publish id CRP7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem(Dev-ID) CRP7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem “Legal-Business-LLC” {id-metadata} --verifiers CRPrivnXzjwXtG5jz1au25f9eitqepBQB1qu(ID-Ver) CRPG7ujrsky7xFokf1fVB2rdp4gEkdcdo4xV(ID-Ver) --min-sig-number 2

register verify id CRP7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem

Some slight changes in the algorithm are possible. For example, the initiator of verification transaction can be an Identity Owner instead of an Identity Verifier. Or the verification also possible without the Identity Owner signature, but between 2 Identity Verifiers. The goal is to expose just one algorithm, but make sure all possible scenarios are secure. There is also an idea that in the verification/update transactions one of the signer is always an Identity Owner, but the revocation transaction may be signed by any 2 parties.

7.2 Identity Update

7.3 Identity Cancellation (Initiated by the owner)

7.4 Identity Revocation (Initiated by the agents)

8. Systemnodes Management

8.1 Systemnode Licensing

Preconditions

  1. A Universal License Agreement for Systemnodes MUST be registered.
  2. Systemnode operator MUST have a registered and verified Identity Key.

Algorithm:

  1. Systemnode Operator MUST have the Universal License Agreement document.
  2. Systemnode Operator MUST find the Universal License Agreement hash in the blockchain and verify the document has not been changed.
  3. Systemnode Operator creates a transaction Tx1.
  4. At least one output Tx1.Out1 MUST contain OP_SIG_NEW opcode with the hash of the registered Universal License Agreement.
  5. The owner of the signing can be a standard address or a multisig address, but, exactly one key MUST be the Identity Key which belongs to the Systemnode Operator.
  6. Systemnode Operator MAY also create another output with a Change Address.
  7. The transaction MUST be broadcasted to the network.
  8. The Systemnode Operator  MUST create a new transaction Tx2 with OP_SIG_VERIFY connected to Tx1.Out1.
  9. The signed transaction MUST be broadcasted to the network.
  10. After the transaction is included into the blockchain and has enough confirmations the Systemnode is considered licensed.

Systemnode Licensing example using JSON-RPC API:

Universal License Agreement registration:

register publish notary CRP2VEhusamhxSa9p9stTLe7viJc75gXYbJU 8A8B430BB3653A568B87EC4D6C6813E39C82734D946845388FA9EB3689FA6948 “Universal-Licensing-Agreement” {notary-metadata} --finite

Systemnode Licensing:

signing publish notary CRPBmXi5oihdKwKXkEowoZCTvkWPPHVyuE1e(SN-ID) 8A8B430BB3653A568B87EC4D6C6813E39C82734D946845388FA9EB3689FA6948

signing verify notary 8A8B430BB3653A568B87EC4D6C6813E39C82734D946845388FA9EB3689FA6948

8.2 Systemnode User Agreement Registration

Preconditions

  1. Systemnode operator MUST have a registered and verified Identity Key.
  2. Systemnode MUST sign the Universal License Agreement.

Algorithm:

  1. Systemnode Operator MUST have a prepared Systemnode User Agreement document.
  2. Systemnode Operator MUST calculate hash of the User Agreement.
  3. Masternode Operator MUST create a new transaction Tx1.
  4. At least one output of Tx1.Out1 MUST contain OP_REG_NEW opcode with the User Agreement hash, its name and metadata. The owner in the transaction output MUST be the Identity Key of the Systemnode Operator.
  5. The transaction inputs MAY contain any number of valid Crown Addresses.
  6. The transaction previous outputs SHOULD NOT contain any OP_REG opcodes.
  7. The signed transaction MUST be broadcasted to the network.
  8. After the transaction is included into the blockchain and has enough confirmations the agreement is considered registered.

Systemnode User Agreement Registration:

register publish notary CRPBmXi5oihdKwKXkEowoZCTvkWPPHVyuE1e(SN-ID) 6A72C91ACED0FC66D4A811A8A634147C166E406400D0DA1D5ED06ACEF2F6627D “My-User-Agreement” {notary-metadata}

8.3 Systemnode User Agreement Signing

Preconditions:

  1. Systemnode MUST sign the Universal License Agreement.
  2. Systemnode MUST register a Systemnode User Agreement.
  3. Application Developer MUST have a registered and verified Application Key.

  1. Application Developer MUST have the Systemnode User Agreement document.
  2. Application Developer MUST find the Systemnode User Agreement hash in the blockchain and verify the document has not been changed.
  3. Application Developer creates a transaction Tx1.
  4. At least one output Tx1.Out1 MUST contain OP_SIG_NEW opcode with the hash of the registered Systemnode User Agreement. The owners in the Tx1.Out1 output MUST be the Identity Key of the Systemnode Operator and the Application Key.
  5. The transaction Tx1 must be broadcasted to the network.
  6. Systemnode Operator MUST receive the Tx1 hash or notification in the wallet.
  7. Systemnode Operator MUST verify the App Key is registered and verified.
  8. Systemnode Operator MUST verify the parent of the App Key is and Identity Key which is registered and verified.
  9. Systemnode Operator MUST check the User Agreement hash is correct.
  10. Systemnode Operator MUST create a new signing transaction Tx2 with OP_REG_VERIFY opcode connected to the Tx1.Out1.
  11. Application Developer MUST receive the Tx2 or notification in the wallet.
  12. Application Developer MUST sign the Tx2 with the App Key.
  13. The transaction Tx2 must be broadcasted to the network.
  14. After the transaction Tx2 is included into the blockchain and has enough confirmations the agreement is considered signed.

Systemnode User Agreement signing example using JSON-RPC API:

signing publish notary CRPBmXi5oihdKwKXkEowoZCTvkWPPHVyuE1e(SN-ID) 6A72C91ACED0FC66D4A811A8A634147C166E406400D0DA1D5ED06ACEF2F6627D --signers CRAL5RwFqyxrJUUBXQm1cvNcg6zifATqZ3mF(App-Key) --min-sig-number 2

signing verify notary 6A72C91ACED0FC66D4A811A8A634147C166E406400D0DA1D5ED06ACEF2F6627D --min-sig-number 1

9. Applications Service Management

9.1 Application Service Registration & Verification

Note: Similar to the Identity Registration & Verification. 

Application Service Registration example using JSON-RPC API:

register publish service CRP7VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem(Dev-ID) CRAL5RwFqyxrJUUBXQm1cvNcg6zifATqZ3mF(App-Key) “My-App-Service” {app-metadata} --verifiers CRPrivnXzjwXtG5jz1au25f9eitqepBQB1qu(App-Ver) CRPG7ujrsky7xFokf1fVB2rdp4gEkdcdo4xV(App-Ver) --min-sig-number 2

register veirfy service CRAL5RwFqyxrJUUBXQm1cvNcg6zifATqZ3mF(App-Key)

9.2 Application Service Subscription

Preconditions:

  1. Application Developer MUST have registered and verified Crown Application Key.
  2. Application Developer MUST sign a Systemnode User Agreement with the Systemnode Operator to which Systemnode(s) that application will be assigned and hosted.

Subscription to a service SHOULD be initiated by a user or a by an application. The first subscription MUST be initiated by a user. All subsequent subscriptions MAY be initiated by a user or an application.

Initiated by a user:

  1. A user SHOULD initiate a subscription request from either a Service Portal operated by a Masternode Operator, or an Application Portal, operated by an Application Developer, or a Network Portal operated by a 3rd party entity supporting the Crown Network (App Store).
  2. The subscription request MAY be paid directly to the service owner (for the service) and the Systemnode Operator (for hosting), or escrowed (2-of-3, 3-of-5), or deposited with the Locktime transaction.
  1. In case of the direct payment: the subscription request MUST contain two outputs with the Application Service Payment Address and the Systemnode Address. The payment MUST be split between them.
  2. In case of the escrow 3-of-5: the contract MUST contain a User Key (Payment Address), Application Key, Systemnode Key and 2 Arbitrator Keys. 2-of-3: User Key, Application Key and Arbitrator Key.
  1. The subscription request MUST be sent to the user’s wallet for signing.
  2. The signed transaction MUST be broadcasted to the network.
  3. After the transaction is included into the blockchain and has enough confirmations, the user is considered subscribed to the service for a defined period of time.

After the subscription time is over, the Application Service Provider/Developer MAY request the payment for the same period of time. If the user wants to continue using the service, he/she needs to confirm the payment in their wallet.

Application Service Subscription example using JSON-RPC API:

10. Crown Platforms Agents Management

10.1 Identity Verification Agent Registration

10.2 Identity Verification Agent Revocation

10. Crown Platform Evolution of CDGP (Agents)

In order to build a decentralized registry system where agents are empowered to accept or reject new registrants, the CDGP must be extended. Currently, it only supports proposals for budget distribution. The goal is to create a governance system where different types of proposals about the future of Crown platform and its ecosystem can be posted. One of the most important mechanisms which should be a part of the CDGP is assigning roles to different entities (agents empowering).

As mentioned in the actors’ section, it’s possible that the system does not have a quorum of the agents to approve a registrant. In this case, responsibility for an agent identity verification before empowering is also a part of work for the eligible voters. It means that in some situations an agent role can be assigned to a not verified registrant. Strictly speaking, the process of empowering for both cases is not really different for the eligible voters. It’s very responsible step to assign a role to someone in the Crown ecosystem. If an entity applies to become an Identity Verification Agent, it will have access to personal data of registrants. That’s why all eligible voters must check agents deliberately before assigning such role to them. Any voter can request information from an agent and verify this information inside and outside of the blockchain.

11. Crown Platform Core API

The API is a way to interact with the Crown Platform Core from application/services and other 3rd parties. It will provide an interface to the Crown Platform via Systemnodes. The API will give access to application/service registration/publishing, deployment, subscription, monitoring, billing, payments etc.

11.1 JSON-RPC API

11.1.1 Key Generation for specific entity type

genkey {type}

type

{

id,

service,

title,

notary,

proof

}

11.1.2 Registration Commands

register {subcommand:action} {type} args

action

{

publish,

verify,

update,

revoke

}

PUBLICATION:

register publish {type} owner-address(required) registration-hash/address(required) data(optional)

result:  {txhash}

register publish id short-id-name(required) -c --co-owners/-v --verifiers list, -n --min-sig-number N

result:  {txhash}

register publish service short-svc-name(required) -c --co-owners/-v --verifiers list, -n --min-sig-number N

result:  {txhash}

register publish title short-title-name(required) -c --co-owners/-v --verifiers list, -n --min-sig-number N

result:  {txhash}

register publish notary -c --co-owners/-v --verifiers list, -n --min-sig-number N, -f --finite

result:  {txhash}

register publish proof -u --user-address user-address, -f --finite          result:  {txhash}

VERIFICATION:

register verify {type} registration-hash/address(required)

result: {multisig-result, txhash or incomplete-tx}

UPDATE:

register update {type} registration-hash/address(required)

register update id -r --rename new-short-id-name, -d --data data

register update service -r --rename new-short-svc-name, -d --data data

register update notary -p --proof new-proof-hash, -d --data data, -f --finite

register update proof -p --proof new-proof-hash, -d --data data, -f --finite

result: {multisig-result, txhash or incomplete-tx}

REVOCATION:

register revoke {type} registration-hash/address(required) -r --reason revoke-reason(required)

result: {multisig-result, txhash or incomplete-tx}

11.1.3 Signing Commands

signing {subcommand:action} {type} args

PUBLICATION:

signing publish {type} initiator-owner-address(required) verified-registered-hash/address(required) -s --signers list, -n --min-sig-number N, -w --at-will

result: {txhash}

VERIFICATION:

signing verify {type} verified-registered-hash/address(required), -n --min-sig-number N, -w --at-will

result: {multisig-result, txhash or incomplete-tx}

UPDATE:

signing update {type} updated-verified-registered-hash/address(required), -n --min-sig-number N, -w --at-will

result: {multisig-result, txhash or incomplete-tx}

REVOCATION:

signing revoke {type} verified-registered-hash/address(required) -r --reason revoke-reason(required)

result: {multisig-result, txhash or incomplete-tx}

11.1.4 Services Subscription

service subscribe app-address -p --period subscription-period(required) -s --subscriber user-address -e --escrow arb-address (if not specified - the payment is made directly)

result: {txhash}